home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1000s / rfc1047.txt < prev    next >
Text File  |  1988-02-24  |  6KB  |  171 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                   Craig Partridge
  8. Request for Comments: 1047                              CIC at BBN Labs
  9.                                                           February 1988
  10.  
  11.  
  12.                       DUPLICATE MESSAGES AND SMTP
  13.  
  14.  
  15. STATUS OF THIS MEMO
  16.  
  17.    An examination of a synchronization problem in the Simple Mail
  18.    Transfer Protocol (SMTP) is presented.  This synchronization problem
  19.    can cause a message to be delivered multiple times.  A method for
  20.    avoiding this problem is suggested.  Nodding familiarity with the
  21.    SMTP specification, RFC-821, is required.  Distribution of this memo
  22.    is unlimited.
  23.  
  24. INTRODUCTION
  25.  
  26.    Over the past few years, the staff of the CSNET Coordination and
  27.    Information Center (CIC) has often been asked to help determine why a
  28.    single mail message is being delivered multiple times to its
  29.    recipients.  In the process of tracing the problems of multiple
  30.    delivery, we have discovered that many duplicate messages are the
  31.    result of a synchronization problem in SMTP.  There is a point in the
  32.    process of delivering a message where the receiving mailer knows it
  33.    has accepted the message but the sending mailer is still not sure the
  34.    message has been reliably delivered.  If the SMTP conversation is
  35.    broken at this point, the sending mailer will be forced to re-deliver
  36.    the message, even though the message has already been received and
  37.    delivered by the receiving mailer.
  38.  
  39. DESCRIPTION OF THE PROBLEM
  40.  
  41.    The synchronization problem occurs at the end of delivering a
  42.    message.  When the sending mailer has finished sending the text of a
  43.    message, it is required to send a line containing a single dot or
  44.    period.  When the receiving mailer receives this final dot, it is
  45.    expected to do its final message processing and either confirm
  46.    receipt of the message (with a 250 reply) or reject the message with
  47.    any one of several error codes.
  48.  
  49.    Observe that there is a potential synchronization gap here.  During
  50.    the period between the time the receiving mailer has determined that
  51.    it will accept the message, and the time that sending mailer gets the
  52.    250 reply, the message is active at both the sending and receiving
  53.    mailer.  Until the sending mailer gets the 250 reply, it must assume
  54.    the message was not delivered.  After the receiving mailer has
  55.  
  56.  
  57.  
  58. Partridge                                                       [Page 1]
  59.  
  60. RFC 1047              DUPLICATE MESSAGES AND SMTP          February 1988
  61.  
  62.  
  63.    decided to accept the message, it must assume the message has been
  64.    delivered to it.  If the communications link fails during this
  65.    synchronization gap, then the message has been duplicated.  Both
  66.    mailers have active copies of the message that they will try to
  67.    deliver.
  68.  
  69.    It may be hard to believe that this problem is the cause of many
  70.    duplicate messages.  Intuitively, one might expect that the time
  71.    spent in the state between the final dot and its accepting 250 reply
  72.    is quite small.  In practice, however, this period is often quite
  73.    long; long enough that timeouts by the sending mailer (or possibly
  74.    network failures) are quite common.  Observations by the author
  75.    suggest that this synchronization problem may be the second leading
  76.    cause of duplicate messages on the Internet (second to mail loops).
  77.  
  78.    Many mailers delay responding to the final dot because they are doing
  79.    sophisticated processing of the message, in an attempt to confirm
  80.    that they can deliver the message.  For example, the mailers may
  81.    expand an entire mailing list to confirm that it can reach all
  82.    addressees or may attempt to physically deposit the message into the
  83.    mailboxes of local users, before confirming receipt of the final dot.
  84.    These practices are not unreasonable, but they often cause the
  85.    synchronization gap to continue for several minutes, and increase the
  86.    likelihood that the sending mailer will timeout or the network will
  87.    fail before the accepting 250 reply is sent.
  88.  
  89. AVOIDING SYNCHRONIZATION PROBLEMS
  90.  
  91.    The best way to avoid the synchronization problem is to minimize the
  92.    length of the synchronization gap.  In other words, receiving mailers
  93.    should acknowledge the final dot as soon as possible and do more
  94.    complex processing of the message later.
  95.  
  96.    RFC-821 (on page 22) states that unless the receiving mailer is
  97.    completely unable to process a message it should accept the message
  98.    and acknowledge any errors in processing in a separate message or
  99.    messages sent back to the originator of the message.  As a result,
  100.    receiving mailers should be able to acknowledge the final dot as soon
  101.    as the message has been safely put in a non-volatile (e.g., disk)
  102.    queue for further processing.  Fast acceptance of a message does not
  103.    violate RFC-821.
  104.  
  105.    Some mailers can be configured to do more or less processing upon
  106.    receipt of the final dot.  In such situations, the mailer should
  107.    always be configured to do less processing.
  108.  
  109.    Finally, some mailers allow remote mailers only a minute or two to
  110.    acknowledge the final dot before timing out and trying again.  Given
  111.  
  112.  
  113.  
  114. Partridge                                                       [Page 2]
  115.  
  116. RFC 1047              DUPLICATE MESSAGES AND SMTP          February 1988
  117.  
  118.  
  119.    the increasing round-trip times on the Internet, and that some
  120.    processing after the final dot is required, the timeout for reply to
  121.    the final dot should probably be at least 5 minutes and a timeout of
  122.    10 minutes would not be unreasonable.
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Partridge                                                       [Page 3]
  171.