[Top] [All Lists]

Re: revised Email Architecture draft

2005-01-27 11:45:56


Thanks for taking the time to pursue such diligent reading and commenting.  The 
concerns you raise involve issues that were at the core of my motivation for 
producing this paper:  The community has demonstrated a distinct lack of 
cohesion about these points, and we need to fix that.

Even more interesting is that some of the citations you use have not been part 
of previous discussions on these topics, so it is good to explore their impact.

  ? Ultimately the simple basis for deciding what address needs
  ? to be in the RFC2821.MailFrom is to determine what address
  ? needs to be informed about transmission-level problems (and,
  ? possibly, successes.

  That's not true,  "Mail From" is exactly what the name says,
  it's no arbitrary "Bounces To".  The quote is taken from the

It IS pretty impressive that it took us 20 years to discover that the labeling 
of RFC2821.mailfrom was wrong and even its formal definition is ambiguous.  In 
effect, it refers both to source identity AND to notifications use.

This specific issue has gotten very wide and deep discussion over the last year 
or so, in quite a few venues.  The language in the architecture draft 
represents both my own view and the view that I believe represents a pretty 
strong community ROUGH consensus.  
Permitting the MailFrom address to be entirely different than RFC2822.From or 
RFC2822.Sender also reflects real-world use of the field.  It is essential that 
notifications be able to go to addresses that have no observable relationship 
with From or Sender.

  MSA section, and in RfC 2476 6.1 "enforced submission rights"
  "Mail From" is the authenticated source.  RfC 2476 3.2 says:

  ! If an MSA is not able to determine a return path to the
  ! submitting user, from a valid MAIL FROM, a valid source IP
  ! address, or based on authenticated identity, then the MSA
  ! SHOULD immediately reject the message.

First of all, let's note that the text you are quoting here is in a section of 
RFC2821 that is not defining the MailFrom command nor any of its semantics.  
Second note that MailFrom is referenced in a LIST of choices.  And these 
choices pertain to an implication of what IS being specified.  Hence, the 
paragraph was neither intended nor succeeds at being a normative reference for 
RFC2821.MailFrom.  The text certainly does say that MailFrom COULD contain a 
source identification string, but not that it MUST or even that it SHOULD.

  It's the Return-Path, as specified in STD 10, not some obscure

Well, the RFC821 definition of Mail From is:

  It gives the reverse-path which can be used to report errors.

Std 10 is RFC821.  Note that it is explicitly obsoleted by RFC2821.  (The STD 
reference is, therefore, out of sync. But that's OK, since the historical 
reference is useful.)

We can quibble about the rfc821 reference to reverse-path, but the language 
that says what to actually DO with this string is clear and straightforward:  
it is a notifications address.

So, even ignoring all normative documents since RFC821, we can see that the 
intention of this field matches exactly what the architecture document says it 
is for.  

  ? The MDA records the RFC2821.MailFrom address into an RFC2822
  ? header field named Return-Path.

  It's not only "named" so, it really _was_ the Return-Path in
  STD 10 and 11, as the name says.  And it's still considered as
  _the_ responsible source in say RfC 3834 or in the "mail-arch"
  draft for some important cases of mediators like mailing lists
  or resent mail.

'still considered as the_ responsible source in... the "mail-arch" draft'?

I do not understand this reference.  Please clarify.

As for RFC 3834, it's statement:

  The primary purpose of the MAIL FROM address is to serve as the
  destination for delivery status messages and other automatic

seems to me to be in 100% agreement with the language of the architecture 
draft.  So I do not understand why you think it supports a view that MailFrom 
is about authoriship our assertion of source.

  The "Return-Path" quote was taken from the MTA section, IMHO it
  should be moved to the MDA section.  The MDA section contains
  HELO, that could be removed.  Or it needs an explanation, when
  does an MDA say HELO ?

Good catch.  Thanks.  Both the MTA and the MDA sections have significant errors 
in listing identities that they use.  I've moved things around, to fix that.

  ! The primary "routing" mechanism for Internet mail is the DNS
  ! MX record [RFC1035].  It is an advertisement, by a recipient
  ! domain, of hosts that are able to relay mail to it, within
  ! the portion of the Internet served by this instance of the
  ! DNS.

  Yes, and based on this simple observation it's clear that mail
  sent to _another_ (3rd party) MX is a special case, where using
  the original unmodified "Mail From" is far from "natural". 

Unfortunately I am not understanding what you mean here.  Please say it again, 

At a minimum, I have no idea what relationship and constraints, between MX 
usage and MailFrom usage, you are trying to draw.

  fact it's not allowed by STD 10, and it's the reason for codes
  251 and 551.

I am not understanding what it is that you believe is not allowed.

  ? The agent responsible for gatewaying the message may choose
  ? to specify a new address to receive handling notices.

  Generally it's not only a "may" for a gateway, but a "should".
  The only case where keeping the original "Mail From" could make
  sense is when original sender and recipient are in the same
  "messaging environment" (aka net), e.g. moderated newsgroups.

Actually, this depends upon how seamlessly the gateway can emulate being a 
relay. The goal of a gateway is to provide perfect emulation, to the two email 
services it is interconnecting.  To each of them, it seeks to appear as an 
ideal relay.  However gatewaying is needed when there are significant 
differences between the service; such differences pretty much always affect 
visible mail service semantics.  So perfect emulation is not possible. In any 
event when the two different email service have reasonably close semantics, 
then even the notifications/bounce mechanism can be emulated.  

As for the case you cite, if the two sides are in the same messaging 
environment, then they do not need a gateway.

  IMHO gateway considerations should not be a part of the MUA
  section.  MUAs (ab)used as gateways are normally very bad news.

The nature of a gateway is that it alters the message.  It is not merely part 
of the underlying transfer service.  Recognizing that gateways operate at the 
MUA level (as well as, yes, the MHS level) is an explicit goal for the 
architecture document.

  ? The agent responsible for submission to an alias address will
  ? often retain the original address to receive handling
  ? notifications.  The benefit of retaining the original
  ? MailFrom value is to ensure that the origination-side agent
  ? knows of that there has been a delivery problem.  On the
  ? other hand, the responsibility for the problem usually lies
  ? with the recipient, since the Alias mechanism is strictly
  ? under the recipient's control.

  There's no "benefit of retaining the original MailFrom", and it
  was never allowed by STD 10, the forwarding host was added to

Please cite the text that says that this action is "never allowed".

Anyhow, I am changing "usually" to "often", in order to give more weight to the 
"On the other hand" sentence and to avoid the implication that the architecture 
document is recommending one over the other, since I do not have a sense of 
community consensus on this.

  the reverse path.  That's the single point of failure in 2821,
  and why we have a problem with forged "Mail From" addresses
  today, plus attempts to fix it like RMX. SPF, domain keys, etc.

Real forgery problems are due to a lack of authentication techniques, not 
debates about actual semantics.

Dave Crocker
Brandenburg InternetWorking
dcrocker  a t ...