Dave Crocker wrote:
2. Unsigned vs. Mismatched Signature
The original SSP specification applied only to unsigned messages. The
current
version includes mail that is signed but has different domains
between the
DKIM i= attribute and the rfc2822.From field. Presumably, this new
capability
overrides whatever reputation is associated with the message signer.
If a signer has a good reputation, then why is that not sufficient for
enabling delivery? In other words, with a signature of a domain with
a good
reputation, what threats is SSP trying to protect against?
To the extent that the above is not sufficiently clear:
All text that causes SSP to be applied to an already-signed
message needs to be removed.
A DKIM signature is a statement of responsibility. When a signature
is present, an organization has taken responsibility for the message.
Reconciling an existing signature against another identity field, such
as rfc2822.From moves the use of DKIM from statements about simple
transit responsibility into assertions of content legitimacy and/or
accuracy. This is out of scope for DKIM.
-1
As others have noted, bypassing SSP based on a valid signature from any
arbitrary domain permits a trivial attack: attackers could sign
messages using throw-away domains they control.
Without placing a dependency on a reputation or accreditation service
(both of which are out of scope), it's not possible to specify the
circumstances under which an SSP query should be done when a message is
signed by other than the author domain. Furthermore, trust isn't an
absolute: while I might generally trust mail signed by, say, ietf.org,
I wouldn't expect that signature on transactional mail. Eliminating the
query on signed mail also negates the effect of the SSP expectation
assertion specified in RFC 5016 that manifests itself as the "strict"
practice in SSP.
I fully expect that some verifiers will implement an SSP-like thing that
places signer reputation at a higher priority than the expectation
published by the author domain, and they're welcome to do whatever works
for them, even if it isn't, strictly speaking, SSP.
Your last statement seems to deal with issue 1524 more than 1521.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html