[ietf-dkim] Authorizing List Domains
2010-09-25 08:46:05
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: 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?
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 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?
--
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
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs, (continued)
- Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs, Alessandro Vesely
- Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs, Ian Eiloart
- Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs, Graham Murray
- Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs, Steve Atkins
- Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs, Ian Eiloart
- Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs, Alessandro Vesely
- Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs, Michael Deutschmann
- Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs, Ian Eiloart
- Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs, Ian Eiloart
- Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs, Douglas Otis
- [ietf-dkim] Authorizing List Domains,
Hector Santos <=
- Re: [ietf-dkim] Authorizing List Domains, Douglas Otis
- Re: [ietf-dkim] Authorizing List Domains, Murray S. Kucherawy
- Re: [ietf-dkim] Authorizing List Domains, Douglas Otis
- Re: [ietf-dkim] Authorizing List Domains, Murray S. Kucherawy
- Re: [ietf-dkim] Authorizing List Domains, Douglas Otis
- Re: [ietf-dkim] Authorizing List Domains, Murray S. Kucherawy
- Message not available
- Re: [ietf-dkim] Authorizing List Domains, Douglas Otis
- Re: [ietf-dkim] Authorizing List Domains, Stephen Farrell
- Re: [ietf-dkim] Authorizing List Domains, Hector Santos
- Message not available
- Re: [dkim-dev] [ietf-dkim] Authorizing List Domains, Douglas Otis
|
Previous by Date: |
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs, Douglas Otis |
Next by Date: |
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs, Michael Deutschmann |
Previous by Thread: |
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs, Douglas Otis |
Next by Thread: |
Re: [ietf-dkim] Authorizing List Domains, Douglas Otis |
Indexes: |
[Date]
[Thread]
[Top]
[All Lists] |
|
|