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.
astro is using the default timeouts. if those are the wrong timeouts,
blame sendmail. (or NetBSD, if they changed them)
the problem could also be in the network - if connectivity between here
and there were sufficiently lousy.
it should be obvious that there are several potential sources of error,
that the condition was probably caused by a combination of factors,
and that we can't pinpoint the true nature of the problem unless
it recurs often enough that we can diagnose it. (I could have left
the message in the queue for such purposes, but it didn't seem worth
the trouble). Fortunately, unless the problem does recur (which given
history doesn't seem likely), it's already solved.
isn't your finger tired of pointing by now?
Keith