As per Relevance of the word duplicate, we have this rfc below:
Network Working Group Craig
Request for Comments: 1047 CIC at BBN
February 1988
DUPLICATE MESSAGES AND
STATUS OF THIS
An examination of a synchronization problem in the Simple
Transfer Protocol (SMTP) is presented. This synchronization
can cause a message to be delivered multiple times. A method
avoiding this problem is suggested. Nodding familiarity with
SMTP specification, RFC-821, is required. Distribution of this
is unlimited
Over the past few years, the staff of the CSNET Coordination
Information Center (CIC) has often been asked to help determine why
single mail message is being delivered multiple times to
recipients. In the process of tracing the problems of
delivery, we have discovered that many duplicate messages are
result of a synchronization problem in SMTP. There is a point in
process of delivering a message where the receiving mailer knows
has accepted the message but the sending mailer is still not sure
message has been reliably delivered. If the SMTP conversation
broken at this point, the sending mailer will be forced to re-
the message, even though the message has already been received
delivered by the receiving mailer
DESCRIPTION OF THE
The synchronization problem occurs at the end of delivering
message. When the sending mailer has finished sending the text of
message, it is required to send a line containing a single dot
period. When the receiving mailer receives this final dot, it
expected to do its final message processing and either
receipt of the message (with a 250 reply) or reject the message
any one of several error codes
Observe that there is a potential synchronization gap here.
the period between the time the receiving mailer has determined
it will accept the message, and the time that sending mailer gets
250 reply, the message is active at both the sending and
mailer. Until the sending mailer gets the 250 reply, it must
the message was not delivered. After the receiving mailer
Partridge [Page 1]
RFC 1047 DUPLICATE MESSAGES AND SMTP February 1988
decided to accept the message, it must assume the message has
delivered to it. If the communications link fails during
synchronization gap, then the message has been duplicated.
mailers have active copies of the message that they will try
deliver
It may be hard to believe that this problem is the cause of
duplicate messages. Intuitively, one might expect that the
spent in the state between the final dot and its accepting 250
is quite small. In practice, however, this period is often
long; long enough that timeouts by the sending mailer (or
network failures) are quite common. Observations by the
suggest that this synchronization problem may be the second
cause of duplicate messages on the Internet (second to mail loops).
Many mailers delay responding to the final dot because they are
sophisticated processing of the message, in an attempt to
that they can deliver the message. For example, the mailers
expand an entire mailing list to confirm that it can reach
addressees or may attempt to physically deposit the message into
mailboxes of local users, before confirming receipt of the final dot
These practices are not unreasonable, but they often cause
synchronization gap to continue for several minutes, and increase
likelihood that the sending mailer will timeout or the network
fail before the accepting 250 reply is sent
AVOIDING SYNCHRONIZATION
The best way to avoid the synchronization problem is to minimize
length of the synchronization gap. In other words, receiving
should acknowledge the final dot as soon as possible and do
complex processing of the message later
RFC-821 (on page 22) states that unless the receiving mailer
completely unable to process a message it should accept the
and acknowledge any errors in processing in a separate message
messages sent back to the originator of the message. As a result
receiving mailers should be able to acknowledge the final dot as
as the message has been safely put in a non-volatile (e.g., disk
queue for further processing. Fast acceptance of a message does
violate RFC-821.
Some mailers can be configured to do more or less processing
receipt of the final dot. In such situations, the mailer
always be configured to do less processing
Finally, some mailers allow remote mailers only a minute or two
acknowledge the final dot before timing out and trying again.
Partridge [Page 2]
RFC 1047 DUPLICATE MESSAGES AND SMTP February 1988
the increasing round-trip times on the Internet, and that
processing after the final dot is required, the timeout for reply
the final dot should probably be at least 5 minutes and a timeout
10 minutes would not be unreasonable
Partridge [Page 3]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
