[CentOS] The case of the missing mail
Anne Wilson
cannewilson at googlemail.com
Fri Dec 24 12:06:03 UTC 2010
On Thursday 23 December 2010 18:40:43 Bart Schaefer wrote:
> On Thu, Dec 23, 2010 at 9:22 AM, Anne Wilson <cannewilson at 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 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.centos.org/pipermail/centos/attachments/20101224/cd7e3417/attachment.sig>
More information about the CentOS
mailing list