RE: client requests ending \012

[Michael Scharff <[e-mail]>]

I don't disagree with this philosophy at all. What I have issue with is that we appear to be expanding the RFC's to include these "gentlemen's agreements" instead of holding true to the original concept that you describe below. If anything , we have taken it to the extreme in the name of "interoperability". As I stated before, there will always be "rogues" and "non-conformists", however, this doesn't mean that we should relax the standard to the point where there is no standard at all.




At 02:39 PM 7/25/00 -0700, Larry Osterman wrote:

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].
>