Tony Hansen wrote:
Resent-From: and Resent-Sender: would be signed only if present in the
header. It's perfectly legit for a forwarding system to add them (and
expected according to the specs), and if that forwarding server then
signs the message, those headers MUST be treated in the same category as
From: and Sender:.
All four of these headers should be treated as: if present, it MUST be
signed.
Here's my big question though: does your receiver enforce that, or is
this just
a policy mandate on the signer? The original text made it sound a lot
like the
latter. The new wording makes it sound a lot like the former, which I
think is
a big problem. As I said, I'd be even happier to get rid of the normative
language here to eliminate this ambiguity on the receiver altogether.
Mike
Tony Hansen
tony(_at_)att(_dot_)com
Michael Thomas wrote:
Eric Allman wrote:
For the same reason From: has to be signed --- they represent the
[fill in blank with your favorite word: author, originator, whatever]
of the message. I suppose we can legitimately ask why From: MUST be
signed though. In terms of interoperability it is not required, but
in terms of being useful it seems like it is.
I'm unclear on Resent-From and Resent-Sender: can they be added in
transit?
If so, the MUST as worded below will guarantee the signature won't be
valid
after somebody adds those headers.
I guess if you're going to make these MUST requirements why Sender or
ListID aren't MUST's too. Frankly I think the wording with From, Subject
and Date is fine and leave the rest to the disgression of the signer.
Mike
eric
--On July 12, 2006 4:36:41 PM -0700 Michael Thomas <mike(_at_)mtcc(_dot_)com>
wrote:
Eric Allman wrote:
> section 3.6.2, Resent-From, and Resent-Sender MUST also be
included.
Why MUST these be signed?
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html