On Jan 24, 2006, at 7:07 AM, Mark Delany wrote:
On Mon, Jan 23, 2006 at 10:18:59PM -0500, Hector Santos allegedly
wrote:
From: "Tony Hansen" <tony(_at_)att(_dot_)com>
I'm tempted to say: if the mailing list is going to do *anything*
to the message other than act as a simple reflector, it *must*
strip out any existing dkim signature. What it does after that is
up to the mailing list.
This would make sense for certain policies.
Actually I'm not sure why a list has to do anything in this case.
If a failed signature is the same as no signature, then the very
action of a mutating list has the effect of "stripping out" any
existing sig. So why impose extra work on a list? And why not let
the natural course of existing lists serendipitously "do the right
thing"?
The mutations made by a list can be removed with a small effort.
When the goal is to ensure protection from replay abuse (holding the
recipient domain accountable for replay abuse) the dissemination of
signatures increases this exposure. Rudimentary changes made by
list-server would not offer adequate protection. When the list-
server software is modified to at least understand DKIM signatures,
all but the most recent MSA signature should be removed. Any
signature not by the list-server itself should have the signature
portion overlaid with the verification results (even !unknown). The
headers included should be to protect the list-server from possible
exploits. As signatures use larger keys and hash algorithms, the
overhead associated with multiple signatures would be mitigated by
using this strategy.
Of the big benefit is instant compliance by a huge array of pre-
existing list s/w.
This may not be a big benefit if replay abuse becomes problematic.
I also worry about the expectation of lists looking at policy -
it's going to be many many years before a signer can expect their
policy to be looked at by a significant majority of list s/w. In
the intervening years they will be able to advertise as restrictive
policy as they like and it will mostly be disappointed at the outcome.
Agreed. The time frame before using separate email policy could be
very long. It may be faster to include the policy directly within
the signature, where caching would not demand additional network/time
related overhead.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org