On Feb 13, 2008, at 1:32 PM, Wietse Venema wrote:
Douglas Otis:
The current assumption used when asserting DKIM policy is that this
policy might apply across _all_ protocols used to carry messages
that might contain DKIM signatures. Either DKIM policy records
need to declare the scope of the protocols covered by the policy,
or the label used to discover a policy should employ different
labels.
Add:
Policy assertions for _SSP records are limited to messages
exchanged by SMTP. When other protocols are used to receive
messages, the appropriate policy should be applied upon receipt,
and/or the protocol should be tracked within the message. One
method for such tracking could be implemented using Authenticated-
Results headers.
Excuse my ignorance, but why limit DKIM (or SSP) to information that
is delivered via SMTP? They can work with any transport that uses
RFCx822 for content and that uses DNS for name resolution.
Agreed. DKIM can be employed in conjunction with _many_ transport
protocols. While a domain may assert they sign "all" their SMTP
traffic, they may not be signing other types of traffic that could
potentially use DKIM signature headers. How would a domain indicate
what protocol they cover by their assertion? It seems logical to
restrict the _SSP policy to that of SMTP. Other protocols can define
where the relevant policy can be found, or they could add a protocol
policy scope to the record.
The policy should make it clear when it applies to SMTP. When there
is also a mandate to publish an MX record while publishing SMTP
policy, the the following states will have been defined:
SMTP SMTP/DKIM
DISCOVERY POLICY
(MX) (SSP) State
NO NO 0 Status Quo
YES NO 1 No Policy Defined
NO YES 2 SMTP Disavowed (cease further transactions)
YES YES 3 Policy Defined (SMTP/DKIM supported)
For example, when "non-smtp-domain.sld.tld" publishes a SMTP/DKIM
policy without an MX record resulting in state 2, this halts a
discovery process from making SSP record queries against "sld", and
could prevent bogus key record queries from being made against "non-
smtp-domain.sld.tld". Being able to disavow having sent a message
while also curbing some DNS related traffic should provide an
incentive for domains to publish SMTP/DKIM policy record. As
currently defined, only state 2 offers a clear indication of a message
being disavowed or repudiated. This repudiation should be even
stronger evidence than that obtained with an invalid signature. Those
that fail to publish MX records in conjunction with SSP policy records
might find some verifiers consider their SMTP traffic as having been
disavowed. This would also be an incentive to publish.
Providing incentives for domains that don't use email to publish
policy records ensures greater value in bothering to query for the
record in the first place. The juice being worth the squeeze.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html