dkim-dev
[Top] [All Lists]

Re: [dkim-dev] dkim validation software and mail lists

2009-09-29 15:10:42
Daniel Black wrote:

Thanks for the quick response Hector,


Do you have any comment with the other post about fixing mail 

lists by changing the From address?

IMEO, I would be naturally allergic to any kind of From: rewriting 
concept.

Is some temporary whitelist logic until MLS become DKIM=DISCARD|ALL friendly 
an unreasonable request?


IMEO, the problem has been anonymous transactions. Known entities can 
offer corrective help in the decision path.


For A, the DATA is received allowing for RFC5322 header analysis,
specifically a ADSP domain check.

   Test #1 DKIM=DISCARD|ALL, NO SIGNATURE
           --> REJECT, REPLY CODE 550
   Test #2 DKIM=DISCARD|ALL, INVALID SIGNATURE
           --> REJECT, REPLY CODE 550
   Test #3 DKIM=UNKNOWN, NO SIGNATURE
           --> DATA ACCEPT, REPLY CODE 250
   Test #4 DKIM=UNKNOWN, INVALID SIGNATURE
           --> Add Authentication-Results header header
           --> DATA ACCEPT, REJECT, REPLY CODE 250

This is a RFC 2821 compliant,
ok


There was a 5th test that is critical to this discussion:

     Test #5 DKIM=DISCARD|ALL, 3rd party Signing Domain
            --> REJECT, REPLY CODE 550


I would of thought the DKIM=ALL is just a final step after an organisations 
signs all their email without having to consider the MLS breaks.


POLICY for DKIM has been discussed and analyzed for over 2-3 years by 
many smart people on both sides of the PRO/CON policy camp. 
Unfortunately, the final ADSP was a highly reduced version of SSP and 
conflicted with the perception that open-ended policy framework in 
principle would be a natural part of the DKIM process.

How is DKIM going to take off?

Signing is easy. Verification rules are easy. But how do I do filtering in a 
way 
that doesn't leave me in one of the following battles:
1. with email list operators who don't want to change settings
2. with email  list operators who do want to help but can't find all the 
'dkim-
friendly' settings on the software
3. with sender who have DKIM=ALL|DISCARDABLE, as you suggested, who's users 
aren't using the domain in that way
4. and with my users who are not getting some email while the above 
correspondence is taking place

I'm still searching for answers on how to deploy DKIM verification on large 
domains and do filtering on it with the impending ADSP adoption.


I think you need to keep in mind that there are people who don't 
expect ADSP to be adopted.  ADSP is a stripped down version of SSP 
which IMO made it impractical for MLS systems. ADSP are for 
"exclusive" 1 to 1 private direct mail transactions.  The payoff are 
the detected spoofs external from the 1 to 1 expectation - i.e. 
preventing ALL forms of 3rd party signatures or middle ware damages.

SSP had 3rd party signing considerations.  In my DSAP (DKIM Signature 
Authorization Protocol) draft proposal (long expired):

     http://tools.ietf.org/html/draft-santos-dkim-dsap-00

it attempted to make sense of SSP from a protocol consistency 
framework.  Take at look at a slide 9 in this PDF presentation:

     http://www.winserver.com/public/ssp/dsap-00.pdf

which gives you the POLICY filtering we are looking for.

In slide 18, an outline of the basic "middle ware" issues.

Overall, ADSP was not designed for the DKIM ready MLS which would be a 
3rd party signer.  It provides logic for handling a no 3rd party 
signing, but nothing that allows for a 3rd party signing short of not 
using a ADSP record.

That might be the missing policy domains in a MLS environment might 
need and use.  Today, with ADSP as it stands, their can't use ADSP for 
a mailing list without creating some form of DKIM/ADSP contention.  It 
wouldn't be "protocol consistency" as ADSP is written today.

So can you work around it without violation the AUTHOR DOMAIN 
intentions for having a ADSP record in the first place?

How do you decipher the BAD vs the GOOD?   Again, think anonymous.  If 
  a Black/White List or Reputation service is available, that helps, 
but  in lieu of the "Batteries Required" concept, how can continue to 
protect a ADSP domain where the integrity will be broken and do so in 
a manner that all downlinks will understand?

I can only see that done (or begin to be protocol consistency) with 
some form of an explicit "3rd party Signature" policy offering.

-- 
Sincerely

Hector Santos
http://www.santronics.com


_______________________________________________
dkim-dev mailing list
dkim-dev(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev