ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] PROTO writeup for draft-ietf-dkim-mailinglists-10

2011-05-11 08:43:34
I'm sorry, Hector: I can't understand what you're saying in this
message, nor what you want done.

Barry, as chair

On Wed, May 11, 2011 at 03:35, Hector Santos <hsantos(_at_)isdg(_dot_)net> 
wrote:
There is consensus of the working group, as a whole, behind it.  A
minority of participants feel that the advice given in the last paragraph
of section 1 is all that makes sense, and that the rest of the document
isn't needed (see "Working Group Summary" later in this writeup).  Those
participants are willing to accept this document, nonetheless, seeing
no harm in it.

I was the MLM I-D non-acknowledged person who highlighted the
interoperability problem with MLM and DKIM (RFC4871) and ADSP (RFC5617 plus
all other related document.  The Author Domain awareness solutions described
were my inputs ad outlined in the expired 2006 DSAP I-D.

As described in MLM I-D section 1.1:

  The DKIM signing specification deliberately rejects the notion of
  tying the signing domain (the "d=" tag in a DKIM signature) to any
  other identifier within a message; any ADMD that handles a message
  could sign it, regardless of its origin or author domain.  In
  particular, DKIM does not define any meaning to the occurrence of a
  match between the content of a "d=" tag and the value of, for
  example, a domain name in the RFC5322.From field, nor is there any
  obvious degraded value to a signature where they do not match.  Since
  any DKIM signature is merely an assertion of "some" responsibility by
  an ADMD, a DKIM signature added by an MLM has no more, nor less,
  meaning than a signature with any other "d=" value.

This must be a PROBLEM statement because the MLM I-D offers solutions to
deal with protocol definable "obvious" associations declared by the author
domain.

If there is a consensus to accept this MLM I-D document to address concerns
with the MLM interoperability problems, then it conflicts with the stated
non-consensus chair conclusion related to Ticket #25 for RFC4871bis to close
the issue.

--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html