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