RE: client requests ending \012

["Larry Osterman" <[e-mail]>]

I've been keeping quiet for quite some time now, but I gotta chime in
right now:


Even if 821bis has a MUST that CRLF is the line terminator (and not just
LF), this only means that a server MUST treat CRLF as a line terminator,
and that a conforming client MUST generate only CRLF characters.

It says NOTHING about what a particular implementation choses to accept
in the face of broken clients.  When faced with a client that sends only
LF, an SMTP server vendor has two choices that they can make:
	1) Say to the author of the client: "You are violating the
protocol, fix your client (neener neener :))"
or	2) Change the server to also accept LF as a line terminator (be
liberal in what you accept, conservative in what you generate).

There is nothing in 821bis that says that a server MUST NOT accept LF as
a line terminator, all that 821bis does is to specify the conforming
on-the-wire format for the SMTP protocol.  A server vendor can still
choose (for the sake of interoperability) to accept input from non
conforming clients, that's their choice.  However a vendor does not HAVE
to accept input from a non conforming client, and having an explicit
prohibition against LF (or if you'd rather, an explicit endorsement of
CRLF) in the protocol provides amunition for a server vendor that wants
to say #1.  If the specification is mute, then the client vendor can say
(as they did to Philip below) "but [sendmail|qmail|whatever] accepted my
input, your server must be the broken one".

I've been reading the recent debate with a great deal of amusement, this
issue (and the issue involving arguments to DATA and RSET) make it clear
to me that some of the people reading the list have forgotten one of the
principal tenets of IETF protocol design:

There is nothing in 821bis (or any other IETF protocol) that prevents
servers from chosing to accept inputs that are NOT covered by 821bis
(arguments to DATA and RSET, or raw LF's as line terminators, for
example), but if they do so, they are doing it between concenting adults
and outside the protocol.

As long as a server/client accepts ALL legal inputs as defined by
821bis, and produces output that is in conformance with 821bis, it's an
821bis server.  Anything else falls into the area of gentleman's
agreements.

What the protocol definition does is to describe what you MUST do to
claim to be 821bis, and it provides amunition for those who ARE 821bis
to try to convince those who are NOT 821bis to change.  It is NOT
intended to be a comprehensive implementors guide, neither is it
intended to be a document that describes every possible situation that
might be encountered in internet email (some of the strawmen brought up
during the "must say quit" debate come to mind on that respect).

(And before anyone rakes me over the coals, I know that Nick Shelness
and Keith Moore have both said what I said multiple times, I just
thought it needed to be said still one more time).



Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000
and Exchange Platinum!  Please notify the sender of any difficulties.

I'm an individual, and nothing I say should be considered an official
policy of Microsoft :)


> -----Original Message-----
> From: Philip Hazel [mailto:[e-mail]]
> Sent: Tuesday, July 25, 2000 11:53 AM
> To: Michael Scharff
> Cc: [e-mail]
> Subject: Re: client requests ending \012
> 
> 
> On Tue, 25 Jul 2000, Michael Scharff wrote:
> 
> > I have to chime in here and protest such a response. This 
> sounds like a 
> > good reason to go back and insure that CRLF is a MUST and 
> NOT considered 
> > optional in ANY CASE. 
> 
> The problem is historical baggage. I can't remember the 
> details, but the 
> reason I changed Exim was something like this: There was a 
> company that 
> had a server running Sendmail or Smail (I can't remember which) and a 
> whole slew of local clients. They changed the server to Exim, 
> and some 
> clients stopped working. The clients were running software 
> for which the 
> source was not available. Management's attitude was "The 
> clients used to
> work, so they should continue to work."; the technical guys 
> didn't want to
> go back. Maybe I'm too kind hearted, but I listened to their plea for 
> help.
> 
> It's the old, old story: if a non-conformance gets widely spread, 
> something will exploit it, and you can never claw back to strict 
> conformance. Once some widely used server is "liberal in what it 
> accepts", everybody else has to follow suit. Look at PP; it tried to 
> implement the RFC "correctly", even to the extent of 
> rejecting messages
> without a Date: header line (just one example). This just caused 
> trouble.
> 
> -- 
> Philip Hazel            University of Cambridge Computing Service,
> [e-mail]      Cambridge, England. Phone: [phone].
>