ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Authorizing List Domains

2010-09-27 14:03:03
   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
 got:

 Authentication-Results: dkim.megabytecoffee.com; dkim=pass
 header.d=winserver.com; adsp=pass policy=all author.d=santronics.com
 asl.d=winserver.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(_dot_)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(_dot_)com :: spf-discuss(_at_)listbox(_dot_)com

 as this is the only stream I will want this to exist for that
 address.

 Is there a case where winserver.com could of signed with

 d=winserver.com; s=tms1; i=spf-discuss(_at_)winserver(_dot_)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
 association.

 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 
TPA-Label scheme.

 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(_dot_)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(_dot_)com ; ; Zone
 Records for author-domain: winserver.com ;

 f95d718ce593c9062808eec0470edbdb._atps TXT ("v=atps1;
 d=spf-discuss(_at_)listbox(_dot_)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(_dot_)com>

 I thought the format would be (according to RFC 2919)

 List-ID: [description]<spf-discuss.listbox.com>

 Comments?

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.

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

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