Sven Mueller <[EMAIL PROTECTED]> wrote:
>> 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).
Spampd is not the incoming MTA here. It is configured as a proxy
filter and it sits between two postfix daemons, exactly as you
described. It is just that postfix doesn't wait until it has received
the entire message - the incoming smtp data is directly directed to a
spampd instance.
Transfer times > 6 minutes are of course very rare and until now
everythink coming in so slow was only spam, but I the error messages
are annoying anyway.
> 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.
True. But it this case you should mention that there is another
timeout.
>> 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 only know daemon_timeout, which is set to 18000 seconds by default.
>> 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)
Nice to know. :-)
>> 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).
This is the configuration I'm running here. And this is where
childtimeout becomes a problem.
> However, if you insist on using spampd at the very front of your
> incoming connections, try adjusting the --child-timeout parameter of
> spampd.
I think I will set to a somethink similar as daemon_timeout now, the
IO::Socket timeout should be sufficient for me.
--Nikolaus
--
Gefährlich wird es, wenn die Dummen fleissig werden
