From: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>
...
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)
I doubt NetBSD changed the timeouts, but given the age of the system
implied by its running sendmail 8.9.3, it would be as hard to check that.
the problem could also be in the network - if connectivity between here
and there were sufficiently lousy.
Given the lack of problems evident in the delivery of viruses and warnings,
any relevant connectivity problems would have to be closer to cs.utk.edu
than ietf.org. The clock-like regularity of the duplicates argues against
simple connectivity problems. One would expect connectivity problems to
sometimes happen before all of the message got to ietf.org, but instead
the failures always seemed to happen after the body and before the status
reply. Of course, that's sugestive and not proof. I strongly suspect
Keith Moore is mistaken about his timeouts, but as long as the problem
does not reappear, that is irrelevant.
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.
Until and unless the problem reappears, that is the right tactic.
isn't your finger tired of pointing by now?
No, but what about your shield against any hint of blame? Do you think
no one has noticed that you've changed your all of tune except your outrage
that anyone noticed that your system and only your system was spewing?
That your system probably screwed up and and certainly spewed many copies
of one of your messages, and you didn't notice until it was pointed out
to you is nothing to brag or to get excited about. Instead of waving your
arms and shouting that it must have been the IESG's, the NetBSD project's,
or someone, anyone else's fault, take it as a reason to affect (if not
adopt) a little humility.
No one around is divinely ordained to provide standards exegesis. That
an idea comes from someone other than Keith Moore does not make it
automatically wrong. It makes no sense to require that we be so generous
in what we accept that we accept the viruses that have flooded this list
simply because they are RFC conformant. That spewing vCards to many
people who have no way to use them and less interest is itself probably
harmless is not sufficient reason to worry about inadvertently stopping
it if we also stop the viruses and warnings. That encoding simple ASCII
text into two different base64 MIME attachments (as some have done) is
conformant does not make it acceptable in this mailing list.
Rejecting all base64 and any message larger than about 100K is a great
idea. It would reject the viruses, but not the IETF announcement
traffic or any reasonable I-D. 90% of the RFC's in my private stash
are smaller than 100KBytes. This tactic would not solve the vacation
message problem, but that is separate.
I think that would take about 3 new lines and one changed line in a
sendmail 8.11 sendmail.cf. The same lines might work in 8.9.1a, but
I don't remember if the new sendmail header matching facility was in 8.9.
8.9 was long before Melissa, wasn't it?
By my fading recollections, the message size limit was enforced per-mailer
in 8.9 and before, so that it should be straight forward to allow the
ietf.org machines to pass bloated I-D's and RFC's, if that is necessary.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com