Difference between revisions of "Qpsmtpd:dkim"
(Created page with "<span id="_top">Qpsmtpd#Plugins</span> = NAME = dkim: validate DomainKeys and (DKIM) Domain Keys Indentified Messages = SYNOPSIS = Validate the ...") |
Unnilennium (talk | contribs) |
||
| Line 10: | Line 10: | ||
= [[#___top|CONFIGURATION]] = | = [[#___top|CONFIGURATION]] = | ||
| − | == [[#___top|reject [ 0 | 1 | naughty ]]] == | + | == [[#___top|reject [ 0 | 1 | naughty]] ] == |
<pre> dkim [ reject 0 ] | <pre> dkim [ reject 0 ] | ||
| Line 25: | Line 25: | ||
= [[#___top|HOW TO SIGN]] = | = [[#___top|HOW TO SIGN]] = | ||
| + | |||
| + | {{Warning box|This is not the way to do currently, please refer to https://wiki.contribs.org/Email#DKIM_Setup_-_qpsmtpd_version_.3E.3D_0.96}} | ||
== [[#___top|generate DKIM keys]] == | == [[#___top|generate DKIM keys]] == | ||
Latest revision as of 15:46, 18 May 2018
NAME
dkim: validate DomainKeys and (DKIM) Domain Keys Indentified Messages
SYNOPSIS
Validate the DKIM and Domainkeys signatures of a message, enforce DKIM sending policies, and DKIM sign outgoing messages.
CONFIGURATION
reject [ 0 | 1 | naughty ]
dkim [ reject 0 ]
0 - do not reject
1 - reject messages that fail DKIM policy
naughty - defer rejection to the B<naughty> plugin
Default: 1
reject_type
dkim reject_type [ temp | perm ]
Default: perm
HOW TO SIGN
generate DKIM keys
the easy way
cd ~smtpd/config/dkim; ./dkim_key_gen.sh example.org
the manual way
mkdir -p ~smtpd/config/dkim/example.org cd ~smtpd/config/dkim/example.org echo 'may2013' > selector openssl genrsa -out private 2048 chmod 400 private openssl rsa -in private -out public -pubout chown -R smtpd:smtpd ../example.org
After generating the keys, there will be three files in the example.org directory: selector, private, and public.
selector
The selector can be any value that is a valid DNS label.
key length
The minimum recommended key length for short duration keys (ones that will be replaced within a few months) is 1024. If you are unlikely to rotate your keys frequently, choose 2048, at the expense of a bit more CPU.
publish public key in DNS
If the DKIM keys were generated the easy way, there will be a fourth file named dns. The contents contain the DNS formatted record of the public key, as well as suggestions for DKIM, SPF, and DMARC policy records. The records are ready to be copy/pasted into a BIND zone file, or better yet, NicTool. If you created your keys manually, look in the dkim_key_gen.sh script to see the commands used to format the DKIM public key.
The combination of the three example DKIM, SPF, and DMARC policy records in the dns file tell other mail servers that if a sender claims to be from example.org, but the message is not DKIM nor SPF aligned, then the message should be rejected. Many email servers, including the largest email providers (Gmail, Yahoo, Outlook/Live/Hotmail) will refuse to accept such messages, greatly reducing the harm caused by miscreants who forge your domain(s) in the From header of their spam.
The DKIM record will look like this:
may2013._domainkey TXT "v=DKIM1;p=[public key stripped of whitespace];"
And the values in the address have the following meaning:
hash: h=[ sha1 | sha256 ] test; t=[ s | s:y ] granularity: g=[ ] notes: n=[ ] services: s=[email] keytypes: [ rsa ]
testing
After confirming that the DKIM public key can be fetched with DNS (dig TXT may2013._domainkey.example.org. @ns1.example.org.), send test messages. You can testing DKIM by sending an email to:
* a Gmail address and inspect the Authentication-Results header. * mailtest@unlocktheinbox.com * check-auth@verifier.port25.com * checkmyauth@auth.returnpath.net
The three email reflectors provide nice email reports with additional debugging information.
publish DKIM policy in DNS
_domainkey TXT "o=~; t=y; r=postmaster@example.org"
o=- - all are signed o=~ - some are signed t=y - test mode r=[email] - responsible email address n=[notes]
After DKIM and SPF are tested and working, update the policy, changing o=~ to o=-, so that other mail servers reject unsigned messages claiming to be from your domain.
As of this writing, most mail servers do not reject messages that fail DKIM policy, unless they also fail SPF, and no DMARC policy is published. The same holds true for SPF. There are technical reasons for this. See DMARC for more information, how you can control change that behavior, as well as receiving feedback from remote servers about messages they have accepted and rejected from senders claiming the identity of your domain(s).
SEE ALSO
http://tools.ietf.org/html/rfc6376 - DKIM Signatures
http://tools.ietf.org/html/rfc5863 - DKIM Development, Deployment, & Operations
http://tools.ietf.org/html/rfc5617 - DKIM ADSP (Author Domain Signing Practices)
http://tools.ietf.org/html/rfc5585 - DKIM Service Overview
http://tools.ietf.org/html/rfc5016 - DKIM Signing Practices Protocol
http://tools.ietf.org/html/rfc4871 - DKIM Signatures
http://tools.ietf.org/html/rfc4870 - DomainKeys
http://www.protodave.com/tools/dkim-key-checker/
AUTHORS
2013 - Matt Simerson - added DKIM signing and key creation script 2012 - Matt Simerson - initial plugin
ACKNOWLEDGEMENTS
David Summers - http://www.nntp.perl.org/group/perl.qpsmtpd/2010/08/msg9417.html
Matthew Harrell - http://alecto.bittwiddlers.com/files/qpsmtpd/dkimcheck
I first attempted to fix the dkimcheck plugin, but soon scrapped that effort and wrote this one. Why?
The use of $dkim->fetch_author_policy, which is deprecated by Mail::DKIM.
The paradim of a single policy, when DKIM supports 0 or many.
The OBF programming style, which is nigh impossible to test.
The nine 'if' brackets with 19 conditionals, and my inability to easily determine which of the 15 possible permutations (5 signature validation results x 3 possible policy results) were covered.
