On Thu, Apr 16, 2009 at 8:40 PM, Stefano Bagnara <[email protected]> wrote: > 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
That would solve the problem but I think the behavior of James would then become non-standard compliant. See http://tools.ietf.org/html/rfc5321#section-3.8: "SMTP clients that experience a connection close, reset [...] SHOULD [...] treat the mail transaction as if a 451 response had been received and act accordingly." Maybe a switch would be in order? But if nobody else ever had this problem I can also write a workaround locally without affecting the code base. >>> 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? I would rather not; or at least not until I have spoken to my co-workers. The company is located in Austria but I have no idea how widely the product has been adopted. Markus --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
