On Feb 17, 2008, at 1:24 PM, Hector Santos wrote:
Douglas Otis wrote:
It would be safer and less work for policy scoping to list the
domain's supported protocols.
Sorry, I just don't see how this will help nor see how it will be
less work. I see more complexity with little benefit or value
behind it.
You many feel *SP is limited to transport protocols delivering
messages into SMTP related repositories, including messages bridged
into SMTP. In other words, *SP governs SMTP message compliance.
Several may balk at this suggestion, and insist DKIM policy extends to
other protocols. The categorization of messages permitted by *SP
could occur for other transport protocols, without their messages
being delivered to the same location as would SMTP email. The number
of message transport protocols that might eventually use DKIM is
sizeable. If so, an assertion of "all" messages being DKIM signed
means what exactly?
Listing protocols where DKIM policy applies, as well as listing
protocols the domain does not support would be beneficial when
messages are received over non-SMTP related protocols and:
1) message are delivered to an SMTP related repository.
2) messages are delivered to a non-SMTP related repository.
In both cases, such a list permits:
a) detection of fraudulent sources without reliance upon invalid DKIM
signatures, and
b) makes an expectation of DKIM signature explicit for non-SMTP
related protocols to ensure proper message categorization.
By including scope within the policy record, the verifier is then free
to:
i) assume policy applies to SMTP and ignore it.
ii) detect non-complaint transport protocols.
iii) be assured that DKIM had been implemented for the transport
protocol in question.
This is not really that different from being able to determine whether
all messages have been signed.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html