DKIM and ARC features for Sympa

• DKIM has been introduced in Sympa version 6.1.
• ARC has been introduced in Sympa version 6.2.38.

DKIM is a cryptographic signature method designed to prevent phishing. As postmaster or listmaster you should consider

1. checking the DKIM status of each incoming message
2. signing all or a subset of outgoing messages

ARC is intended to fix the problems introduced by DMARC by adding signature “seals” that show the chain of servers that processed a message. Once ARC is more widely implemented, DMARC workarounds shouldn’t be needed. Once you have DKIM set up, adding ARC seals is straightforward.

Processing of DKIM status of incoming messages is done by the MTA (Mail transfer agent) that delivers emails to the Sympa server Sympa domain (in order to reject some messages). This topic is not addressed in the chapter of the documentation.

The mailing list server can take advantage of incoming DKIM signatures in order to measure the trust of the message while evaluating message workflow. This is based on scenario mechanism. An authentication level named dkim can be used within scenario rules to check that an incoming message has a valid DKIM signature (dkim signature status = pass).

In addition, you must consider signature of outgoing messages. Should messages broadcasted by Sympa to list subscribers be signed by your organization? Should all of them be signed? Should a subset of trusted messages be signed? Should service messages (automatic answer, welcome messages etc) be signed ? In most cases Sympa should sign all the mail it sends to get the most benefit from DKIM.

ARC seals only make sense on mail forwarded by Sympa, that is, individual messages sent through to mailing lists. The ARC feature will only add seals to those messages. ARC checks the ARC seals, if any, on incoming messages,

Prerequisites

Prerequisites for DKIM

DKIM features in Sympa are based on the Mail::DKIM cpan module ; you should install it first. Check the documentation related to cpan modules installation.

Prerequisites for ARC

ARC requires Mail::DKIM version 0.55 or later which includes ARC support.

It also requires that the MTA that delivers emails to Sympa adds an Authentication-Results: header that shows how a message was (or wasn’t) authenticated as it arrived.

• Several Postfix milters can add the header, with opendmarc or the Fastmail authentication milter being widely used.
• amavisd-new also may add this field.

Incoming messages DKIM

To make Sympa check the DKIM signature of incoming messages, you need to set the dkim_feature configuration parameter to on. Before doing that you must first update your customized scenario to introduce dkim authentication method, otherwise Sympa may reject messages because they include a valid DKIM signature !. All default scenarios starting at version 6.1 already include rules for DKIM, both for command and lists messages.

What kind of changes is required in scenarios?

Turning on the dkim_feature configuration parameter will provide a new authentication level to the scenario engine. Scenario evaluation for incoming messages with a valid DKIM signature (but no S/MIME signature) will be evaluated with authentication method dkim. So rules that use authentication method smtp will not match.

Example:

  is_subscriber([listname],[sender])   smtp      request_auth
  is_subscriber([listname],[sender])   md5,smime do_it

Those 2 rules will not match any messsage with a valid DKIM signature, you must replace them with one of the following:

  is_subscriber([listname],[sender])   smtp,dkim request_auth
  is_subscriber([listname],[sender])   md5,smime do_it

  is_subscriber([listname],[sender])   smtp           request_auth
  is_subscriber([listname],[sender])   dkim,md5,smime do_it

If you choose the second solution, you accept DKIM as a valid authentication mecanism.

If the front MTA adds the Authentication-results header field, Sympa can of course check this SMTP header field using standard match() and equal() scenario conditions.

Outgoing messages DKIM

You may want to make Sympa sign outgoing messages. Almost every aspects of DKIM signature behavior can be customized via Sympa configuration parameters. Please check the DKIM parameters section for further details. Note that each parameter can also be set for a given virtual robot; and most of them are available as list parameters.

Which messages should be signed

In order to configure Sympa for signing outgoing messages, you have to decide which messages Sympa should sign . This should be decided for four kind of messages:

• Services messages : these are all messages sent by Sympa itself : welcome messages, answers to mail commands, various notification such as remind message and digest messages;

• List messages : messages distributed to list members (where the initial From: header is preserved). These messages will fall info one of these subcategories:

  • authenticated messages (using S/MIME signature, challenge or password);

  • received with a valid DKIM signature;

  • validated by one of the list moderators;

  • other messages.

This behavior is controlled by dkim_add_signature_to and dkim_signature_apply_on parameters.

In most cases Sympa should sign all outgoing messages to get the maximum advantage from DKIM.

Prerequisites for DKIM signing

Before Sympa is able to DKIM-sign messages, you need to set several related parameters. The most important ones are dkim_private_key_path (private key file location) and dkim_selector. Other parameters related to RFC 6376: dkim_signer_domain, dkim_signer_identity,dkim_header_list.

The private key is a PEM encoded RSA key ¹⁾ (a PEM encoded key include base64 encoded informations and starts with —–BEGIN RSA PRIVATE KEY—–.). The public key associated with that private key must be published in a DNS TXT record for entry <selector>._domainkey.<domain> where <selector> is dkim_selector and <domain> is dkim_signer_domain. The signer domain should be the domain of the list ; this is the default, don’t change it unless you have strong reason for it.

example with selector = ‘lists’ and domain ‘mail.example.org’:

  lists._domainkey.mail.example.org. IN TXT "v=DKIM1; g=*; k=rsa; t=y; p=MDB34............DB"

In order to generate the public and private keys, you may use openssl or opendkim-genkey included in OpenDKIM software. There are also online tools to generate them, but those services will generate the private key for you (is it still a private key?).

• http://www.socketlabs.com/services/dkwiz
• http://www.port25.com/support/support_dkwz.php

Summary of DKIM parameters

¹⁾ The private key can’t be encrypted with a passphase

Incoming messages ARC

Incoming messages will be checked for ARC seals automatically if the arc_feature is enabled. The arc_srvid configuration parameter must be set to the srvid in the local MTA’s Authentication-Results: headers if the srvid is not the same as the ARC signer domain. There is no parameter to control which messages to check because the software automatically checks as needed.

Outgoing messsages ARC

Outgoing forwarded messages will have ARC seals added if the arc_feature is enabled. ARC uses the same signatures and keys as DKIM, and DKIM is a prerequisite for ARC, so if your ARC seals use the same signer domain and selector as DKIM signatures, as they usually do, they need no further configuration. If you want to use a different domain or selector which uses a different private key, they can be set in the same way as the DKIM domain, selector, and key. See the parameters below.

Summary of ARC parameters