On 05/26/2010 02:04 PM, Scott Kitterman wrote: > > > "Brett McDowell"<[email protected]> wrote: > >> I agree that adding anything to "throw away anything that doesn't have our >> signature" add complexity to implementation and therefore, by definition, is >> a barrier to adoption. That's not what we are debating. What we are >> debating is whether such complexity is a necessary evil that we should >> provide a specification to support -- as an optional mechanism for >> stakeholders who want to opt-in to the authenticated email ecosystem. I >> *think* the answer is "yes". But we haven't yet had the meaningful debate >> that will resolve that question. >> >> Let's debate whether transient trust through a MLM is actionable. Would a >> new header that enabled the MLM to report to the receiver that they indeed >> validated the original signature actually make any difference in the >> deliverability of that message to the receiver, and if yes, is that actually >> a good thing? I say "yes" and "yes". But I expect that if we debate this >> specific point one of you might highlight an unintended consequence that >> would tip the balance away from pursuing such a model. >> >> Thoughts? >> > That's not quite the question. > > Such transient trust can't be spoofable. It needs to have properties such > that if it asserts "trust me, it was signed by PayPal when I got it, so you > can ignore their discardable flag" it can't be used by arbitrary senders to > bypass PayPal's ADSP. > > I don't know of a way to do that which doesn't require a trust relationship > with the mail list provider. If you have such a relationship then it's > relatively trivial to just not bother with ADSP checks for mail from such > lists. > > I'm left not knowing what advantage there would be from a more complex > standardized approach.
Right, and where I have problems is that I doubt that most admins have any clue whatsoever which lists their users subscribe to. Some certainly have policies which may inform them (= don't do it), but beyond that this sounds somewhere close to an impossible task. Mike _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
