I'm saying that
if there are Resent-* headers representing identity, they should
be signed
We should be agnostic to the debate. If the MUA uses them, support them.
If the MUA does NOT use them, we don't.
Tony Hansen
[EMAIL PROTECTED]
Hector Santos wrote:
> From: "Tony Hansen"
>
>
>>> Does this presume that BS will be taking responsibility for the
>>> original domain?
>> Of course not; BS is taking responsibility for its domain. Hence its
>> signing of the Resent-From: header.
>
> Ok, so do have some insight into what HEADERS should be signed depending on
> what role the signer is taking?
>
>>> If Resent-From: becomes the source for DKIM verification, in essence,
>>> it has become a 3rd party signature system in the eyes of
>>> downlink verifiers? Yes?
>> No; it's a 1st party signature system for the forwarder.
>
> So its using From: for the key, and Resent-From: is just part of the signing
> hash? So basically, we have rule that says DKIM compliant Forwarders:
>
> a) Must Support RESENT-*
> b) Must Sign RESENT-FROM:
>
> Correct?
>
>>> Also another no so minor point:
>>>
>>> Will DKIM mandate support for RESENT-* fields? That's an awful big
>>> jump if so.
>
>> We already do. See section 5.4.
>
> Tony, unless I missed it, this does not say Resent fields support is a
> requirement. Specifically, it does not say that forwarder:
>
> a) Must support RESENT-*
> b) Must sign RESENT-FROM:
>
> Per 2822, section 3.6.6, Resent fields are a "SHOULD" not a MUST. And as far
> as I can tell, it is not a widely use practice. If this is a DKIM mandate,
> this goes against the idea that infrastructure change is not required for
> DKIM support.
>
> So once again, how does DKIM handle inconsistency and fail analysis. There
> is no Resent-*, the message is signed and it appears to be from a 3rd party?
>
> In short, I hope we are not assuming there will always be a Resent-* header
> from forwarders. This is clearly not the current standard practice across
> the board.
>
> --
> Hector Santos, Santronics Software, Inc.
> http://www.santronics.com
>
>
>
>
>
>
>
>
>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
