Doug,
The way I read SSP-02 is that MTA verifiers are no longer in the picture
but rather MUAs and it is MUAs that would do the DISCARDING:
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.
^^^^^^^^^^^^
As it reads, the recepient(s) A.K.A END USER(S) will do the discarding
(whatever that means). There is no any semantics in this draft for MTA
verifier handling, therefore, there are no MTA rejections concerns.
The draft seems to cater to BULKS MAILERS pushing mail pass MTAs with
the hope the MTA will ignore DKIM processing passing the buck to the MUA
DKIM market where "DISCARDNG" (Whatever that means) does not play a SMTP
rejection/bounce like concept.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Douglas Otis wrote:
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
tohttp://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html