~/.procmailrc not being processed after updating 3.81 -> 3.82-2 (Ubuntu 10.04LTS)

So I updated a few packages using Virtualmin today, and procmail (while still running) has stopped processing my ~/.procmailrc file. It is, however, still processing the /etc/procmailrc file. And I have no idea why.

I can tail /var/log/procmail.log and watch new items being filtered (until it ‘assumes identity of the recipient’) but tailing ~/.procmail/log shows nothing new being added (which means my ~/.procmailrc isn’t being processed, I think?)

I’m still learning all the virtualmin ropes, but after hours bashing my head against this I’m just hoping someone can point me in the right direction :slight_smile:

I’m using:
Ubuntu 10.04.1 LTS i686
Virtualmin 3.82-2.gpl (3.81 previous to this problem)
Postfix 2.7.0-1
Procmail 3.22-18ubu
Procmail-Wrapper 1.0-2

According to the virtualmin logs, security-updates/update.cgi updated the following packages:
mysql-client mysql-common libmysqlclient16 mysql-client-core-5.1 mysql-client-5.1 mysql-server mysql-server-core-5.1 mysql-server-5.1 postgresql-client-common postgresql-common webmin-virtual-server webmin-virtual-server-theme

I’m fairly sure it’s related to one of these updated packages. Emails a minute prior to the time of update were filtered into folders; emails a minute the update are all just dropping into my Inbox.

None of those packages appeared to relate to procmail at first glance.

Postfix is set up to call procmail-wrapper like this, so no .forward file exists but none has been needed previously:

mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME

The ~/.procmailrc file hasn’t changed in weeks. Just to make things easier to test, I’ve simplified it to look like the below.


And it has permissions/ownership set up like so:

-rw-r–r-- 1 myusername myusername 108 Nov 17 09:04 .procmailrc

The /etc/procmailrc file looks like this (should be stock):

VIRTUALMIN=|/etc/webmin/virtual-server/lookup-domain.pl $LOGNAME

  • ?/usr/bin/test “$VIRTUALMIN” != “”

When mail arrives, something like this gets added to /var/log/procmail.log:

procmail: Assigning “TRAP=/etc/webmin/virtual-server/procmail-logger.pl”
procmail: Assigning “VIRTUALMIN=”
procmail: Executing “/etc/webmin/virtual-server/lookup-domain.pl,myusername”
procmail: [12004] Wed Nov 17 09:32:24 2010
procmail: Executing “/usr/bin/test,!=,”
procmail: [12004] Wed Nov 17 09:32:24 2010
procmail: Non-zero exitcode (1) from “/usr/bin/test”
procmail: No match on "/usr/bin/test != "
procmail: Assigning “DEFAULT=/home/myusername/Maildir/”
procmail: Assigning “ORGMAIL=/home/myusername/Maildir/”
procmail: Assigning “DROPPRIVS=yes”
procmail: Assuming identity of the recipient, VERBOSE=off
From useralias@domainname.com Wed Nov 17 09:32:19 2010
Subject: test 24
Folder: /home/myusername/Maildir/new/1289986344.12004_0.myservername 1271
Time:1289986344 From:useralias@domainname.com To:testingness@domainname.com User:myusername Size:1324 Dest:/home/myusername/Maildir/new/1289986344.12004_0.myservername Mode:None

Frustratingly, nothing gets added to ~/.procmail/log

How do I know procmail’s working at all? If I change the last line of /etc/procmailrc from $DEFAULT as a destination to .Testingness/ then it does so.

I’m anything but a Postfix expert, so for now lemme just point out some differences of your setup to mine (where processing of the user’s procmailrc still works okay, just tested it with a forwarding) that I noticed.

Firstly, there is no ~/.procmail directory at all in my email users’ home directories.

My /etc/procmailrc ends with the “DROPPRIVS” line, there is no “:0 $DEFAULT” behind that. Also it does not contain the “VERBOSE” line.

The user’s procmailrc, where I added a forwarding, is much shorter than yours. It just consists of:

! email-address-to-which@i-test-forwarded.to[/code]

(Have fun grabbing this, spammers! :wink: )

I suppose the additional stuff in your user procmailrc is what is supposed to do the local logging?

Yeah, user-scope logging’s just being done like this:

It was indeed the :0 $DEFAULT lines at the end of /etc/procmailrc that were fouling things up. Removing them seems to have fixed things. I had assumed they were intended to be there as a consequence of piping mail to procmail via postfix’s mailbox_command directive – without a LASTFOLDER I thought mail might not be delivered at all – but it does just drop into the inbox anyway.

Now the next interesting question is how the hell those lines got added there by those routine package updates!

Thankyou very much for the advice Locutus! (And they say there’s never a collective around when you need one.) :slight_smile:

You’re welcome… And assimilation is overrated. Although it’s fun. :wink:

And yeah, it’d be interesting to know what caused those lines to be added to the procmailrc. It’s odd, since for me, during the updates of my production and experimental server nothing of the sort happened.

At a guess, that may have something to do with differing antivirus and antispam filtering configurations.

Or… my box could just be haunted by the spirits of jilted sysadmins.