On Thu, 14 Feb 2008 19:08:41 -0000, Douglas Otis <dotis(_at_)mail-abuse(_dot_)org>
wrote:
On Feb 14, 2008, at 3:26 AM, Charles Lindsey wrote:
On Wed, 13 Feb 2008 22:46:10 -0000, Douglas Otis <dotis(_at_)mail-abuse(_dot_)org>
wrote:
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.
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(_dot_)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-
separated list of policy scopes specify which protocols to which
this record applies. Verifiers for a given service type MUST
ignore this record if the appropriate type is not listed.
Currently defined service types are as follows:
No! The default must be '*'.
* matches all service types
! disavows protocol use
SMTP RFC2821
NNTP RFC3977
MSRP RFC4975
This tag is intended to constrain the use of policy for various
transport protocols that may implement, should DKIM be defined by
other protocols in the future. This tag can also disavow use
of specific protocols to repudiate references to this domain.
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.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html