> 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.
> Sign all fields that are expected to be important to a filtering
> engine.
Yes. One slight problem with that is one doesn't know for sure which
headers might be relevant to a recipients filters. So I suspect this
approach will fall back to the "safest road" approach in which you sign
as many headers as possible.
> This implies that you sign Received fields, and I'll bet you don't.
I checked my code and yes, I do sign Received headers. This could
potentially cause a problem if they got re-ordered but that's not
supposed to happen with trace headers and in practice I've not seen it
happen. Is there some other problem with signing Received headers?
> Do you have any fields, besides Received, that you feel should/must
> NOT be signed?
I don't sign "Return-Path", "X" headers, or "Authentication-Results"
headers. "X" type headers are too unpredictable and are often stripped
(this is routine in my experience) by various software in the email
transmission path. IIRC "Return-Path" has a "strip it out" directive
written down somewhere. I've often found incoming messages collected
from store and forward services which contain a "Return-Path".
Stripping it breaks the signature so I don't sign that one if/when I
encounter it in a message I'm signing. "Authentication-Results" has a
criteria in the spec by which it too could potentially be stripped out
from an incoming message. So, to sign headers which are, in the spec
that defines them or through common practice, are likely to be sripped
should never be included in signatures IMO.
--
Arvel Hathcock
CEO, Alt-N Technologies
http://www.altn.com
_______________________________________________
dkim-dev mailing list
dkim-dev(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev