From: "Tony Hansen" <tony(_at_)att(_dot_)com>
I'm tempted to say: if the mailing list is going to do
*anything* to the message other than act as a simple
reflector, it *must* strip out any existing dkim signature.
What it does after that is up to the mailing list.
This would make sense for certain policies. If the processor is going to
bother with 'understanding' DKIM entities, it would not make sense to
blindly strip without sound logic.
So it might suggest for a LS to offer options to just allows
subscriptions and submissions from domains with policies:
[X] Allow DKIM domains with:
[X] NONE (no policy)
[X] WEAK (signature optional, no third party)
[X] NEUTRAL (signature optional, 3rd party allowed)
[_] STRONG (signature required, 3rd party allowed)
___ EXCLUSIVE (signature required, no 3rd party)
___ NEVER (no mail expected)
because the above offers consistent logic to be able to strip any
signatures and distribution verifiers will not break.
If it allows a STRONG policy, then needs to do a resigning when changing
content.
EXCLUSIVE and NEVER should not apply because mail from these domains
should never gain entry into the LS network anyway (i.e. stopped at the
SMTP receiver/verifier).
If we go with a stripping concept, I think this action should to be
recorded in the headers, maybe within the DKIM results header, to track
the history of the process.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org