On Thu, 15 May 2003, Ray Jackson wrote:
> However, when we started load testing we ran into trouble. Basically,
> we discovered that our AV daemon would do 2 things:
>
> o It would take up to 2 seconds to establish/close an SMTP session
> o It would automatically disconnect an SMTP session as soon as it saw
> an end-of-message. (i.e. it see's the '.' line and with a second or
> so disconnects the session)
That second behaviour is not compliant with the SMTP protocol. See RFC
2821.
> The AV daemon will allow up to 'x' concurrent connections (we set it at
> 100) - however it appears that it will close an active connection after
> receiving just one email message).
That is also not compliant with the SMTP protocol.
> ... R=av_router T=av_transport defer (-18): Remote host 192.168.1.17
> [192.168.1.17] closed connection in response to end of data
That's Exim saying "this connection died unexpectedly".
> ... unexpected disconnection while reading SMTP command from mailserv
> [127.0.0.1]
That's something completely different - a problem with an *incoming*
connection on the local interface.
> ... 192.168.1.17 [192.168.1.17]: Connection refused
> ... R=av_router T=av_transport defer (111): Connection refused
That's your AV host refusing to accept a connection.
> It appears that Exim was trying to send subsequent messages down the
> same connection and was booted out my the AV daemon?
I don't think so. It certainly looks at first sight as though the AV
daemon is just plain broken.
> What I want Exim to do (I think) is open a completely new socket
> connection with our AV daemon each time a message is sent to the
> av_transport (i.e. a completely new process) - as it appears that the AV
> daemon is tearing down the socket connection as soon as it has received
> one complete message.
No, it looks like it is tearing down the connection *before* it has
completely received one message, because it hasn't sent an
acknowledgement.
Is there a way of doing this using the SMTP
> transport or do I have to go down the 'pipe' route? I though
> connection_max_messages would help me - but this appears not to be the case.
connection_max_messages will do what you ask, but as I say above, I
don't think that is the problem.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
