feature request: adding whitelisting for 192.168.0.0

[hanscees]

Context

If I use spf with rspamd it results in internal emails being send to myself (logging reports etc) as spam due to rspamd rules.
I have solved this by adding internal networks to a rspamd whitelist.
The whitelist gives the network -9 points and that works well here.

Description

I have added two files to whitelist an internal network like so

vi /var/lib/docker/volumes/mailserver_Tconfig/_data/wh-ip.map
## a map file
192.168.0.0/24 # local network


local.d/multipmap.conf
vi /var/lib/docker/volumes/mailserver_Tconfig/_data/multimap.conf
IP_WHITELIST {
  type = "ip"; 
  map = "$LOCAL_CONFDIR/local.d/wh-ip.map";
  prefilter = true;
  action = "accept";
}


add to user-patches.sh
vi /var/lib/docker/volumes/mailserver_Tconfig/_data/user-patches.sh

# whitelist local networks
cp /tmp/docker-mailserver/multimap.conf etc/rspamd/local.d/
cp /tmp/docker-mailserver/wh-ip.map etc/rspamd/local.d/

Alternatives

non, this is the way (for rpamd as far as I could find)

see also https://github.com/moisseev/rspamd-multimap-bl/blob/master/local.d/multimap.conf
and https://rspamd.com/doc/modules/multimap.html

Applicable Users

to whomever wants to whitelist networks or other things in rspamd

Are you going to implement it?

Yes, because I know the probability of someone else doing it is low and I can learn from it.

What are you going to contribute?

see above for the solution. I am using it

[polarathene]

I've raised this to @georglauterbach before to consider PERMIT_DOCKER to configure rspamd like it does for opendkim/opendmarc. That would be the proper way to support it.

Your approach with a .map file is good, similar to what I've encouraged for Postfix to switch to with a CIDR table map (where it's easier for it to support IPv6 and IPv4 then the current approach).

PERMIT_DOCKER is planned for a refactor as it has some flaws in the current implementation. Everything is laid out there. There's an alternative proposal by @georglauterbach I just haven't had time to go over that but can probably discuss it once other higher priority items are resolved such as the Debian Bookworm upgrade PR.

In the meantime, a more direct fix could be considered. I'm not really in support of adding subnets by default when they imply trust as that conflicts with PERMIT_DOCKER=none default, which is to prevent IPv6 routing to IPv4 only containers rewriting remote source IP (due to userland-proxy: true in /etc/docker/daemon.json) to the docker network gateway IP, thus trusting remote connections as from the trusted subnet...

[polarathene]

192.168.0.0/24 # local network

192.168.0.0/16 is the private range IP range reserved, while Docker will split this specific block into smaller /20 subnets (4096 range, although bridge networks will hit limits over 1,000 IPs bridged), not /24 (254 IPv4 addresses IIRC, 2-3 per IPv4 network are not assignable).

[georglauterbach]

I have a broken dev machine ATM, so #3804 takes precedence for me now. I will work on this once #3804 is resolved.

[peterhirn]

Hardcoding a specific ip range in the default config is probably not a good idea. I'm sure I'm not the only one running dms with a custom bridge/network config.

networks:
  network:
    driver: bridge
    driver_opts:
      com.docker.network.bridge.name: bridge-mail
    enable_ipv6: true
    ipam:
      config:
        - subnet: 10.10.0.0/24
        - subnet: fd10::/64

If I use spf with rspamd it results in internal emails being send to myself (logging reports etc) as spam due to rspamd rules.

Can you elaborate on how these emails are created/sent (ie. tools, hosts, containers, domains, etc.)?

[williamdes]

I am also using a custom IP range
https://github.com/wdes/mails.wdes.eu/blob/dfefb2ca9e70aa59409180b583e334c42fc60356/docker-compose.yml#L295

I order to have a custom DNS server running and resolving stuff

[georglauterbach]

I will look at this next. Implementation seems to be straight-forward. We can utilize the logic from PERMIT_DOCKER to create the map file and refer to it via multimap.conf as @hanscees showed. When #3820 is merged, I can start implementing this.

[hanscees]

Hardcoding a specific ip range in the default config is probably not a good idea. I'm sure I'm not the only one running dms with a custom bridge/network config.

networks:
  network:
    driver: bridge
    driver_opts:
      com.docker.network.bridge.name: bridge-mail
    enable_ipv6: true
    ipam:
      config:
        - subnet: 10.10.0.0/24
        - subnet: fd10::/64

If I use spf with rspamd it results in internal emails being send to myself (logging reports etc) as spam due to rspamd rules.

Can you elaborate on how these emails are created/sent (ie. tools, hosts, containers, domains, etc.)?

I do not want to propose whitelisting private networks by default. I merely pointing out that rspamd has a mechanism to whitelist networks.
My proposal would be that DMS implements a anti-spam network whitelist variable. And if a user adds a networks to it, those networks are added to this whitelist map.

In my case we have a number of servers in the local network at 192.168.0.0/ These servers send emails to the central email server DMS based. Because these servers use an intermal MTA (they are linux), and these MTA's do not use dmarc and spf and what not, the emails are marked as spam by rspamd spf rules.

X-Rspamd-Queue-Id: 412B760047
X-Rspamd-Action: rewrite subject
X-Spamd-Result: default: False [7.18 / 11.00];
	R_SPF_FAIL(4.50)[-all];
	VIOLATED_DIRECT_SPF(3.50)[];
	R_DKIM_ALLOW(-1.00)[hanscees.com:s=mail];
	DMARC_NA(1.00)[hanscees.com];
	NEURAL_HALF_DAY_HAM(-0.86)[-0.862];
	ONCE_RECEIVED(0.10)[];
	RCVD_NO_TLS_LAST(0.10)[];
	MIME_GOOD(-0.10)[text/plain];
	BAYES_HAM(-0.06)[61.08%];
	ARC_NA(0.00)[];
	RCVD_COUNT_ONE(0.00)[1];
	MIME_TRACE(0.00)[0:+];
	FROM_NO_DN(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MISSING_XM_UA(0.00)[];
	TO_DN_NONE(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	GREYLIST(0.00)[pass,meta];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	DKIM_TRACE(0.00)[hanscees.com:+]

There are multiple way to approach this, but I would like a variable for sure in ENV .

[georglauterbach]

I'm struggling with the idea of an ENV. I'd recommend using the override.d/ functionality that DMS already offers and set local_networks. On the other hand, I never liked the way PERMIT_DOCKER is implemented to be honest. Having an explicit ENV with networks might be good in order to set it in all places.

[peterhirn]

My proposal would be that DMS implements a anti-spam network whitelist variable. And if a user adds a networks to it, those networks are added to this whitelist map.

Right, makes sense as configurable value. I didn't realize that reading the initial comment 😁

In my case we have a number of servers in the local network at 192.168.0.0/ These servers send emails to the central email server DMS based. Because these servers use an intermal MTA (they are linux), and these MTA's do not use dmarc and spf and what not, the emails are marked as spam by rspamd spf rules.

For these setups I've been using postfix configured as satellite with a (opt. external) service account. The required config and resource usage is minimal.

[polarathene]

Hardcoding a specific ip range in the default config is probably not a good idea. I'm sure I'm not the only one running dms with a custom bridge/network config.

It is proposed to integrate using the PERMIT_DOCKER ENV feature we provide. Or in the meantime for a user to provide a separate config file and document that is adequate.

PERMIT_DOCKER needs a refactor, but the functionality intended for one of it's settings related to this is to identify networks connected to the container and trust those entire subnets. Presently it doesn't do this well.

The feature would likely be adapted (separate feature work) to also support providing your own IP address list / subnets for trust, and updating the various services related configs.

On the other hand, I never liked the way PERMIT_DOCKER is implemented to be honest.

For the types of changes it's meant to support it seems fine.

Having an explicit ENV with networks might be good in order to set it in all places.

I'm reluctant towards heavy reliance on ENV (not just this request but in general), config files exist for a reason and often the justification for ENV is convenience to avoid creating files.

If all the ENV serves is storing a config to store elsewhere by creating a file or swapping a setting, I'd like a good reason a config file or override (like postfix-main.cf) isn't as viable.

When an ENV is more like an enum, such as PERMIT_DOCKER this is acceptable. DMS is actually using ENV in a way to provide proper convenience for that sort of task.

---

If I use spf with rspamd it results in internal emails being send to myself (logging reports etc) as spam due to rspamd rules.

Can you elaborate on how these emails are created/sent (ie. tools, hosts, containers, domains, etc.)?

This is due to implementation of rspamd. It is configured as a Postfix milter by updating main.cf:

docker-mailserver/target/scripts/startup/setup.d/security/rspamd.sh

Lines 147 to 155 in ed1e1eb

	# Adjust Postfix's configuration files. We only need to append Rspamd at the end of
	# `smtpd_milters` in `/etc/postfix/main.cf`.
	function __rspamd__setup_postfix() {
	__rspamd__log 'debug' "Adjusting Postfix's configuration"
	postconf 'rspamd_milter = inet:localhost:11332'
	# shellcheck disable=SC2016
	_add_to_or_update_postfix_main 'smtpd_milters' '$rspamd_milter'
	}

Milters will process mail before they're added to the postfix queue, potentially rejecting the mail, etc. A bit different from Amavis + SpamAssassin which is configured as a content filter, which waits until mail is queued, redirects it and processes, then sends it back to Postfix to process and deliver again.

Regardless of spam solution however both are running not only on port 25, but also submission ports 587 and 465. I actually thought Amavis was configured to not apply there, but I guess there are valid use-cases where you'd still want anti-spam/anti-virus filtering handled on the submission(s) ports (prevent malware spread internally within an organization).

So trusting networks/clients can work. There are other ways to have rules based on sender address / domain, or just opt-out on the entire service port, but that's more involved to handle.

[hanscees]

I must really be careful and precise when communicating with developers. For me a variable and env are meant generally and loosely, but for you they are different and specific things.

So lets try that.

I do not care if the DMS admin uses and ENV of config file. I just want a way to configure functionality and do not have enough insight on the inner workings of those.

So I would like a way to configure:

1. networks that are trusted: this means they are open to email relaying: emails can be send from them to the MTA to the internet.
2. networks that are not spam-checked.

These two can be different networks in practice. So the configuration cannot be the same variable.

I would like to be able to configure in some way:
A. network 192.168.0.0/24 does not need to be checked for spam
B. network 192.168.0.0/24 can relay, and 10.0.0.0/16 too
C. and presumably A also means a fail2ban whitelist. That means if I mistakenly use a wrong password it doesnt lock me out. Of course you can argue if that is wise: in my small home it is imho.

So we need more different items, you cant just use internal_networks for all three and have the same functionality

Hope that makes sense.
So if the documentation mentions you can whitelist a network from spam-checking by using an override file, thats fine with me. But that doesnt address B and C.

[polarathene]

So if the documentation mentions you can whitelist a network from spam-checking by using an override file, thats fine with me. But that doesnt address B and C.

Your fastest route to what you want is identifying the network trust or related config settings for each service, what format they expect and providing those manually.

If you're not comfortable with that because of a lack of familiarity with anything in DMS, you can ask us, otherwise for us the next fastest route that meets your needs is to add a docs page with that same information and guidance.

PERMIT_DOCKER meets most needs when it comes to trust (but needs to be refactored), except for the fact that it's trust through all services it configures, not selective.

Avoiding spam could be done by subnet, or probably also by port such as the submission(s) ports 587 and 465 where opt-out there is more relevant. For Amavis+SpamAssassin it's a simple opt-out, but rspamd is mixed in with the other milters AFAIK, we could treat with custom settings in Postfix main.cf like we do for MUA restrictions with SPOOF_PROTECTION=1 which should work well.

Getting more specific config support into DMS as you want is going to depend on someone putting the time into it, and getting it through review. I have other priorities right now that I've been putting off for weeks, so I'm not available for this. Just providing guidance for anyone that would tackle it.

[georglauterbach]

@polarathene what do you reckon on how we should proceed here? An additional ENV like TRUSTED_NETWORKS is one option, but it would intersect with PERMIT_DOCKER (whose naming is unfortunate by now, including "DOCKER`").

The OP of this issue could also use custom-command.conf for Rspamd with content:

set-common-option local_addrs "192.168.0.0/16"

This is a solution for Rspamd only, though. Ideally, we should configure all services through one centralized option. #3478 is related here.

If you ask me, we could

1. extend PERMIT_DOCKER
2. replace with something like TRUSTED_NETWORKS which works similar to PERMIT_DOCKER but allows users to insert networks manually

[polarathene]

@polarathene what do you reckon on how we should proceed here? An additional ENV like TRUSTED_NETWORKS is one option, but it would intersect with PERMIT_DOCKER (whose naming is unfortunate by now, including "DOCKER`").

If you ask me, we could

1. extend PERMIT_DOCKER
2. replace with something like TRUSTED_NETWORKS which works similar to PERMIT_DOCKER but allows users to insert networks manually

I have very low bandwidth available right now to provide much input on this.

• If the feature is something of clear value and not difficult to implement and maintain, go ahead 👍
• It should be more meaningful however than a small user-patches.sh script or ENV that copies a value. Especially if we have existing solutions for config updates (postfix-main.cf / postfix-master.cf, custom-command.conf). We tend to defer to docs guidance.
• In this case, the intent is to configure multiple services (or only a subset IIRC, which is adding complexity to be flexible) with their equivalent setting but varied formats. That can be worthwhile for DMS to support depending on context.

---

Personally, I'd have an easier time when I can go over pragmatic use-cases and the manual config updates required to support those, with justification for why DMS should add another feature.

From the above comment use-case, all I see is the existing trusted clients (PERMIT_DOCKER) and the desire to separately allow spam opt-out.

So I would like a way to configure:

• networks that are trusted: this means they are open to email relaying: emails can be send from them to the MTA to the internet.
• networks that are not spam-checked.

I would like to be able to configure in some way:

• A. network 192.168.0.0/24 does not need to be checked for spam
• B. network 192.168.0.0/24 can relay, and 10.0.0.0/16 too
• C. and presumably A also means a fail2ban whitelist

So we need more different items, you cant just use internal_networks for all three and have the same functionality

This only highlights the A request to opt-out of the spam check, while also requesting that trusted networks are exempt from Fail2Ban.

My question is what is 10.0.0.0/16 doing differently that it should still be spam checked but trusted everywhere else?

• This context was not provided.
• Otherwise we could just toggle the anti-spam functionality on submission(s) in Postfix and that can easily be supported via postfix-master.cf and a main.cf change by us.

I can get behind anti-spam only on port 25, but would like more context for the separate subnet toggle.

[georglauterbach]

I have very low bandwidth available right now to provide much input on this.

If the feature is something of clear value and not difficult to implement and maintain, go ahead 👍

• It should be more meaningful however than a small user-patches.sh script or ENV that copies a value. Especially if we have existing solutions for config updates (postfix-main.cf / postfix-master.cf, custom-command.conf). We tend to defer to docs guidance.
• In this case, the intent is to configure multiple services (or only a subset IIRC, which is adding complexity to be flexible) with their equivalent setting but varied formats. That can be worthwhile for DMS to support depending on context.

---

Personally, I'd have an easier time when I can go over pragmatic use-cases and the manual config updates required to support those, with justification for why DMS should add another feature.

I agree. We should only provide basic configuration options and leave advanced configurations (like you referred to above) to our users. My intention here is to

1. fix PERMIT_DOCKER's implementation;
2. extend it so users can additionally add custom networks.

I proposed an implementation in #3478 (comment); I don't need to you to go over it now, you're low on time already. I just want to clarify whether we're on the same page here to avoid me starting to really work on that only for it to be rejected at a later point because we haven't talked about it enough.

---

My proposal, in short: replace PERMIT_DOCKER with TRUSTED_NETWORKS_IPV4 (and later _IPV6) where TRUSTED_NETWORKS_IPV4 does not take a single value but "an array" (delimiter-separated string with value) that can easily be parsed. This allows the implementation to take the same values as PERMIT_DOCKER but also new values, in the form of IPv4 networks in CIDR notation.

[polarathene]

I just want to clarify whether we're on the same page here to avoid me starting to really work on that only for it to be rejected at a later point because we haven't talked about it enough

As mentioned in the other issue. If others see value in it, especially maintainers then I won't block on that 👍

[williamdes]

My proposal, in short: replace PERMIT_DOCKER with TRUSTED_NETWORKS_IPV4 (and later _IPV6) where TRUSTED_NETWORKS_IPV4 does not take a single value but "an array" (delimiter-separated string with value) that can easily be parsed. This allows the implementation to take the same values as PERMIT_DOCKER but also new values, in the form of IPv4 networks in CIDR notation.

Sounds like a good plan !

---

off topic

I had a very bad issue with this, maybe it's a bug more global. Let me explain

• Have a public IPv6 on the MX record
• Have no permit docker ENV
• The email will be received by the gateway IP of docker
• SPF check will fail, email rejected
• Then add this PERMIT_DOCKER env, it will skip the hop and process the checks normally

Conclusion: custom whitelisting is important

Patch (this is probably equivalent to PERMIT_DOCKER=container/network):
I can not use PERMIT_DOCKER=network because my CIDR is /28.

echo "Allow this network (${CONTAINER_NETWORK_V4})"

source /usr/local/bin/helpers/log.sh
source /usr/local/bin/helpers/utils.sh

# Copied from /usr/local/bin/setup.d/networking.sh since it is wrapped into another function
__add_to_postfix_mynetworks() {
	local NETWORK_TYPE=$1
	local NETWORK=$2

	_log 'trace' "Adding ${NETWORK_TYPE} (${NETWORK}) to Postfix 'main.cf:mynetworks'"
	_adjust_mtime_for_postfix_maincf
	postconf "$(postconf | grep '^mynetworks =') ${NETWORK}"
	[[ ${ENABLE_OPENDMARC} -eq 1 ]] && echo "${NETWORK}" >>/etc/opendmarc/ignore.hosts
	[[ ${ENABLE_OPENDKIM} -eq 1 ]] && echo "${NETWORK}" >>/etc/opendkim/TrustedHosts
}

# Custom ENV: CONTAINER_NETWORK_V4
__add_to_postfix_mynetworks 'Container network' "${CONTAINER_NETWORK_V4}"

[polarathene]

PERMIT_DOCKER=network as per #3478 (comment) notes that it's hard-coded to a wide private range rather than the actual subnet, and does not cover additional private ranges used by Docker.

Have no permit docker ENV

Assuming you mean the default PERMIT_DOCKER=none is used then.

Then add this PERMIT_DOCKER env, it will skip the hop and process the checks normally

While here you are referring to your modified approach?

---

PERMIT_DOCKER=connected-networks

If your network is visible to the Docker container and you don't need to restrict only to this /28 subnet but any network interface DMS belongs to, you can use PERMIT_DOCKER=connected-networks. That mode does not enforce any CIDR:

#!/bin/bash

function _mask_ip_digit() {
  if [[ ${1} -ge 8 ]]; then
    MASK=255
  elif [[ ${1} -le 0 ]]; then
    MASK=0
  else
    VALUES=(0 128 192 224 240 248 252 254 255)
    MASK=${VALUES[${1}]}
  fi

  local DVAL=${2}
  ((DVAL&=MASK))

  echo "${DVAL}"
}

# Transforms a specific IP with CIDR suffix
# like 1.2.3.4/16 to subnet with cidr suffix
# like 1.2.0.0/16.
# Assumes correct IP and subnet are provided.
function _sanitize_ipv4_to_subnet_cidr() {
  local DIGIT_PREFIX_LENGTH="${1#*/}"

  declare -a MASKED_DIGITS DIGITS
  IFS='.' ; read -r -a DIGITS < <(echo "${1%%/*}") ; unset IFS

  for ((i = 0 ; i < 4 ; i++)); do
    MASKED_DIGITS[i]=$(_mask_ip_digit "${DIGIT_PREFIX_LENGTH}" "${DIGITS[i]}")
    DIGIT_PREFIX_LENGTH=$((DIGIT_PREFIX_LENGTH - 8))
  done

  echo "${MASKED_DIGITS[0]}.${MASKED_DIGITS[1]}.${MASKED_DIGITS[2]}.${MASKED_DIGITS[3]}/${1#*/}"
}

# Everything above is the helper script network.sh:
# https://github.com/docker-mailserver/docker-mailserver/blob/a815bf5ab44388baecb597a0b83f71872a2d34bc/target/scripts/helpers/network.sh

function connected_networks() {
  local CONTAINER_IP CONTAINER_NETWORK

  unset CONTAINER_NETWORKS
  declare -a CONTAINER_NETWORKS

  # Set earlier via separate script:
  NETWORK_INTERFACE="eth0"

  # Gets the IP for the eth0 interface, requires the iproute2 package for ip command:
  # This should be your IPv4 address, in your case probably the /28 assigned to the container.
  # NOTE: Both of these vars are only relevant to `container` and `host` modes respectufully.
  CONTAINER_IP=$(ip addr show "${NETWORK_INTERFACE}" | grep 'inet ' | sed 's|[^0-9\.\/]*||g' | cut -d '/' -f 1)
  CONTAINER_NETWORK=$(echo "${CONTAINER_IP}" | cut -d '.' -f1-2).0.0

  # Connected Networks feature then collects all subnets from known interfaces, such as loopback (127.0.0.1/8)
  # NOTE: This would include the above NETWORK_INTERFACE too.
  while read -r IP; do
    CONTAINER_NETWORKS+=("${IP}")
  done < <(ip -o -4 addr show type veth | grep -E -o '[0-9\.]+/[0-9]+')

  # Example of /28 inserted as if we had that on an interface:
  CONTAINER_NETWORKS+=("172.16.1.2/28")

  # Connected Networks logic to then iterate over the networks, sanitize and add to configs:
  for CONTAINER_NETWORK in "${CONTAINER_NETWORKS[@]}"; do
    CONTAINER_NETWORK=$(_sanitize_ipv4_to_subnet_cidr "${CONTAINER_NETWORK}")
    #__add_to_postfix_mynetworks 'Docker Network' "${CONTAINER_NETWORK}"
    echo "CIDR: ${CONTAINER_NETWORK}"
  done
}

connected_networks

Outputs:

CIDR: 127.0.0.0/8
CIDR: 172.17.0.0/16
CIDR: 172.16.1.0/28

Provided you have NETWORK_INTERFACE as the correct interface to query, you'll get the container (CONTAINER_IP) or host (CONTAINER_NETWORK) modes configured with that IP:

docker-mailserver/target/scripts/startup/setup.d/networking.sh

Lines 57 to 63 in f28fce9

	( 'container' )
	__add_to_postfix_mynetworks 'Container IP address' "${CONTAINER_IP}/32"
	;;
	( 'host' )
	__add_to_postfix_mynetworks 'Host Network' "${CONTAINER_NETWORK}/16"
	;;

Those are not relevant to you because they have the fixed CIDR of /32 or /16 appended.

connected-networks mode, as shown above would collect all known subnets instead:

docker-mailserver/target/scripts/startup/setup.d/networking.sh

Lines 50 to 55 in f28fce9

	( 'connected-networks' )
	for CONTAINER_NETWORK in "${CONTAINER_NETWORKS[@]}"; do
	CONTAINER_NETWORK=$(_sanitize_ipv4_to_subnet_cidr "${CONTAINER_NETWORK}")
	__add_to_postfix_mynetworks 'Docker Network' "${CONTAINER_NETWORK}"
	done
	;;

Which only really leaves network which ignores all that for the fixed subnet:

docker-mailserver/target/scripts/startup/setup.d/networking.sh

Lines 65 to 67 in f28fce9

	( 'network' )
	__add_to_postfix_mynetworks 'Docker IPv4 Subnet' '172.16.0.0/12'
	;;

---

That is all covered in the tracking issue as known bugs: #3478

You just need the fix I had suggested which doesn't assume the fixed subnet for network. If you want to use that network interface, I can't think of much reason that it should be contained within a larger subnet range like it is currently. It should replace network and host for new option subnet, while container can still lock to the single IP.

---

Actual issue:

Have a public IPv6 on the MX record
The email will be received by the gateway IP of docker

You have this arriving through your /28 via the gateway IP yes? That is bad, fix that.

• Follow our IPv6 docs and grant the container IPv6 address too, or disable the ability for IPv6 to route to the container. This will allow external connections directly connecting to DMS published ports to keep the client IP correct, like it is with IPv4.
• If you have a proxy inbetween, follow the advice of our PROXY protocol docs (_updated in v14 / edge docs). This will allow you to keep the correct client IP when it internally connects to DMS.

At least this is what I get from your description that it's an XY problem.

You do not want to use PERMIT_DOCKER as a fix for traffic arriving through the docker network gateway IP, as that enables open relay IIRC. While you may be the trusted client on the other side, if you're trusting an entire subnet for a docker network DMS belongs to, you open up that vulnerability.

For trusting a specific external client IP, you shouldn't need a CIDR at all, and just provide the static IP explicitly.

[polarathene]

You have this arriving through your /28 via the gateway IP yes? That is bad, fix that.

That's not really bad, it's the result of ipv6 to ipv4 from Docker i guess.

IPv6 to IPv4 losing proper client IP is bad when an IP unrelated to the private network DMS is connected thinks the client IP is also from that (the gateway IP).

It means anyone that connects to your DMS instance this way via IPv6 can bypass the trust in the same way. Why would you want that? I have told you how to prevent it as it's a security vulnerability.

But I have to ignore this address or checks fail thinking it was not an internal ip.

Need more context. Why is an internal service of yours going through IPv6 MX record to the Docker host of DMS?

For trusting a specific external client IP, you shouldn't need a CIDR at all, and just provide the static IP explicitly.

I agree, maybe I should use =host

No.. As per above host is /16, proper fix is to use associated subnet CIDR of the interface the DMS IP is associated to.

---

Follow our IPv6 docs and grant the container IPv6 address too, or disable the ability for IPv6 to route to the container. This will allow external connections directly connecting to DMS published ports to keep the client IP correct, like it is with IPv4.

Yeah and it broke my server, had to revert ipv6 support for Docker 😢
6 to 4 works good, I doubt having a working setup any time soon
See: revert of IPv6 for Docker: wdes/mails.wdes.eu@ee8cc46

Your referenced commit doesn't say why you reverted.

DMS was crashed once because of my IPv6 range whitelist format that was wrong: wdes/mails.wdes.eu@61f9e20

But after that some services in DMS still where not happy, hence the revert.

Likewise lacking context. I can only see you doing some custom things there. You perhaps configure wrong?

If you don't use IPv6 on DMS why have MX records resolve IPv6?

• Use separate A record for DMS instead of sharing it (mail.example.com).
• You can still have email for @example.com have MX record point to mail.example.com with only IPv4.

If you have Fail2Ban active, then just need to perform failed logins via IPv6 to trigger ban on gateway IP, then no IPv6 connections accepted.

[github-actions]

This issue has become stale because it has been open for 20 days without activity.
This issue will be closed in 10 days automatically unless:

• a maintainer removes the meta/stale label or adds the stale-bot/ignore label
• new activity occurs, such as a new comment