Jim Fenton wrote:
the use of multiple terms creates an architectural
separation of authority that is not reflected in real life.
I was reacting to what limited consensus I saw, rather than
to the architectural issue. If there is support for the use
of AdMD instead, I'm happy to use that.
Divining rough consensus from less than five opinions is white
or black magic for the Chairs... ;-) On the MON side we have
the domain owner, one of his AUs or AdMDs is his registrar or
Web hoster or his own box, whereever the name servers for his
domain are. Another AU or AdMD is responsible for his MSA, he
could use more than one MSA, or he has his own mailer.
The "MSA of the ISP" can be relevant for some aspects of the
threat drafts. E.g. address(_at_)ISP(_dot_)example is a relevant case if
ISP.example picks a "closed" signing policy.
Otherwise address(_at_)my(_dot_)homepage(_dot_)example is interesting, if all
mails sent via the MSA of ISP.example get a signature, no
matter what the my.homepage.example domain owner might wish.
With the term MON you'd cover these different cases. On the
other side (receiver) you have essentially *(mediator) MRN,
zero or more "mediators" before the final MRN.
That final MRN may contain MXs at a third party or not, or
AV-software at a 3rd party or not, as long as it contains
the final MDA you're ready and don't care about the details.
It can be also a gateway to something else (4356 SMTP to MMS
is an example), and in that case it will please check DKIM
signatures before it modifies 2822 header fields for MMS.
The cases with one or more mediators are essentially mailing
lists, that's an "MRN plus MON" redistributing the mail, or
251-style "user not local" forwarders, in that case they're
logically a part of the final MRN.
For DKIM all SMTP subtleties of keeping the old MAIL FROM or
not while changing the RCPT TO are irrelevant. Only if the
2822 header fields are modified by a "mediator" (e.g. for PRA,
by mailing lists, in conjunction with moderated newsgroups,
etc.) we're very interested, because then that's a potential
point of failure for DKIM.
Bye, Frank
_______________________________________________
ietf-dkim mailing list
http://dkim.org