> > could someone please describe the difference between AlwaysSignHeaders
> > and OversignHeaders? I read the man page but it is still absolutely
> > unclear to me.
>
> They're very similar. They evolved at very different times. It's likely
> that they could be merged.
>
> If you list a header field name in AlwaysSignHeaders, then you're
> guaranteed your name will appear at least once in the "h=" tag. If the
> field was present, then it has no effect; if the field was absent, then it
> will appear in "h=" once anyway to ensure that it can't be added
> downstream without invalidating the signature.
>
> If you list a header field name in OversignHeaders, then you're guaranteed
> that for "n" times your header field appeared in the original message, it
> will be listed "n+1" times in the "h=" tag, guaranteeing it can't be added
> downstream.
>
> AlwaysSignHeaders does not prevent the addition of a second instance of a
> header field that was present in the original.
>
> > If I want to prevent someone adding a non-existant and deleting or
> > modifying an existing header, where should that be put into?
>
> You can't delete or modify an existing header field if it was signed,
> regardless of these settings. The extra names in "h=" that these create
> prevents addition of extra instances of the header field.
>
> Does that clear it up?
>
> We probably should look at merging AlwaysSignHeaders and OversignHeaders
> into a single setting once OversignHeaders is no longer an FFR.
Thanks a lot.
I will try to repeat what I understood with my own words. (I believe that this discussion might be helpful for others, too.)
AlwaysSignHeaders (ASH) will add exactly one header field. So, if this header field is set then it will be included in the signature with its value. If it is not set then it will be included in the signature with its value of null. So it makes sure that nobody modifies the field if it exists or adds the field if it does not exist. But if it exists and someone adds this specific field a second time (downstream) then the signature is still ok as it accounts for the first field only and "does not see" the second field.
If I would like to make sure that only the exact number of fields that I put into the header travel down the road then I should use OversignHeaders (OSH). It takes all of the named fields at the time of signing and puts them n+1 times into the header "h=" (and the signature). The "+1" is used for a final empty header of that name to close the list. Means nobody can add a header without being detected because that delimiting last header is not empty anymore and the signature verification would fail.
So, if you used OSH for signing Received headers and you had 3 Received lines at the moment of signing, you would find Received 4 times in the "h=" field and the 4th acts as a delimiter. If the mail travels on and gets some more Received headers it will finally fail signature verification. If I used ASH it will succeed the verification because it does not consider the ones added.
Means, in my case where I would like to make sure nobody modifies the header or adds the header if it does exist or if it does not exist I should use OSH and not ASH because with ASH someone could easily add that header a second time, what would be prohibited when using OSH.
And the Debian default of "OversignHeaders From" makes sure that no more of the From headers that I put into the message are added (normally one From, but two would be ok, too (if I put them in)).
Do I still need to use ASH for my X-Scan-Info or can I omit that for OSH to work correctly? I believe I can omit the ASH?
Am I right? Please correct me.
Thanks a lot!
-lutzn
Btw, did a backport of the wheezy version. It's not the very latest but better than the one in squeeze.
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Received on Tue Jun 19 2012 - 22:04:16 PST