Re: client requests ending \012

[[e-mail] (Kai Henningsen)]

[e-mail] (Philip Hazel)  wrote on 25.07.00 in <[e-mail]>:

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

There's an answer to this. Unfortunately, it takes a significant amount of  
work, so it's not very likely to be actually employed.

That is, whenever you enable non-RFC behaviour, make it depend on an  
option that says, for example, break_rfc_allow_linefeed_lineends, and  
defaults to off.

The point being, (a) only those people who think they need it activate it,  
so chances are any odd server you happen to look at will still reject it  
as an error, and (b) people who switch it on *learn* that it conflicts  
with the standard.

I don't expect it to happen, but I do think it would be a good thing.


MfG Kai