How to debug DMARC check?
Hi,
I've been running a dockerized mailman3 server for several years with DMARC mitigation set to conditional. I use the 0.4 version of the mailman3 docker images.
Recently I had to update my network configuration to prevent spammers using IPv6 to circumvent the no-relay configuration of my exim4 server.
Previously, I had both exim4 and mailman3 on the same docker bridge 172.19.0.0/16 and exim4 was configured to relay email from this network only. There was no problem regarding DMARC mitigation : most of the emails didn't need to be altered.
Now I have added an internal docker network 172.29.0.0/16 and configured exim4 to relay from this internal network only. Since this network is not accessible from the host, IPv6 spammers are blocked (*).
But since this modification mailman alters every emails with DMARC mitigation.
Any hint how to debug this issue?
Thanks in advance, _g.
(*) With IPv6 incoming connexions mailman docker replaces the client address with the IPv4 address of the host one the bridge network: 172.19.0.1.
Gilles Filippini writes:
Now I have added an internal docker network 172.29.0.0/16 and configured exim4 to relay from this internal network only. Since this network is not accessible from the host, IPv6 spammers are blocked (*).
But since this modification mailman alters every emails with DMARC mitigation.
Any hint how to debug this issue?
Mailman has three levels of DMARC mitigation: never, as-needed, always. If you have it set to as-needed, Mailman will look for the DMARC policy as the DNS TXT record for _dmarc.domain-of-from.tld. If it can't get a reply it assumes the worst (p=reject) and applies the mitigation.
You can
- set mitigation to never
- give Mailman a way to connect to a DNS server.
Steve
Stephen J. Turnbull a écrit le 01/09/2023 à 16:17 :
Gilles Filippini writes:
Now I have added an internal docker network 172.29.0.0/16 and configured exim4 to relay from this internal network only. Since this network is not accessible from the host, IPv6 spammers are blocked (*).
But since this modification mailman alters every emails with DMARC mitigation.
Any hint how to debug this issue?
Mailman has three levels of DMARC mitigation: never, as-needed, always. If you have it set to as-needed, Mailman will look for the DMARC policy as the DNS TXT record for _dmarc.domain-of-from.tld. If it can't get a reply it assumes the worst (p=reject) and applies the mitigation.
You can
- set mitigation to never
- give Mailman a way to connect to a DNS server.
You're right, thanks!
I remember now that I had to set up only one network interface for mailman-core because when I add another one to enable internet access then exim4 cannot reach mailman-core anymore:
Sep 1 15:08:09 lists exim[1004]: 2023-09-01 15:08:09 1qc5km-0000G9-2u H=mailman_core.exim4_internal [172.29.0.3] Connection refused
How can I fix that?
Thanks again, _g.
Gilles Filippini writes:
I remember now that I had to set up only one network interface for mailman-core because when I add another one to enable internet access then exim4 cannot reach mailman-core anymore:
Sep 1 15:08:09 lists exim[1004]: 2023-09-01 15:08:09 1qc5km-0000G9-2u H=mailman_core.exim4_internal [172.29.0.3] Connection refused
How can I fix that?
Depends on your network topology, where the DNS server, MTA, and Mailman core live on it, and where the network gateway to the public Internet is.
Stephen J. Turnbull a écrit le 02/09/2023 à 08:09 :
Gilles Filippini writes:
I remember now that I had to set up only one network interface for mailman-core because when I add another one to enable internet access then exim4 cannot reach mailman-core anymore:
Sep 1 15:08:09 lists exim[1004]: 2023-09-01 15:08:09 1qc5km-0000G9-2u H=mailman_core.exim4_internal [172.29.0.3] Connection refused
How can I fix that?
Depends on your network topology, where the DNS server, MTA, and Mailman core live on it, and where the network gateway to the public Internet is.
Sure.
The issue was that exim4 could connect to mmailman_core when the latter had only one network interface, but the connection was refused when it had two.
And the cause was that when MM_HOSTNAME is not defined, it is initialized with the result of the command 'hostname -i' which returns as mainy IPs as network interfaces:
172.29.0.3 172.18.0.19
This erroneous value was then used into /etc/mailman.cfg and /etc/exim-mailman.cfg.
The solution is to force MM_HOSTNAME to the wanted IP.
Thanks, _g.
participants (2)
-
Gilles Filippini -
Stephen J. Turnbull