Subject: Re: client requests ending \012

From: Charles Lindsey <[email-masked]>
Date: Tue, 25 Jul 2000 13:57:51 +0100 (BST)

On Tue, 25 Jul 2000 09:43:46 +0100 (BST)
	Philip Hazel <[email-masked]> said...

> 
> i've got a problem with javamail. I discovered that all apperances of
> the linefeed character "\n" were changed into an "\r\n" (Carriage
> Return+Linefeed) while sending the mail to the smtpserver. I'm working
> with S/MIME Routines and signed Mails so that all Mails had a bad digest
> (bad signature) because of the changed Mail Body. Is there an option to
> prevent this modification ? 

Which sounds like a good reason not to use S/MIME. PGP (with its '-t'
option) is especially designed to treat all line endings as CRLF,
and to disregard trailing whitespace (but not trailing blank lines,
infortunately).

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

---

From: Michael Scharff <[email-masked]>
Date: Tue, 25 Jul 2000 09:41:26 +0100

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. I don't understand why it is so difficult to simply 
establish a consensus (which it seems pretty obvious to me that there is 
one, at least on this subject) and move forward with it. There are ALWAYS 
going to be "rogues" who choose not to adhere to, or perhaps to not even 
learn, the standards. This is not what we should be focused on, nor is it 
truly feasible either. What we should be doing is determining REAL, VALID, 
TECHNICAL reasons for or against any specific mechanism or procedure, such 
as CRLF . CRLF

---

From: Philip Hazel <[email-masked]>
Date: Tue, 25 Jul 2000 19:53:15 +0100 (BST)

On Tue, 25 Jul 2000, Michael Scharff wrote:

> 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: "Lee Thompson" <[email-masked]>
Date: Tue, 25 Jul 2000 14:16:51 -0700

> TECHNICAL reasons for or against any specific mechanism or procedure, such 

We market a SMTP/POP3 server for win32 platform and have had to make numerous
changes over the years to allow one client (or server) or another interoperate
with us.

Unfortunately most IT people aren't interested in "that client isn't working
to spec" -- they're in the position of having all of their deployed client
software working with the server -- and if ours doesn't - they'll go to
someone else.

The SMTP/Message Format system currently in use is a mess.  We have nearly 20
years of standard drift and those standards are vague in some areas.   For
better or for worse the internet is now a commercial environment which means
interoperability and reliability are the key factors.

I do think the revised spec should tighten the standard down -- but I also
think MTAs should be liberal in what they accept.

Anyway my 2 cents :)

-- 
Lee Thompson                       [email-masked]
Seattle Lab Inc.           http://www.seattlelab.com
Software Engineer                      ICQ: 19545760

---

From: Tony Hansen <[email-masked]>
Date: Tue, 25 Jul 2000 17:34:58 -0400

For DATA, our internal SMTP server keeps reading until it sees a block
of data ending in crlf.crlf or it times out. Only on the timeout does it
then check to see if there was a lf.lf. Yes, we'll recognize it, but a
client that sends it is going to get lousy performance. Seems like a
reasonable tradeoff.

	Tony Hansen
	[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Jul 2000 18:17:06 -0400

>>>>> "Lee" == Lee Thompson <[email-masked]> writes:
    Lee> We market a SMTP/POP3 server for win32 platform and have had to make
    Lee> numerous changes over the years to allow one client (or server) or
    Lee> another interoperate with us.

    Lee> Unfortunately most IT people aren't interested in "that client isn't
    Lee> working to spec" -- they're in the position of having all of their
    Lee> deployed client software working with the server -- and if ours
    Lee> doesn't - they'll go to someone else.

  Some group, e.g. IMC or some such, needs to actually test against the spec.

   :!mcr!:            |  Solidum Systems Corporation, http://www.solidum.com
   Michael Richardson |For a better connected world,where data flows faster<tm>
 Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html
	mailto:[email-masked]	mailto:[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Jul 2000 03:48:47 -0700

>interoperability and reliability are the key factors.

There is truth in what you observe, but it does not apply to CRLF.  If 
anything the standards drift is due to constantly making local changes to 
accept non-conforming behavior.  It is the norm for email.

Imagine if folks had taken that approach for TCP...

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Jul 2000 03:46:43 -0700

>go back. Maybe I'm too kind hearted, but I listened to their plea for

You took a quality approach to responding to a customer problem.  The line 
"it worked with the competition's software" pretty much left you with no 
choice about making a change.

The difficulty is with imposing a fix for a local problem as a global 
product default.

d/

=-=-=-=-=

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Jul 2000 09:35:13 -0400

> The difficulty is with imposing a fix for a local problem as a global

except that it's not purely a local problem - the same clients could
(and often do) crop up anywhere.  and the vendor ends up dealing with
this support issue again and again.  much easier to just 'fix' the 
problem.

I'd say that the difficulty is one of trying to get people to accept
near-term pain to minimize long-term pain.  and also the difficulty of
replacing many broken clients when you can "fix" the problem on a small 
number of servers.

Keith

this may actually be a "flaw" in the traditional IETF notion of 
interoperability testing being sufficient - merely being able to 
interoperate doesn't mean that the implementations conform to the 
standard, or more importantly, that the implementations behave 
robustly in corner cases (like LF . LF in the middle of a message).

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Jul 2000 11:33:38 -0700

>except that it's not purely a local problem - the same clients could

The context of my statement was not a general discussion about Things 
Around the Net.

We were told of a specific situation that forced the change to the code.

That specific situation was local.

d/

=-=-=-=-=

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Jul 2000 15:34:23 -0400

> That specific situation was local.

perhaps, but the general problem of clients that send bare LF is not.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Jul 2000 12:36:25 -0700

>perhaps, but the general problem of clients that send bare LF is not.

Well in fact, for the experiences of the particular system that was being 
discussed, yes it was indeed only local.

And we have report that another, widely deployed system, is not seeing bare 
LFs.

d/

=-=-=-=-=

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Jul 2000 15:44:04 -0400

> discussed, yes it was indeed only local.

all experiences of a particular system are "only local".  so what?

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Jul 2000 12:49:43 -0700

>all experiences of a particular system are "only local".  so what?

very creative misunderstanding.

the operational situation that was described was with clients that were 
within the organization using the MTA.

This is in marked contrast to email coming from OUTSIDE (ie, non-local) the 
organization.

d/

=-=-=-=-=

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Jul 2000 17:22:10 -0400

> This is in marked contrast to email coming from OUTSIDE (ie, non-local) the

how?  SMTP treats both kinds of mail just the same.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Jul 2000 14:20:36 -0700

>how?  SMTP treats both kinds of mail just the same.

the administrators of the intranet do not.

d/

=-=-=-=-=

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Jul 2000 17:46:11 -0400

> the administrators of the intranet do not.

I don't see how this is relevant.

Keith

---

From: [email-masked] (Kai Henningsen)
Date: 29 Jul 2000 12:27:00 +0200

> without a Date: header line (just one example). This just caused

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

---

From: [email-masked] (Kai Henningsen)
Date: 29 Jul 2000 12:33:00 +0200

[email-masked] (Dave Crocker)  wrote on 26.07.00 in <[email-masked]>:

> >The SMTP/Message Format system currently in use is a mess.  We have nearly
> >20 years of standard drift and those standards are vague in some areas.
> >For better or for worse the internet is now a commercial environment which
> >means interoperability and reliability are the key factors.
>

Oh, they have. But I notice that, at least in the case I'm familiar with,  
they're a little more obvious about what is going on:

-- snip --
PC/TCP compatibility mode
CONFIG_INET_PCTCP
  If you have been having difficulties telnetting to your Linux
  machine from a DOS system that uses (broken) PC/TCP networking
  software (all versions up to OnNet 2.0) over your local Ethernet try
  saying Y here. Everyone else says N.

  People having problems with NCSA telnet should see the file
  linux/Documentation/networking/ncsa-telnet.
-- snip --

MfG Kai

---

From: Philip Hazel <[email-masked]>
Date: Sun, 30 Jul 2000 18:29:43 +0100 (BST)

> option that says, for example, break_rfc_allow_linefeed_lineends, and  

A number (but not all) of the RFC-breaking features of Exim do indeed
work that way, and I certainly agree with the principle.