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: [email protected] > > 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: > > [email protected] :: [email protected] > > 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; [email protected]; > > 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 [email protected]? > > V:\wc5beta>makeatps (c) copyright 2010 Santronics Software, Inc. > usage: MakeAPTS author-domain signer-domain [... signer-domain] > > V:\wc5beta>makeatps winserver.com [email protected] ; ; Zone > Records for author-domain: winserver.com ; > > f95d718ce593c9062808eec0470edbdb._atps TXT ("v=atps1; > [email protected];") > > 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:<[email protected]> > > 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
