Robert Burrell Donkin ha scritto: > 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
+1 >> But has anyone ever experienced something like this? And maybe is >> there a workaround? > > (hopefully stefano or norman will jump in here) I'm using a custom RemoteDelivery but (if I remember correctly) that case should be handled the same. I never had a "duplicate delivery" issue reported. I deliver a lot of mail nowadays, but mainly to italian recipients: maybe the antivirus gateway Markus talks about is not so used in italy. Markus, can you name the product? Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
