I am cross-posting this because the discussion originated on the 822
list but my response belongs mostly on the SMTP list (although only
'mostly'). Any responses on that set of issues should probably go to
the latter list to avoid clutter.
Quoting DRB(_at_)relay(_dot_)prime(_dot_)com (>) and
[I'd rather count lines in 1154! After all the only real problem with lines
is that some older mailers wrap illegally. I suspect those mailers will get
fixed as they get upgraded to 8-bit SMTP... ]
# Many of the offending MTAs are already 8-bit capable. There is no need to
# upgrade them, and even if the future of SMTP provides us an upgrade (which
# is FAR from evident at this point) we cannot possibly rely on this for the
# purposes of RFC-XXXX.
Some of the little exchanges that occur between the gaps in this
discussion are quite interesting. Here we have one of the major
advocates of a position that I hope I can describe with reasonable
accuracy as "most SMTP implementations don't need conversion to handle
8bit transport, so let's take advantage of that and just tell the [tiny
minority] of 'others' to clean up their acts" saying, more or less
"well, everyone who wraps at below 1000 octet lines will stop doing that
when they convert". If the main proposition is correct, then we have
very few conversions, so the problem remains. Unless David really wants
to assert that no existing putatively 8-bit-clean implementation does
line wrapping... :-).
So, let me reinforce Ned's response with a slightly different answer.
We have always, since the dawn of inter-host email, had serious problems
regulating the behavior of mail gateways from other environments.
People have been talking about, and postponing, creation and
standardization (in one way or another) of a strong "mail gateway
requirements RFC" for years--recognition of the problem and the
difficulties with fixing it predate RFC821 and 822.
One of the origins of the problem is that, if you write an absolute rule
about wrapping, so what? Real mail gateways do what they think they
have to do to get the traffic through, and we don't disconnect hosts for
distorting mail. We also lack protocol police, protocol judges, and
protocol jails, especially in this area. Even if we created strong
rules, they would not help: Suppose a message originates on a
non-Internet "long-lines" host, A, and is transferred to a non-Internet
"short lines" host, B, which wraps (rather than, e.g., encapsulating,
for all the reasons that have caused the 822 list to hold encapsulation
in disfavor). Some of the destinations go by way of C, a "long-lines"
non-Internet host, but nothing we have written, or can write, can
require B to tell C that wrapping occurred or how to undo it. And C
turns out to be, or to forward to, an Internet gateway for some of the
messages. Now we have something that has been seriously wrapped. And,
even if all of those hosts are using clones of 822 (or even of XXXX),
these are mail-gateway-authority transport modifications and everyone is
in a state of grace relative to the pairs of networks they are mapping
We really have ample experience to make strong statements. If one is
going to do anything that really depends on the integrity of
"lines"--either number or length-- then transport encodings that needed
that preserve line-boundaries as invariants and treat transport-end-
of-line as arbitrary noise. (As has been observed, those encodings
should probably carry checksums on the unencoded text, too.) I think
Base64 is still such a transport encoding, although a few of the
comments in the checksum discussion cause me to wonder.)
While I wouldn't have agreed with David a month ago, I would have been a
little sympathetic to the argument that the "wrappers" would gradually
be fixed under user pressure. But I've been struggling lately with a
production "other system to Internet via transformations in and out of
X.400" gateway that is wrapping, and wrapping at about 65 characters (a
limit shorter than our group paranoia deemed necessary). I can tell the
vendors that what they are doing is stupid, but they aren't breaking any
rules. [Since the actual internet gateway is operated by the
organization that employs the IAB Chair, the IESG Secretary, and the
mail WG chair, and that used to employ the IETF chair, we can assume
*they* are being scrupulous about the rules, right? :-)].
OK, I'd "rather" count lines too. But the only real problem with lines
is that they don't work as a unit of measure and neither does anything
that depends on their integrity during transport modifications.