On Tue, 7 Feb 2017, Kjetil Kjernsmo wrote:
On Monday 6. February 2017 01.15.30 frank wrote:
I literally just did DKIM last week. And the way I did it didn't touch
qpsmtpd, instead it's a couple helper scripts that feed qmail-remote,
messages are signed as they're being sent out.
Ah, TIMTOWDI, I like it! :-)
I think wrapping qmail-remote makes a lot of sense, so I'd like to try
that too.
I have a number of domains all on the same server using this setup. It's
pretty slick. Any DKIM on the SMTP server would be for validating incoming
mail from 3rd parties I think, I let spamassassin do it instead. Note that
any mail that stays within your qmail server (multiple accounts or
domains) won't get signed because all the work is in qmail-remote.
The instructions I followed didn't exactly fit my setup but it only
really took a couple edits to get things working. I'm pretty sure it
was helpful that I have a real cert signed by a CA rather than
self-signed, but maybe it doesn't matter(?)
Right. I don't know. I suppose Let's Encrypt certificates can't be used for
that purpose?
My cert is a freebie from StartSSL and it works for my POP3S/IMAPS, HTTPS,
and now SMTP TLS. At least it passes all the tests that Google requires. I
bet your Let's Encrypt cert is of the same caliber. And now that I think
about it again the cert was only used for TLS, not DKIM. I did too many
things at once so they're jumbled in my head.
At the same time I added TLS to qmail-remote so I now transmit email
encrypted. Separately I activated the TLS plugin on qpsmtpd (mine is
0.95) so incoming mail can be encrypted too. I have a second instance
of qpsmtpd for auth that has been using stunnel3 for encryption for
years. Both QPs feed the same qmail instance.
The DKIM instructions I used:
https://beingasysadmin.wordpress.com/2013/04/30/dkim-signing-in-qmail/
You will probably have to compile libdomainkeys to get the dktest binary
because it's not usually included in distro packages.
Hmmmm. I don't really understand this... Hasn't DomainKeys been completely
replaced by DKIM? I would have been guessing that using Mail::DKIM with
the dkimsign.pl script would be sufficient to support DKIM, and the stuff
that they do with dktest and libdomainkeys is to support the legacy
DomainKeys that isn't needed anymore?
So, I'm wondering if this could be simplified?
I'm a beginner at DKIM but as far as I can tell DKIM is a superset
replacement for Domain Keys so people didn't have to redo a bunch of steps
to implement it.
The dktest program appears to be used to validate your keys before the
script tries to use them for signing. If the test fails it feeds the old
unsigned message directly to qmail-remote. You could probably remove that
test section from the shell script, I chose to leave it. All the hard work
is done with Mail::DKIM as you guessed. libdomainkeys is only used for
that dktest binary, you don't need the lib otherwise. (It's dynamically
linked to system libs but the DK functions look to be static.)
Qmail TLS patch was from http://inoa.net/qmail-tls/
Cool! I'd like to do that too.
I think the patch had one chunk that failed when run against
netqmail-1.06 but it was easy enough to fix by hand. After compiling and
installing qmail-remote the only config was putting the necessary key
pieces in /var/qmail/control/clientcert.pem.
For incoming I used 3 separate files:
/var/qpsmtpd-0.95/config/ssl/qpsmtpd-ca.crt
/var/qpsmtpd-0.95/config/ssl/qpsmtpd-server.crt
/var/qpsmtpd-0.95/config/ssl/qpsmtpd-server.key
Hope this gives you a start.
Yes, it does!
-frank
P.S. If you're using tcpserver you should be able to add your subnet to
your tcp.cdb with a tag to tell QP it's ok. Something like:
172.22:allow,RELAYCLIENT=""
OK, but I'm just using forkserver. It's been Just Working for many years
now :-)
Cheers,
Kjetil
Enjoy!
-frank
