RFC 1047 (rfc1047) - Page 2 of 3

Duplicate messages and SMTP

RFC 1047              DUPLICATE MESSAGES AND SMTP          February 1988


   decided to accept the message, it must assume the message has been
   delivered to it.  If the communications link fails during this
   synchronization gap, then the message has been duplicated.  Both
   mailers have active copies of the message that they will try to
   deliver.

   It may be hard to believe that this problem is the cause of many
   duplicate messages.  Intuitively, one might expect that the time
   spent in the state between the final dot and its accepting 250 reply
   is quite small.  In practice, however, this period is often quite
   long; long enough that timeouts by the sending mailer (or possibly
   network failures) are quite common.  Observations by the author
   suggest that this synchronization problem may be the second leading
   cause of duplicate messages on the Internet (second to mail loops).

   Many mailers delay responding to the final dot because they are doing
   sophisticated processing of the message, in an attempt to confirm
   that they can deliver the message.  For example, the mailers may
   expand an entire mailing list to confirm that it can reach all
   addressees or may attempt to physically deposit the message into the
   mailboxes of local users, before confirming receipt of the final dot.
   These practices are not unreasonable, but they often cause the
   synchronization gap to continue for several minutes, and increase the
   likelihood that the sending mailer will timeout or the network will
   fail before the accepting 250 reply is sent.

AVOIDING SYNCHRONIZATION PROBLEMS

   The best way to avoid the synchronization problem is to minimize the
   length of the synchronization gap.  In other words, receiving mailers
   should acknowledge the final dot as soon as possible and do more
   complex processing of the message later.

   RFC-821 (on page 22) states that unless the receiving mailer is
   completely unable to process a message it should accept the message
   and acknowledge any errors in processing in a separate message or
   messages sent back to the originator of the message.  As a result,
   receiving mailers should be able to acknowledge the final dot as soon
   as the message has been safely put in a non-volatile (e.g., disk)
   queue for further processing.  Fast acceptance of a message does not
   violate RFC-821.

   Some mailers can be configured to do more or less processing upon
   receipt of the final dot.  In such situations, the mailer should
   always be configured to do less processing.

   Finally, some mailers allow remote mailers only a minute or two to
   acknowledge the final dot before timing out and trying again.  Given



Partridge