[ietf-dkim] NEW ISSUE: SSP-02: Policy Scope //defaults
dotis at mail-abuse.org
Fri Feb 22 11:21:06 PST 2008
On Feb 22, 2008, at 5:53 AM, Frank Ellermann wrote:
> Charles Lindsey wrote:
>> It is evident to me that the whole idea is utterly indefensible.
> +1 It's a real issue, but *doumenting* it instead of *fixing* it
> with obscure scopes suffices for now. Gateway operators need to
> know it, e.g., GMaNe could educate its users in its FAQ.
When SSP policy applies to other transport protocols independent of
SMTP, a prefix of "!" for "Not Used", "-" for "Except", and a protocol
wildcard of "*" for "Any Other Protocol" as in [! | -]<protocol>
would allow construction of the transport sources for DKIM messages.
If policy scope is defined in the future, a default of "s=SMTP" would
> In addition to the domain owners intending to introduce some kind of
> strict/reject/discard/whatever *SP, they first have to educate their
> users. And maybe folks like you have to do something with their
> mail2news solutions if they want SSP protection.
Agreed. However, the "s=SMTP" (default) would indicate the domain
does not sign NNTP messages. A domain that does sign NNTP to avoid
mail2news problems, could indicate this by asserting "s=SMTP:NNTP".
> Later, if say NNTP introduces a variant of DKIM in addition to
> "pgpverify" for its purposes, a document explaining NNTP-DKIM can
> say what NNTP-*SP is supposed to be, if anything at all.
Using separate policy records would be an option, however, this would
impose greater overhead. By stating that today's DKIM policy records
pertain to governing SMTP related infrastructure, this would clarify
the scope of this record at least.
> Let's get some KISS *SP out soon, and see what happens. Maybe
> "experimental" is good enough for now. There are issues where I am
> far from sure that they'll work. But the lack of *SP scopes isn't
> one of them.
Agreed, but a concern still remains with respect to truncating the
discovery processes. This becomes especially important as perhaps
dozens of message protocols attempt to introduce their policies in the
same fashion. As more organizations attempt to unite this protocol
babble, curbing undesired key/policy discovery transactions walking up
domains not supporting the protocol is likely to only grow in
Despite the lack of adoption of various modifiers used by SPF,
providing a foundation for policy scope within the DKIM policy
records, with a default of "s=SMTP" would provide a framework for
future adoption. Macro expansion features and Exist mechanisms of
SPF, due to inherent dangers, where strongly argued against. Removing
these seldom unused features today from SPF parsing routines would
help keep the Internet a much safer place. However, not having a
general means to truncate policy discoveries related to security
enhancements of various communication schemes will be placing DNS at
greater risk again.
To that end, declare the scope of the DKIM policy record is limited to
SMTP infrastructure, and that publishing DKIM policy necessitate a
"proof" of protocol use. In the case of SMTP, this could be
publishing the "MX" record. Required "proof" of use protects domains
that do not support SMTP from being inundated with a flurry of
undesired transactions that only result in an "uncertain" status for
the abusive message inducing undesired traffic. Disavowing use of a
protocol refutes abusive messages to a greater degree than attempting
to validate message signatures and applying the "all" or "repudiate-
able" policy assertions.
More information about the ietf-dkim