> Yup. The problem with bare linefeeds is simple: their
> interpretation is ambiguous on a Unix machine.
This is an oversimplification. Unix machines are perfectly capable of
interpreting bare LFs in whatever way the spec might say they should.
There is a practical problem because MTA and MUA implementations like
to allow the use of standard Unix tools to process messages; this can
be considered an implementation issue, although it's a big one.
> Given the differing interpretations of bare linefeeds and
> carriage-returns, they must be disallowed by the SMTP specification,
Certainly, given that sendmail munges them (or at least used to), the
spec should disallow them, and the DRUMS draft does.
> and they must not be accepted by SMTP clients or servers.
This is a matter of philosophy. The IETF tendency on such matters is
to regularly mandate that servers must accept invalid data as long as
the data can be interpreted. I don't agree with this philosophy, at
least for the initial deployment of a protocol ("be liberal in what
you accept" increases robustness now at the expense of encouraging
interoperability problems later), but it is somewhat defensible.
The DRUMS draft should probably become clearer about the proper
interpretation of a bare LF before it becomes a standard, if it ever
does. (Given that it has much more precisely specified grammar rules
than RFC 822 does, I would love to see it become a standard, but I
don't know how likely that is.)
