docker-postfix/configs/opendkim.conf

AutoRestart             Yes
AutoRestartRate         10/1h
UMask                   002
Syslog                  Yes
SyslogSuccess           Yes
LogWhy                  No

Canonicalization        relaxed/simple
RequireSafeKeys         no

ExternalIgnoreList      refile:/etc/opendkim/TrustedHosts
InternalHosts           refile:/etc/opendkim/TrustedHosts
KeyTable                refile:/etc/opendkim/KeyTable
SigningTable            refile:/etc/opendkim/SigningTable

Mode                    sv
PidFile                 /var/run/opendkim/opendkim.pid
SignatureAlgorithm      rsa-sha256

UserID                  opendkim:opendkim
Socket                  inet:8891@localhost

SignHeaders             From,Sender,To,CC,Subject,Message-Id,Date,MIME-Version,Content-Type,Reply-To
OversignHeaders         From,Sender,To,CC,Subject,Message-Id,Date,MIME-Version,Content-Type,Reply-To
Initial support for DKIM and testing This commit brings two important features: - DKIM support It's now possible to configure this postfix image to sign messages using DKIM by simply generating the keys and providing them in the approprate folder. This should bring us one step closer to directly sending out emails without relying on a 3rd-party proxy. - test support A nice and handy script, conviniently called `test.sh` has been provided, builds the image, spins it up and tries to send out an email. You'll need `docker-compose` to run it, though. 2019-02-19 17:49:55 +08:00			`AutoRestart Yes`
			`AutoRestartRate 10/1h`
			`UMask 002`
Fixes for DKIM implementation Important note: DKIM segment is hardcoded to "mail" in the configuration. You shouldn't be using any other segment name. If you don't know what that means: DKIM checks your DNS server for this segment name by querying `<segment>._domainkey.<domain>`. So, when saying you need to use the `mail` segment this means that the record must reside under `mail._domainkey.<domain>`. 2019-03-07 15:29:50 +08:00			`Syslog Yes`
Initial support for DKIM and testing This commit brings two important features: - DKIM support It's now possible to configure this postfix image to sign messages using DKIM by simply generating the keys and providing them in the approprate folder. This should bring us one step closer to directly sending out emails without relying on a 3rd-party proxy. - test support A nice and handy script, conviniently called `test.sh` has been provided, builds the image, spins it up and tries to send out an email. You'll need `docker-compose` to run it, though. 2019-02-19 17:49:55 +08:00			`SyslogSuccess Yes`
Fixes for DKIM implementation Important note: DKIM segment is hardcoded to "mail" in the configuration. You shouldn't be using any other segment name. If you don't know what that means: DKIM checks your DNS server for this segment name by querying `<segment>._domainkey.<domain>`. So, when saying you need to use the `mail` segment this means that the record must reside under `mail._domainkey.<domain>`. 2019-03-07 15:29:50 +08:00			`LogWhy No`
Initial support for DKIM and testing This commit brings two important features: - DKIM support It's now possible to configure this postfix image to sign messages using DKIM by simply generating the keys and providing them in the approprate folder. This should bring us one step closer to directly sending out emails without relying on a 3rd-party proxy. - test support A nice and handy script, conviniently called `test.sh` has been provided, builds the image, spins it up and tries to send out an email. You'll need `docker-compose` to run it, though. 2019-02-19 17:49:55 +08:00
			`Canonicalization relaxed/simple`
Fixes for DKIM implementation Important note: DKIM segment is hardcoded to "mail" in the configuration. You shouldn't be using any other segment name. If you don't know what that means: DKIM checks your DNS server for this segment name by querying `<segment>._domainkey.<domain>`. So, when saying you need to use the `mail` segment this means that the record must reside under `mail._domainkey.<domain>`. 2019-03-07 15:29:50 +08:00			`RequireSafeKeys no`
Initial support for DKIM and testing This commit brings two important features: - DKIM support It's now possible to configure this postfix image to sign messages using DKIM by simply generating the keys and providing them in the approprate folder. This should bring us one step closer to directly sending out emails without relying on a 3rd-party proxy. - test support A nice and handy script, conviniently called `test.sh` has been provided, builds the image, spins it up and tries to send out an email. You'll need `docker-compose` to run it, though. 2019-02-19 17:49:55 +08:00
			`ExternalIgnoreList refile:/etc/opendkim/TrustedHosts`
			`InternalHosts refile:/etc/opendkim/TrustedHosts`
			`KeyTable refile:/etc/opendkim/KeyTable`
			`SigningTable refile:/etc/opendkim/SigningTable`

			`Mode sv`
			`PidFile /var/run/opendkim/opendkim.pid`
			`SignatureAlgorithm rsa-sha256`

			`UserID opendkim:opendkim`
Relax OpenDKIM TrustedHosts Having very specific `TrustedHosts` has turned out to be more of a hassle than a benefit in the end. Since the service is runing on `localhost` either way, there's no theoretical way for anybody alse to access the service. Hence we just set all hosts (`0.0.0.0/0`) to trusted, reduce the LOC and call it a day. 2019-09-17 15:11:53 +08:00			`Socket inet:8891@localhost`
Add additional headers to DKIM signature By default OpenDKIM will sign just `From`, `To`, `Sender`, `Subject` and `Date`. It makes sense to also sign other headers (especially `Reply-To`) to make sure nobody fiddles with the email. 2019-09-17 15:31:42 +08:00
			`SignHeaders From,Sender,To,CC,Subject,Message-Id,Date,MIME-Version,Content-Type,Reply-To`
			`OversignHeaders From,Sender,To,CC,Subject,Message-Id,Date,MIME-Version,Content-Type,Reply-To`