[ietf-dkim] Clarifying DKIM (etc.) expectations for mailing lists in the face of digests
hsantos at isdg.net
Wed Aug 4 16:18:34 PDT 2010
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
More information about the ietf-dkim