ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review

2010-09-01 21:30:43
Murray S. Kucherawy wrote:

Steve Atkins

If your goal is to have MLM developers rewrite their perfectly working
code to work around the fundamental flaws in ADSP - a protocol nobody
other than bulk mailers is interested in, and which in any even
marginally sane deployment would never interact with mailing lists at
all - I think you're going to be disappointed.

Setting aside ADSP for a second, I think there are still some 
people that would like to see MLMs preserve author signatures 
for the purposes of reputation evaluation.

Yes.

But two things:

    1) What is forgotten is what the author domain wants and,

    2) The unknown world of reputations services or
       non-standard assessment engines being used.

 From the perspective of an developer, if the technology is available 
with the 100% goal to address these type of issues, it should not be 
excluded as part of MLM+DKIM+ADSP offerings.

For example Murray.  Lets say I want to be flexible here and I provide 
the list options:

    [X] DKIM sign list mail
        [X] Check for ADSP domains

Then this list operator will help in short circuiting DKIM related 
issues regarding restrictive policy domains.

     Problem: We are being asked to not offer the
              [X] Check For ADSP domains option. We
              are being asked to ignore RFC 4686, 5016
              and 5617.

But I can see where someone doesn't want to enable the option, so the 
other options to consider:

    [X] DKIM sign list mail
        [_] Check for ADSP domains
        [?] Strip broken signatures

There are two design motivations for having the strip enabled or not.

1) Enabled: [X] Strip broken signatures

This makes it consistent with RFC 4871 when DKIM verifiers follow the 
mandate in 4871 to ignore broken signatures as no signature. 
Reputation engines that do no follow this are violating the 
specification because they should not be using the broken signature 
for any scoring or weighting.

2) Disabled: [_] Strip broken signatures

This only time this is valid is when the assessors are using a broken 
signature fault condition as a "data point" for their assessment.  The 
assumption is these assessors will be ignoring RFC 4871 Invalid To No 
Signature and are also ignoring RFC 4686, 5016 and 5617 regarding the 
POLICY security related standards because if they did support them, 
then they will be immediately filtered.

So #1 is more protocol consistent from a DKIM VERIFIER standpoint, and 
#2 is not which could only exist when 4871 Broken to No Signature is 
ignored and ADSP is not part of the framework.

The above options are possible, but only one is DKIM protocol correct 
as the draft standards are written.

I think your MLM covered both sides with its statements and teaches 
MLM developers what they need to do.

If by change the POLICY related drafts and also the threat/security 
provisions were removed, then I have no problem just having:

    [X] DKIM sign list mail
        [_] Strip broken signatures

as defaults because know we really need to have ASSESSORS out there 
that ignore the 4871 Broken to No signature status.

For list operators that enable the stripping, well, who knows what 
will happen, but I can only imagine it will create a climate that the 
3rd party signer trust is the only that counts and nothing else and 
all members have whitelisted the list or has signed up to some common 
reputation service - hmmm a POLICY for LIST domains!


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