Subject: duplicate messages on IETF mailing lists

From: stanislav shalunov <[email-masked]>
Date: 25 Jul 2001 20:38:30 -0400

A number of messages sent to various IETF mailing lists have arrived
in multiple copies.  One such message (just an example that I received
five times) is <[email-masked]>.

According to Received lines, this message was received once by
astro.cs.utk.edu with an internal id of NAA18284 on Wed, 25 Jul 2001
13:53:38 -0400 (EDT).  It was then received by odin.ietf.org
with id NAA16715 on Wed, 25 Jul 2001 13:54:01 -0400 (EDT);
with id OAA18788 on Wed, 25 Jul 2001 14:14:11 -0400 (EDT);
with id OAA21900 on Wed, 25 Jul 2001 14:44:11 -0400 (EDT);
with id PAA25476 on Wed, 25 Jul 2001 15:14:10 -0400 (EDT);
with id PAA28761 on Wed, 25 Jul 2001 15:44:13 -0400 (EDT).

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).  Since odin says it runs Sendmail 8.9.1a,
while in fact that's not what's listening to the incoming SMTP
connections (it looks like smap or some other filter) it's hard to
actually debug anything.

Pure minimal SMTP listener:

$ telnet odin.ietf.org 25
Trying 132.151.1.176...
Connected to odin.ietf.org.
Escape character is '^]'.
220 *********************************2******200**20****0***0*00 *****
EHLO cain
500 Command unrecognized: "XXXX cain"
HELP
500 Command unrecognized: "XXXX"
QUIT
221 ietf.org closing connection
Connection closed by foreign host.

May I suggest installing Postfix or a recent version of Sendmail on
odin.ietf.org?

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

.signature: I/O Error

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 26 Jul 2001 16:27:59 -0600 (MDT)

> From: Keith Moore <[email-masked]>

> ...
> > 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    [email-masked]