--On Saturday, 10 September, 2005 11:01 +0200 Arnt Gulbrandsen
<arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no> wrote:
Valdis Klētnieks writes:
Content-Length: was tried and failed already. It totally
blows chunks if you hit a gateway that has to do an
8bit->7bit conversion or other rewriting (there's still the
occasional %-hack usage, or just canonifying to a FQDN in a
From:/To:/cc:/whatever:).
That's not it. Frank meant that the Received should log the
body length as seen at that hop, for easier pinpointing of
where munging happened.
Not justified by this problem, IMO, but possibly justified
never the less. There's other munging, there are other bugs,
and I at least have wondered where in the chain it happened.
Could an optional 'length <nonzero>' clause be added to the
received field without restarting the standards clock?
Personal opinions:
(1) It isn't clear. In retrospect, we probably should have
tried to more nearly match existing practice (in which all sorts
of commentary get put into Received fields) by making
Opt-info = [Via] [With] [ID] [For] [More-stuff]
where More-stuff would be something like
More-stuff = Keyword-atom String
and with some syntax or handwaving about Keyword-Atom
But we didn't. Whether we could now make that change on the
basis that it was really an error in 2821 to not provide this
additional syntax, that it reflects at least some existing
practice, and the practice is, at worst, harmless would require
a discussion with the ADs and the community, but it seems
plausible to me.
(2) I am not at all persuaded that adding explicit provision for
a "length when it got to me" clause would justify the energy
that would be needed to even ask the question above. As others
have pointed out, lengths on email message bodies are extremely
fragile. Determining where transparancy rules were improperly
applied requires detecting one-octet changes, and getting there
just about requires either a canonicalization algorithm or a
very precise statement about what gets counted. While stuffing
in a bit of syntax wouldn't be hard, those sorts of things would
be.
One more observation, from another note...
Amazingly, the sendmail SMTP client didn't dot-stuff by
default. The unix vendor for which both I and the affected
recipients worked had neglected to change this in its
sendmail.cf.)
<rant>
The technical term for this behavior is "bug". 821 is
sufficiently clear on the subject that even the idea of an SMTP
sender that can even be configured to not dot-stuff falls
somewhere between "bad design" and "nonconformance". Now, if
the sendmail client you had was of the vintage I suspect it was,
I can imagine why that option might have been there and even
been the default. But today, with Internet mail as dominant as
it has become and with the skill level of the average
do-it-yourself sysadmin having declined significantly, there
would seem to be little excuse for still having that behavior.
I hope it is a mistake not easily made any more.
Similarly, failure to un-stuff is a bug.
But, then again, I get badly irritated every time I see an
instance of
From
in a message on my screen that didn't start out that way, when I
see a line of text in an I-D that starts ">From" (at least one
was posted last week), and so on. We know how to do this right
and the behavior is just plain sloppy and careless. At the same
time, we should remember how often it is gotten wrong every time
we consider a new feature that requires servers to do something
subtle, like counting characters correctly.
</rant>
john