The revenge of the empty message bodies

[Jacques Caruso]

Hello Julian and the crowd ;-)

Like others, I'm regularly hit by the « Skipped Messages Of Death »
problem with Postfix. The symptoms are already known : lots of messages
like this in /var/log :

Nov 24 17:08:06 sceuzi postfix/qmgr[27007]: 18CD91B8368: skipped, still being delivered

and empty messages in the mailboxes. I searched the list archives for
someone having had the same problem, and I found an exchange of mails in
October covering the subject. The reporter explained that MS was reading
files in the wrong queue (see <http://minilien.com/?D4cSsU5e8i>). Well,
I managed to catch MS in the act, and put the 'lsof | grep postfix' and
'ps -afx' outputs on a web server nearby (note : the load at the time I
took these snapshots was very high, around 9.0~11.0) :

<http://aragorn.monaco.net/tmp/ms/lsof-grep.out.txt>
<http://aragorn.monaco.net/tmp/ms/ps-afx.out.txt>

I have the full lsof output if you need it, it's just too long to
sanitize it, so if it's needed I'll just mail it to you. BTW, I did a
'cat lsof.out.txt | sort --key=8,8 | grep incoming' and wasn't able to
find any postfix process in the output (or more precisely any postfix
process accessing an inode concurrently with MS). But maybe I just got
the data at a bad time... Another strange thing is that I restarted
postfix.in soon after the incident, and I got this warning :

postsuper: warning: QUEUE FILE NAMES WERE CHANGED TO MATCH INODE NUMBERS

Also, I saw that a patch for this problem has been proposed at the time
(see <http://minilien.com/?VTPIHDxRNs>). Should I apply this patch ? Has
the original reporter (or anyone else, for that matter) tested it, and
what were the results ?...

For the record, here is the configuration I run MS on :

* The server is a (rather busy) 2×PII-233 with 384 MB RAM running Debian/Testing
* Program versions (dpkg -l) :

ii  mailscanner                         4.24.5-1                            An email virus scanner and spam tagger
ii  postfix                             2.0.16-1                            A high-performance mail transport agent
ii  spamassassin                        2.60-1                              Perl-based spam filter using text analysis

* I did it « by the book », except that some configuration files are in
fact hard links to avoid me the hassle of changing these at two
locations. I've done this for the following files :

/etc/postfix.in/mydestination             <-> /etc/postfix/mydestination
/etc/postfix.in/mynetworks                <-> /etc/postfix/mynetworks
/etc/postfix.in/relay_domains             <-> /etc/postfix/relay_domains
/etc/postfix.in/virtual                   <-> /etc/postfix/virtual
/etc/MailScanner/spam.assassin.prefs.conf <-> /etc/spamassassin/local.cf

Anyway, this shouldn't have any impact on the problem, but I'm telling
it preventively. Another depart from the normal (?) configuration is
that I've two init scripts to take care of the two instances of Postfix
(the second is just the same script with all references to
{/etc,/var/spool}/postfix replaced with postfix.in. Works OK).

* The MS configuration file is IMHO too long to be included in a mailing
list posting, so I did put it at
<http://aragorn.monaco.net/tmp/ms/msconf.out.txt> (that's the
MailScanner.conf file, minus comments and empty lines). Same for the
(rather non-standard) SA configuration file at
<http://aragorn.monaco.net/tmp/ms/sa-localcf.out.txt>.

OK, cannot think of anything else at the moment. If you need more
information or another configuration file, ask away. If this has already
been discussed and solved, well I apologize for being such a lousy
searcher :-)

PS : BTW, another recurring problem is that MS sometimes just stops
processing e-mail altogether. The MS processes are still alive, but they
just idle. I haven't so far been able to spot any distress message in
the logs, and it causes big problems everytime (e-mails piles up in the
postfix.in deferred queue and MS takes time to empty the queue, thus
causing huge delays in mail delivery). Has a solution been found to this
(I did a quick search but found nothing) ?...

Cheers,
-- 
[ Jacques Caruso <jacques at monaco.net>                  Développeur PHP ]
[ Monaco Internet                           http://monaco-internet.mc/ ]
[ Tél : (+377) 93 10 00 43                        Clé PGP : 0x41F5C63D ]
[ * Tired of choosing the lesser of two evils? Vote Cthulhu in 2004! * ]