Re: client requests ending \012

Philip Hazel <ph10@cus.cam.ac.uk> Tue, 25 July 2000 18:58 UTC

Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01610 for <drums-archive@odin.ietf.org>; Tue, 25 Jul 2000 14:58:51 -0400 (EDT)
Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA02836; Tue, 25 Jul 2000 14:53:26 -0400 (EDT)
Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 25 Jul 2000 14:53:24 -0400
Received: by cs.utk.edu (cf v2.9s-UTK) id OAA02817; Tue, 25 Jul 2000 14:53:24 -0400 (EDT)
Received: from draco.cus.cam.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id OAA02783; Tue, 25 Jul 2000 14:53:21 -0400 (EDT)
Received: from draco.cus.cam.ac.uk (131.111.8.18 -> draco.cus.cam.ac.uk) by cs.utk.edu (smtpshim v1.0); Tue, 25 Jul 2000 14:53:21 -0400
Received: from ph10 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 3.16 #3) id 13H9pL-0002f0-00; Tue, 25 Jul 2000 19:53:15 +0100
Date: Tue, 25 Jul 2000 19:53:15 +0100
From: Philip Hazel <ph10@cus.cam.ac.uk>
To: Michael Scharff <mscharff@real.com>
cc: drums@cs.utk.edu
Subject: Re: client requests ending \012
In-Reply-To: <4.3.2.7.2.20000725093157.00af95f0@mail.real.com>
Message-ID: <Pine.SOL.4.21.0007251940170.9644-100000@draco.cus.cam.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
List-Unsubscribe: <mailto:drums-request@cs.utk.edu?Subject=unsubscribe>

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,
ph10@cus.cam.ac.uk      Cambridge, England. Phone: +44 1223 334714.