It The original protection being sough in RFC 5016 section 5.3 item 4
was:
--
4. SSP MUST be able to publish an expectation that a verifiable
first party DKIM signature should be expected on receipt of a
message.
--
To support the problem statement in section 3.2:
--
From a receiver's standpoint, knowing that a domain not only signs
all of its mail, but places a very high value on the receipt of a
valid first party signature from that domain is helpful.
--
The assertion "discardable" will not resolve the declared problem
without also increasing the chances email with invalid signatures of
being discarded rather than rejected, or a DSN being generated, even
when the RFC 2821 FromMail is within the same domain. In response to
concerns expressed about the verifier handling implied by the
"discardable" assertion, by Steve Atkins, an author of a similar draft
that coined the term:
"Domains that do not [wish] to suffer a reduction in delivery
integrity are not candidates for use of any variant of SSP (and, as
such, their needs are out of scope)."
See:
http://mipassoc.org/pipermail/ietf-dkim/2008q1/009390.html
http://tools.ietf.org/html/draft-levine-asp-00
It is far too soon to establish (or even suggest) discarding as a
handling practice for DKIM signature failures. Discarding invalid
signature early on will prolong incompatibility issues. In this case,
discarding messages also eliminates evidence of possible criminal
activity, which is counter to an effort at eliminating this type of
fraud.
http://tools.ietf.org/html/draft-ietf-dkim-ssp-02
3.3. SSP Record Syntax
...
discardable All mail from the domain is signed with an Author
Signature. Furthermore, if a message arrives without a valid
Author Signature due to modification in transit, submission via
a path without access to a signing key, or other reason, the
domain encourages the recipient(s) to discard it.
NON-NORMATIVE DISCUSSION: Sender signing practices of
"discardable" would be usually inappropriate for domains of end
users, because of the potential for mailing lists and similar
agents to modify messages in such a way as to render the
signature invalid. Domains sending mail that is expected to
pass with no significant modification to the recipient, such as
domains sending only transactional messages, are appropriate
places to consider the publication of a "discardable" practice.
See [RFC5016] section 5.3 and Appendix A for further
discussion.
To eliminate concerns related to possible mishandling of the message
and to eliminate a reduction in the integrity of delivery assurances,
the term "discardable" needs to be changed.
Change to or add:
sole:
All mail from the domain is signed with an intent to
avoid agents that may damage or remove their signatures.
Therefore, this domain represents the sole entity assured
to provide signatures for this domain's messages.
NON-NORMATIVE DISCUSSION: Sender signing practices of
"sole" would be usually inappropriate for domains of end
users, because of the potential for mailing lists and similar
agents to modify messages in such a way as to render the
signature invalid. Domains sending mail that is expected to
pass with no significant modification to the recipient, such as
domains sending only transactional messages, are appropriate
places to consider the publication of a "sole" practice.
See [RFC5016] section 5.3 and Appendix A for further
discussion.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html