Re: RFC 1123 and SMTP

[John C Klensin <[e-mail]>]

This is going to be one of those weeks, I'm afraid...

The SMTP Extensions WG has part of this area open, and, indeed, has two
draft docs on the table that address parts of this issue. While nothing is
likely to be done that changes what 1123 has to say (at least without
my bullet-ridden body being found in some dark alley), there are a few
areas where it is moving toward some additional specification and 
guidance.  In particular, there is an effort afoot to clarify what sort
of documentation gateways from the 821-defined SMTP world into other
transport environments and address spaces are expected to provide in those
Received fields.

That said, I agree with Bob: The received fields are documentation and
trace information that should not require any interaction with any 822
field such as Sender or From.  They really belong to the transport agents
which, except in some gateway situations, should not even be looking at
message bodies (headers included).

Wrt the broader point, while I think we should not (and probably cannot)
make or try to enforce a rule that prohibits a receiving MTA or UA from
accepting mail that arrives without plausible Date or From fields, this
is one of those areas in which the boundary between extreme liberality
and chaos is pretty fine.  

Think about it this way: a message without a From field cannot be
replied to in any legitimate way.  If a system accepts such a thing and
delivers it, and the user attempts to reply using an automatic facility,
the only options are to try to deduce and then reply to a Sender (which
822 discourages) or to try to reply to the envelope MAIL FROM address
(mapped into Return-path, if 1123 is being followed).  I don't recall
1123 explicitly banning use of that address in replies, but it probably
should have (and, if any relaying is involved in receipt of the mail, it
pretty much does ban it).

So the price of liberality in this case is to accept things that are
pretty clearly going to cause problems further down the road.  Seems to
me that is a bad choice.  Maybe a very bad choice.

As a general principle of how to promote interoperabity, I continue to
believe that bouncing trash is a permissible, nay, worthwhile, activity. 
The alternative is that we all have to be continually seeking least
common denominator behavior with the worst-behaved and weakest
implementations among us.

In particular...

> 	-For example, Eudora will only send a Date: line if the MAC in
> 	question has the localtimezone defined. Many MACs routinely don't
> 	do this, and thus send mail which PP can interpret as "illegal"

Sounds like Steve is trying to defend against getting flamed for putting
out 822-invalid dates.  But a better strategy would be to either refuse
to send anything or to pop a "ok, what is you timezone" box up onto the
user each and every time.   But I think we should discuss that with him,
not change everything else because his software sometimes puts out bad
stuff today.

>> (2)	It appears that PMDF generates Headers when relaying mail that
>> 	append Resent- or Relayed- or Redistributed- to the existing 
>> 	Header.
>
>Do you mean 'relaying', in the strict sense of RFC-1323?  1323 tries very
>hard to discourage relaying.

No.  PMDF invents these headers (Resent- only, I believe) when doing
certain types of exploding and automatic forwarding.  In particular, if
mail arrives at mbx1@domain1, and that turns out to be an alias or
forwarding address pointing to mbx2@domain2, you are going to see
Resent- fields.

Now, while I probably don't read the intent of the various docs the same
way the PP folks do, I also don't read them the same way the PMDF folks
do, and we have had a few "firm and frank exchanges of views" on the
subject.  To my personal taste, some of this is exactly what we should
be solving with better trace fields, e.g., something of the flavor of
  Received: by domain1 for mbx1 forwarded to mbx2@domain2
(probably with different syntax and keywords) and not messing with
Resent- except by explicit user direction.

But we are in very gray areas here: 822 doesn't say enough about Resent-
to predict to any consistency of implementation (there have been
discussions on ietf-smtp, ietf-remmail, and header-people on aspects of
this issue in the last two weeks (!)) and anything smacking of an
exploder is outside the text of 821 and 822 and into oral tradition. 
The oral tradition diverges around the philosophical/religious question
of whether an exploder is a rather special type of relay or whether it
is a special agent for the list owner that is really doing something
that person might do herself.

>> 	If the intent is that all relays prepend additional header lines,
>> 	I think this needs to be more explicit.
>
>?? I don't understand this comment.

The proposed rule in the smtp extensions WG draft is, in essence, that
anything that touches a message -- gateway, relay, exploder, ... -- must
put in a Received field describing who it is and what it did.  That
reading is consistent with a general consensus about what 821 [was
intended to say] said.  The whole purpose of those fields is tracing and
auditing, and, if something actually needs to handle a message, making
that activity transparent makes debugging frightfully difficult.  And,
as Bob says, the general idea in 1123 was to discourage relays whenever
possible: if all that is left are intermediate MTAs that have to take an
active role, then they should be especially careful to document that
role.

I don't know if it is a reasonable place to try to adjudicate anything,
but the collection of people relevant to this sort of discussion can
mostly be found on [e-mail] (subscriptions to
ietf-smtp-request@..., or course) these days, plus the historical
location of [e-mail] (subscriptions to
[e-mail])

   --john
   (for identification... Chair IETF SMTP Extensions WG
   and sometime maintainer of the header-people list)