Issues with docker-compose and opendkim

Docker-compose is awesome: it’s brings automation levels high, driving apps close to be 12 factor. But some times it’s being too smart (for me particularly). This time a couple of words on dynamic network creation.

Setup

Project setup is pretty much the same as in my recent post about backing up dockerized postgres database, except there is smtp container, on which all apps depend and to which are linked to.

 [proxy(nginx)]
         |
         +----------+-> [app1 (rails)] -+-----> [ db (postgres) ] -+
                    |-> [app2 (rails)] -|                          |
                    +-> [app3 (rails)] -+-----> ((public))         |
                                        +-----> ((uploads))        |
                  [smtp (postfix+dkim)]<-+       ((dbdata)) <-------+

Dynamic networks in compose

When command docker-compose up -d is issued a lot happens. One of initial steps is networks creation. It’s actually pretty awesome, how simple virtual networking can be with compose. Except one thing: one can’t be sertain about which ip the default network has.

Sure, it can be hardcoded in the top-level networks section, but for me it does not feel right. One day there may arise the problem with other project or just another compose run of the original project, while there is a virtual network with same address still exist. I suppose one should leave subnet management be managed by compose alone.

But sometimes this could become a problem. There are plenty of services which are meant to be configured with network addresses. One of such services is opendkim.

OpenDKIM

When mailing setup is being devised, SPF1 should be taken into account. One doesn’t want his messages to be marked as spam by google or yahoo. As part of the SPF messages should be signed using DKIM2, for which I use opendkim.

opendkim3 is an open source implementation of the DKIM sender authentication system. It integrates well with postfix.

There are several configuration files, namely

  • opendkim.conf,
  • KeyTable,
  • SigningTable,
  • TrustedHosts.

I suppose the reader already familiar with opendkim, so overall configuration and dockerizing is of no interest and fairly out of the scope. But one thing in the file TrustedHosts took me several hours of googling with no luck.

By default my postfix-dkim docker image was configured to trust default docker network, i.e. 172.17.0.0. The problem with this is that network address here is static and does not change with docker-compose invokes. So I see two approaches to solve this. Either pass network address as an argument to the docker run (inside the docker-compose.yml) or wildcard item in TrustedHosts.

First approach looks like overkill to me4, so I used this inside TrustedHosts:

127.0.0.1
172.*.0.0/16

Note: 127.0.0.1 must be the first line, \16 should not be omitted.

Some tools that may help:

  • Use docker-compose logs.
  • http://dkimvalidator.com/ – get e-mail address to send a message to, click “see results”, PROFIT.
  • Check your hosting provider to set PTR records, as these definitely taken into account by large relays, such as google.

  1. Sender Policy Framework. See http://www.openspf.org/

  2. DomainKeys Identified Mail. See http://www.dkim.org/

  3. http://www.opendkim.org/ 

  4. Taking into account, that SPF setup is proper, including valid PTR and other DNS records. 

SHOW COMMENTS (0)