[ietf-dkim] NEW ISSUE: SSP-02: Policy Scope
dotis at mail-abuse.org
Fri Feb 15 11:27:29 PST 2008
On Feb 15, 2008, at 4:50 AM, Charles Lindsey wrote:
> On Thu, 14 Feb 2008 19:08:41 -0000, Douglas Otis <dotis at mail-
> abuse.org> wrote:
>> On Feb 14, 2008, at 3:26 AM, Charles Lindsey wrote:
>>> If you want to indicate that information, then propose a new tag
>>> within the SSP record for the purpose. But the default should be
>>> that the SSP applies to all modes of transport. Otherwise the Bad
>>> Guys will just send mail like the following:
>>> Received: by bar.com from foo.com by SMTP ...
>>> Received: by foo.com from ebay.com by UUCP ...
>>> From: security at ebay.com
>>> [NO DKIM signature]
>> Agreed. This issue does not appear to have been entered into the
>> RT tracking, but both you and Jim have suggested this alternative
>> solution. Here is a more formalized suggestion for a tag added to
>> the policy record.
>> s= Policy Scope (plain-text; OPTIONAL; default is "SMTP"). A colon-
> No! The default must be '*'.
The concern regarding defaults was addressed in Take #3. This version
includes a means to exclude policy.
* matches against all unlisted transport protocols
! disavows protocol use
- excludes protocol from policy assertions
I suspect the default should be "s=SMTP" where this would be the same
as "s=SMTP:-*". When the domain exchanges no communication
whatsoever, "s=!*" could be used. When only SMTP messages are used,
then "s=SMTP:!*" would make this assertion.
> But you have to make it clear that verifiers can only discern the
> protocol used by the originating site by carefull examination of
> Received headers (and believable ones at that). So I am still very
> dubious about adding this feature.
Trace headers can not be included within DKIM signatures. This
limitation means DKIM policy applied against messages arriving over
SMTP may affect messages passing though third-party protocol gateways
bridging other protocols into SMTP. When messages arrive over
different protocols within the same administrative domain,
Authentication-Results headers could be used to indicate which
protocol transmitted the message into the administrative domain, where
these messages are placed into a common mailbox. It would be wrong to
assume this is always the case.
The significant value in the Authentication-Results header is that it
can be filtered at border MTAs. By adding a ptype of
"Transport=<protocol>" to this header, a gateway can thereby indicate
which transport protocol introduced the message. Unless this
information is conveyed to the recipient by some mechanism when the
mailbox normally serves as a repository SMTP messages, it would be
better to apply policy that pertains to SMTP. This may mean a DKIM
policy of "all" may cause some third-party gateway related messages to
be refused or placed within a different folder as a result.
A policy scope mechanism allows other transports to apply policy in
accordance with the domains assertion of protocol support, and whether
the DKIM specific assertion should be applied. As such, an a DKIM/
SMTP policy of "all" would not affect messages sent over NNTP with a
policy scope of "s=SMTP" for example. As other forms of message
exchange implement DKIM, the scope of DKIM specific policies
assertions becomes more critical. When the NTTP message is translated
into message carried by SMTP, then SMTP policy may negatively affect
the categorization of the NNTP message when these are not being signed.
This WG is largely comprised of those primarily focused upon SMTP. As
such, DKIM policy is being considered only from the aspect of SMTP.
While DKIM could be implemented by other types x822 message exchange,
few would expect all of these communications to simultaneously
implement DKIM. There are a few choices to resolve this potential
a) Stipulate the *SP policy record applies to messages arriving over
SMTP (require different policy domain labels for each protocol).
b) Provide a scope parameter within the policy record.
From a maintenance and overhead standpoint, option "b" could be the
best solution. In Take #3, to make this friendly to gateways change:
When a protocol has been disavowed, any further DKIM related
transactions should cease.
When all protocols has been disavowed, any further DKIM related
transactions should cease.
This last statement provides a means to protect specific domains and
their parent domain from an inordinate amount of DNS traffic when an
existing domain is spoofed in a spam campaign. The policy scope
parameter allows other types of message spoofing to be mitigated with
as DKIM becomes implemented for each respective transport. The fact
that a protocol can be bridged into SMTP should not inhibit the use of
"all" for SMTP, or for other protocols to assume that "all" only
applies to SMTP. For DKIM to offer it greatest protections, a means
to scope the policy is essential. Pick "a" or "b".
More information about the ietf-dkim