> -----Original Message----- > From: [email protected] [mailto:ietf-dkim- > [email protected]] On Behalf Of Douglas Otis > Sent: Tuesday, June 01, 2010 11:38 AM > To: [email protected] > 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
