Auth on outgoing and dkim signing

[Kjetil Kjernsmo]

Hi all!

I finally have to get my outgoing SMTP working, and I have to DKIM-sign
them. So, I need to get auth working, the last time I tried, in 2009, I
simply couldn't get it working... That's a long time ago though :-)

But before I start, I still have 0.84, since the box is Debian Jessie.
Does the dkim plugin depend on a more recent version?

Secondly, I would like to just accept all email unauthenticated from my
LAN, can I configure qpsmtpd to let anything from 172.22.0.0/16 go through?

Kjetil

[frank]

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. 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(?)

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. (Or maybe it's in
the -devel pkg and I forgot to look?) I used opendkim-genkey from distro
packages to make my dkim keys, rather than whatever the instructions said,
just cuz I had it.

You will need to grab
http://www.memoryhole.net/qmail/dkimsign.pl
and
http://www.memoryhole.net/qmail/qmail-remote.sh

Qmail TLS patch was from http://inoa.net/qmail-tls/

Hope this gives you a start.

-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=""

On Sun, 5 Feb 2017, Kjetil Kjernsmo wrote:

> Date: Sun, 05 Feb 2017 23:35:06 +0100
> From: Kjetil Kjernsmo <kje...@kjernsmo.net>
> To: qps...@perl.org
> Subject: Auth on outgoing and dkim signing

[Matt Simerson via qpsmtpd]

> On Feb 5, 2017, at 2:35 PM, Kjetil Kjernsmo <kje...@kjernsmo.net> wrote:
>
> Hi all!
>
> I finally have to get my outgoing SMTP working, and I have to DKIM-sign
> them. So, I need to get auth working, the last time I tried, in 2009, I
> simply couldn't get it working... That's a long time ago though :-)
>
> But before I start, I still have 0.84, since the box is Debian Jessie.
> Does the dkim plugin depend on a more recent version?

Yes, I think it it does.

In 2009, the QP DKIM plugin didn’t support signing. I added that feature in 2013.

> Secondly, I would like to just accept all email unauthenticated from my
> LAN, can I configure qpsmtpd to let anything from 172.22.0.0/16 go through?

Yes, you can.

Matt

[Kjetil Kjernsmo]

On Sunday 5. February 2017 22.34.36 Matt Simerson wrote:
> Yes, I think it it does.
>
> In 2009, the QP DKIM plugin didn’t support signing. I added that feature
> in 2013.

OK! I'll try the qmail-remote route first.

> > Secondly, I would like to just accept all email unauthenticated from
> > my
> > LAN, can I configure qpsmtpd to let anything from 172.22.0.0/16 go
> > through?
> Yes, you can.

Duh! I allready had that in relayclients... :-) Sorry for the noise!

Kjetil

[Kjetil Kjernsmo]

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.

> 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?

> 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?

> Qmail TLS patch was from http://inoa.net/qmail-tls/

Cool! I'd like to do that too.

> 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

[frank]

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

[Kjetil Kjernsmo]

Hi!

I figured I'd just report back on this:

On Tuesday 7. February 2017 15.13.53 frank wrote:
> >> The DKIM instructions I used:
> >> https://beingasysadmin.wordpress.com/2013/04/30/dkim-signing-in-qmail
> >> /
> >>

> 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.

Yeah, I did that, and it works well. I used opendkim to create the
certificates, a bit of renaming, and it worked out allright.

> All the hard work is done with Mail::DKIM as you guessed.

I also had a look at the internals of the shell script, because it was a
bit of a PITA. What really should be done here is to eliminate the
dkimsign.pl script entirely, and instead implement the qmail-remote
wrapper in Perl and call Mail::DKIM::Signer directly from the wrapper. I
started doing that, but the bashism in the shell script got me confused,
so I went away with my tail between my legs ;-)

The dkimsign.pl script in the blog you referenced is a slightly hacked up
version of the same script from the Mail::DKIM distro, but the whole thing
could be made a lot simpler if the qmail-remote wrapper was written in
Perl.

Cheers,

Kjetil