Douglas Otis wrote:
There appears to be confusion regarding the impact of this
requirement. A requirement to publish an MX record when also
publishing SMTP policy does _not_ impact RFC 2821, which had been the
basis for these objections. When the concern is that DKIM Signing
policy records apply to other types of message traffic, then
_different_ policy records must be published for each of the different
protocols or a scope parameter is needed. There should be a general
stipulation that the scope of _asp, _ssp, _adsp, or whatever it is
called is limited to SMTP. When the policy affects other types of
message traffic, such as IM or UUDP, the policy records MUST BE
specifically defined for the type of traffic covered by the policy.
I'm not confused about the impact of this requirement. But I don't see
the benefit of this requirement, not even the efficiency benefit that
you claim. I see it as an unnecessary requirement, and I oppose it on
that basis.
Email policy discovery _will_ impact domains being forged in
fraudulent email. These domains may not be either sending or
accepting SMTP traffic as well. By establishing a convention that
SMTP/DKIM policy is only valid in conjunction with a published MX
record does not change how SMTP or any other message handling protocol
operates. This requirement only affects the publishing of SMTP
related policy.
It is rather unlikely there will be only one policy implemented for
SMTP, NNTP, UUCP, etc. In addition, policy discovery adds to the DNS
burden caused by an undefined number of subsequent key look-ups,
existence tests, and tree walking for policy. There may be any number
of signatures within different sub-domains contained within a
message. The MX record mandate, in the case of SMTP policy, provides
a means to truncate subsequent SMTP transactions to both protect the
domain and to disavow any related traffic purportedly covered by policy.
I see that you have opened a separate issue regarding scope. Good.
Let's discuss it there.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html