PERMIT_DOCKER=none doesn't appear to enforce authentication when running a rootless container?

[StandingPadAnimations]

Hey y'all, I've had some issues recently with my Podman Quadlets setup where I've been receiving random emails from my own server... so I checked for an open relay (just basic telnet to port 25 on my mailserver). I found that, despite setting PERMIT_DOCKER to none in my mailserver.env file, I was still able to connect over telnet without authenticating, and still send messages (albeit denied by the spam filter). I've also tested setting PERMIT_DOCKER in my quadlet file directly, and the issue stll persisted.

For context, I'm running Ubuntu 24.04 (so still Podman 4), with the network driver set to pasta. I'm using the latest release of DMS as well.

[polarathene]

I think more information would need to be provided to reproduce. It is unclear why the information provided below wouldn't apply.

Ensure that the container is properly recreated (not just restarted) if you're changing settings and want to ensure that they're correctly applied. When changing ENV this should imply a new container is setup, but you may need to verify that's the case when that ENV is provided via a .env file.

In this case PERMIT_DOCKER=none is already the default. Within the container the env command should also show the ENV is set (bash shell), or you can see the ENV that DMS has resolved (with defaults) stored at /etc/dms-settings.

Additionally:

• You want to check the mynetworks Postfix setting (stored in /etc/postfix/main.cf, should be able to query with postconf mynetworks). For PERMIT_DOCKER=none this value should be empty.
• Using the container logs, a connecting client IP should be logged as a valid client IP, not a private/internal IP when a connection from the public net is made to DMS. Some network setups with containers fail to propagate the correct source IP and instead it appears to DMS as either an internal network gateway IP or the loopback address, that issue would cause various mishaps if not addressed.

---

I was still able to connect over telnet without authenticating, and still send messages (albeit denied by the spam filter)

Just to clarify.

Port 25 should allow accepting mail without authentication, but it forbids relaying. Only mail for a mail domain DMS knows about will be accepted for delivering locally or forwarding.

Ports 587/465 are submission ports to send mail internally or outbound, which will allow you to send with whatever sender address you choose (it will be rejected if you are not actually authorized by DNS), and to whatever recipient address you choose.

---

Podman support is best effort by community, and our Quadlet config advice I think has only had a first pass and may be incomplete.

As for PERMIT_DOCKER, we have a detailed issue on this feature and work that needs to be done.

PERMIT_DOCKER=none (the default) should not be enabling DMS as an Open Relay however:

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

Lines 45 to 48 in cb76075

	case "${PERMIT_DOCKER}" in
	( 'none' )
	__clear_postfix_mynetworks
	;;

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

Lines 29 to 32 in cb76075

	function __clear_postfix_mynetworks() {
	_log 'trace' "Clearing Postfix's 'mynetworks'"
	postconf "mynetworks ="
	}

As you can see the logic will ensure that mynetworks is unset, so there is no implicit trust even when you have misconfigured environment that fails to propagate the real client IP (and instead appears in your own private subnets or as 127.0.0.1).

For other settings the interface does need to get detected correctly, but as the linked issue on the feature notes, some of the current settings don't really cover IP ranges as expected (with some assumptions based on Docker network defaults):

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

Lines 16 to 27 in cb76075

	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
	if [[ -z ${CONTAINER_IP} ]]; then
	_log 'error' 'Detecting the container IP address failed'
	_dms_panic__misconfigured 'NETWORK_INTERFACE' 'Network Setup [docker_permit]'
	fi
	while read -r IP; do
	CONTAINER_NETWORKS+=("${IP}")
	done < <(ip -o -4 addr show type veth | grep -E -o '[0-9\.]+/[0-9]+')

---

DMS does have the following policy set for Postfix restrictions, permit_networks is one that will skip further security checks when the connecting IP is matched to mynetworks for example, while permit_sasl_authenticated is for authenticated users:

docker-mailserver/target/postfix/main.cf

Lines 55 to 59 in cb76075

	smtpd_helo_restrictions = permit_mynetworks, reject_invalid_helo_hostname, permit
	smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
	smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_recipient_domain
	smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
	smtpd_sender_restrictions = $dms_smtpd_sender_restrictions

docker-mailserver/target/postfix/main.cf

Lines 70 to 75 in cb76075

	# Custom defined parameters for DMS:
	# Custom sender restrictions overview: https://github.com/docker-mailserver/docker-mailserver/pull/4379#issuecomment-2670365917
	# `reject_unknown_sender_domain`: https://github.com/docker-mailserver/docker-mailserver/issues/3716#issuecomment-1868033234
	dms_smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unknown_sender_domain
	# `SPOOF_PROTECTION=1` support requires prepending `reject_authenticated_sender_login_mismatch`
	mua_sender_restrictions = reject_authenticated_sender_login_mismatch, $dms_smtpd_sender_restrictions

[StandingPadAnimations]

Testing again (I recently updated my server to Ubuntu 26.04, which now comes with Podman 5.7), it appears the server now enforces authentication (for sending mail) through port 25. Not sure why the issue resolved itself. For some context though:

• PERMIT_DOCKER appears to be set correctly in the container environment

root@mail:/# env | grep "PERMIT_DOCKER"
PERMIT_DOCKER=none

• No networks are populated for Postfix

root@mail:/# postconf mynetworks
mynetworks =

[polarathene]

Not sure why the issue resolved itself.

Probably due to a breaking change in Podman 5.x compared to 4.x series? Default network driver might have been resolved, or I'm pretty sure there was quite a bit of work on Quadlets which you mentioned using, so possibly resolved a variety of bugs too.

Great that the issue is resolved now :)