----- Original Message -----
From: "Jim Fenton" <fenton(_at_)cisco(_dot_)com>
To: <dcrocker(_at_)bbiw(_dot_)net>
'making this up as I go' is really exactly the problem. multiple
signatures moves from one entity taking responsibility to some unknown
combination of responsibilities, ensuring substantially greater
complexity in the overall system. What are the relationships among
the signers? How much does the validator care and in what way? etc.
Pardon my candor then: Of course I'm making this up as I go, because we
all know that this case isn't covered by the draft specifications.
...
Now suppose that instead the list stripped the original signature but
signed an authentication-results header saying that the message had a
valid signature from the 419 domain. How does that make the decision
any easier?
Sure it does.
But it does open a threat. As long as the original domain allows 3rd party
signing, then everything is okie-dokie.
If this information is lost, then we have a threat. However, if there is
any "trace" of evidence that points back to the original domain, then that
3rd party signing must be confirmed.
From my standpoint, as a vendor of SMTP and as well as LIST software, we
can't add DKIM to SMTP without integration LIST design considerations. It
may turn out that the safest route to take is to STRIP all signatures during
expansion depending on the new type of mailing list options we make
available for DKIM:
[X] Sign expansion
[X] Strip original signing
[X] IFF (if and only if) original SSP allows 3P signers.
[X] if not, keep original signing only.
The logic is extremely complex as you can see and probably enough to make
the LIST Server do nothing with DKIM.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org