Re: [Exim] SMTP transport woes...

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Philip Hazel
Datum:  
To: Ray Jackson
CC: exim-users
Betreff: Re: [Exim] SMTP transport woes...
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.