On Thu, Apr 16, 2009 at 3:32 PM, Markus Wiederkehr
<[email protected]> wrote:
> 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...
i'm not sure that an unchecked close is correct in this case. i would
prefer to see an IO action in a finally wrapped in a exception
handling block eg
try { ...
transport.sendMessage(message, addr);
} finally {
try {
transport.close();
} catch (Exception e) {
getLog().warn("Failed to cleanly close connection to remote server", e);
}
}
if the action needs to be repeated then a boolean should be used. this
should ensure that both exceptions are logging and the appropriate one
processed.
FWIW i would support altering the code without the additional boolean
> But has anyone ever experienced something like this? And maybe is
> there a workaround?
(hopefully stefano or norman will jump in here)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
