ietf-mxcomp
[Top] [All Lists]

Re: Why we should choose the RFC2821 MAIL FROM/HELO identities

2004-03-29 00:37:09

Dave,

Ok, we are supposed to be discussing the identities with which MTA
authorization should be associated with.
*** I think the identities that we should consider are the RFC2821
*** MAIL FROM and HELO domains names.
JK> I agree that the *first* push should be at these identities, since
this is
JK> the stuff claimed by the MTA.


Thank you for making this observation.  I think it is key to this kind
of discussion:  

And I still stand by this, however, I've become concerned that if we
*limit* ourselves to the 2821 identities (really limit I mean, ruling
considerations of other identities out of scope), we'll produce a spec.
that's not very useful to some important constituents, who'll need action
on 2822 stuff, and which isn't easily extensible. Also, the apparent
difficulties we're having in answering what appears to be a simple question
(posing it repeatedly, "falling out" about it), suggests that we could
profitably make it "go away".


we need to be clear about:

   1) the nature of the identity being validated,

   2) the relationship between an identity and the entity that can
   reasonably be held responsible for it

   3) the nature of the validation being attempted.



MTA's are about the transfer process, not the authorship process.  So
RFC2822 From is really quite detached from the transfer process.
RFC2822 Sender has some relationship.  RFC2821 Mail From is directly
related to transfer errors and, of course, RFC2821 EHLO Domain is a
direct assertion by the MTA itself.

This is true. We also need to be clear about (4) the entity making the
"validation". But I don't believe it's a good idea (or possible?) for us to
restrict this to one particular stage in mail processing or for a
particular narrow set of purposes. Some people may have an interest in
binding authorship and transport. We can't say that they're wrong.



 and to the extent that we are supposed to focus on the "peer" MTA,
 the originating MTA might not even be the peer...


No, right. This is the basis of the forwarding issues that many people have
such problems with.

Taking all that into consideration, I've come to believe that allowing the
publisher to identify the identities that a record applies to might be the
best way. Or, viewed slghtly differently, we should support the publisher
in making a richer description of what their "legitimate" mail looks like.
We can make MailFrom the default, for notational convenience, compatibility
with other systems, and following the principle of least surprise.

All the issues about what "breaks" when, become senders problems.
Not ours (except to point them out). Which is as it should be.