On 8/4/10 4:18 PM, Hector Santos wrote: > Douglas Otis wrote: > > Clearly, paypal.com did not initially internalize the significance > > of ADSP dkim=discardable. Perhaps now they have. > > The evidence is there they want hard failures via SPF and ADSP. > Having those public records is a strong conscious decision of their > intent for exclusive paypal.com mail operations. No Outsiders.
By internalize, I meant paypal.com users were not fully cognizant of issues related to their ADSP assertions. I don't think paypal set out to cause mailing-list related problems or failures. > Fault detection is clearly the current biggest possible realistic > practical benefit you can get from DKIM+ADSP - if and only if > receivers supported ADSP. It is also the easiest and most practical > logic you can to software today - no batteries (REPUTATION databases, > do they exist?) required. Agreed. ADSP represents a proactive measure against phishing where reactive solutions have been ineffective primarily due to the rapidity demonstrated with bot-nets. > Whether the receiver actually gets rid/reject the faulty mail is > another matter. Which is why ADSP needs to accommodate normal use. Otherwise, with these issues, broader adoption is less likely. > Even if the WHITE LIST model is being sought, you > can only determine a valid good message after you determine it isn't > a bad message in the first place. In addition, SPF, ADSP allows for > detection of faults with anonymous transactions. Look for good mail > requires batteries - reputations databases (which one?) As the Internet transitions into accepting email from IPv6 sources, associating an IP address seen at receiving MTAs with some DNS response becomes increasingly problematic. With IPv6 not being a superset of IPv4, the resulting CGNs, tunnels, and translation services will cause such methods to be unreliable. I am about to write an ID to describe how DKIM keys could be used to authenticate outbound servers, and not just the message. Reputation will not work at the message using cryptographic schemes that can be replayed. Any such scheme can be easily gamed. The TPA-Label scheme is able to authorize informal third-party services based upon this type of authentication. A cryptograhic name based approach to authenticating outbound servers represents a sound bases for defending email. > > I seriously doubt they were alone in that regard. It is not > > inconceivable that A-R headers were seen as a remedy that might > > allow such use. There are many similar companies where employees > > exchange messages using the recognizable domain of their > > organization. > > Maybe they decided to use subdomains (i.e. corp.paypal.com, > sales.paypal.com, etc). Its not hard to accept this practice of > separating the highly abused paypal.com brand domain from everything > else. Using subdomains or look-alike domains are not very helpful at preventing phishing. Such tactics make phishing more productive by increasing recipient confusion. There is paypal-inc.com that lacks any ADSP assertion, where one hopes this domain does not become targeted. > Facebook.com, facebookmail also has a hard SPF policy, all messages > seem to be 1st party signed only but there is no explicit ASDP saying > so. Paypal.com is already at the limit of 10 spf records (that are replicated for version 2) to define their IPv4 address space. However their version 1 and 2 record sets return a neutral result when a source IP address does not match. Facebook, on the other hand, offers a FAIL. Clearly, the spf approach will prove frustrating when attempting to connect to IPv6 servers. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
