{"id":67268,"date":"2023-11-02T07:57:36","date_gmt":"2023-11-02T07:57:36","guid":{"rendered":"https:\/\/antonini.ddns.net\/?p=67268"},"modified":"2023-11-02T07:57:36","modified_gmt":"2023-11-02T07:57:36","slug":"opendkim","status":"publish","type":"post","link":"https:\/\/antonini.ddns.net\/?p=67268","title":{"rendered":"OpenDKIM"},"content":{"rendered":"

Protocolo de autentica\u00e7\u00e3o de e-mails para bloquear SPAMs<\/p>\n

The opendkim<\/strong> package contains a full-featured DKIM milter (mail filter<\/a>) implementation <\/span>suitable for use with MTAs (Message Transfer Agent mail servers) such as Postfix<\/a>. Upstream development at OpenDKIM<\/a> is a community effort. <\/span><\/span><\/p>\n

DomainKeys Identified Mail (DKIM) combines several existing antiphishing and antispam methods to improve the quality of the classification and identification of legitimate e-mail. Instead of the traditional IP-address to determine the message sender, DKIM adds a digital signature associated with the domain name of the organization. In tandem, DNS is used to publish TXT records with the public portion of the cryptographic certificate used for digital signing. <\/span><\/span><\/p>\n

OpenDKIM can add DKIM signatures to outbound mail and check DKIM signatures on inbound mail. It can be configured to reject mail that has missing or invalid DKIM signatures. <\/span><\/span><\/span><\/p>\n

Jump to #Quickstart<\/a> for an overview and minimal setup, and refer to <\/span>#Configuration<\/a> for the complete picture. <\/span><\/span><\/p>\n

 <\/p>\n

\n

Conte\u00fado<\/p>\n

    \n
  1. Quickstart<\/a><\/li>\n
  2. Configuration<\/a>\n
      \n
    1. Installation details<\/a><\/li>\n
    2. Generating keys<\/a><\/li>\n
    3. User and privileges<\/a><\/li>\n
    4. Key selection<\/a><\/li>\n
    5. Important OpenDKIM options<\/a><\/li>\n
    6. Socket<\/a><\/li>\n
    7. DNS resolution<\/a><\/li>\n
    8. Postfix integration<\/a><\/li>\n<\/ol>\n<\/li>\n
    9. Troubleshooting<\/a><\/li>\n
    10. DNS Configuration<\/a><\/li>\n
    11. Testing<\/a>\n
        \n
      1. opendkim-testkey<\/a><\/li>\n
      2. opendkim-testmsg<\/a><\/li>\n
      3. email tests<\/a><\/li>\n<\/ol>\n<\/li>\n
      4. Mailman and DKIM Configuration<\/a><\/li>\n
      5. FAQ<\/a><\/li>\n
      6. See also<\/a>\n
          \n
        1. upstream specific information<\/a><\/li>\n
        2. Debian-specific information<\/a><\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<\/div>\n

           <\/p>\n

          Quickstart<\/h1>\n

          The quickstart instructions in this section describe setting up a minimal, but <\/span>functional installation of opendkim for signing and verifying, integrated with <\/span>Postfix<\/a>. This is the five-minute version of opendkim configuration for the <\/span>impatient. For a fuller discussion of the setup options available, please refer <\/span>to the subsequent sections. <\/span><\/span><\/p>\n

          Let\u2019s go! First, install opendkim: <\/span><\/span><\/p>\n

           <\/p>\n

          <\/span>sudo apt install opendkim opendkim-tools<\/pre>\n
          Next, generate the key pair for your DNS domain and selector<\/em>: <\/span><\/span><\/p>\n
           <\/p>\n
          <\/span>sudo -u opendkim opendkim-genkey -D \/etc\/dkimkeys -d yourdomain.org -s 2021<\/pre>\n
          Now, edit \/etc\/opendkim.conf. Four parameters need to be adapted: the <\/span>domain\/selector\/key file triple, and the socket. For the socket, the easiest <\/span>option is to use a TCP socket listening on a local port (bypassing socket file ownership or chroot access issues). <\/span><\/span><\/p>\n
           <\/p>\n
          <\/span>Domain   yourdomain.org\r\n<\/span>Selector 2021\r\n<\/span>KeyFile  \/etc\/dkimkeys\/2021.private\r\n<\/span>\r\n<\/span>Socket   inet:8891@localhost<\/pre>\n
          That\u2019s it for opendkim. Restart the service with <\/span>sudo systemctl restart opendkim<\/tt>. <\/span><\/span><\/p>\n
          The final step is integrating the opendkim service with Postfix. Edit <\/span>\/etc\/postfix\/main.cf to connect the two: <\/span><\/span><\/p>\n
           <\/p>\n
          <\/span>smtpd_milters = inet:localhost:8891\r\n<\/span>non_smtpd_milters = $smtpd_milters<\/pre>\n
          And finally reload the Postfix configuration with <\/span>sudo systemctl reload postfix<\/tt>. <\/span><\/span><\/p>\n
          Done! Your mail is now being signed and verified. Don\u2019t forget to publish your <\/span>public key as a TXT record in DNS at 2021._domainkey.yourdomain.org<\/tt>. The <\/span>generated file \/etc\/dkimkeys\/2021.txt contains that record for your convenience. <\/span><\/span><\/p>\n
           <\/p>\n
          Configuration<\/h1>\n
          The following sections discuss opendkim configuration options in more detail. <\/span>See the manual page opendkim.conf(5)<\/a> <\/span>for reference. <\/span><\/span><\/p>\n
           <\/p>\n
          <\/span><\/p>\n
          The opendkim configuration file<\/strong> can be found at \/etc\/opendkim.conf<\/tt> . As of Debian 9 “stretch” all configuration parameters should be set in this file. <\/span><\/span><\/p>\n
          This needs to be stated, because there is a lot of older, now misleading <\/span>information on this online. Previously (#864162<\/a>), one would edit the default settings at <\/span>\/etc\/default\/opendkim<\/em>, and then execute <\/span>\/lib\/opendkim\/opendkim.service.generate to generate systemd override files at <\/span>\/etc\/systemd\/system\/opendkim.service.d\/override.conf and <\/span>\/etc\/tmpfiles.d\/opendkim.conf. While this is still possible, it is now <\/span>recommended to adjust the settings directly in \/etc\/opendkim.conf.<\/p>\n<\/div>\n
           <\/p>\n
          Installation details<\/h2>\n
          The opendkim and opendkim-tools packages should already be installed. See #Quickstart<\/a> for basic steps. <\/span><\/span><\/p>\n
          The standard directory for DKIM keys on Debian 9 “stretch” and later releases, is \/etc\/dkimkeys.
          \n<\/span>On Debian 8 “jessie” that directory must be created. This directory contains private encryption keys, and should thus be owned and set to only be accessible by user opendkim<\/em>. <\/span><\/span><\/span><\/span><\/span><\/span><\/p>\n
          <\/span># only for Debian 8 \"jessie\"\r\n<\/span>mkdir \/etc\/dkimkeys\/\r\n<\/span>chown opendkim:opendkim \/etc\/dkimkeys\r\n<\/span>chmod 0700 \/etc\/dkimkeys<\/pre>\n
           <\/p>\n
          Generating keys<\/h2>\n
          For key generation, the opendkim-tools package provides the <\/span>opendkim-genkey<\/strong> program. This program generates a private key named <\/span><selector>.private<\/tt> in the specified directory, as well as a public key <selector>.txt<\/tt> ready to be included in a bind DNS zone file. An example invocation: <\/span><\/span><\/p>\n
           <\/p>\n
          <\/span>sudo --user opendkim opendkim-genkey \\\r\n<\/span>    --directory=\/etc\/dkimkeys \\\r\n<\/span>    --domain=yourdomain.org \\\r\n<\/span>    --selector=2021 \\\r\n<\/span>    --nosubdomains<\/pre>\n
          You will want to tweak some of these options. For example, you might not want <\/span>to forbid subdomain signing with --nosubdomains<\/tt>, or you might want to <\/span>restrict usage to email with --restrict<\/tt>. In Debian, the cryptographic <\/span>options use reasonably strong defaults, so it is usually not necessary to <\/span>specify --bits<\/tt> (default: 2048) and --hash-algorithms<\/tt> (default: <\/span>SHA-256). <\/span><\/span><\/p>\n
          The selector<\/em> allows for removing old keys from a domain and creating new ones. One common practice is to use the creation year as the selector.
          \n<\/span>It’s also possible to have multiple keys for a domain, if there are multiple servers sending mail on behalf of a domain then each can have a unique key. Note that one can also have an unlimited number of domains with the same key. <\/span><\/span><\/p>\n
          In Debian, the directory \/etc\/dkimkeys<\/strong> serves as the canonical key storage <\/span>location, and is created by the opendkim package on installation. The owner is <\/span>set to opendkim by default, and access is restricted to the user, so private keys remain safe. <\/span><\/span><\/p>\n
          Notice how we execute opendkim-genkey as user opendkim. That way, <\/span>opendkim-genkey produces key files with the correct, restricted permissions, <\/span>owned by opendkim. <\/span><\/span><\/p>\n
          It is also possible to restrict key ownership further to user root by invoking <\/span>opendkim-genkey directly as root: <\/span><\/span><\/p>\n
           <\/p>\n
          <\/span>sudo opendkim-genkey ...<\/pre>\n
          However, while this does work, opendkim will not be able to reload<\/em> keys <\/span>during operation: during startup, the key file may be read into memory as root, <\/span>but subsequently, after root privileges are dropped, the keys will be accessed <\/span>as user opendkim. This is discussed in the following section. <\/span><\/span><\/p>\n
           <\/p>\n
          User and privileges<\/h2>\n
          By default, the opendkim service runs as user opendkim. This is because the <\/span>default configuration contains a setting for parameter UserID<\/tt> in <\/span>\/etc\/opendkim.conf: <\/span><\/span><\/p>\n
           <\/p>\n
          <\/span>UserID opendkim<\/pre>\n
          This setting instructs opendkim to become<\/em> user opendkim. So, more <\/span>accurately, what happens is that the opendkim service is started as root<\/em>, does <\/span>everything it needs to do as root \u2013 such as reading private keys and writing the <\/span>pid file \u2013, and then, before beginning normal operation, it drops the root <\/span>privileges and becomes user opendkim. This is a standard, secure procedure that <\/span>should be appropriate for most users. <\/span><\/span><\/p>\n
          An alternative setup is possible where the opendkim service runs as an <\/span>unprivileged user from the very start, and this is described in the following <\/span>section. <\/span><\/span><\/p>\n
           <\/p>\n
          Running as an unprivileged user<\/h3>\n
          For setups that have additional security requirements, it is possible to run the <\/span>opendkim service as user opendkim from the very beginning, with no root <\/span>privileges involved at any stage. Please note that most users do not need this. <\/span><\/span><\/p>\n
          Create a systemd override file at <\/span>\/etc\/systemd\/system\/opendkim.service.d\/override.conf (you may need to create the <\/span>directory too), with the following contents: <\/span><\/span><\/p>\n
           <\/p>\n
          <\/span>[Service]\r\n<\/span>User=opendkim\r\n<\/span>Group=opendkim<\/pre>\n
          The UserID opendkim<\/tt> setting in \/etc\/opendkim.conf can now be removed, as <\/span>no privilege dropping is necessary. Reload the systemd configuration with <\/span>sudo systemctl daemon-reload<\/tt>, and restart the opendkim service. It now <\/span>runs as an unprivileged user. <\/span><\/span><\/p>\n
          Make sure that the unprivileged user can actually read the keys in <\/span>\/etc\/dkimkeys (see above), and write the pid file. (Since both \/etc\/dkimkeys and the runtime <\/span>directory \/run\/opendkim come owned by user\/group opendkim, this should work <\/span>without further adjustment.) <\/span><\/span><\/p>\n
           <\/p>\n
          Key selection<\/h2>\n
          For a single-domain DKIM setup with only a single key, the configuration shown <\/span>in #Quickstart<\/a>, using the three parameters Domain<\/tt>, Selector<\/tt>, <\/span>KeyFile<\/tt> is enough. However, opendkim configuration supports multiple <\/span>domains and keys, read from a variety of sources (files, SQL databases, Lua <\/span>scripts, \u2026). KeyTable<\/tt><\/strong> and SigningTable<\/tt><\/strong> are the <\/span>configuration parameters that enable this. For mail servers that are “smarthosts”, opendkim can be configured to sign messages from subnets of trusted systems via the InternalHosts<\/tt><\/strong> parameter. <\/span><\/span><\/p>\n
          Setup the \/etc\/opendkim.conf: <\/span><\/span><\/p>\n
           <\/p>\n
          <\/span># Specify the list of keys\r\n<\/span>KeyTable file:\/etc\/dkimkeys\/keytable\r\n<\/span># Match keys and domains. To use regular expressions in the file, use refile: instead of file:\r\n<\/span>SigningTable refile:\/etc\/dkimkeys\/signingtable \r\n<\/span># Match a list of hosts whose messages will be signed. By default, only localhost is considered as internal host.\r\n<\/span>InternalHosts refile:\/etc\/dkimkeys\/trustedhosts<\/pre>\n
          Now in the file \/etc\/dkimkeys\/keytable, put information about the private key: <\/span><\/span><\/p>\n
          <\/span>mail._domainkey.yourdomain.org yourdomain.org:mail:\/etc\/dkimkeys\/mail.private<\/pre>\n
          In the file \/etc\/dkimkeys\/signingtable, specify which key will sign a domain: <\/span><\/span><\/span><\/span><\/span><\/span><\/p>\n
          <\/span># Domain yourdomain.org\r\n<\/span>*@yourdomain.org mail._domainkey.yourdomain.org\r\n<\/span># You can specify multiple domains\r\n<\/span># Example.net www._domainkey.example.net<\/pre>\n
          In the file \/etc\/dkimkeys\/trustedhosts, specify which hosts will have messages signed. If needed, include localhost as it is not implicit: <\/span><\/span><\/span><\/span><\/p>\n
          <\/span>127.0.0.1\r\n<\/span>10.1.0.0\/16\r\n<\/span>1.2.3.4\/24<\/pre>\n
           <\/p>\n
          Important OpenDKIM options<\/h2>\n
          The Canonicalization<\/tt><\/strong> configuration parameter changes the signing options which can allow messages to be verified after being munged a bit by list servers etc. The “relaxed\/simple” option specifies that headers can be munged a bit without breaking a message validation. The “relaxed” checks on headers MIGHT allow messages that have been through a Mailman list server to be validated, it’s almost certain that they won’t be validated if relaxed isn’t used. <\/span><\/span><\/p>\n
          The default is to accept mail with bad signatures. If you want to reject such mail, use the On-BadSignature<\/tt><\/strong> parameter. <\/span><\/span><\/p>\n
          The BodyLengthDB<\/tt><\/strong> parameter specifies a dataset that controls which messages are signed with the l=<\/tt> option to specify the length. When l=<\/tt> is used a hostile party could append data to the end of the message without breaking a signature, but it also means that a list server can add a footer to the message without breaking it. Unless you are running a list server (which should not be sending to other list servers) or other automated system you generally want l=<\/tt> on all mail. If the bodylengthdb.cfg has the contents “.*” it will cause every message to have the l=<\/tt> option. <\/span><\/span><\/p>\n
           <\/p>\n
          <\/span>Canonicalization    relaxed\/simple\r\n<\/span>On-BadSignature     reject\r\n<\/span>BodyLengthDB        refile:\/etc\/mail\/bodylengthdb.cfg<\/pre>\n
           <\/p>\n
          Socket<\/h2>\n
          The opendkim service has to provide a communication channel for the MTA <\/span>(Postfix). A TCP socket listening on a port only accessible locally is a <\/span>reasonable choice that is also easy to set up. <\/span><\/span><\/p>\n
           <\/p>\n
          <\/span>Socket inet:8891@localhost<\/pre>\n
          Sockets can be of IPv4 or IPv6 type, and can listen on all interfaces or on a <\/span>specific interface only. <\/span><\/span><\/p>\n
          Some prefer setting up a UNIX domain socket instead, as a faster and more secure <\/span>channel (though opinion on this point varies). This requires a little more <\/span>configuration work, and is described in the following section. <\/span><\/span><\/p>\n
           <\/p>\n
          Using a UNIX domain socket<\/h3>\n
          The UNIX domain socket file must be accessible to the MTA. In Debian, Postfix <\/span>runs in a chroot jail in \/var\/spool\/postfix by default, so the socket must be <\/span>below that path. <\/span><\/span><\/p>\n
          Postfix does not prescribe a standard location for UNIX sockets in its chroot. <\/span>You can mimic the \/run directory hierarchy, and place the socket below <\/span>\/var\/spool\/postfix\/run\/opendkim, or you can simply claim a top-level directory <\/span>like \/var\/spool\/postfix\/opendkim. Here we go with the latter. <\/span><\/span><\/p>\n
          First, create the directory, owned by opendkim and world-inaccessible: <\/span><\/span><\/p>\n
           <\/p>\n
          <\/span>sudo mkdir -m o-rwx \/var\/spool\/postfix\/opendkim\r\n<\/span>sudo chown opendkim: \/var\/spool\/postfix\/opendkim<\/pre>\n
          Then, configure the socket in \/etc\/opendkim.conf: <\/span><\/span><\/p>\n
           <\/p>\n
          <\/span>Socket local:\/var\/spool\/postfix\/opendkim\/opendkim.sock<\/pre>\n
          Next, add user postfix to group opendkim. Postfix then relies on the group <\/span>permissions to actually access the socket: <\/span><\/span><\/p>\n
           <\/p>\n
          <\/span>sudo adduser postfix opendkim<\/pre>\n
          Finally, adjust the Postfix configuration in \/etc\/postfix\/main.cf to use the <\/span>desired socket path: <\/span><\/span><\/p>\n
           <\/p>\n
          <\/span>smtpd_milters = unix:opendkim\/opendkim.sock\r\n<\/span>non_smtpd_milters = $smtpd_milters<\/pre>\n
          Note that when Postfix runs chrooted (the default in Debian), an absolute pathname <\/span>here is interpreted relative to the Postfix queue directory \/var\/spool\/postfix. <\/span><\/span><\/p>\n
          Don\u2019t forget to restart opendkim and postfix to apply the settings. <\/span><\/span><\/p>\n
           <\/p>\n
          DNS resolution<\/h2>\n
          In Debian, opendkim is compiled with libunbound<\/strong>, a DNSSEC-capable <\/span>asynchronous resolver library. It is important to be aware of this, because it <\/span>means opendkim does DNS queries for DKIM keys independently, that is, it does <\/span>not go through any local resolver and does not take into account configuration <\/span>at \/etc\/resolv.conf. <\/span><\/span><\/p>\n
          The default opendkim configuration ships with a valid trust anchor setting, <\/span>TrustAnchorFile \/usr\/share\/dns\/root.key<\/tt>, thus letting opendkim do DNSSEC <\/span>queries out-of-the-box. <\/span><\/span><\/p>\n
          Advanced users should be aware of two additional configuration parameters. <\/span><\/span><\/p>\n
          The Nameservers<\/tt><\/strong> parameter can be used to override the name servers <\/span>that libunbound uses. For example, you may already have an Unbound resolver <\/span>running locally (a relatively typical setup in a mail server). In that case, a <\/span>setting like the following instructs opendkim to send DNS queries through that <\/span>resolver: <\/span><\/span><\/p>\n
           <\/p>\n
          <\/span>Nameservers 127.0.0.1<\/pre>\n
          The ResolverConfiguration<\/tt><\/strong> parameter can be used to pass an Unbound <\/span>configuration file <\/span>(unbound.conf(5)<\/a>) <\/span>to libunbound. Using this, more sophisticated customization regarding DNS <\/span>resolution in opendkim is possible. <\/span><\/span><\/p>\n
           <\/p>\n
          <\/span>ResolverConfiguration \/etc\/opendkim\/unbound.conf<\/pre>\n
           <\/p>\n
          <\/span><\/p>\n
          The Debian unbound package installs a default configuration file at <\/span>\/etc\/unbound\/unbound.conf<\/strong>. Do not attempt to use this file unchanged with <\/span>ResolverConfiguration<\/tt>! opendkim will just quietly shut down. <\/span><\/span><\/p>\n
          The reason for the incompatibility is that the shipped unbound.conf includes an <\/span>auto-trust-anchor-file<\/tt> setting, for which opendkim does not have the <\/span>necessary permissions. Unfortunately, libunbound is rather fragile in this area. <\/span>Prepare your own unbound.conf for opendkim and test carefully.<\/p>\n<\/div>\n
           <\/p>\n
          Postfix integration<\/h2>\n
          The opendkim service functions as a milter<\/em>, that is, a plugin software <\/span>hooked into the SMTP processing of the Postfix MTA. To enable a milter, it is <\/span>enough to tell Postfix on which socket the milter application is listening. <\/span>Example \/etc\/postfix\/main.cf: <\/span><\/span><\/p>\n
           <\/p>\n
          <\/span>smtpd_milters = inet:localhost:8891\r\n<\/span>non_smtpd_milters = $smtpd_milters<\/pre>\n
          With opendkim, two additional milter configuration parameters in <\/span>\/etc\/postfix\/main.cf are useful. <\/span><\/span><\/p>\n
          The milter_default_action<\/tt><\/strong> parameter determines what to do when a <\/span>milter fails, for example, when it does not respond after a crash. In order to <\/span>avoid losing mail, it is best to set this to accept<\/tt>: <\/span><\/span><\/p>\n
           <\/p>\n
          <\/span>milter_default_action = accept<\/pre>\n
          Postfix does not pass internally-generated messages such as bounce messages to <\/span>opendkim, so by default bounces are not DKIM-signed. This can be a problem if <\/span>you also use a strict DMARC policy, because it may cause your unsigned bounce <\/span>messages themselves to get rejected. The <\/span>internal_mail_filter_classes<\/tt><\/strong> parameter can be used to pass bounces <\/span>through the milters as well: <\/span><\/span><\/p>\n
           <\/p>\n
          <\/span>internal_mail_filter_classes = bounce<\/pre>\n
          Further details of milter usage in Postfix can be found in its <\/span>MILTER_README<\/a>. <\/span><\/span><\/p>\n
           <\/p>\n
          Troubleshooting<\/h1>\n
          Try to send a mail. If you see in \/var\/log\/mail.log something like <\/span><\/span><\/span><\/p>\n
          <\/span>Aug 13 13:18:00 yourhostname opendkim[15765]: OpenDKIM Filter: Unable to bind to port local:\/var\/spool\/postfix\/opendkim\/opendkim.sock: No such file or directory\r\n<\/span>Aug 13 13:18:00 yourhostname opendkim[15765]: OpenDKIM Filter: Unable to create listening socket on conn local:\/var\/spool\/postfix\/opendkim\/opendkim.sock<\/pre>\n
          then that probably means that you did not create the directory for the socket (see above) or you gave it the wrong permissions. Double-check! <\/span><\/span><\/p>\n
          If you see <\/span><\/span><\/p>\n
          <\/span>Aug 13 13:46:19 yourhostname postfix\/cleanup[17588]: warning: connect to Milter service unix:\/opendkim\/opendkim.sock: No such file or directory<\/pre>\n
          then that means postfix could not read the socket. Did you put postfix in group opendkim? Are the permissions on \/var\/spool\/postfix\/opendkim\/opendkim.sock correct? <\/span><\/span><\/p>\n
          If everything is correct, that does not mean your configuration of DKIM is complete: you must configure the DNS. <\/span><\/span><\/p>\n
           <\/p>\n
          DNS Configuration<\/h1>\n
          Add a _domainkey<\/tt> TXT record for yourdomain.org and selector<\/em> (e.g. 2021). <\/span><\/span><\/p>\n
          \n\n\n\n\n
          \n
          Record Name<\/strong><\/p>\n<\/td>\n
          		\n
          Record Type<\/strong><\/p>\n<\/td>\n
          		\n
          Text<\/strong><\/p>\n<\/td>\n<\/tr>\n
          <\/span><\/p>\n
          2021._domainkey<\/p>\n<\/td>\n
          		\n
          TXT<\/p>\n<\/td>\n
          		\n
          v=DKIM1; k=rsa; p=MI.. (take it from \/etc\/dkimkeys\/2021.txt file; remove the >”< and connect the lines after p= to one key.)<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
          BIND Configuration : The public key file \/etc\/dkimkeys\/2021.txt created by opendkim-genkey<\/tt> is in a format ready to be included in a DNS bind9 zone data file. It can be copied to a bind9 server, and pasted into a zone file, or the $INCLUDE<\/a> statement may be used. <\/span><\/p>\n