On Thu, 11 Jan 2007, Dave Crocker wrote:
So, one approach is to make sure to sign all fields that are typically
displayed to users. (A signature can cover multiple "approaches"; I'm
merely trying to characterize one of them, from your comment.)
Yes, I think that's necessary.
Would this be best communicated through a BCP document or another draft
(or both)?
> 1. How are folks deciding what fields to sign?
In my own case I decided to a) sign all headers (except X type headers)
and b) not give my customers a UI to decide which headers to sign and
This implies that you sign Received fields, and I'll bet you don't.
We do, by default anyway. You can disable it by replacing the list of
signed headers.
> 2. To what extent do we care about different signers choosing
> different fields to sign, in terms of how to process a validated
> signature?
I care greatly if the Subject isn't covered for the reason mentioned above.
Does anyone else have thoughts on this?
I concur.
What would be the minimum set of headers that you would find credible to
have signed? And, of course, why?
All displayed headers, and any header which indicates ownership of the
message in some way (e.g. the Sender and Resent-* ones).
Do you have any fields, besides Received, that you feel should/must NOT
be signed?
The feature to change the list of signed headers was specifically added to
enable someone to omit the Return-Path: header which apparently Exchange
adds. If the verifier gets such a message only after the receiving MTA
has replaced it with its own idea of what that value should be, the
signatures will not verify.
And the other line of question is about having different folks signing
different sets of fields. Is that variation important? How? And how
can/should they be distinguished by the validator/filter?
I would think the verifier could be given a list of headers which, if
present, MUST be signed. If for example the verifier wants all From
headers to be signed and it gets a message whose signature verifies but
From wasn't signed, the verifier SHOULD act as though the signature was
not present.
This is all local policy or BCP stuff though, not something the base
specifications necessarily need to address.
-MSK
_______________________________________________
dkim-dev mailing list
dkim-dev(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev