On Jul 12, 2006, at 10:44 PM, Mark Delany wrote:
On Wed, Jul 12, 2006 at 05:42:53PM -0700, Michael Thomas allegedly
wrote:
Eric Allman wrote:
The draft has /always/ said that these header fields are to be
signed. From -03:
any header field that describes the role of the signer (for
example, the Sender or Resent-From header field if the
signature is on behalf of the corresponding address and that
address is different from the From address) MUST also be
included.
All I've done is re-word it.
We clearly have a disconnect here. When I read the previous text,
I see that
it is the *signers* resposibility to figure that role based stuff
and if
it can, it MUST add those headers to h=. If it can't figure out
that role, then
it's not
This is an interesting topic and dwells on the desire to protect UAs
from bad guys adding originating headers that could aid in a spoof. It
was part of my thinking wrt h=* discussion.
The problem of course is that no one knows what are, or will be,
originating headers either because we have no clue about the
destination UA or we have no clue about future headers.
My current thinking, FWIW, is that a diligent UA/MDA will likely
remove *all* headers that are not signed, excepting trace headers so
the need to ensure protection of any header becomes moot. That
includes, From: et al.
To my mind, the spec currently stands mid-way, it sort-of protects
obvious headers but cannot possibly protect all, so my druthers is
that we actually remove all compulsion as to which headers are signed
as it may well look truly quaint in five years time when other
important originator headers get created.
+1
This makes good sense, especially with EAI activity likely to be
making such changes necessary should this go wrong.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html