I agree with you about the reason to make things like that.
The problerm is when you first fall in them and you give trust to the
documentation and ignore all about function like "email protection" that
changes entirely the behaviour.
Actually I'm glad because I know the reason about this changed behaviour
and create some parameter timed pauses between each email and burst
emails. It's "proviso ire"...
But I would like to have a regulated function with some good probes able
to adapt to different load situations.
Kind regards
Artur
Le 04/11/2010 16:48, martijn.list a écrit :
>> This has several consequences:
>> - the email exchanges is not synchronous, that is the execution flow
>> is returned to the program before the email is not yet delivered to
>> the smtp server. In the case that the connection is broken after the
>> return, the user is not advertised about the problem.
> I think there is a good reason why they 'need' to do this. I think that
> the reason is that they first need to receive the email before sending
> it to the final SMTP server is to make sure that nothing gets send if
> the message contains a virus. You can only detect if a message contains
> a virus after the complete message has been received. That's why they
> first need to receive the complete message. Once the message is received
> by the virus scanner SMTP proxy the SMTP proxy should report back to the
> client that it has received the message (a 250). It would however be
> better to not report a 250 immediately but only when the message has
> been scanned AND sent to the final SMTP server. Waiting until the
> message has been delivered to the final SMTP server will be fine if the
> message is small. If the message however is a large message (multiple
> MBs) it can take some time before the message is sent to the final SMTP
> server. The problem with that is that the SMTP client will timeout on
> the connection if the 250 is not sent back within a certain timeout
> time. If the SMTP client detects a timeout it will try to send the
> message again... and again.. and again. That's why the SMTP proxy must
> report a 250 back to the client if sending the message to the final SMTP
> server takes longer than the timeout value of the SMTP client. This is
> what you are seeing. With small messages sending of messages is
> synchronous (because delivering to the final SMTP is fast) and with
> larger messages sending through the proxy is asynchronous.
>
> Kind regards,
>
> Martijn Brinkers
>