[Top] [All Lists]

Re: revised Email Architecture draft

2005-01-28 18:26:03

  The case that an alias can be an address behind another MX is rather
  obscure, maybe it simply didn't work with old sendmails (I'm guessing).

I am still not understanding how the use of MX records is important to anything 
but routing.

 > The language in the architecture draft represents both my own view and
 > the view that I believe represents a pretty strong community ROUGH
 > consensus.

  The "bounces to" concept is IMHO a minority view. 

whereas my own assessment of community consensus is that it is the majority 

but, then, a goal of the architecture document is to try to resolve exactly 
these sorts of issues.

 Or at least it's not
  more popular, because it indirectly allows forgeries.

I do not know what it means to 'indirectly allow forgeries' or what forgeries 
you think rfc2821.mailfrom relates to.

 > Permitting the MailFrom address to be entirely different than
 > RFC2822.From or RFC2822.Sender also reflects real-world use

  Yes, but that's no problem, only Sender-ID fans hate this idea.  As long
  as there is no Sender: I'd consider the mailbox in the Return-Path: as
  some kind of default "sender". 

That would be a mistake.

If there is no rfc2822.sender field, then rfc2822.from is defined as holding 
the (virtual) value of sender.

 If a Sender: mailbox is spec> > the language that says what to actually DO 
with this string is
 > clear and straightforward:  it is a notifications address.

  Sure, but as "originator" I can't specify whatever I like, it's an
  address for error reports...
  If I'd think that ICANN should solve my mail problems, then I'm
  still _not_ free to say "bounces to ICANN".  

That is why the architecture document states that the rfc2822.sender specifies 
the value in rfc2821.mailfrom.

 > we can see that the intention of this field matches exactly what
 > the architecture document says it is for.

  No, I don't see it, it makes no sense for me.  In very strange
  cases it might be interesting that I send RCPT TO:<you> with a
  forged MAIL FROM:<user(_at_)dcrocker>. 

The term "forged" does not make sense, with respect to rfc2821.mailfrom.

It is like saying that my use of a recipient address, in To or CC is "forged".

Mailfrom specifies a recipient address.

My use of a particular mailfrom address might not be *authorized* but that is 
different from saying it is "forged", since "forged" pertains to claims of (my 
own) identity.

  RfC 1123 explains why source routes were not more "state of the art"
  (1989), because MX was a much better idea.  The quoted part of your
  text is also about MX.  And all is fine as long as there is only
  one MX between sender and recipient.  But if the recipient forwards
  his mail to _another_ MX keeping the original MAIL FROM it breaks,
  in that case the MAIL FROM is not more the responsible party.

having relaying through a second MX, in a sequence, does not automatically 
invalidate the original rfc2821.mailfrom.  sometimes, yes, but not always.

whether relaying through second MX changes who is really accountable -- and 
therefore, possibly, whether the rfc2821.mailfrom should be changed -- depends 
on a number of issues, as I said in any earlier message.


  >> it's not allowed by STD 10
 > I am not understanding what it is that you believe is not allowed.

  The "mediating source" would at least add his FQDN to the "reverse
  path", and so the "Mail From" would be always different from the
  original "Mail From", and indicate the last responsible party.  

you are suggesting some sort of reverse source route specification.  common 
practise is to have the address(s) be simple and global, rather than relative.

 > if the two sides are in the same messaging environment, then they
 > do not need a gateway.

  Then you probably consider mail and net news as different "message


Similar, but different.

 If I had my own LAN with SMTP, 127.* IPs, and funny
  TLDs, then my gateway to the Internet better replaces funny addresses
  (incl. Mail From) by something with a meaning in the Internet.  If I
  decide that ICANN isn't good enough and use some alternate DNS (in

If I understand you correctly, you are describing environments that use all the 
same standard email technology and conventions, but differ is some aspects of 
the domain name addressing.

This is, of course, more than simple relaying, but not by much.  It probably 
falls in the category of "gateway" rather than "relay" because the semantics of 
addresses needs translation.

 > Recognizing that gateways operate at the MUA level
 > is an explicit goal for the architecture document.

  Okay, apparently you define "MUA level" as "something above SMTP",

Yes.  That is exactly the point.  User-level is above Transfer-level.  Hence 
the different diagrams in the architecture document.

  and that has nothing to do with (ab)using ordinary MUAs as gateways.


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

  I'm not sure, this semantical difference explains why SPF is no
  part of CSV or vice versa,

The semantics of the two are entirely different.

Dave Crocker
Brandenburg InternetWorking
dcrocker  a t ...