DKIM is a crytographic signature method designed to prevent phishing. As postmaster or listmaster you should consider 1) checking the DKIM status of each incoming message and 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 (Message transfert 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 signature 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 brodcasted 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,
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.
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.
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 scenario 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.
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.
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.
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;
In most cases Sympa should sign all outgoing messages to get the maximum advantage from DKIM.
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 1) (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> 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 ‘sympa.org’:
lists._domainkey.sympa.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
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?).
|parameter name (
||default||overwritten by (list configuration)|
|dkim_signer_domain||the robot domain||dkim >
|dkim_selector||no default||dkim >
|dkim_signer_identity||none for robot’s messages,
|as recommended in RFC 6376||Not yet implemented|
1) The private key can’t be encrypted with a passphase
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 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.
|parameter name (
||default||overwritten by (list configuration)|
Theme originally designed by orderedlist