On Thursday 23 December 2010 18:40:43 Bart Schaefer wrote: > On Thu, Dec 23, 2010 at 9:22 AM, Anne Wilson <cannewilson@xxxxxxxxxxxxxx> 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 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.) > 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 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. 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 -- KDE Community Working Group New to KDE Software? - get help from http://userbase.kde.org
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
