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