On Feb 15, 2008, at 3:49 PM, Damon wrote:
Just in case we need a tie breaker...
-1
To summarize, as a bunch of -1 says so little, the push back generated
by this concept had to do with DKIM policy being applicable to other
transport protocols that might be bridged into SMTP. Protocol
bridging could become problematic when email is not supported natively
by the transmitting domain. Of course, this also creates problems
with respect to DSNs as well. Ignoring the problem of DSNs, mandating
support of SMTP when accepting an SMTP message bridged from a
different transport would be rather problematic when SMTP is not also
supported. However, accepting such messages into an SMTP represents a
choice that opens up an avenue likely to permit abuse. So this
concern seems somewhat ill founded.
Determining support of the relevant transport protocol could have been
generally stated as using the absence of the protocol discovery
record, (MX in the case of SMTP) in conjunction with the presence of
the DKIM policy record. This offered a means to indicate the support
of a specific protocol, and if not supported, a means to truncate the
policy discovery process and subsequent validation transactions. This
would have better protected existing domains that are not involved in
email from the traffic generated by spoofed messages. In addition,
this would have offered extremely strong refutation of fraudulent
messages made against any existing domain. Strong evidence is a good
thing in general.
To settle the issue as to what protocol is covered by a DKIM policy,
Jim suggested a policy scope tag instead. This would permit domains
to indicate which transport protocols have implemented DKIM and to
signal when DKIM policy can be applied. For gateways into SMTP, a
means to disavow support of a transport protocol could be important as
a means to better limit avenues of abuse. In any case, any message
bridged over into SMTP is likely find SMTP policy applied, and IMHO,
that can't be helped. With a protocol scope parameter, DKIM policy
could then do for IM, what it did for SMTP. Abuse is not just limited
to SMTP.
The ability to clearly indicate whether any message is fraudulent
without incurring additional transactions is also important from a
general domain protection standpoint. Jim is right. Policy can be
made to include scope, and that also offers a more flexible and
workable solution. Message abuse will demand negotiated changes
accommodated to some extent by policy assertions. Keeping a lid on
the the added overhead represents the remaining challenged.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html