ietf-dkim
[Top] [All Lists]

[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>