Douglas Otis wrote:
> Blocking all neutral sources is not practical, nor is reactive blocking
> effective against phishing. DKIM should be able to support proactive
> blocking based upon sender practices. Recipients processing these
> practices will benefit with less email in an unknown state.
Hi Doug,
+1
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?
Adding a VBR-INFO header doesn't seem to provide some assistance?
In layman terms, how can TPA help here?
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?
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
