Greg Hudson writes:
> > Yup. The problem with bare linefeeds is simple: their
> > interpretation is ambiguous on a Unix machine.
>
> This is an oversimplification.
I don't believe so. Email messages consist of lines of text. While
in transit, those lines are separated by the Tenex newline, CRLF.
When stored on the destination system, the lines are separated by the
local newline. Therefore, lines in email cannot contain any
characters which may be interpreted as local newlines. Fortunately,
this is only CR and LF.
> > 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.
No one would ever send bare CR's and/or LF's if servers didn't accept
them. "Be liberal in what you accept" allows people to put broken
clients into production and makes it politically difficult to get them
repaired.
It's a much, much better philosophy for servers to be strict in what
they accept. That way, you never get broken (protocol-violating)
clients deployed.
Life *is* change. You can detect the absence of life by the absence
of change. "Be liberal in what you accept" means accepting multiple
versions of a protocol. This allows for change. It doesn't mean
accepting anything thrown down your gullet, and choosing one of
multiple interpretations of it.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | "Ask not what your country
521 Pleasant Valley Rd. | +1 315 268 1925 voice | can force other people to
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | do for you..." -Perry M.
