> 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
--
Djigzo open source email encryption