On 5/11/10 7:37 AM, Serge Aumont wrote:
-Sympa include DKIM signature verification and use DKIM signature
status in the process of message submission and email commands
-it remove broken pre-existing DKIM signature and keep others as is
(not all messages are processed in way that brake signature)
-it reject message comming from author ADSP record is discardable
and if the process of message by the MLM brakes signature. This
prevent brodcasting of a message that should be discarded by final
-it add it's own signature (on per list configuration parameter)
-it sign MLM services messages and digest.
Why limit rejection to ADSP "discardable" and not include ADSP "all"?
Why would it be okay to accept messages having ADSP "all" that lack a
valid Author Domain Signature?
BTW, ADSP "discardable" does not imply the desire to have messages
rejected, especially from a MLM application running post acceptance.
I notice a good idea : as Sympa verify incomming DKIM signature it
should add a [AUTH-RESULTS] header field ; this header should be part
of the DKIM signature added by the MLM engine. I will add this feature
in Sympa in a near future.
In respect to Auth-Results, when is it safe to assume MLM applications
ensure compliance with ADSP?
"Verifiers that receive mail bearing DKIM signatures that fail to
verify might benefit from attempting to detect that such mail passed
through a non-participating MLM and then decide not to apply [ADSP] in
order to avoid aggressive filtering of mail that should otherwise have
This proposition may introduce a security issue : spammers could fake
an sender email and a MLM engine in order to bypass ADSP from a
particular domain. This proposition is a limit of what "ADSP
discardable" mean. If we accept this idea that the final verifier may
not test ADSP because the message comes from an non DKIM MLM, "ADSP
discardable" is not usefull anymore. We all known that the use case of
"ADSP discardable" is really limited.
Agreed. When ADSP requires alternative domains to be compliant with
third-party services, this lessens security. Essentially, this approach
requires recipients to ignore the From header and to pay attention to an
unseen DKIM signature perhaps without an indication of it being valid.
Please remove this paragraph from this draft.
How would removing this paragraph change signing behaviors in a way that
At last, another idea usefulness is that draft in * :*
"A possible mitigation to this incompatibility is use of the "l=" tag
to bound the portion of the body covered by the body hash, but this
has security considerations (see Section 3.5 of [DKIM])."
The "l=" tag is one of the worth idea of DKIM if introduced because of
message body footer added by some MLM. MLM must not add anything after
the end of a message because this break Mime content. When adding a
footer, MLM should add an extra mime part, and this often require to
modify mime headers. So "l=" tag should not ne considered as an
efficient way to protect DKIM signature.
I known that the problem is comming from rfc-4871 but I propose to
remove this sentence from this draft.
Would you also suggest a practice of not altering the Subject line, or
of not providing uniform message formats?
It seems unlikely there is a desire to have these features removed from
Would you be interested in an alternative mechanism requiring the same
overhead as for ADSP, that eliminates a need to change any MLM handling?
If ADSP is worth doing, why is it not worth doing in a way that
NOTE WELL: This list operates according to