On Apr 24, 2006, at 11:59 AM, Jim Fenton wrote:
John R Levine wrote:
DKIM lets anyone sign any message, with no necessary connection
between the signing domain and the domain in any other header such
as From: or Sender:. By third-party signatures we mean signatures
that don't match the From: or don't match the Sender:, or don't
match something else.
The definition in the current SSP draft is that a third-party
signature is a signature that doesn't match the From:. There is no
reference to Sender: or "something else".
This detail is still open, as SSP is at an early stage of development
where details covered in the SSP raise concerns.
The semantics as well as definition of third party signatures are,
to put it mildly, somewhat unclear. Some thought or actual
experiments with such signatures could be helpful.
I have done a lot of thinking about this; other thought or
experiments welcome. Given that SSP is the next document up for
discussion in the DKIM WG, I think this has progressed beyond
"research", and I don't think it's a good idea to fragment
discussion between this mailing list and that one.
The DKIM WG are dealing with the Base draft and there is a desire to
postpone SSP related discussions. Similar concepts discussed here
should not cause any fragmentation at this time.
Concepts dealing with both DoS and message replay abuse concerns
could be found with a strategy to make associations between the
originating source (from/sender/resent-from/resent-sender) and the
signing-domain. Associations are practical for a substantial portion
of the email traffic (including DKIM related traffic) without
incurring a high level of DNS transactions while also providing a DoS
protection strategy. The current draft SSP draft neglects to offer
such associations or protective strategies.
This draft offers a possible approach.
http://www.ietf.org/internet-drafts/draft-otis-smtp-name-path-00.txt
What is not covered in this example is a specific association between
an originating source and a DKIM signature. This association is
assumed to provide both the third-party EHLO _and_ DKIM signature
authorization list. Purists may desire a specific PTR list such as
_tps._smtp.<example.com> to define an explicit list of what domain is
allowed to sign messages for a specific domain and not just transmit
(if that really matters). A special domain label was also not
created to indicate no email is allowed. This could be a domain of
'-.' that indication no mail association, for example. A list, in
addition to making explicit associations, also defines the nature of
list, negating a need for the current SSP syntax that does this sans
any associations.
Rather than raising issues specific to just DKIM, this strategy
relates to a broader class of emails, while also providing DKIM
relevant protective strategies.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg