ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Draft minutes...

2006-07-13 11:55:39

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

<Prev in Thread] Current Thread [Next in Thread>