I have a problem with a manufacturer of a certain anti-virus e-mail
gateway. This particular mail receiver closes the TCP connection after
receiving the terminating <CRLF>.<CRLF> indicator of the DATA command
without waiting for a QUIT command to be sent by the client (James in
this case).
This is a clear violation of RFC 5321 which says that "the receiver
MUST NOT intentionally close the transmission channel until it
receives and replies to a QUIT command".
Unfortunately the manufacturer is aware of this fact but still refuses
to change the behavior of the software. They claim that this behavior
is common for bigger providers in order to avoid DDOS attacks and save
port numbers (which is BS in my opinion).
Anyway, RemoteDelivery uses the Java Mail API to send the message,
something like this:
try { ...
transport.sendMessage(message, addr);
} finally {
transport.close();
}
So sendMessage() succeeds but close() throws a MessagingException and
James (correctly) thinks it has to send the message again. As a
consequence the recipient receives the same message several times
until James gives up permanently.
Now, I do not ask for a modification in James since the problem
clearly lies on the recipient's side...
But has anyone ever experienced something like this? And maybe is
there a workaround?
Thanks in advance,
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
