[ietf-dkim] Authorizing List Domains
dotis at mail-abuse.org
Mon Sep 27 11:59:44 PDT 2010
On 9/25/10 6:41 AM, Hector Santos wrote:
> And it works great with sender/domain policies. Here is a A-R
> record examples with the experimental ASL extension:
> This was from a message posted to a list and how a beta tester member
> Authentication-Results: dkim.megabytecoffee.com; dkim=pass
> header.d=winserver.com; adsp=pass policy=all author.d=santronics.com
> MegabyteCoffee.com validated the winserver.com signature and also
> saw this 3rd party signer was authorized by santronics.com with the
> domain included in the asl= list. In this my AMDM domains white
> list themselves.
> Here is another interesting one just created with the SPF Mail
> Reports just posted. The mail bot was off since Nov 2009 and I just
> turned it on to see our signing and listbox.com signing. This is
> what I got when listbox.com echoed back a list copy:
> Authentication-Results: dkim.winserver.com; dkim=pass
> header.i=listbox.com header.d=listbox.com header.s=launch; adsp=fail
> policy=all author.d=winserver.com asl.d=listbox.com (unauthorized
> signer); dkim=fail (DKIM_BODY_HASH_MISMATCH) header.i=winserver.com
> header.d=winserver.com header.s=tms1; adsp=pass policy=all
> author.d=winserver.com asl.d=; From: spf-discuss at winserver.com
> As expected, reading the two pairs from the bottom, listbox.com
> destroyed my DKIM body hashing. ADSP passed although it should
> report fail since "there is no signature anymore" for winserver.com.
> The resigning listbox.com was valid but the ADSP policy failed since
> it was not within the winserver.com ASL authorized list.
> Adding it to the list will solve it but I will use a different
> domain for this mailing list. :)
> In a way it seems that a greater granularity will help here for
> example a complex association:
> spf-discuss at winserver.com :: spf-discuss at listbox.com
> as this is the only stream I will want this to exist for that
> Is there a case where winserver.com could of signed with
> d=winserver.com; s=tms1; i=spf-discuss at winserver.com;
> Overall, I think, at best, I want to tell a TRUST/REPUTATION layer
> what is positively expected. Not give it a negative. It should
> not just add weight for just "listbox.com" but a specific
> How can/will VBR help here?
It can't, especially against phishing. This also leaves open the issue
of Sender or List-ID header fields that might be needed to ensure proper
message sorting of those from third-party services. In addition, DKIM
whitelisting reliance makes it an imperative to ensure against damaged
signatures to retain delivery integrity. The small percentage of DKIM
mail that might otherwise fail can be recovered safely using the
> Adding a VBR-INFO header doesn't seem to provide some assistance?
> In layman terms, how can TPA help here?
The TPA-Label scheme is similar to your ASL ADSP extension, however it
scales to any desired size, and can stipulate what type of
authentication is to be applied and whether additional header fields are
required to be compliant with the authorization.
There would be a benefit in adopting your ASL list specifically for
those wanting to use sub-domain signing when segregating mail streams,
where scaling or header field compliance would be much less of an issue.
> Maybe, with ATPS, you can hash the entire spf-discuss at listbox.com?
> V:\wc5beta>makeatps (c) copyright 2010 Santronics Software, Inc.
> usage: MakeAPTS author-domain signer-domain [... signer-domain]
> V:\wc5beta>makeatps winserver.com spf-discuss at listbox.com ; ; Zone
> Records for author-domain: winserver.com ;
> f95d718ce593c9062808eec0470edbdb._atps TXT ("v=atps1;
> d=spf-discuss at listbox.com;")
> Hmmmm, does this make sense? I kinda like this idea.
> This would be the LDSP extension idea where the LIST-ID is used for
> the hash. BTW, listbox.com has this header:
> List-ID:<spf-discuss at listbox.com>
> I thought the format would be (according to RFC 2919)
> List-ID: [description]<spf-discuss.listbox.com>
The ATPS draft incorrectly assumes two things:
1) All desired third-party services use DKIM.
2) Additional header fields are not needed to ensure proper message
sorting or recognition.
The TPA-Label scheme can include wildcard or separate domain
descriptions to match against Sender or List-ID headers. In other
words, the Author Domain can allow the third-party signature and List-ID
or Sender header fields to differ.
More information about the ietf-dkim