diff --git a/CHANGES b/CHANGES
index fac2eb3bce8533b3cbdab0e5262a69989e9d22bf..6c4c8ad04e16f3960306107e701cff9811599110 100644
--- a/CHANGES
+++ b/CHANGES
@@ -1,3 +1,9 @@
+1.2.2 2020-08-09
+ - Improve README.md formating for markdown display on pypi
+ - Improve documentation in dkimpy-milter.conf (5) and README.md for signing
+ for multiple domains (Thanks to Stefano Rivera)
+ - Minimal fix for dnspython 2.0.0 compatibility (still works with 1.16.0)
+
1.2.1 2020-01-04
- Fix expand option not to fail if files are missing since socket activation
service files are not shipped in the sdist
diff --git a/PKG-INFO b/PKG-INFO
index 917e8491e54d6201841f514cee94bd6de8a109db..618102b86c0a070ac3e82b87a296c7325da2c137 100644
--- a/PKG-INFO
+++ b/PKG-INFO
@@ -1,6 +1,6 @@
Metadata-Version: 2.1
Name: dkimpy-milter
-Version: 1.2.1
+Version: 1.2.2
Summary: Domain Keys Identified Mail (DKIM) signing/verifying milter for Postfix/Sendmail.
Home-page: https://launchpad.net/dkimpy-milter
Author: Scott Kitterman
@@ -61,22 +61,23 @@ Description: # OVERVIEW
file locations in init scripts, man pages, and config files to be over-ridden
at install time.
- expand: Expand @@ variables in input files, simlar to make macros.
- user_options:
- --sysconfigdir=, e: Specify system configuration directory.
- --sbindir=, s: Specify system binary directory [not used].
- --bindir=, b: Specify binary directory.
- --rundir=,r: Specify run state directory.
+
+ expand: Expand @@ variables in input files, simlar to make macros.
+ user_options:
+ --sysconfigdir=, e: Specify system configuration directory.
+ --sbindir=, s: Specify system binary directory [not used].
+ --bindir=, b: Specify binary directory.
+ --rundir=,r: Specify run state directory.
As an example, to change the run directory to /var/run, one would do:
- python3 setup.py expand --rundir=/var/run
- [sudo] python3 setup.py install --single-version-externally-managed \
+ python3 setup.py expand --rundir=/var/run
+ [sudo] python3 setup.py install --single-version-externally-managed \
--record=/dev/null
or in a single step (the order matters):
- [sudo] python3 setup.py expand --rundir=/var/run install \
+ [sudo] python3 setup.py expand --rundir=/var/run install \
--single-version-externally-managed \
--record=/dev/null
@@ -96,7 +97,7 @@ Description: # OVERVIEW
1024 bits and should have a size of at least 2048 bits. The dknewkey script
that is provided with dkimpy is one such tool:
- dknewkey exampleprivkey
+ dknewkey exampleprivkey
will produce both the private key file (.key suffix) and a file with the DKIM
public key record to be published DNS (.dns suffix). RSA is the default key
@@ -108,7 +109,7 @@ Description: # OVERVIEW
so in order to generate Ed25519 keys for dkimpy-milter, dkimpy specific tools
must be used to be compatible. The same dknewkey script support Ed25519:
- dknewkey --ktype ed25519 anothernewkey
+ dknewkey --ktype ed25519 anothernewkey
will provide both the private key file (.key suffix) and a file with the DKIM
public key record to be published DNS (.dns suffix). Ed25519 keys do not have
@@ -144,9 +145,9 @@ Description: # OVERVIEW
comkey example.com:bar:/usr/local/etc/dkim/keys/excom
netkey example.net:baz:/usr/local/etc/dkim/keys/exnet
- If also signing with ed25519, specify a KeyTableEd25519 pointing to the keys
- needed for ed25519. Both KeyTable and KeyTableEd25519 are evaluated if there
- is a SigningTable (see below).
+ If also signing with ed25519, specify a KeyTableEd25519, with the same
+ names, pointing to the keys needed for ed25519. Both KeyTable and
+ KeyTableEd25519 are evaluated if there is a SigningTable (see below).
Per the documentation, multi-field data sets that are made of flat files have
the fields separated by colons, but the key and value(s) are separated by
@@ -194,7 +195,7 @@ Description: # OVERVIEW
UserID. During initial setup, this system user needs to be manually created.
As an example, using the default dkimpy-user on Debian, the command would be:
- [sudo] adduser --system --no-create-home --quiet --disabled-password \
+ [sudo] adduser --system --no-create-home --quiet --disabled-password \
--disabled-login --shell /bin/false --group \
--home /run/dkimpy-milter dkimpy-milter
@@ -204,10 +205,10 @@ Description: # OVERVIEW
To start dkimpy-milter with systemd for the first time, you will need to take
the following steps:
- [sudo] systemctl daemon-reload
- [sudo] systemctl enable dkimpy-milter
- [sudo] systemctl start dkimpy-milter
- [sudo] systemctl status dkimpy-milter (to verify it started correctly)
+ [sudo] systemctl daemon-reload
+ [sudo] systemctl enable dkimpy-milter
+ [sudo] systemctl start dkimpy-milter
+ [sudo] systemctl status dkimpy-milter (to verify it started correctly)
As with all milters, dkimpy-milter needs to be integrated with your MTA of
choice (Sendmail or Postfix). When integrating with your MTA, the risk of
@@ -223,7 +224,7 @@ Description: # OVERVIEW
dkimpy-milter. Here's an example configuration line to include in your
sendmail.mc:
- INPUT_MAIL_FILTER(`dkimpy-milter', `S=local:/run/dkimpy-milter/dkimpy-milter.sock')dnl
+ INPUT_MAIL_FILTER(`dkimpy-milter', `S=local:/run/dkimpy-milter/dkimpy-milter.sock')dnl
Changing the sendmail.mc file requires a Make (to compile it into sendmail.cf)
and a restart of sendmail. Note that S= needs to match the value of Socket in
@@ -246,7 +247,7 @@ Description: # OVERVIEW
By default, sendmail quotes to address header fields when there are no
quotes and the display part of the address contains a period or an
- apostrophe. However, opendkim only sees the raw, unmodified form of
+ apostrophe. However, dkimpy-milter only sees the raw, unmodified form of
the header field, and so the content that gets verified and what gets
signed will not be the same, guaranteeing the attached signature is not
valid.
@@ -272,16 +273,16 @@ Description: # OVERVIEW
To: very long name <a@example.org>,
anotherloo...ong name b <b@example.org>
- This rewrite is also done after opendkim has seen the message, meaning
- the signature opendkim attaches to the message does not match the
- content it signed. There is not a known configuration change to
+ This rewrite is also done after dkimpy-milter has seen the message,
+ meaning the signature dkimpy-milter attaches to the message does not match
+ the content it signed. There is not a known configuration change to
mitigate this mutation.
The only known mechanism for dealing with this is to have distinct
- instances of opendkim do the verifying (inbound) and signing (outbound)
- so that the version that arrives at the signing instance is already
- in the rewritten form, guaranteeing the input and output are the same
- and thus the signature matches the payload.
+ instances of dkimpy-milter do the verifying (inbound) and signing
+ (outbound) so that the version that arrives at the signing instance is
+ already in the rewritten form, guaranteeing the input and output are the
+ same and thus the signature matches the payload.
### POSTFIX
@@ -290,15 +291,15 @@ Description: # OVERVIEW
to two dkimpy-milter instances, one configured for signing and one configured
for verification:
- smtp inet n - - - - smtpd
- ...
- -o smtpd_milters=inet:localhost:8892
- ...
+ smtp inet n - - - - smtpd
+ ...
+ -o smtpd_milters=inet:localhost:8892
+ ...
- submission inet n - - - - smtpd
- ...
- -o smtpd_milters=inet:localhost:8891
- ...
+ submission inet n - - - - smtpd
+ ...
+ -o smtpd_milters=inet:localhost:8891
+ ...
These need to match the Socket value for each dkimpy-milter instance.
@@ -309,28 +310,28 @@ Description: # OVERVIEW
Postfix master.cf:
- smtp inet n - - - - smtpd
- ...
- -o smtpd_milters=inet:localhost:8891
- -o milter_macro_daemon_name=VERIFYING
- ...
-
- submission inet n - - - - smtpd
- -o syslog_name=postfix/submission
- -o smtpd_tls_security_level=encrypt
- -o smtpd_sasl_auth_enable=yes
- ...
- -o milter_macro_daemon_name=ORIGINATING
- -o smtpd_milters=inet:localhost:8891
- ...
+ smtp inet n - - - - smtpd
+ ...
+ -o smtpd_milters=inet:localhost:8891
+ -o milter_macro_daemon_name=VERIFYING
+ ...
+
+ submission inet n - - - - smtpd
+ -o syslog_name=postfix/submission
+ -o smtpd_tls_security_level=encrypt
+ -o smtpd_sasl_auth_enable=yes
+ ...
+ -o milter_macro_daemon_name=ORIGINATING
+ -o smtpd_milters=inet:localhost:8891
+ ...
Dkimpy-milter.conf:
- ...
- Mode sv
- MacroList dameon_name|ORIGINATING
- MacroListVerify daemon_name|VERIFYING
- ...
+ ...
+ Mode sv
+ MacroList dameon_name|ORIGINATING
+ MacroListVerify daemon_name|VERIFYING
+ ...
# NOTES
diff --git a/README.md b/README.md
index a908c8e33da987c768e7f8c8f80c4e09b7618393..49efe6fe1b823529ffd1bf07952c4dbb0d55a7bd 100644
--- a/README.md
+++ b/README.md
@@ -52,22 +52,23 @@ The package includes a custom setup command called expand. It allows various
file locations in init scripts, man pages, and config files to be over-ridden
at install time.
-expand: Expand @@ variables in input files, simlar to make macros.
-user_options:
- --sysconfigdir=, e: Specify system configuration directory.
- --sbindir=, s: Specify system binary directory [not used].
- --bindir=, b: Specify binary directory.
- --rundir=,r: Specify run state directory.
+
+ expand: Expand @@ variables in input files, simlar to make macros.
+ user_options:
+ --sysconfigdir=, e: Specify system configuration directory.
+ --sbindir=, s: Specify system binary directory [not used].
+ --bindir=, b: Specify binary directory.
+ --rundir=,r: Specify run state directory.
As an example, to change the run directory to /var/run, one would do:
-python3 setup.py expand --rundir=/var/run
-[sudo] python3 setup.py install --single-version-externally-managed \
+ python3 setup.py expand --rundir=/var/run
+ [sudo] python3 setup.py install --single-version-externally-managed \
--record=/dev/null
or in a single step (the order matters):
-[sudo] python3 setup.py expand --rundir=/var/run install \
+ [sudo] python3 setup.py expand --rundir=/var/run install \
--single-version-externally-managed \
--record=/dev/null
@@ -87,7 +88,7 @@ tools available to create them. Keys must (RFC 8302) have a minimum size of
1024 bits and should have a size of at least 2048 bits. The dknewkey script
that is provided with dkimpy is one such tool:
-dknewkey exampleprivkey
+ dknewkey exampleprivkey
will produce both the private key file (.key suffix) and a file with the DKIM
public key record to be published DNS (.dns suffix). RSA is the default key
@@ -99,7 +100,7 @@ There is no standardized non-binary representation for Ed25519 private keys,
so in order to generate Ed25519 keys for dkimpy-milter, dkimpy specific tools
must be used to be compatible. The same dknewkey script support Ed25519:
-dknewkey --ktype ed25519 anothernewkey
+ dknewkey --ktype ed25519 anothernewkey
will provide both the private key file (.key suffix) and a file with the DKIM
public key record to be published DNS (.dns suffix). Ed25519 keys do not have
@@ -135,9 +136,9 @@ for the above might look like this:
comkey example.com:bar:/usr/local/etc/dkim/keys/excom
netkey example.net:baz:/usr/local/etc/dkim/keys/exnet
-If also signing with ed25519, specify a KeyTableEd25519 pointing to the keys
-needed for ed25519. Both KeyTable and KeyTableEd25519 are evaluated if there
-is a SigningTable (see below).
+If also signing with ed25519, specify a KeyTableEd25519, with the same
+names, pointing to the keys needed for ed25519. Both KeyTable and
+KeyTableEd25519 are evaluated if there is a SigningTable (see below).
Per the documentation, multi-field data sets that are made of flat files have
the fields separated by colons, but the key and value(s) are separated by
@@ -185,7 +186,7 @@ The dkimpy-milter drops priviledges after setup to the user/group specified in
UserID. During initial setup, this system user needs to be manually created.
As an example, using the default dkimpy-user on Debian, the command would be:
-[sudo] adduser --system --no-create-home --quiet --disabled-password \
+ [sudo] adduser --system --no-create-home --quiet --disabled-password \
--disabled-login --shell /bin/false --group \
--home /run/dkimpy-milter dkimpy-milter
@@ -195,10 +196,10 @@ missing, the milter will create it on startup.
To start dkimpy-milter with systemd for the first time, you will need to take
the following steps:
-[sudo] systemctl daemon-reload
-[sudo] systemctl enable dkimpy-milter
-[sudo] systemctl start dkimpy-milter
-[sudo] systemctl status dkimpy-milter (to verify it started correctly)
+ [sudo] systemctl daemon-reload
+ [sudo] systemctl enable dkimpy-milter
+ [sudo] systemctl start dkimpy-milter
+ [sudo] systemctl status dkimpy-milter (to verify it started correctly)
As with all milters, dkimpy-milter needs to be integrated with your MTA of
choice (Sendmail or Postfix). When integrating with your MTA, the risk of
@@ -214,7 +215,7 @@ Configuration is very similar to opendkim, but needs some adjustment for
dkimpy-milter. Here's an example configuration line to include in your
sendmail.mc:
-INPUT_MAIL_FILTER(`dkimpy-milter', `S=local:/run/dkimpy-milter/dkimpy-milter.sock')dnl
+ INPUT_MAIL_FILTER(`dkimpy-milter', `S=local:/run/dkimpy-milter/dkimpy-milter.sock')dnl
Changing the sendmail.mc file requires a Make (to compile it into sendmail.cf)
and a restart of sendmail. Note that S= needs to match the value of Socket in
@@ -237,7 +238,7 @@ and deserve consideration.
By default, sendmail quotes to address header fields when there are no
quotes and the display part of the address contains a period or an
- apostrophe. However, opendkim only sees the raw, unmodified form of
+ apostrophe. However, dkimpy-milter only sees the raw, unmodified form of
the header field, and so the content that gets verified and what gets
signed will not be the same, guaranteeing the attached signature is not
valid.
@@ -263,16 +264,16 @@ and deserve consideration.
To: very long name <a@example.org>,
anotherloo...ong name b <b@example.org>
- This rewrite is also done after opendkim has seen the message, meaning
- the signature opendkim attaches to the message does not match the
- content it signed. There is not a known configuration change to
+ This rewrite is also done after dkimpy-milter has seen the message,
+ meaning the signature dkimpy-milter attaches to the message does not match
+ the content it signed. There is not a known configuration change to
mitigate this mutation.
The only known mechanism for dealing with this is to have distinct
- instances of opendkim do the verifying (inbound) and signing (outbound)
- so that the version that arrives at the signing instance is already
- in the rewritten form, guaranteeing the input and output are the same
- and thus the signature matches the payload.
+ instances of dkimpy-milter do the verifying (inbound) and signing
+ (outbound) so that the version that arrives at the signing instance is
+ already in the rewritten form, guaranteeing the input and output are the
+ same and thus the signature matches the payload.
### POSTFIX
@@ -281,15 +282,15 @@ README_FILES/MILTER_README). Here's an example master.cf excerpt that talks
to two dkimpy-milter instances, one configured for signing and one configured
for verification:
-smtp inet n - - - - smtpd
- ...
- -o smtpd_milters=inet:localhost:8892
- ...
+ smtp inet n - - - - smtpd
+ ...
+ -o smtpd_milters=inet:localhost:8892
+ ...
-submission inet n - - - - smtpd
- ...
- -o smtpd_milters=inet:localhost:8891
- ...
+ submission inet n - - - - smtpd
+ ...
+ -o smtpd_milters=inet:localhost:8891
+ ...
These need to match the Socket value for each dkimpy-milter instance.
@@ -300,28 +301,28 @@ macros to keep the mail streams segregated:
Postfix master.cf:
-smtp inet n - - - - smtpd
- ...
- -o smtpd_milters=inet:localhost:8891
- -o milter_macro_daemon_name=VERIFYING
- ...
-
-submission inet n - - - - smtpd
- -o syslog_name=postfix/submission
- -o smtpd_tls_security_level=encrypt
- -o smtpd_sasl_auth_enable=yes
- ...
- -o milter_macro_daemon_name=ORIGINATING
- -o smtpd_milters=inet:localhost:8891
- ...
+ smtp inet n - - - - smtpd
+ ...
+ -o smtpd_milters=inet:localhost:8891
+ -o milter_macro_daemon_name=VERIFYING
+ ...
+
+ submission inet n - - - - smtpd
+ -o syslog_name=postfix/submission
+ -o smtpd_tls_security_level=encrypt
+ -o smtpd_sasl_auth_enable=yes
+ ...
+ -o milter_macro_daemon_name=ORIGINATING
+ -o smtpd_milters=inet:localhost:8891
+ ...
Dkimpy-milter.conf:
-...
-Mode sv
-MacroList dameon_name|ORIGINATING
-MacroListVerify daemon_name|VERIFYING
-...
+ ...
+ Mode sv
+ MacroList dameon_name|ORIGINATING
+ MacroListVerify daemon_name|VERIFYING
+ ...
# NOTES
diff --git a/dkimpy_milter.egg-info/PKG-INFO b/dkimpy_milter.egg-info/PKG-INFO
index 917e8491e54d6201841f514cee94bd6de8a109db..618102b86c0a070ac3e82b87a296c7325da2c137 100644
--- a/dkimpy_milter.egg-info/PKG-INFO
+++ b/dkimpy_milter.egg-info/PKG-INFO
@@ -1,6 +1,6 @@
Metadata-Version: 2.1
Name: dkimpy-milter
-Version: 1.2.1
+Version: 1.2.2
Summary: Domain Keys Identified Mail (DKIM) signing/verifying milter for Postfix/Sendmail.
Home-page: https://launchpad.net/dkimpy-milter
Author: Scott Kitterman
@@ -61,22 +61,23 @@ Description: # OVERVIEW
file locations in init scripts, man pages, and config files to be over-ridden
at install time.
- expand: Expand @@ variables in input files, simlar to make macros.
- user_options:
- --sysconfigdir=, e: Specify system configuration directory.
- --sbindir=, s: Specify system binary directory [not used].
- --bindir=, b: Specify binary directory.
- --rundir=,r: Specify run state directory.
+
+ expand: Expand @@ variables in input files, simlar to make macros.
+ user_options:
+ --sysconfigdir=, e: Specify system configuration directory.
+ --sbindir=, s: Specify system binary directory [not used].
+ --bindir=, b: Specify binary directory.
+ --rundir=,r: Specify run state directory.
As an example, to change the run directory to /var/run, one would do:
- python3 setup.py expand --rundir=/var/run
- [sudo] python3 setup.py install --single-version-externally-managed \
+ python3 setup.py expand --rundir=/var/run
+ [sudo] python3 setup.py install --single-version-externally-managed \
--record=/dev/null
or in a single step (the order matters):
- [sudo] python3 setup.py expand --rundir=/var/run install \
+ [sudo] python3 setup.py expand --rundir=/var/run install \
--single-version-externally-managed \
--record=/dev/null
@@ -96,7 +97,7 @@ Description: # OVERVIEW
1024 bits and should have a size of at least 2048 bits. The dknewkey script
that is provided with dkimpy is one such tool:
- dknewkey exampleprivkey
+ dknewkey exampleprivkey
will produce both the private key file (.key suffix) and a file with the DKIM
public key record to be published DNS (.dns suffix). RSA is the default key
@@ -108,7 +109,7 @@ Description: # OVERVIEW
so in order to generate Ed25519 keys for dkimpy-milter, dkimpy specific tools
must be used to be compatible. The same dknewkey script support Ed25519:
- dknewkey --ktype ed25519 anothernewkey
+ dknewkey --ktype ed25519 anothernewkey
will provide both the private key file (.key suffix) and a file with the DKIM
public key record to be published DNS (.dns suffix). Ed25519 keys do not have
@@ -144,9 +145,9 @@ Description: # OVERVIEW
comkey example.com:bar:/usr/local/etc/dkim/keys/excom
netkey example.net:baz:/usr/local/etc/dkim/keys/exnet
- If also signing with ed25519, specify a KeyTableEd25519 pointing to the keys
- needed for ed25519. Both KeyTable and KeyTableEd25519 are evaluated if there
- is a SigningTable (see below).
+ If also signing with ed25519, specify a KeyTableEd25519, with the same
+ names, pointing to the keys needed for ed25519. Both KeyTable and
+ KeyTableEd25519 are evaluated if there is a SigningTable (see below).
Per the documentation, multi-field data sets that are made of flat files have
the fields separated by colons, but the key and value(s) are separated by
@@ -194,7 +195,7 @@ Description: # OVERVIEW
UserID. During initial setup, this system user needs to be manually created.
As an example, using the default dkimpy-user on Debian, the command would be:
- [sudo] adduser --system --no-create-home --quiet --disabled-password \
+ [sudo] adduser --system --no-create-home --quiet --disabled-password \
--disabled-login --shell /bin/false --group \
--home /run/dkimpy-milter dkimpy-milter
@@ -204,10 +205,10 @@ Description: # OVERVIEW
To start dkimpy-milter with systemd for the first time, you will need to take
the following steps:
- [sudo] systemctl daemon-reload
- [sudo] systemctl enable dkimpy-milter
- [sudo] systemctl start dkimpy-milter
- [sudo] systemctl status dkimpy-milter (to verify it started correctly)
+ [sudo] systemctl daemon-reload
+ [sudo] systemctl enable dkimpy-milter
+ [sudo] systemctl start dkimpy-milter
+ [sudo] systemctl status dkimpy-milter (to verify it started correctly)
As with all milters, dkimpy-milter needs to be integrated with your MTA of
choice (Sendmail or Postfix). When integrating with your MTA, the risk of
@@ -223,7 +224,7 @@ Description: # OVERVIEW
dkimpy-milter. Here's an example configuration line to include in your
sendmail.mc:
- INPUT_MAIL_FILTER(`dkimpy-milter', `S=local:/run/dkimpy-milter/dkimpy-milter.sock')dnl
+ INPUT_MAIL_FILTER(`dkimpy-milter', `S=local:/run/dkimpy-milter/dkimpy-milter.sock')dnl
Changing the sendmail.mc file requires a Make (to compile it into sendmail.cf)
and a restart of sendmail. Note that S= needs to match the value of Socket in
@@ -246,7 +247,7 @@ Description: # OVERVIEW
By default, sendmail quotes to address header fields when there are no
quotes and the display part of the address contains a period or an
- apostrophe. However, opendkim only sees the raw, unmodified form of
+ apostrophe. However, dkimpy-milter only sees the raw, unmodified form of
the header field, and so the content that gets verified and what gets
signed will not be the same, guaranteeing the attached signature is not
valid.
@@ -272,16 +273,16 @@ Description: # OVERVIEW
To: very long name <a@example.org>,
anotherloo...ong name b <b@example.org>
- This rewrite is also done after opendkim has seen the message, meaning
- the signature opendkim attaches to the message does not match the
- content it signed. There is not a known configuration change to
+ This rewrite is also done after dkimpy-milter has seen the message,
+ meaning the signature dkimpy-milter attaches to the message does not match
+ the content it signed. There is not a known configuration change to
mitigate this mutation.
The only known mechanism for dealing with this is to have distinct
- instances of opendkim do the verifying (inbound) and signing (outbound)
- so that the version that arrives at the signing instance is already
- in the rewritten form, guaranteeing the input and output are the same
- and thus the signature matches the payload.
+ instances of dkimpy-milter do the verifying (inbound) and signing
+ (outbound) so that the version that arrives at the signing instance is
+ already in the rewritten form, guaranteeing the input and output are the
+ same and thus the signature matches the payload.
### POSTFIX
@@ -290,15 +291,15 @@ Description: # OVERVIEW
to two dkimpy-milter instances, one configured for signing and one configured
for verification:
- smtp inet n - - - - smtpd
- ...
- -o smtpd_milters=inet:localhost:8892
- ...
+ smtp inet n - - - - smtpd
+ ...
+ -o smtpd_milters=inet:localhost:8892
+ ...
- submission inet n - - - - smtpd
- ...
- -o smtpd_milters=inet:localhost:8891
- ...
+ submission inet n - - - - smtpd
+ ...
+ -o smtpd_milters=inet:localhost:8891
+ ...
These need to match the Socket value for each dkimpy-milter instance.
@@ -309,28 +310,28 @@ Description: # OVERVIEW
Postfix master.cf:
- smtp inet n - - - - smtpd
- ...
- -o smtpd_milters=inet:localhost:8891
- -o milter_macro_daemon_name=VERIFYING
- ...
-
- submission inet n - - - - smtpd
- -o syslog_name=postfix/submission
- -o smtpd_tls_security_level=encrypt
- -o smtpd_sasl_auth_enable=yes
- ...
- -o milter_macro_daemon_name=ORIGINATING
- -o smtpd_milters=inet:localhost:8891
- ...
+ smtp inet n - - - - smtpd
+ ...
+ -o smtpd_milters=inet:localhost:8891
+ -o milter_macro_daemon_name=VERIFYING
+ ...
+
+ submission inet n - - - - smtpd
+ -o syslog_name=postfix/submission
+ -o smtpd_tls_security_level=encrypt
+ -o smtpd_sasl_auth_enable=yes
+ ...
+ -o milter_macro_daemon_name=ORIGINATING
+ -o smtpd_milters=inet:localhost:8891
+ ...
Dkimpy-milter.conf:
- ...
- Mode sv
- MacroList dameon_name|ORIGINATING
- MacroListVerify daemon_name|VERIFYING
- ...
+ ...
+ Mode sv
+ MacroList dameon_name|ORIGINATING
+ MacroListVerify daemon_name|VERIFYING
+ ...
# NOTES
diff --git a/dkimpy_milter/__init__.py b/dkimpy_milter/__init__.py
index b912660c8e3c66b3c2d942304b2cd456747905a5..5118ae88d4f79c6c65f068ae2996e3aa3cb9ef67 100644
--- a/dkimpy_milter/__init__.py
+++ b/dkimpy_milter/__init__.py
@@ -363,8 +363,12 @@ class dkimMilter(Milter.Base):
try:
dnsoverride = self.conf.get('DNSOverride')
if isinstance(dnsoverride, str):
+ timeout = 5
+ domain = self.fdomain
+ def dnsfunc(domain, timeout=timeout, dnsoverride=dnsoverride):
+ return dnsoverride
syslog.syslog("DNSOverride: {0}".format(dnsoverride))
- res = d.verify(idx=y, dnsfunc=lambda _x: dnsoverride)
+ res = d.verify(idx=y, dnsfunc=dnsfunc)
else:
res = d.verify(idx=y)
algo = codecs.decode(d.signature_fields.get(b'a'), 'ascii')
diff --git a/dkimpy_milter/dnsplug.py b/dkimpy_milter/dnsplug.py
index 9e7aa58012407f52fbe38ddaa1d864bb68ceb5e1..d1f7a15e59065426fa8acded2df6d4e6e3dbf1ad 100644
--- a/dkimpy_milter/dnsplug.py
+++ b/dkimpy_milter/dnsplug.py
@@ -127,7 +127,7 @@ def DNSLookup_dnspython(name,qtype,tcpfallback=True,timeout=5):
elif qtype == 'PTR':
retVal.append(((name, qtype), rdata.target.to_text(True)))
elif qtype == 'TXT' or qtype == 'SPF':
- retVal.append(((name, qtype), rdata.strings))
+ retVal.append(((name, qtype), list(rdata.strings)))
except dns.resolver.NoAnswer:
pass
except dns.resolver.NXDOMAIN:
diff --git a/man/dkimpy-milter.conf.5.in b/man/dkimpy-milter.conf.5.in
index 9a776af44c0c80a0e4bf9c2cafe54524ac69a542..45e3097865f0d47b13b5bf6a9fac301e6a46762f 100644
--- a/man/dkimpy-milter.conf.5.in
+++ b/man/dkimpy-milter.conf.5.in
@@ -428,7 +428,7 @@ of this field.
.TP
.I SigningTable (dataset)
-Defines a table used to select one or more signing identities to apply to a message based on the address found in the From: header field. Keys in this table vary depending on the type of table used; values in this data set should include one field that contains a name found in the KeyTable (see above) that identifies which key should be used in generating the signature, and an optional second field naming the signer of the message that will be included in the "i=" tag in the generated signature. Note that the "i=" value will not be included in the signature if it conflicts with the signing domain (the "d=" value).
+Defines a table used to select a signing identity to apply to a message based on the address found in the From: header field. Keys in this table vary depending on the type of table used; values in this data set should include one field that contains a name found in the KeyTable (see above) that identifies which key should be used in generating the signature, and an optional second field naming the signer of the message that will be included in the "i=" tag in the generated signature. Note that the "i=" value will not be included in the signature if it conflicts with the signing domain (the "d=" value).
If the first field contains only a "%" character, it will be replaced by the domain found in the From: header field. Similarly, within the optional second field, any "%" character will be replaced by the domain found in the From: header field.
diff --git a/setup.py b/setup.py
index 07039f71ddd28d32fa3df47cd258e19306d25cdc..fcb4e37541f313edcab9c9bad2e43088971d92b0 100644
--- a/setup.py
+++ b/setup.py
@@ -89,7 +89,7 @@ except ImportError: # If PyDNS is not installed, prefer dnspython
setup(
name='dkimpy-milter',
- version='1.2.1',
+ version='1.2.2',
author='Scott Kitterman',
author_email='scott@kitterman.com',
url='https://launchpad.net/dkimpy-milter',