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