Docker-mailserver: SPF fail - not authorized

[Rajh]

I restarted my mailserver and now I can't recieve emails anymore.
Keep getting this error :
mailserver | May 20 20:06:49 emails postfix/smtpd[1044]: NOQUEUE: reject: RCPT from unknown[172.21.0.1]: 550 5.7.1 : Recipient address rejected: Message rejected due to: SPF fail - not authorized. Please see http://www.openspf.net/Why?s=helo;id=eur01-db5-obe.outbound.protection.outlook.com;ip=172.21.0.1;r=XXXXXXX; from= to= proto=ESMTP helo=

Is it possible to disable SPF ?
How is this supposed to work with docker ?

[tuxpowered]

I found that SPF fails when using postfix aliasing to forward messages, (I use this a lot)
The issue is a technical limitation imposed by SPF. Specifically if you are forwarding mail using Postfix ALIAS function Postfix does not touch or modify the message envelope at all. So the results is the message from say [email protected] looks like it is being sent from my-kickass-domain.com. When the _receiving_ side does an SPF lookup for @aol.com it sees that email from my-kickass-domain.com is not allowed, and you get this message.

BUT WAIT THERE ARE SOLUTIONS

There are essentially 2 ways to still forward, you could use the basic sieve support, though I do not personally like this method, it works, because the forwarding is not done by postfix but by dovecot, and as a result, the envelope gets rewritten, so this looks like it comes from your local account.
I personally find this more difficult to setup, and worse from an administrative point it is more complex to maintain and trouble shot.

Enter SRS, (Sender Rewrite Service), this service will allow you to use your postfix aliases (beautiful for us admins not wanting to maintain mailboxes individually). It works by using a standardized rewrite schema to the envelope so that bounce backs still work, and so that [email protected], looks like it comes from my-kickass-domain.com, but is received by the other side as [email protected].
This is the method I recommend.

Unfortunately this is not built into this docker, and I was thinking of forking to add it, but it is pretty straight forward to add yourself.

https://github.com/roehling/postsrsd

You will need to install cmake to compile, but aside from that it is pretty straight forward.
Modify your postfix/main.cf with the included directives and restart your docker container.

Email will pass the SPF filtering because it will be coming from "YOUR" domain.

Hope that helps, it helped me just last week.

[ConorIA]

I've been having emails rejected frequently. Emails from important places too: my University (Office365), my internet service provider, the property management company of my apartment. They are being forwarded form the docker gateway (172.20.0.1), which is obviously not authorized to send the emails from the sender addresses. I can't seem to figure my way around it.

[ConorIA]

Related issues:

• https://github.com/moby/moby/issues/15086
• https://github.com/hardware/mailserver/issues/43

SPF should really be optional until the issue is resolved.

[tomav]

In the meantime, you can downgrade to another exiting version or choose a commit (+ rebuild yourself).
2 options might interesting:

• dive into @tuxpowered proposal
• and/or add an ENV to enable/disable SPF

[arneke]

This one bit me pretty hard, but now I am not 100% sure I can reproduce it.

I don't know much about the SPF implementation in Postfix, but looking at the configuration it appears to be part of smtpd_recipient_restrictions , so then it should be possible to disable this by redefining that setting in config/postfix-main.cf ? (In case anyone else is looking for short term workaround)

~Wondering though, permit_mynetworks precedes check_policy_service unix:private/policyd-spf. So then PERMIT_DOCKER=network in docker-compose.yml may do the trick, with minimal consequences for those that can trust the surrounding containers ?~
Edit: It gets rid of the spf problem, but afaict it disables all the other checks as well

[tuxpowered]

Seems this is still an issue for some, here has been my solution I spoke about above, a little copy and paste.

After your container is up, log in to the container

docker exec -ti mail /bin/bash

Next execute the following:

apt-get -y update && apt-get -y install postsrsd \
&& echo -e "\n# Added postSRSd rules to process spf mail forwarding." >> /etc/postfix/main.cf \
&& postconf -e sender_canonical_maps=tcp:localhost:10001 \
&& postconf -e sender_canonical_classes=envelope_sender \
&& postconf -e recipient_canonical_maps=tcp:localhost:10002 \
&& postconf -e recipient_canonical_classes=envelope_recipient,header_recipient \
&& service postsrsd restart \
&& postfix reload 

That will update your app repo, install postsrsd, and add the configuraiton lines.
You should now be able to forward messages with SPF still enabled.

The docker container uses supervisord to start services, so the default sysv startup will not auto start on a reboot, run the following to update supervisor-app.conf and your changes should survive a restart

cat << EOF >> /etc/supervisor/conf.d/supervisor-app.conf

[program:postsrsd]
startsecs=0
autostart=true
autorestart=true
stdout_logfile=/var/log/supervisor/%(program_name)s.log
stderr_logfile=/var/log/supervisor/%(program_name)s.log
command=/etc/init.d/postsrsd start
EOF

@tomav perhaps this should be enabled in the default build esp if spf is on by default? If so I could create a pull and patch the setup script.

[johansmitsnl]

@tuxpowered could you create a PR for your fix?

[Steiniche]

I tried @tuxpowered's solution but it did not work for me.
However, I found the environment option PERMIT_DOCKER: https://github.com/tomav/docker-mailserver#permit_docker
When set to host my SPF fail disapeared.

[johansmitsnl]

Is it solved and can it be closed?
If it is solved please share what the issue was and how to solve it.

[pudo]

I'm having the same issue setting up a simple Gmail forward from a local mail server. Would really appreciate @tuxpowered's solution getting merged, since SRS is Google's recommended approach to doing mail forwards.

[Steiniche]

@pudo however @tuxpowered solution did not resolve my problem so I do not think this is the one fix to rule them all.
For me it was the PERMIT_DOCKER=host option that did the trick.

[pudo]

@Steiniche I don't understand how this is related at all, could you kindly explain? My problem is that when I forward email to a Gmail account I end up with SPF softfails and temporary bans on my IP because the signature of my mail server does not match the From: fields of the forwarded messages. How does this relate to the docker host name?

[Steiniche]

The original issue was about receiving emails not sending them.
Thats where my issue arose as well and by using PERMIT_DOCKER=host it was possible.
I got the same error as @Rajh.

However, if the solution purposed by @tuxpowered fixes the forward error you are having I think you should create a pull request with the fix to main.cf :

# Added postSRSd rules to process spf mail forwarding.
sender_canonical_maps=tcp:localhost:10001
sender_canonical_classes=envelope_sender
recipient_canonical_maps=tcp:localhost:10002
recipient_canonical_classes=envelope_recipient,header_recipient

[johansmitsnl]

Someone wants to create a PR for the solution @tuxpowered suggested?

[ericblade]

FWIW, I was completely unable to figure out a SPF line that actually worked for the situation that I have setup, so I ended up just disabling SPF. In postfix-main.cf, I remove the part of "smtpd_recipient_restrictions" that says " check_policy_service unix:private/policyd-spf," .. which worked for me. I really have absolutely no idea what I'm doing, though, so not sure if that's helpful to anyone or not.

[thiesschneider]

I have the same problem now. None of the above worked :/
Any tips?

[sereysethy]

@thiesschneider can you try PERMIT_DOCKER=host? how do you run your mail server using service (swarm) or docker-compose?

[thiesschneider]

hey @sereysethy, thx for your input. found the solution here: https://github.com/tomav/docker-mailserver/issues/844

[johansmitsnl]

@Rajh did this issue got solved with #814?

[ItsEcholot]

If using docker swarm you have to change the publishing port mode to host instead of ingress for port 25
After that it works perfectly so I think this issue got indeed solved with #814