After much debugging on your system, I discovered that your procmail behaves differently to the one everywhere else - it runs /etc/procmailrc as the user receiving mail right from the start, rather than only when DROPPRIVS=yes is encountered.
When I copied in the exact same version of procmail from my Ubuntu system (3.22) to /usr/bin/procmail, it started working just fine! My guess is that the version built by Gentoo has some strange patches that cause this. Bizarre …
When I copied in the exact same version of procmail from my Ubuntu system (3.22) to /usr/bin/procmail, it started working just fine! My guess is that the version built by Gentoo has some strange patches that cause this. Bizarre ..
So it’s the exact same version, but just seems to run differently? That is bizzare. I can look further into the Gentoo ebuild and see why it’s like that. Do you have any idea what we can possibly do to check about whether procmail runs like this? Maybe you can add that check to your install script.
Did you change anything else on the system besides the binary?
Thanks so much for your help, this has been a head scratcher for Months! Once again, I am much in debt to you!
The last only weird problem I have now is that I updated syslog-ng and logrotate a couple weeks ago. This seems to have caused Postfix to once in awhile, stop writing to the mail.log file. I think this usually happens on the logrotate shedule. Should I add a /etc/init.d/postfix reload in the after actions for that rotation?
Oh, I also noticed that some Webmin programs were using /var/webmin as their log directory (which doesn’t exist), while others used /var/log/webmin . This is why the lookup-domain-daemon.log file wasn’t being updated. Once I linked /var/webmin to /var/log/webmin , all was well.
After looking at Nick’s system, I found the real cause of this problem, and it turned out to be a bug in procmail !
It seems that if the default mail directory /var/mail doesn’t exist, procmail’s code will stupidly switch to the user who is receiving email right away, causing most of /etc/procmailrc to fail. When I created the /var/mail directory on his system, it started working again.
I’m going to file a bug with the procmail developers about this …
Great detective work! I see that the procmail bug couldn’t have affected my system since I had the /var/mail dir. Did you find this through the source or just investigating? Maybe we can make a patch.
Yeah, strace knows all … and it was able to point me in the right direction in this case. I also had to look at the procmail source code though.
In Sean’s case, I’ve realized that procmail was looking for mail in the ~/.maildir directory, and incorrect switching IDs when that was not found. This must have been a path compiled into the Gentoo version of procmail, which is why it started working when I replace procmail with the copy from my system (which looks for /var/mail , which exists on Sean’s system).
[code:1]
procmail: Assigning "TRAP=//etc/webmin/virtual-server/procmail-logger.pl"
procmail: Assigning "VIRTUALMIN="
procmail: Executing "/etc/webmin/virtual-server/lookup-domain.pl,joesomeone.mydomain"
procmail: Executing "/usr/bin/test,!=,"
procmail: Non-zero exitcode (1) from "/usr/bin/test"
procmail: No match on "/usr/bin/test != "
procmail: Assigning "ORGMAIL=/home/windish/homes/amy/Maildir/"
procmail: Assigning "DEFAULT=/home/windish/homes/amy/Maildir/"
procmail: Assigning "DROPPRIVS=yes"
procmail: Assuming identity of the recipient, VERBOSE=off
procmail: No match on "^X-Spam-Status: Yes"
procmail: Assigning "PATH=/home/mydomain/homes/joesomeone/bin:/bin:/usr/bin:/usr/local/bin"
procmail: Assigning "LASTFOLDER=/home/mydomain/homes/joesomeone/Maildir/new/1201644084.13825_0.myserver.mydomain.com"
procmail: Notified comsat: "amy.windishagency@0:/home/mydomain/homes/joesomeone/Maildir/new/1201644084.13825_0.myserver.mydomain.com"
From somebloke@outheresomehwere.com Tue Jan 29 16:01:24 2008
Subject: This is the story of my life
Folder: /home/mydomain/homes/joesomeone/Maildir/new/1201644084.13825_0.myserver.mydomain.com 9016
procmail: Assigning "EXITCODE=0"
procmail: Executing "//etc/webmin/virtual-server/procmail-logger.pl"
Time:1201644084 From:«»somebloke@outheresomehwere.com To:joesomeone@mydomain.com User:joesomeone.mydomain Size:9062 Dest:/home/mydomain/homes/joesomeone/Maildir/new/1201644084.13825_0.myserver.mydomain.com Mode:None
VIRTUALMIN is not getting assigned. And the lookup-domain.pl script is being fired AFTER the assignment. This makes no sense to me. As far as I understand Procmail, =| will run the script following it, wait for it to return with data, and then set it to the variable to the left.
Is this not happening for some reason? Is there some magic Procmail etting that is set somewhere that I don't know about?
When you run lookup-domain.pl as root from the command line, does an entry get logged to that file?
No, it does not appear that anything gets logged when I run lookup-domain.pl as root. That is if you mean in the /var/log/webmin/lookup-domain-daemon.log.
My mailbox command for postfix has always been:
[code:1]mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME[/code:1]
This is how I configured it from installation.
And this is how my procmail-wrapper looks:
[code:1]-rwsr-sr-x 1 root root 8266 Oct 22 00:37 /usr/bin/procmail-wrapper[/code:1]
I did have to make my procmail-wrapper on my own. This Virtualmin installation for the most part was performed manually. Here is the source I used for the wrapper (found on this forum):
To me, everything is where it should be. If you think I should, let you in to debug it, you can email me your public key file, and I’ll create an account that can su in.
To me, everything is where it should be. If you think I should, let you in to debug it, you can email me your public key file, and I’ll create an account that can su in.
[code:1]# Use maildir-style mailbox in user’s home directory
VERBOSE=yes
LOGFILE=/var/log/procmail.log
TRAP=//etc/webmin/virtual-server/procmail-logger.pl
:0wi
VIRTUALMIN=|/etc/webmin/virtual-server/lookup-domain.pl $LOGNAME
:0