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