John,
Thanks for providing your settings. They are ok.
I asked for it because Postfix logs don't show port numbers,
so checking the most obvious was my first guess.
Actually your problem is more tricky, and I have seen
similar situations during testing. The telltale log entry is:
Dec 3 14:48:03 sa amavis[22609]: (22609-01)
ESMTP: INFO client broke the connection without a QUIT
and it shows something fishy is going on, either with
forks (subprocesses) done by SpamAssassin, or by SpamAssassin
playing games with STDIN/STDOUT while amavisd-new is trying
to talk SMTP with Postfix. The Net::Server Perl module
unfortunately makes stdin/stout a dup of its TCP socket.
I have seen these problems with SpamAssasin 2.20
when external tests were not disabled. It seems the
SpamAssassin 2.43 fixed this, so even when Razor2
external test is enabled with 2.43, things seem
to work fine now. I haven't tried with other
external SA tests, they may still break things.
The likely scenario goes like this: amavisd-new process
is talking SMTP on a TCP socket to first Postfix instance.
While that connections is still open, it calls SA to check
the message. Now if SA would do a fork, and forget to
properly terminate its subprocess, we end up with
two copies of amavisd-new process, both trying to talk
to Postfix. At that point amavisd-new still needs to do
two things: forward the checked mail, and send the
SMTP response code to Postfix. Now, if there are two
copies of this process, both succeed to forward mail
(making two copies out of it), and the quickest of them
terminates the SMTP transaction, Postfix sends it
a QUIT and goes away - while the second copy now
only sees that the SMTP connection broke, and issues
a warning.
Please try:
- make sure you have SpamAssassin 2.43 and not earlier version;
- set: '$sa_local_tests_only = 1;' and see if the problem goes
away. Later you may try to selectively disable SpamAssassins
external tests, to see which one is guilty;
- turning up the amavisd-new log level and checking in the log
that the amavis process id always matches the task id, such as in:
vvvvv vvvvv
Dec 3 14:48:03 sa amavis[22609]: (22609-01) Passed, <sende...
Dec 3 14:48:03 sa amavis[22609]: (22609-01) ESMTP: INFO client broke ...
Dec 3 14:48:10 sa amavis[22697]: (22697-01) Passed, ...
Dec 3 14:48:15 sa amavis[22697]: (22697-02) Not-Delivered, ...
^^^^^ ^^^^^
Finding a mismatch would confirm my guess that more than
one clone of amavisd-new child process is trying to survive.
Mark
P.S. I CCed this to SAtalk just as a possibly useful information.
We may continue the topic on the amavis-user list.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
