Doug, two things are clear.
One, your design philosophy for DKIM is counter that of the current
consensus and direction; two, I don't think I will go wrong with
sticking with the what has been the standard electronic communications
variables in any environment since the dawn of time, WHO ARE YOU?
(From:), ARE YOU TALKING TO ME? (To:) , ABOUT WHAT (Subject:) and WHEN
(Date:).
Any new "altering" system being consider is a FOREIGN concept and should
follow a "reversibility" rule of thumb that is the standard
consideration in all transformations.
In short, if you can secure these four fundamental message variables,
From:, To: Subject: and Date: then nothing will work right, never mind DKIM.
Dave asked a simple question and as it is TODAY and has been for
multiple decades of years, these variables are pretty sound across the
board. Thats obvious and they will be our defaults.
--
HLS
Douglas Otis wrote:
On Jan 11, 2007, at 12:36 PM, Hector Santos wrote:
Dave Crocker wrote:
1. How are folks deciding what fields to sign?
Odds are good we will use a default of the most common fields across
all mail networks and devices. The top most:
From:
To:
Subject:
Date:
These questions need to be asked of MUA vendors as well. Should signed
headers be annotated in some fashion? For example, what if the
signature included the identity found in the Sender header, but was not
signed? Should the Display-Name be highlighted differently? When
header annotation depends upon the identity being recognized by retained
information and associated with the signature, then retained
Display-Names might supplant this questionable component in an unsigned
header.
>
and throw in Message-ID:
2. To what extent do we care about different signers choosing
different fields to sign, in terms of how to process a validated
signature?
Only that it isn't something that will readily change and use a field
that may not survive.
How should a header <utf-8(_at_)utf-8 <ascii(_at_)ascii>> be annotated? Should it
be signed? Which component of this header can be trusted as having been
confirmed via the DKIM signature? Keep in mind, domains might differ.
-Doug
_______________________________________________
dkim-dev mailing list
dkim-dev(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev