Charles Lindsey wrote:
Or changed to X-DKIM-Signature and bind this also in the new signature.
And +1 to that. It prevents subsequent verifiers from worrying about that
signature any more, but retains the opportunity for Sleuths, Conspiracy
Theorist or just the Plain Curious to work out what had gone wrong, and
possibly even to try to verify that signature by reversing the changes
which had broken it.
But all this tends to confirm my view that we need some BCP document to
encourage Mailing Lists to behave in some consistent way.
Yes, DKIM consistency is required for list servers who are "natural
destroyers" of original mail integrity.
Since POLICY is no longer the emphasis of the WG and won't work well
with the List server interoperability requirement, and the consensus
of the group seems to be they don't want it, I have been trying to
justify a reason how adding DKIM support will not cause problems.
I analyzed the consistent processing DKIM signing requirements and the
boundary conditions for our list server and produced this summary table:
Possible List Server Action for DKIM-BASE + Reputation
Boundary Conditions
+==================================================================+
| Signed | Vouched | List Server (Domain Safe?) Action |
|==================================================================|
| NONE | NONE | optional sign, no domain signing presumed |
| NONE | YES | indeterminate state (How is vouch determine?)|
| VALID | NONE | resign |
| VALID | YES | sign, domain expectations intact |
| INVALID | NONE | No sign (don't hide breakage) |
| INVALID | YES | Rejected at SMTP receiver |
+------------------------------------------------------------------+
You see, we planned on adding receiver verify support first, then add
signing support until signing was better understood, deemed safe for
my customers to sign their domains or hosted domains and the DKIM/DNS
Signing management tools was completed.
By adding verify support first we can at least include it as part our
existing incoming mail filtering system. When policy was considered,
I saw something really useful for many domains, not all but many, if
not the majority (the larger set of smaller systems, and highly
exclusive domain organizations not email providers combined).
However, for an integrated list server system such as ours, we are
forced into a position of how to handle signed list mail that will be
naturally broken by the list server. So by supporting DKIM for
verification, I feel somewhat technically and also ethically obligated
to require the list server to perform DKIM (re)signing otherwise
domains signatures can be harmed. Either that or hold off on DKIM as
was done.
About the states above:
RFC 4871 says the invalid signature equals never signed. I have a
serious problem with that idea and considered it flawed. The above
three vouched states, I think, shows the reason for me:
NONE/VOUCHED How can this happen when there is no d=?
VALID/VOUCHED PERFECT! The golden needle in the haystack!
INVALID/VOUCHED REJECT! I hope!
What is the certified signer domain being vouched for? I hope its for
a valid signature only. If the certified domain signature is invalid,
it should rejected (flagged).
But if we can also vouched for a message that had no valid signature,
then what responsible domain identity do we used? There is no d= tag.
There is i= tag. There is no signature. Do we fall back to the
5322.MailForm domain?
So this is a case where INVALID SIGNATURE is not the same as NO SIGNATURE.
Finally, now I see where the deprecated revision 06 DKIM-Overview
statement which I had suggested to be removed (because reputation was
not a chartered item) saying:
2.3. Filtering
...
Unless a scheme can correlate the DKIM signature with accreditation
or reputation data, the presence of a DKIM signature SHOULD be
ignored.
IMO, is now a very important guideline to once again provide.
I don't particularly feel comfortable with supporting a commoditized
protocol that is only useful when the domain has registered with
centralized accreditation service, nonetheless whether we do support
it or not, the guideline should be well noted. Receivers are no longer
going to be able to depend on chartered Policy framework, hence they
are going to need "something" and if reputation is going to be it,
regardless of what the DKIM WG Charter says, then it should be
highlighted DKIM signed mail is potentially harmless without some
vouching system associated with the signing domain.
--
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html