Bug#981156: dkimpy-milter: issues in sign-vs-verify logic (and documentation)

[Michel Lespinasse]

Package: dkimpy-milter
Version: 1.2.1-1~bpo10+1
Severity: normal


I have been encountering issues trying to configure the sign-vs-verify
logic in dkimpy-milter. Some of it comes down to confusing documentation,
but it also appears that the behavior I want can not be configured.

I would like the sign-vs-verify logic to behave similarly to the
smtpd_relay_restrictions rules in my postfix configuration:
- any email coming from local networks (local sendmail, localhost smtpd,
or 10.0.0.0/8 smtpd) should be signed,
- any email coming from other sources should be verified.


Reading the documentation, it seems that setting InternalHosts should work,
but this doesn't seem to be the case:

In dkimMilter.connect(),
- self.internal_connection is set if the connection comes from an address matching InternalHosts, or if the milter macros match MacroList.
- self.external_connection is set if the milter macros match MacroListVerify

In dkimMilter.eom():
- self.external_connection disables signing
- self.internal_connection disables verifying

Therefore, MacroListVerify ends up controllinjg signing (despite what
the name implies!), and MacroList ends up controlling verifying
(despite what the documentation says about it). Additionally, for a
smtpd milter receiving mail from both internal and external
connections, it is not possible to control signing based on the
InternalHosts value.


My wishes for resolving this bug are:
1- There should be a way to control signing based on the originating
connection's IP address;
2- It would be nice for the documentation to explain how the
MacroList, MacroListVerify and InternalHosts values interact to
determine wether we are dealing with an internal/trusted or
external/untrusted connection (right now the values are only described
separately and the interactions are not documented in any way);
3- I am not sure if there are any reasons for connections to be marked as
both internal and external at once, or to have neither markings - if there
are valid reasons for that, the documentation should explain them; if not
maybe the milter should emit a warning when incorrectly configured...
4- The interaction between Mode and internal vs external connections
should be documented (i.e. that Mode=s still only signs internal
connections, and Mode=v still only verifies external connections).


Sorry for the long winded report, hope it is at least clear enough :)

Thanks,


-- System Information:
Debian Release: 10.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dkimpy-milter depends on:
ii adduser 3.118
ii python3 3.7.3-1
ii python3-authres 1.1.1-1
ii python3-dkim 1.0.3-1~bpo10+1
ii python3-dns 3.2.0-2
ii python3-dnspython 1.16.0-1
ii python3-milter 1.0.3-3
ii python3-nacl 1.3.0-2
ii python3-pkg-resources 40.8.0-1

dkimpy-milter recommends no packages.

Versions of packages dkimpy-milter suggests:
ii lsb-base 10.2019051400
ii postfix 3.4.14-0+deb10u1

-- no debconf information

[Scott Kitterman]

On Tue, 26 Jan 2021 21:47:42 -0800 Michel Lespinasse <wal...@lespinasse.org>
wrote:

Thanks. I agree it's a bit of a mess.

The theory is that a connection identified as "internal" should only sign, not
verify and a connection that's identified as "external" should only verify and
not sign.

Currently the code will identify a connection as "internal" if it is in
IntHosts or libmilter provides the macro in "MacroList".

The code will identify a connection as "external" if the MacroListVerify macro
is provided.

If it's not an "external" connection and the mode is s or sv, it will sign.

If it's not an "internal" connection and the mode is v or sv, DKIM will be
verified.

If it's not "internal" or "external" (i.e.IntHosts not set and neither
MacroLIst or MacroLIstVerify provided), then the Mode (v, s, or sv) controls
exclusively.

I agree this could be better documented and I had to look at the code to try t
figure it out again. I don't think both internal and external would every be
set, but neither being set is appropriate if there aren't any macros provided
and it's not covered by IntHosts.

Scott K