On May 26, 2008, at 3:26 AM, Charles Lindsey wrote:
On Sun, 25 May 2008 21:53:11 +0100, Douglas Otis <dotis(_at_)mail-
abuse.org>
wrote:
Such testing is not mission creep. The test is simply based upon
SMTP being the focus of ADSP assertions.
But SMTP IS NOT, and CANNOT BE the focus of ADSP assertions, simply
because a message may be gatewayed in and out of SMTP umpteen times
during its journey from original sender to ultimate recipient.
Messages containing addresses unrelated to SMTP will always
potentially conflict with ADSP. The otis-dkim-adsp-02 draft makes a
statement:
,----
|Application of ADSP by Mail User Agents (MUAs) might need
|to be offered as an option, to accommodate messages exchanged
|over different public protocols.
'----
Perhaps this text should be expanded to include both protocol gateways
and MUAs. A receiving host should be able to decide what (non-SMTP)
message source it will accept over SMTP. In addition, it should not
be an insurmountable hardship that, for a message address to be
acceptable for SMTP, the domain needs to support SMTP.
It seems rather ludicrous to claim address-spoofing is to be
prevented, and then not define what protocol generates and accepts the
protected address. With either John's or Jim's versions, the protocol
adopting DKIM is never defined. As a result, these issues have been
ignored and definitely not resolved.
The true "focus of ADSP assertions" is "all those protocols which
rely upon DSN as a part off their addressing mechanisms".
There is no assurance that an undefined protocol will use DNS, since
there are already such protocols available. The draft should indicate
limitations imposed when adopting ADSP. Due to high levels of abuse,
any gateway left open is likely to be abused once acceptance is
otherwise restricted. This issue can not be glossed over by
suggesting other protocols will also be using DNS. How does that even
help? What do you see as the goal of ADSP?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html