(Discussion) Can we auto-detect open relays?

[micw]

In the mailu helm chart, I found several ways how people create an open relay. Some are just bad setups, others happens completely unexpected (e.g. one user had a broken CNI configuration in kubernetes). Others might come from a change to the environment even when mailu itself is untouched. In the mailu main repository, also some issues exists which discuss open relays.

I think, creating open relays is one of the bigges issues when running an MTA - even bigger than other security issues like outdated software since it affects way more people. So I'm thinking about how we could auto-detect if a running mailu application is an open relay or not.

I have read through many open relay issues. While it's possible to create open relays by bad postfix configuration, the most common situation is that mailu does not see the real IP where mail traffic is coming from so that external traffic is handled like local traffic.

So what is needed for a mailu installation to detect, that it's running as an open relay?

1st, mailu needs to know what internal IPs are. This is the case by default since it's part of the setup. 2nd, mailu would need an incoming request that comes from a known-to-be-external IP address. This could be achieved by an external service. 3rd, the request needs to be recorded and it's source IP as it is seen by the "front" service must be checked. And finally, some action must be taken when an open relay is detected. This could be a flag in mailu admin that prevents any mail to be received unless an admin verifies and fixes the setup.

What do you think about such a feature?

Kind regards, Michael.

[Diman0]

I think this would be a great feature. We have seen many people who incorrectly configured their deployment in the past that caused open relays. This would warn them very quickly that they should double check their configuration.

Even for people who know what they are doing, it would be handy to have such a feature that gives this extra thumbs up that you are not an open relay.

[micw]

I think we would need to host a service somewhere that can be used to perform such a check. Mailu admin calls that external service, telling it "please check me". The service calls an endpoint within mailu installation. The endpoint returns the external IP it sees. The service compares it with it's own IP and tells the result back to mailu.

Ideally, the request to mailu is done on one of the mail ports (imap, pop3 or SMTP) because for HTTP, keeping the original IP is usually handled well on higher protocol level.

So, how could we make nginx mail proxy tell, which IP it sees?

And how can we avoid that the service is abused for whatever?

[micw]

Just an idea. Nginx mail proxy asks the admin backend for auth, see https://docs.nginx.com/nginx/admin-guide/mail-proxy/mail-proxy/#mail_auth

So the backend react on special credentials and return the IP it sees as error message. The flow is then:

• Backend creates one-time credentials for the test
• Backend calls external service and passes these one-time credentials to it
• The service uses these credentials and tries to login on mailu smtp
• The backend recognizes the credentials and denies smtp access with some error message like "SMTP relay check IP=11.22.33.44"
• Service returns it's own IP and the IP the smtp backend returned
• Admin backend sees if the IPs matches (=no ip based open relay) or not (=potential open relay, especially if the IP is an internal IP)

[nextgens]

If all we care about is ip-based misconfiguration/open-relays, the test could be done locally. We can attach a new network interface to the smtp container, use a non-assigned IP space (say TEST-NET-1 : 192.0.2.0/24) and spoof packets to perform the test (with ncat for instance). If we get a "250 Ok" from postfix we have a problem.

[nextgens]

#1370 was already touching on this btw

[nextgens]

So we have discussed it recently on #mailu-dev and decided that this is not a problem we want to tackle.

The two common reasons for ending up with an open-relay are:

• setting SUBNET or RELAYNETS too wide (we could detect this by limiting their sizes)
• having a misconfigured proxy/NAT masquerading the source IP (we could detect these by inferring that if we only see a single IP after XXX connections or X hours something is off)