Package: spampd Tags: +wontfix close thanks
Nikolaus Rath schrieb:
Thanks for the fast responses to my previous reports - excellent maintainer work. But here is another one..
Thanks.
I have the problem that, from time to time, the spampd child process is
killed due to a timeout. This makes postfix send me an error message and
refuse the mail with 4xx ("queue file write error"). Bad..
True.
My primary wish is to stop these errors (if they are actually errors) or error messages (if there is no error at all). If you know what to do - please stop reading here and tell me. What follows is what I have tried on my own and it may be misleading ;-).
I can't reproduce the behaviour in any way, but I deduced that it must occur during reading after the DATA command, because the satimeout (which is shorter) is not hit.
It might be the childtimeout parameter (usually 6 minutes) or it could be IO::Socket::INET timeout (not changeable on the command line, set to 5 minutes). However, spampd isn't intended to be placed _before_ the incoming MTA. It is intended to be used as a local filter, between the primary MTA (incoming SMTP, possibly over slow connections) and a secondary MTA which does the actual deliveries. Therefore, no acceptable message should take > 6 minutes to transfer to spampd and/or from spampd, even over 10Mbit Ethernet (that would need a 300MB message to exceed that timeout).
I don't know about the IO::Socket::INET timeout parameter but assume it resets the timer on each received packet. The childtimeout parameter of spampd however sets a limit to the total network transfer time (or even total handling time in spampd) a message might take. Since this is adjustable, I see no reason to change this behaviour.
I guess that the above behaviour might occur when the client sends his mail very slowly, but at a constant rate. The spampd timeout just counts the seconds and doesn't care if there is data coming or not. The postfix timeout algorithm in contrast only runs when there is no data received at all.
Postfix also has various timeouts. And IIRC also a timeout for the maximum time an incoming DATA command (including the message) might take or a maximum time an SMTP connection might take.
I see 2 possible solutions for this problem:
- Implement postfix style timeouts for spampd.
AFAICT, this is already done (IO::Socket::INET timeout: 5 minutes)
With this report sent to spampd you probably know what solution I currently favour.
Actually, the real solution is to use spampd as described in the postfix filter readme/howto:
- Have postfix listen on port 25/465/589/whatever with content-filter=smtp:[localhost]:10024 - Have spampd listen on port 10024 (localhost) and connect to 10025 (localhost) - Have a second instance of postfix listen on port 10025 (localhost) with content-filter= (empty), doing the actual delivery
This definately only allows post-queue filtering (though a similar filter might also work as a pre-queue filter). However, if you insist on using spampd at the very front of your incoming connections, try adjusting the --child-timeout parameter of spampd.
cu, sven
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
