Errors-to: owner-drums@CS.UTK.EDU
Message-ID: <0jnSEla00WBwA9xqMG@andrew.cmu.edu>
Date: Thu,  1 Jun 1995 12:00:49 -0400 (EDT)
From: John Gardiner Myers <jgm+@CMU.EDU>
To: drums@CS.UTK.EDU
Subject: Re: end-of-message indication in SMTP
In-Reply-To: <MailManager.801995117.19114.mrc@Ikkoku-Kan.Panda.COM>
References: <MailManager.801995117.19114.mrc@Ikkoku-Kan.Panda.COM>
Beak: Is

Mark Crispin <MRC@Panda.COM> writes:
> A certain inferior losing MTA, which shall go nameless but whose name rhymes
> with bendmail, treats <LF>.<LF> to be the end of a message.  This causes an
> interoperability problem if <LF>.<LF> is actual data in a message.

This is a specific instance of a more general problem in my initial
list:

John Gardiner Myers <jgm+@CMU.EDU> writes:
> "The mail data may contain any of the 128 ASCII characters" permits
> NUL octets, as well as bare CR and LF octets, which are not handled by
> the vast majority of the installed base.

My recommendation is to adopt the slightly more restrictive definition
of "7bit data" in section 4.7 of draft-ietf-822ext-mime-imb-03.txt for
use in both SMTP and the message format.

> 4.7.  7bit Data
> 
> "7bit data" refers to data that is all represented as
> relatively short lines with 998 octets or less between CRLF
> line separation sequences [RFC821].  No octets with decimal
> values greater than 127 are allowed and neither are NULs
> (octets with decimal value 0).  CR (decimal value 13) and LF
> (decimal value 10) octets only occur as part of CRLF line
> separation sequences.

The octet sequence <LF>.<LF> would thus only qualify as "binary data"
and would have to be transfer-encoded in order to be sent over base
SMTP or ESMTP with the 8BITMIME extension.

Mark Crispin <MRC@Panda.COM> writes:
> I don't know if this is permitted by the charter or not, but I would like to
> eliminate the following foolish (and commonly violated) requirements of 822:
> 
> 1) Simplify the syntax, remove obnoxious restrictions:
>     a) Remove ".", "[", and "]" from specials.
>     b) Redefine local-part as word.
>     c) Redefine domain as atom.
>     d) Remove sub-domain, domain-literal, and domain-ref
> 
> This is what most people have to implement in their parsers anyway, in order
> to cope with:

I'm not sure it is within the charter to loosen the syntax.  I would
like to tighten it up to get rid of some hard-to-parse constructs that
are never used.  

I had occasion to write an 822 parser recently, I redefined local-part
as phrase and phrase as *(word / ".").  I parse a "phrase" and then make
a decision about what that data means depending on what special came
after it.

I think we might be in a situation where we need two syntaxes, one for
sending, one for receiving.  In any case, we have to be extremely
careful about any changes we might make to the address syntax.  The
situation is a mess and we don't want to make it more of a mess.

> 2) Change the definition of fields so that 1*destination becomes 
> *destination;

I think dropping the requirement to have at least one destination
header would be in order.  

> and to obnoxious behavior on the part of MTAs, such as the inferior
> losing MTA whose name rhymes with "bendmail" writing an hokey
> "Apparently-To:" header

The smtpas document had some wording about Apparently-To:.  The
real-world problem is being fixed--the beta version of sendmail now
defaults to not inserting Apparently-To:

As an aside, a *lot* of things have been fixed in sendmail version 8.
For example, Errors-To: is ignored by default.  I usually say that
people who complain about sendmail should take a look at recent
versions.

-- 
_.John G. Myers		Internet: jgm+@CMU.EDU
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up