On 4/29/10 12:02 PM, McDowell, Brett wrote: > (oops, sorry, it was an issue Al raised, not John... in any event here's my > answer) > > On Apr 29, 2010, at 1:23 PM, Al Iverson wrote: > >> On Thu, Apr 29, 2010 at 11:58 AM, McDowell, Brett<[email protected]> >> wrote: >> >>> On Apr 28, 2010, at 2:11 PM, John R. Levine wrote: >>> >>> >>>>> Your proposal that MLM remove Signatures would cause restrictive >>>>> policies to fail. >>>>> >>> Which is why I oppose this proposal. >>> >> As John Levine mentioned previously, your own posts to this list fail >> authentication and end up in many of our spam folders because of >> Paypal's SPF policy. I'm not against strong authentication policies -- >> but I'm wondering how you personally expect to be able to post to >> mailing lists without acceptance of this proposal? The status quo >> interferes with your ability currently, and broader adoption of >> authentication on the receiving side will only make it worse. >> > It's a question of priority and timing. > > Priority: it's more important to us that cyber criminals not be systemically > enabled to leverage MLM systems to bypass email authentication flows and > consumer protection policies designed to block their attacks... the attacks > that, if not for the MLM intermediary, would have been blocked thanks to > DKIM+ADSP and the voluntary compliance to ADSP policies by certain > ISP's/Mailbox Providers. > > Timing: therefore, until the standards community enables MLM systems to > maintain (if they wish) the integrity of DKIM/ADSP-enabled message > authentication flows that exist today (and are on the rise) and would > successfully deliver authenticated mail if not for the intervention of the > MLM system, our consumer protection policy has this apparent consequence on > PayPal employees that participate in certain public mail lists -- the ones > that break or strip DKIM signatures -- that would lead us to have to perform > workarounds as the issues are discovered. > > It's not ideal for me personally, but more importantly it's not ideal for any > sender trying to leverage these technologies to improve consumer protection. > That's why I'm here trying to advocate for a *solution* which Murray's > proposal just might be the basis for, but I humbly assert John's is not. > > I'd characterize the X-Y-Z proposal from Murray as having some hope of > solving the problem without dismissing the current consumer protection values > of DKIM+ADSP, and John's proposal as something akin to giving up on ever > seeing authenticated mail survive MLM intermediaries. > Reliance upon A-R chains combined with DKIM assumes proper handling of prior A-R headers with inclusion of valid A-R headers. There may also be concerns related to injection of misleading content, such as ads by other vendors, which could confuse recipients. In addition, any open-ended allowance for broken signatures create more exposure to exploitation when mailing-lists fail to make obvious annotations to the subject line. After all, any ADSP "tolerated" message could be replayed in spam campaigns.
Until mailing lists only relay messages, which IMHO few want, it is unreasonable to expect ISPs or recipients are able to decide when it is safe to trust A-R chains to override ADSP assertions. In addition, many large corporations list outbound servers in SPF records without knowing who else shares the service. Neither SPF nor A-R chains alone permit safe acceptance. Safety can be improved when a corporation knows which third-party providers are employed, and they audit how messages are handled. This effort only offers protection when they are also able to specifically authorize these services. When authorization is published as a hash, it will not directly reveal who is being used. The proposed third-party authorization scheme allows corporations a means to make extremely strict acceptance requirements, and to specifically enable ADSP exceptions for third-party providers, such as mailing-lists, whenever needed. The adoption of Internet Name-Bundles is to give users the latitude to enter names using synonymic ideograms. Such allowance will make alias or shadow domains appear as a third-party domain. Once again, the third-party authorization scheme ensures the acceptance of valid email without danger of inviting abuse. The TPA specification is at: http://tools.ietf.org/html/draft-otis-dkim-tpa-label-03 -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
