After upgrading to procmail-3.22-r9 today, I stopped receiving new mail. It took me a while to realize what was happening, but it started delivering mail to /var/mail/username instead of ~username/.maildir as configured. In fact, it seems to be ignoring /etc/procmailrc altogether now. I'm pasting my /etc/procmailrc below. Prior to the upgrade, all e-mail was delivered to ~/.maildir/ in maildir format. Post upgrade, all e-mail began being delivered to /var/mail/user in mbox format. Prior to the upgrade, I'd get detailed messages like this in /var/log/procmail.log: procmail: [13540] Mon Dec 1 16:04:04 2008 procmail: Assigning "DROPPRIVS=yes" procmail: Assuming identity of the recipient, VERBOSE=off procmail: Match on ! "^Received: by mail.domain.tld \(Postfix, from userid .*" procmail: Executing "clamdscan,--no-summary,--stdout,-" procmail: Assigning "CLAMAV=" procmail: [13540] Mon Dec 1 16:04:05 2008 procmail: No match on "^.*: \/.* FOUND" procmail: Extraneous filter-flag ignored procmail: Executing "formail,-b,-f,-t,-I,X-ClamAV-Status: No" procmail: Executing "/usr/bin/spamc" procmail: No match on "^X-Spam-Status: Yes" procmail: Assigning "PATH=/home/user/bin:/bin:/usr/bin:/usr/local/bin" procmail: Assigning "LASTFOLDER=/home/user/.maildir/new/1228169045.13540_0.domain" procmail: Notified comsat: "jimmyb@0:/home/user/.maildir/new/1228169045.13540_0.domain" Post upgrade, I began getting entries like this: procmail: [937] Mon Dec 1 16:22:17 2008 procmail: Assigning "DROPPRIVS=yes" procmail: Assuming identity of the recipient, VERBOSE=off procmail: Extraneous filter-flag ignored I verified that my config file(s) hadn't changed and even compared it against a backed up copy to be sure. Downgrading made everything work again. Upgrading again made everything start failing again. I'm posting this as a new bug because, honestly, I'm not sure where else it belongs. If this is failing for me, then it's likely failing for others, and I think this is a pretty serious issue. Any help in understanding what causes this failure, and better yet an updated ebuild to fix the problem, which be greatly appreciated. /etc/procmailrc: # Use maildir-style mailbox in user's home directory MAILDIR=$HOME/.maildir LOGFILE=/var/log/procmail.log LOGABSTRACT=no VERBOSE=yes DROPPRIVS=yes # Skip additional processing if mail originated from local system :0 * ! ^Received: by mail.domain.tld \(Postfix, from userid .* { # Check for virus :0 CLAMAV=|clamdscan --no-summary --stdout - :0fw * CLAMAV ?? ^.*: \/.* FOUND { :0fw | formail -b -f -t -I "X-ClamAV-Status: Yes, $MATCH" :0 $MAILDIR/.Virus/ } :0Efw | formail -b -f -t -I "X-ClamAV-Status: No" # Check for spam :0fw | /usr/bin/spamc :0: * ^X-Spam-Status: Yes $MAILDIR/.Spam/ } Reproducible: Always Steps to Reproduce: see description for complete details, but in summary: 1. use given /etc/procmailrc with 3.22-r7 2. verify mail delivery to ~/.maildir/ 3. upgrade to 3.22-r9 4. verify incorrect mail deliver to /var/mail/user
Confirmed. With the new version I suddenly find myself having a /var/spool/mail/$USER entry that wasn't there before. Oddly enough, the old maildir patch works fine for the -r9 revision too: Index: procmail-3.22-r9.ebuild =================================================================== RCS file: /var/cvsroot/gentoo-x86/mail-filter/procmail/procmail-3.22-r9.ebuild,v retrieving revision 1.7 diff -u -B -r1.7 procmail-3.22-r9.ebuild --- procmail-3.22-r9.ebuild 2 Dec 2008 06:51:20 -0000 1.7 +++ procmail-3.22-r9.ebuild 2 Dec 2008 08:05:21 -0000 @@ -32,7 +32,7 @@ echo "# Use maildir-style mailbox in user's home directory" > "${S}"/procmailrc echo 'DEFAULT=$HOME/.maildir/' >> "${S}"/procmailrc cd "${S}" - epatch "${FILESDIR}/gentoo-maildir3.diff" + epatch "${FILESDIR}/gentoo-maildir2.diff" else echo '# Use mbox-style mailbox in /var/spool/mail' > "${S}"/procmailrc echo 'DEFAULT=/var/spool/mail/$LOGNAME' >> "${S}"/procmailrc
package.masked for now. Need to take a look at it, but probably won't have time for that before sunday.
I can confirm that I have a /var/mail/${username} added with that version. However, mail distribution does still work as with -r7 revision. I installed -r9 on Nov 29. If I can be of assistance to track this down, please let me know. BR, Dustin
I upgraded from -r8 to -r9 in ~arch back in July. I've never seen this problem. The only real change since then was the src_compile/src_unpack change from ~7 days ago.
I experienced a similar problem and resolved it. My problem was that the mails that do not trigger any of the recipes and 'fall off' the end of procmailrc got sent to /var/spool/mail/user instead of /home/user/.maildir as before. This problem is caused by the resolution of bug #108869 (http://bugs.gentoo.org/108869). By setting MAILSPOOLHOME to '' at compile time mails get sent by default to $DEFAULT which if not set in the procmailrc defaults to the value of $ORGMAIL. $ORGMAIL in turn defaults to /var/spool/mail/$LOGNAME. Adding the following 2 lines to procmailrc resolved the issue for me: MAILDIR=/home/$LOGNAME/.maildir DEFAULT=$MAILDIR/
Can everyone who's got that problem please confirm that they don't have a DEFAULT maildir configured? The default /etc/procmailrc does so - therefore everything works as expected if the default procmailrc is used (or DEFAULT is set). homer ~ # cat /etc/procmailrc # Use maildir-style mailbox in user's home directory DEFAULT=$HOME/.maildir/
I can confirm that I did not have DEFAULT explicitly set in my /etc/procmailrc file, and that adding the following line appears to make things work correctly: DEFAULT=$MAILDIR/ Thanks for the fix. However, I do have a couple of concerns about this: 1. I've been using this basic procmail configuration for quite a while on Gentoo servers, and have never had this problem. The fact that it all of a sudden breaks now because $DEFAULT is no longer set by default (whether this is "proper" or not) isn't really a good thing. While new users probably won't be affected, any maildir users upgrading from previous versions could very well be affected. 2. You mention that DEFAULT is set by default in the current ebuild. However, I'm pretty sure that back when I initially configured procmail (which was done on Gentoo originally), this variable wasn't explicitly defined in the configuration. So again, this could affect long time users and upgraders while new users wouldn't see an issue. I'm not really opposed to moving in this direction as I think it makes sense to explicitly define the default mailbox, especially if it overrides MAILDIR (which I don't really understand). Given that this is a rather significant change in behavior from the previous defaults, though, I think at the very least an ewarn should be thrown at upgraders about this change. I do appreciate the quick response to this issue. Thanks for the help.
> 2. You mention that DEFAULT is set by default in the current ebuild. However, > I'm pretty sure that back when I initially configured procmail (which was done > on Gentoo originally), this variable wasn't explicitly defined in the > configuration. Same for me. I configured procmail ~2 years ago on Gentoo and DEFAULT was not set in procmailrc back then. I may have missed it when it was added later but its absence did not cause any unexpected behaviour until the modification of MAILSPOOLHOME was introduced with 3.22-r9. > I think at the very > least an ewarn should be thrown at upgraders about this change. Yes. Asking the upgrader to verify that DEFAULT is set in procmailrc should do.
Added the note in 3.22-r10, will do the usual stablization call in 30 days.
