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