-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Douglas Otis
Sent: Tuesday, June 01, 2010 11:38 AM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Lists "BCP" draft review
See section 4.3, third paragraph:
,---
[ADSP] presents an additional challenge. Per that specification,
when a message is unsigned or the signature can no longer be
verified, the verifier must discard the message. There is no
exception in the policy for a message that may have been altered by
an MLM. Verifiers are thus advised to honor the policy and disallow
the message. Furthermore, authors whose ADSP is published as
"discardable" are advised not to send mail to MLMs as it is likely to
be rejected by ADSP-aware recipients. (This is discussed further in
Section 5.3 below.)
'---
There is no MUST discard, only "encourage".
Correct, and as has been discussed on the list already, this document is
avoiding making normative assertions.
Secondly, there is no
clear
definition for discard, although it is generally understood to mean
silently delete.
Can you point me to such a definition someplace?
This recommendation appears to be making deliver-ability distinctions
between "discardable" and "all", that does not exist in the ADSP
specification.
Yes, that is precisely the problem.
Please add a statement indicating this concept is in conflict with
ADSP. Such as:
ADSP is in conflict with the Message Stream concept, since An Author
Domains Signature must match exactly with the email-address domain.
I fail to see how those two are in conflict. ADSP works just fine to nail down
the use of one particular message stream while leaving others less restricted.
From a phishing perspective, advocating use of different domains, or
sub-domains will lead to phishing being more successful, and also
likely increase the number of attempts.
[...]
This and the rest of it seems to be a variant of the ADSP debate, so I'm going
to avoid replying within this thread. It belongs in a different thread.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html