ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Resigner Support of RFC 5617 (ADSP)

2009-10-11 14:49:01
On 10/11/2009 02:41 AM, Michael Deutschmann wrote:


If this is indeed the official semantics of the protocol, then I would
petition to add a "dkim=except-mlist" policy.  Which means "I sign
everything that leaves my bailiwick, but may post to signature-breaking
MLs."


Michael Thomas wrote:

No need. That is exactly what the semantics of "all" is.


Wow!

-1

    all       All mail from the domain is signed with an Author
              Domain Signature.

    discardable
              All mail from the domain is signed with an
              Author Domain Signature. ......

These two policies are 100% the same with the difference DISCARD has 
explicit  actionable semantic:

                ....... Furthermore, if a
                message arrives without a valid Author Domain
                Signature due to modification in transit,
                submission via a path without access to a
                signing key, or any other reason, the domain
                encourages the recipient(s) to discard it.

I read that to say to implementators:

   DISCARD - add rejection/drop Software logic
   ALL     - add logging, recording, tracing "learning" Software logic

I don't see anything that says DKIM=ALL allows for a 3rd party 
signature expectation.  The ADSP name, by WG consensus, was 
specifically titled for "AUTHOR DOMAIN" Signing Practice.  Not 3rd 
party signing practice.

Now, was it was a mistake and the authors really meant DKIM=ALL was an 
ALWAYS signed by someone concept?

That would be a different issue, but come on folks, ADSP was not 
framed to mean anything but the Author Domain signing his mail.

The authors position was one to intentional neglect and ignore any 
considering for 3rd party signatures:

B.4.  Third-Party Senders

    Another common use case is for a third party to enter into an
    agreement whereby that third party will send bulk or other mail on
    behalf of a designated Author or Author Domain, using that domain
    in the [RFC5322] From: or other headers.  Due to the many and
    varied complexities of such agreements, third-party signing is
    not addressed in this specification.


--

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

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