ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Clarifying DKIM (etc.) expectations for mailing lists in the face of digests

2010-08-04 18:20:18
Douglas Otis wrote:
On 8/4/10 2:01 PM, John Levine wrote:

If you believe in ADSP or manual drop lists, you drop the message
because it's from paypal.com and it's unsigned.  I think we can expect
that we won't see any real paypal.com mail coming through lists.

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.

While I have no direct confirmation, I believe PAYPAL.COM is looking
for faults (BAD) more than anything else:

   If the mail didn't come from our machines, its not our mail.
   Get rid of it. (SPF)

   If the mail does not a valid 1st DKIM signature, its not out mail.
   Get rid of it. (DKIM+ADSP)

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.

Whether the receiver actually gets rid/reject the faulty mail is 
another matter.  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?)

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.

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.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>