From: stanislav shalunov <shalunov(_at_)internet2(_dot_)edu>
...
It appears that astro.cs.utk.edu has transmitted the message at least
five times, with probably sendmail running with `-q30m' option, the
message was transmitted successfully, but astro.cs.utk.edu didn't
learn about the success at least the first four times.
The only reasonable explanation for this behaviour would be that
odin.ietf.org is in violation of RFC1047 (or that astro is broken,
which is ruled out by the fact that there are numerous messages from
various places sent to various ietf.org lists that arrived in
duplicates and triplicates). ...
Please consider the rest of RFC 1047, and note that while other messages
have been duplicated, only that one was multipled a dozen times. That
suggests that the problem with that message is more on astro.cs.utk.edu,
perhaps because astro.cs.utk.edu is running a short timeout and ietf.org
was so busy pumping viruses and warnings that ietf.org was repeatedly
exceding that short timeout. Of course it could have been some other
problem at astro.cs.utk.edu, or perhaps something in the message
triggered a long delay at ietf.org.
Since at least about 8.11.1, sendmail has had a default hour or two
timeout for the DATA command. The fact that the messages from
astro.cs.utk.edu were coming more frequently than once an hour is evidence
that it has shorter than default sendmail timeout, and might be related
those duplicates. As I recall, sendmail 5 in the mid-1980's had what
comments in sendmail.cf called a non-standard long timeout. I don't have
convenient access to a 8.9.3 sendmail such as appears to be running on
astro.cs.utk.edu, but I bet the default timeout for 8.9.3 was longer than
the delays between some of its duplicate messages.
A secondary use of a bulk mail detecting checksumming system like that
described at http://www.rhyolite.com/dcc/ is watching such problems.
This is the DCC header from what is so far the 11th and last duplicate
copy of the message (not counting my directly addressed copy and one
of the copies via ietf.org):
} X-DCC-RHYOLITE-Metrics: calcite.rhyolite.com 101; IP=249 env_From=ok From=23
} Subject=many Message-ID=13 Received=13 Body=13 Fuz1=13
The count on the Received: header is for the textually last, usually
temporally first one.
This morning (7/27) ietf.org or optimus.ietf.org claims via the HELP
command to be running Sendmail 8.9.1a. There are reasons that many
people consider sufficent to switch from ancient 8.9 to current 8.11.4
or even 8.12.0.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com