Jon,
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: 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.
For most purposes, the MTA is not expected to mess with RFC2822 headers.
(The fact that many do is different from what we actually require/expect
of MTAs.)
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.
JK> And that's what we're about right?
JK> Authorizing MTAs. This is not to say that names used in (2822)headers
JK> aren't a concern, but it's primarily a concern in MUA. I don't have a
JK> strong philosophical objection to server MTA components doing tests on
JK> content, but it's not the client MTA that asserts identities in
JK> (2822)headers.
right.
and to the extent that we are supposed to focus on the "peer" MTA,
the originating MTA might not even be the peer...
d/
--
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>