[Mailman-Developers] New RFC on using DKIM with MLMs

[Barry Warsaw]

On Oct 12, 2011, at 02:46 PM, Murray S. Kucherawy wrote:

>The IETF recently issued an RFC, with BCP status, regarding interaction
>between DKIM and MLMs.  It seems like this community might be interested.
>
>http://www.ietf.org/rfc/rfc6377.txt
>
>Long ago I mentioned on this list that the IETF was undertaking this effort;
>this is the final product.  I hope it's helpful.

It is, and thanks very much for sending us the reference.

I found myself nodding my head quite a bit as I read it, often thinking "yeah,
we do that".  I'm in general agreement with the recommendations, so just a few
notes here.

$3.3

"In general, absent a general movement by MLM developers and operators toward
more DKIM-friendly practices, an MLM subscriber cannot expect signatures
applied before the message was processed by the MLM to be valid on delivery to
a Receiver.  Such an evolution is not expected in the short term due to
general development and deployment inertia.  Moreover, even if an MLM
currently passes messages unmodified such that Author signatures validate, it
is possible that a configuration change or software upgrade to that MLM will
cause that no longer to be true."

For Mailman, I think we'd like to, and would generally be able to be more
DKIM-friendly, if we actually knew what to do.  Short of not modifying the
incoming message at all, and absent clear guidelines in this or any other RFC,
we're just flailing in the dark.  I think the RFC makes it clear though that
there really are no good answers.  It's a minor point that has no practical
effect, but I think it states our project's general policy of wanting to be as
RFC-compliant as possible.

I do agree with the RFC's point that the output of a resending MLM (such as
Mailman) is a new message, i.e. it is the originator.  The original message
has been received, and its existence in the mail infrastructure is complete.

$4.4 points to what I think is the right solution for us, and which we already
largely implement.  If a site running Mailman wants to verify signatures on
incoming posts, it should do this in the receiving MTA that feeds messages to
Mailman.  And if they want to sign outgoing messages, again this is done in
the outgoing MTA that Mailman feeds messages to ($5.8).  Mailman should not
verify or DKIM sign anything.  Mailman's is moderately DKIM aware, in that it
will simply remove DKIM headers if configured to do so, and this should be the
default (backed up by $5.7 as I read it).

$5.2 "A resending MLM SHOULD reject outright any mail from an Author whose
domain posts such a policy, as those messages are likely to be discarded or
rejected by any ADSP-aware recipients."

Within Mailman's architecture, this would be the prerogative of the incoming
MTA feeding messages to Mailman.

$5.3 Interesting that they recommend checking ADSP at subscription time, with
periodic rechecks.  Given that discardable is not a recommended policy, I
can't see the value of Mailman doing this; the extra code and complexity isn't
worth it.  It would be useful though to make sure that a plugin could be
written to add such verifications should some site decide they want it.

$5.6 is interesting too (using DKIM as input to posting privileges).  I put
this in the same general category as using OpenPGP signatures to verify
posting permissions.  Again, probably not something we'd support out of the
box, but certainly we'd provide hooks for those who want it (and Mailman's
internal OpenPGP verifier, which I hope we'll gain at some point, would use
the same API).

$5.11 indicates possible enhancements to Mailman's bounce policy.

Again, thanks.  It's nice to see specific guidelines published as an RFC which
we can then refer to for justification of Mailman's policy and features.

Cheers,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20111013/3aa00231/attachment.pgp>