ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: DKIM and mailing lists

2006-01-19 23:47:35
On Fri, Jan 20, 2006 at 05:44:25AM +0100, Eliot Lear allegedly wrote:
Sender beware.  If it were to become common practice to overlay or
remove the DKIM signature upon delivery...
The ONLY time one removes a signature is when one breaks it.

Eliot I agree with all of what you say, particularly the philosophy of
keeping list participation cheap and simple.

On the matter of breaking signatures, I think that mantra #1 is that a
broken sig is the exact equivalent of no sig therefore we need not
impose the task of sig removal on any party.

Given mantra #1, I think we can give Lists very simple guidance:

 o preferably use DKIM to verify submissions
 o add List-ID - as all good Lists are doing now
 o DKIM sign the content so as to include List-ID

Verifiers should first process the "outer" signature of the List and
assuming that verifies, take the List delivery path.

Additionally a verifier might wish to attempt verification of the
"inner" signature, and if that verifies they may be able to add some
value. For the services I'm involved with, I would not do this step,
but I understand that others find this of value. Rather, I would
manage knowledge of which List-IDs the recipient has subscribed to and
regardless of anything else, email with a List-ID would be delivered
to a "List" Folder in the absence of more specific instructions.

The point about all this is that the List does not involve itself in
the matter of the original author and the final receiver. If the
original author sig happens to survive then the final receiver can add
value if they choose to - but it's not a matter for the List to
consider one way or the other. In short, Lists can be lazy and I'm
guessing they'll like that. This also happens to be what a lot of
Lists will do today with no changes in code.

Some have talked about a List verifying the submission and adding a
header that claims they made the DKIM verification. This delegated
trust approach bothers me and seems contrary to the fundamental
concept that a final receiver can determine all authentication matters
independent of intervening parties. I call this mantra #2 - trust no
one but yourself.

All of which delves into the contentious issue of multiple valid
signatures - on that note, I'll abstain for now apart to suggest that
valid multiples only seem to make sense when viewed as a hierarchy.


Mark.
_______________________________________________
ietf-dkim mailing list
http://dkim.org