Message-Id: <199612052346.SAA28025@ig.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: Mark Crispin <MRC@panda.com>
cc: Keith Moore <moore@cs.utk.edu>, Chris Newman <Chris.Newman@innosoft.com>,
        Directed Revision/Update of Message Standards <drums@cs.utk.edu>
Subject: Re: MTA action with illegal input 
In-reply-to: Your message of "Thu, 05 Dec 1996 14:24:34 PST."
             <MailManager.849824674.6737.mrc@Ikkoku-Kan.Panda.COM> 
Date: Thu, 05 Dec 1996 18:46:00 -0500
Sender: moore@cs.utk.edu

> A relay's SMTP receiver may, at its discretion, accept a message with
> excessively long lines (or other bogosity).
> 
> If it accepts such a message, the relay's SMTP sender may, at its discretion,
> attempt to pass the message unchanged to the next hop.
> 
> If the next hop accepts the message, it is now the next hop's problem.
> 
> If the next hop refuses the message due to bogosity, the relay may, at its
> discretion, either choose to attempt a fix or bounce it back to the previous
> hop.
> 
> If the relay bounces it back to the previous hop, and the previous hop refuses
> to accept the message because of the bogosity, then the previous hop is guilty
> of pooping bogosity that it won't accept.  

Provided that the bouncing MTA didn't somehow mung the message when putting
it into the delivery report, making it undeliverable in a completely new
way.  (this happens all too often)

> If the relay drops the message into
> a black hole, it's the previous hop's own fault for being broken.

Except that in the post-RFC 1123 world the message is no longer constrained
to return by the same path as the one it arrived on.  (so it's not necessarily
the "previous hop")

So if you send out bogus messages, and your primary MXes aren't capable
of accepting bogus messages, you lose.  The simple version of this
requirement is: if you relay bogus messages from A to B, you must be
willing to relay a bounced bogus message from B to A.  But this isn't
sufficient for the case where the outgoing MTA isn't a primary MX
for the sender's domain.

> Therefore, a MUST NOT SEND rule really means NEED NOT ACCEPT.

If I'm not mistaken, that's the converse.

I would say that a "MAY send FOO" rule implies that if you do 
send FOO, you MUST accept FOO.  Equivalently, if you don't accept FOO,
you MUST NOT send FOO.
 
> So far so good.  But this then leads us into the conundrum that the "just send
> 8 bits" crowd exploits.  Basically, they claim that breaking the rules leads
> to a better-quality implementation.  This will be encouraged by the proposed
> prohibition on unauthorized fixes -- they could claim that a relay which does
> not advertise 8bit and discards the 8th bit from a "just send 8" client is
> violating the no "authorized fixes" rule (similarly for a relay which
> truncates overlong lines).

We could explicitly make an exception for an 8bit->7bit conversion.

But I suggest that long term, we're far better off encouraging 8 bit
transparency, even to the point of "just send 8", than encouraging
MTAs to build in 8-to-7 conversion code.   The latter will damage
more messages than the former.

(but that is a discussion for another venue...)

> An SMTP receiver which does not advertise 8-bit capability may do whatever it
> wants to "just send 8" data, including stripping it.  An SMTP receiver may do
> whatever it wants to overlong lines, including truncating it.
> 
> An SMTP sender probably should do neither of these two things, but it's off
> the hook if the SMTP receiver did it.

Meaning you would allow and SMTP sender to send bogons as long as they 
were identical (modulo received header) to the message Received?

Yes, that's what I had in mind.

Keith