Subject: RE: client requests ending \012

From: Michael Scharff <[email-masked]>
Date: Tue, 25 Jul 2000 15:02:19 +0100

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:[email-masked]]

> Sent: Tuesday, July 25, 2000 11:53 AM

> To: Michael Scharff

> Cc: [email-masked]

> 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,

> [email-masked]      Cambridge, England. Phone: +44 1223 334714.

---

From: "Larry Osterman" <[email-masked]>
Date: Tue, 25 Jul 2000 14:39:28 -0700

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 :)

> From: Philip Hazel [mailto:[email-masked]]

---

From: Maurizio Codogno <[email-masked]>
Date: Wed, 26 Jul 2000 11:26:49 +0200 (MET DST)

> From: Edward Hibbert <[email-masked]>

> I disapprove of the "must not recognise" text.  I think that:
> - existing implementations will ignore this text in the proven interest of
> interoperability
> - any new implementor who follows the RFC will become very frustrated when
> it later emerges that the RFC is explicitly encouraging them to add interop
> problems to their code.

but this means that you explicitly defy the scope of the standard,
approving bad implementations and mandating good guys to accept
them.

ciao, .mau.

---

From: Charles Lindsey <[email-masked]>
Date: Wed, 26 Jul 2000 19:31:43 +0100 (BST)

On Wed, 26 Jul 2000 13:08:56 -0400
	Keith Moore <[email-masked]> said...

> 
> > Naked LF should not be found in a conforming message
> 
> naked LF is valid in RFC 822.
> (though it's highly likely to be converted to CRLF by some MTA)
> 
Ah! But I see that it is not allowed in MESSFOR. But presumably MTAs
will need to cope with stuff that conformed to the old standard for some
considerable time.

FWIW, it will not be allowed in the new USEFOR.

Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     [email-masked]  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9     Fingerprint: 73 6D C2 51 93 A0 01 E7  65 E8 64 7E 14 A4 AB A5