I became suspicious that I should have received a certain message, and reading pm.log I discovered that it had indeed arrived and had been allocated to /var/mail/anne, despite procmailrc telling it that
MAILDIR=/home/anne/Maildir/
Any idea what might have caused this? It seems to have been working like this only in the last 24 hours or so.
Anne
On Wednesday 22 December 2010 13:33:10 Anne Wilson wrote:
I became suspicious that I should have received a certain message, and reading pm.log I discovered that it had indeed arrived and had been allocated to /var/mail/anne, despite procmailrc telling it that
MAILDIR=/home/anne/Maildir/
Any idea what might have caused this? It seems to have been working like this only in the last 24 hours or so.
Also, since /var/mail/anne is mbox and /home/anne/Maildir/ is maildir, I need to find a way of getting the messages into the correct directory. I could clip them into separate files, but I assume that the cryptic names of files are used for indexing.
Anne
On Wed, 22 Dec 2010, Anne Wilson wrote:
On Wednesday 22 December 2010 13:33:10 Anne Wilson wrote:
I became suspicious that I should have received a certain message, and reading pm.log I discovered that it had indeed arrived and had been allocated to /var/mail/anne, despite procmailrc telling it that
MAILDIR=/home/anne/Maildir/
Any idea what might have caused this? It seems to have been working like this only in the last 24 hours or so.
Also, since /var/mail/anne is mbox and /home/anne/Maildir/ is maildir, I need to find a way of getting the messages into the correct directory. I could clip them into separate files, but I assume that the cryptic names of files are used for indexing.
There are a few things that are likely to cause the symptoms you describe:
1. Lax permissions on ~/.procmailrc: make sure that file isn't accessible by group or world (0600 works for me).
2. Lax permissions on your $HOME. Procmail gets picky when things are group-writeable.
3. SELinux issues. Run "ausearch -m avc | grep procmail" to see if anything needs to be relabeled.
/var/log/maillog will usually supply part of the answer as well.
On Wednesday 22 December 2010 16:51:02 Paul Heinlein wrote:
On Wed, 22 Dec 2010, Anne Wilson wrote:
On Wednesday 22 December 2010 13:33:10 Anne Wilson wrote:
I became suspicious that I should have received a certain message, and reading pm.log I discovered that it had indeed arrived and had been allocated to /var/mail/anne, despite procmailrc telling it that
MAILDIR=/home/anne/Maildir/
Any idea what might have caused this? It seems to have been working like this only in the last 24 hours or so.
Also, since /var/mail/anne is mbox and /home/anne/Maildir/ is maildir, I need to find a way of getting the messages into the correct directory. I could clip them into separate files, but I assume that the cryptic names of files are used for indexing.
There are a few things that are likely to cause the symptoms you describe:
- Lax permissions on ~/.procmailrc: make sure that file isn't accessible by group or world (0600 works for me).
It was 0700 - I've changed it to 0600.
- Lax permissions on your $HOME. Procmail gets picky when things are group-writeable.
The directory itself is not group- or world-writable. There are one or two files inside that are group-writable, but most aren't. I could change those, I suppose, but they are nothing related to the mail system.
- SELinux issues. Run "ausearch -m avc | grep procmail" to see if anything needs to be relabeled.
I'm not running SELinux
/var/log/maillog will usually supply part of the answer as well.
There's nothing obvious, at first scan. Everything seems to be "Delivered to command /usr.bin/procmail" which of course is correct. The only messages affected are thos which should be in my Inbox, having failed to match any recipe.
Anne
On 12/22/2010 11:19 AM, Anne Wilson wrote:
/var/log/maillog will usually supply part of the answer as well.
There's nothing obvious, at first scan. Everything seems to be "Delivered to command /usr.bin/procmail" which of course is correct. The only messages affected are thos which should be in my Inbox, having failed to match any recipe.
If you have VERBOSE on in your .procmailrc it should log what it does with each message.
On Wed, 22 Dec 2010, Les Mikesell wrote:
On 12/22/2010 11:19 AM, Anne Wilson wrote:
/var/log/maillog will usually supply part of the answer as well.
There's nothing obvious, at first scan. Everything seems to be "Delivered to command /usr.bin/procmail" which of course is correct. The only messages affected are thos which should be in my Inbox, having failed to match any recipe.
If you have VERBOSE on in your .procmailrc it should log what it does with each message.
I usually don't rely on user .procmailrc files to specify INBOX locations. Instead, I set the DEFAULT variable in /etc/procmailrc, e.g.,
# /etc/procmailrc DEFAULT=$HOME/Maildir/
On Wednesday 22 December 2010 17:39:56 Paul Heinlein wrote:
On Wed, 22 Dec 2010, Les Mikesell wrote:
On 12/22/2010 11:19 AM, Anne Wilson wrote:
/var/log/maillog will usually supply part of the answer as well.
There's nothing obvious, at first scan. Everything seems to be "Delivered to command /usr.bin/procmail" which of course is correct. The only messages affected are thos which should be in my Inbox, having failed to match any recipe.
If you have VERBOSE on in your .procmailrc it should log what it does with each message.
I usually don't rely on user .procmailrc files to specify INBOX locations. Instead, I set the DEFAULT variable in /etc/procmailrc, e.g.,
# /etc/procmailrc DEFAULT=$HOME/Maildir/
Interesting. I don't have an /etc/procmailrc. Are there other things you'd recommend to place there?
Anne
On Wed, 22 Dec 2010, Anne Wilson wrote:
# /etc/procmailrc
DEFAULT=$HOME/Maildir/
Interesting. I don't have an /etc/procmailrc. Are there other things you'd recommend to place there?
That's all I put in there. It may be worthwhile to take a peek at the "Environment variable defaults" section of the procmailrc(5) man page.
Note that /etc/procmailrc is often executed as root, not $USER, so I tend to avoid putting anything but variable definitions in it.
On Wednesday 22 December 2010 18:35:29 Paul Heinlein wrote:
On Wed, 22 Dec 2010, Anne Wilson wrote:
# /etc/procmailrc
DEFAULT=$HOME/Maildir/
Interesting. I don't have an /etc/procmailrc. Are there other things you'd recommend to place there?
That's all I put in there. It may be worthwhile to take a peek at the "Environment variable defaults" section of the procmailrc(5) man page.
OK, I'll do that, thanks
Note that /etc/procmailrc is often executed as root, not $USER, so I tend to avoid putting anything but variable definitions in it.
I'll leave it for tomorrow, with a fresher mind, hopefully.
Anne
Anne Wilson wrote:
On Wednesday 22 December 2010 16:51:02 Paul Heinlein wrote:
On Wed, 22 Dec 2010, Anne Wilson wrote:
On Wednesday 22 December 2010 13:33:10 Anne Wilson wrote:
I became suspicious that I should have received a certain message, and reading pm.log I discovered that it had indeed arrived and had been allocated to /var/mail/anne, despite procmailrc telling it that
MAILDIR=/home/anne/Maildir/
Any idea what might have caused this? It seems to have been working like this only in the last 24 hours or so.
<snip>
There's nothing obvious, at first scan. Everything seems to be "Delivered to command /usr.bin/procmail" which of course is correct. The only
messages
affected are thos which should be in my Inbox, having failed to match any recipe.
Dumb question: um, is the ".", rather than "/", a typo, in /usr.bin/procmail?
mark
On Wednesday 22 December 2010 19:35:33 m.roth@5-cent.us wrote:
Anne Wilson wrote:
On Wednesday 22 December 2010 16:51:02 Paul Heinlein wrote:
On Wed, 22 Dec 2010, Anne Wilson wrote:
On Wednesday 22 December 2010 13:33:10 Anne Wilson wrote:
I became suspicious that I should have received a certain message, and reading pm.log I discovered that it had indeed arrived and had been allocated to /var/mail/anne, despite procmailrc telling it that
MAILDIR=/home/anne/Maildir/
Any idea what might have caused this? It seems to have been working like this only in the last 24 hours or so.
<snip>
There's nothing obvious, at first scan. Everything seems to be "Delivered to command /usr.bin/procmail" which of course is correct. The only
messages
affected are thos which should be in my Inbox, having failed to match any recipe.
Dumb question: um, is the ".", rather than "/", a typo, in /usr.bin/procmail?
Never discount the possibilities :-) Yes, a typo - I'm on the laptop, close to the server.
All the recipes work perfectly - it's just those that fall off the end. For some reason it overrides the DEFAULT setting in procmailrc. This is a recent development, and in the log I see LASTFOLDER - is it possible that DEFAULT is no longer read and I need to define LASTFOLDER?
Anne
On Thu, Dec 23, 2010 at 3:03 AM, Anne Wilson cannewilson@googlemail.com wrote:
All the recipes work perfectly - it's just those that fall off the end. For some reason it overrides the DEFAULT setting in procmailrc.
I'm seeing messages from you about this on the procmail list as well so pardon me if I've got my threads confused, but did you indicate this has been happening some of the time for several days before you noticed it? Have you determined that it's consistent for any message that "falls off the end" or is it intermittent?
If its consistent and there's a reasonably well-defined time that it started happening, you should be looking for changes to the system such as an automatically-applied update that occurred shortly before the symptoms began. However ...
Earlier in this thread you said MAILDIR=/home/anne/Maildir/ ... but MAILDIR is procmail's equivalent of the shell's PWD, it has nothing to do with delivery except as the path prefix if you use a relative path name in a delivering recipe. Assigning to MAILDIR is just a "cd".
Have you tried DEFAULT=/home/anne/Maildir/ ?
This is a recent development, and in the log I see LASTFOLDER - is it possible that DEFAULT is no longer read and I need to define LASTFOLDER?
LASTFOLDER is informational, procmail sets it immediately before delivering to that folder; if you see LASTFOLDER in your logs, the only way the message should fail to arrive in that folder is in the event of an error writing to that folder.
I don't recall whether setting DEFAULT to a pipe (e.g., to delivermail) is supposed to work, but I wouldn't rely upon it. In some simple tests I tried, the pipe was never opened and the mail was passed through to standard output. Setting DEFAULT to a file or directory worked.
If you haven't already, you really should add
LOGABSTRACT=all VERBOSE=yes
to your procmailrc until you have resolved the problem. This isn't a guarantee that you'll be able to track it down but it'll help eliminate a lot of possibilities.
On Thursday 23 December 2010 16:53:22 Bart Schaefer wrote:
On Thu, Dec 23, 2010 at 3:03 AM, Anne Wilson cannewilson@googlemail.com
wrote:
All the recipes work perfectly - it's just those that fall off the end. For some reason it overrides the DEFAULT setting in procmailrc.
I'm seeing messages from you about this on the procmail list as well so pardon me if I've got my threads confused, but did you indicate this has been happening some of the time for several days before you noticed it?
From the dates of messages I found in /var/mail/anne, it began on the day I left for a short vacation. Consequently it was 5 or 6 days before I noticed. Few message fail the procmail recipes, normally, so I don't expect to see many there.
Have you determined that it's consistent for any message that "falls off the end" or is it intermittent?
I found that yesterday morning at 6 am messages were being delivered correctly, including a couple that "fell off the end". Suddenly though, things changed. In the logs I saw messages about by-passing a lock file. I'm wondering if some of the longer html messages are causing locks to be set that don't expire in time for the next message. I do remember in the past using the setting for No Lock (and yes, I read the warning), but can't remember where I found that. I'll think more about that.
If its consistent and there's a reasonably well-defined time that it started happening, you should be looking for changes to the system such as an automatically-applied update that occurred shortly before the symptoms began. However ...
Earlier in this thread you said MAILDIR=/home/anne/Maildir/ ... but MAILDIR is procmail's equivalent of the shell's PWD, it has nothing to do with delivery except as the path prefix if you use a relative path name in a delivering recipe. Assigning to MAILDIR is just a "cd".
Have you tried DEFAULT=/home/anne/Maildir/ ?
No, I haven't touch the settings, because they have worked well for several years.
This is a recent development, and in the log I see LASTFOLDER - is it possible that DEFAULT is no longer read and I need to define LASTFOLDER?
LASTFOLDER is informational, procmail sets it immediately before delivering to that folder; if you see LASTFOLDER in your logs, the only way the message should fail to arrive in that folder is in the event of an error writing to that folder.
They do arrive there - it just defines it as /var/mail/anne, which is useless on my IMAP server.
I don't recall whether setting DEFAULT to a pipe (e.g., to delivermail) is supposed to work, but I wouldn't rely upon it. In some simple tests I tried, the pipe was never opened and the mail was passed through to standard output. Setting DEFAULT to a file or directory worked.
In fact I misquoted when I first wrote. The line I gave is correct, but it should have been followed by DEFAULT=$MAILDIR/new/
In fact my logs show no mail going to /var/mail/anne today, so I will have to watch and wait. I repeat, I'm using a procmailrc that has worked perfectly for years.
If you haven't already, you really should add
LOGABSTRACT=all VERBOSE=yes
When I first set this up it was with a printed set of documentation. I do have VERBOSE=YES, but I have LOGABSTRACT=YES. Are these equivalents or has something changed in the meantime? Not that I'm worried about that - I repeat, everything has been fine up to now.
to your procmailrc until you have resolved the problem. This isn't a guarantee that you'll be able to track it down but it'll help eliminate a lot of possibilities.
I've not had a single message to my Inbox today, but nor have any ended in the Local mail account, so I'll just have to wait to see whether the problem recurs.
Anne
On Thu, Dec 23, 2010 at 9:22 AM, Anne Wilson cannewilson@googlemail.com wrote:
On Thursday 23 December 2010 16:53:22 Bart Schaefer wrote:
LASTFOLDER is informational, procmail sets it immediately before delivering to that folder; if you see LASTFOLDER in your logs, the only way the message should fail to arrive in that folder is in the event of an error writing to that folder.
They do arrive there - it just defines it as /var/mail/anne, which is useless on my IMAP server.
Sure, but the point is that assigning to LASTFOLDER yourself is meaningless.
Procmail will fall back on the folder named in $ORGMAIL in the event that it is unable to deliver to $DEFAULT, for example because of a locking issue. It's quite likely that this assignment to LASTFOLDER is coming from ORGMAIL.
In fact I misquoted when I first wrote. The line I gave is correct, but it should have been followed by DEFAULT=$MAILDIR/new/
I'm pretty sure that's wrong. From the procmailrc manual:
If the mailbox name ends in "/", then this directory is presumed to be a maildir folder; i.e., procmail will deliver the message to a file in a subdirectory named "tmp" and rename it to be inside a subdirectory named "new".
So you should not have the "new/" on the end of the DEFAULT value unless you want a folder that is *named* "new" (and thus file paths ending in new/new/ and new/cur/ etc.)
In fact my logs show no mail going to /var/mail/anne today, so I will have to watch and wait. I repeat, I'm using a procmailrc that has worked perfectly for years.
Unfortunately that it "worked" doesn't always mean that it is correct, it just means you haven't hit the corner cases before.
If you haven't already, you really should add
LOGABSTRACT=all VERBOSE=yes
When I first set this up it was with a printed set of documentation. I do have VERBOSE=YES, but I have LOGABSTRACT=YES. Are these equivalents or has something changed in the meantime?
Again from the manual pages:
LOGABSTRACT Just before procmail exits it logs an abstract of the delivered message in $LOGFILE showing the `From ' and `Subject:' fields of the header, what folder it finally went to and how long (in bytes) the message was. By setting this variable to `no', generation of this abstract is sup- pressed. If you set it to `all', procmail will log an abstract for every successful delivering recipe it pro- cesses.
So "all" includes some cases that "yes" does not, particularly copies made with the "c" flag on recipes.
On Thursday 23 December 2010 18:40:43 Bart Schaefer wrote:
On Thu, Dec 23, 2010 at 9:22 AM, Anne Wilson cannewilson@googlemail.com
wrote:
On Thursday 23 December 2010 16:53:22 Bart Schaefer wrote:
LASTFOLDER is informational, procmail sets it immediately before delivering to that folder; if you see LASTFOLDER in your logs, the only way the message should fail to arrive in that folder is in the event of an error writing to that folder.
They do arrive there - it just defines it as /var/mail/anne, which is useless on my IMAP server.
Sure, but the point is that assigning to LASTFOLDER yourself is meaningless.
Procmail will fall back on the folder named in $ORGMAIL in the event that it is unable to deliver to $DEFAULT, for example because of a locking issue. It's quite likely that this assignment to LASTFOLDER is coming from ORGMAIL.
Hmm - "echo $ORGMAIL" returns nothing.
In fact I misquoted when I first wrote. The line I gave is correct, but it should have been followed by DEFAULT=$MAILDIR/new/
I'm pretty sure that's wrong. From the procmailrc manual:
If the mailbox name ends in "/", then this directory is presumed to be a maildir folder; i.e., procmail will deliverthe message to a file in a subdirectory named "tmp" and rename it to be inside a subdirectory named "new".
So you should not have the "new/" on the end of the DEFAULT value unless you want a folder that is *named* "new" (and thus file paths ending in new/new/ and new/cur/ etc.)
To be honest I was surprised to see it there. I didn't remember putting it in. The fact that mail is significantly down due to the holiday season makes testing difficult, but I'll experiment with that when things get back to normal.
In fact my logs show no mail going to /var/mail/anne today, so I will have to watch and wait. I repeat, I'm using a procmailrc that has worked perfectly for years.
Unfortunately that it "worked" doesn't always mean that it is correct, it just means you haven't hit the corner cases before.
If you haven't already, you really should add
LOGABSTRACT=all VERBOSE=yes
When I first set this up it was with a printed set of documentation. I do have VERBOSE=YES, but I have LOGABSTRACT=YES. Are these equivalents or has something changed in the meantime?
Again from the manual pages:
LOGABSTRACT Just before procmail exits it logs an abstract ofthe delivered message in $LOGFILE showing the `From ' and `Subject:' fields of the header, what folder it finally went to and how long (in bytes) the message was. By setting this variable to `no', generation of this abstract is sup- pressed. If you set it to `all', procmail will log an abstract for every successful delivering recipe it pro- cesses.
So "all" includes some cases that "yes" does not, particularly copies made with the "c" flag on recipes.
I can see that could be useful at times. Currently I don't have any "c" flag recipes, although I have used them from time to time.
Thanks for your patient help. We probably can't do any more for a few days, until things get back to normal, but so far I've had no more messages in /var/mail/anne. Since pebcak is always a high possibility, I confess that whenever I read config files I tend to tidy up unwanted spaces, etc. It's just possible that I edited the recipes just before going away and accidentally inserted something that would interfere - such as a "." in front of the DEFAULT line, which I might not notice, but which would get cleaned up as an unwanted space, next time I read. My eyes are not brilliant these days, so I'd not discount the possibility.
Anyway, thanks again. I'll let you know if I discover anything more.
Anne
-
Anne Wilson -
Bart Schaefer -
Les Mikesell -
m.roth＠5-cent.us -
Paul Heinlein