ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: ISSUE 1547: SSP-02: MX Record publishing mandateto reduce DNS overhead for SSP Discovery and to detectfraudulent messages

2008-02-15 19:32:53

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

<Prev in Thread] Current Thread [Next in Thread>