OpenRelay enabled by default ?

[VFourneau]

Hey,
I setup mailu through the helm chart for my kubernetes cluster. Everything works so far but after going through my log aggregator I found an issue.

Feb 19 17:24:02 mail postfix/smtp[27484]: 99419D237E7: to=<RANDMOM>@gmail.com>, relay=alt1.gmail-smtp-in.l.google.com[142.250.4.27]:25, delay=100681, delays=100669/1.5/7/3.1, dsn=4.7.0, status=deferred (host alt1.gmail-smtp-in.l.google.com[142.250.4.27] said: 421-4.7.0 [<MY_IP>      15] Our system has detected that this message is 421-4.7.0 suspicious due to the very low reputation of the sending IP address. 421-4.7.0 To protect our users from spam, mail sent from your IP address has 421-4.7.0 been temporarily rate limited. Please visit 421 4.7.0  https://support.google.com/mail/answer/188131 for more information. b18si301567pge.389 - gsmtp (in reply to end of DATA command))\n

And there is a lot.
I setup mailu last week and I'm already blacklisted with some providers.

I used the default config.

How can I disable /block smtp relaying ?

[rouja]

Hi,

Is-it a new IP ?
Did you check the reputation of your IP before to install mailu ?

To check if you are an open relay, you can do this test (from a linux terminal and from outside your email server) :

nc -v $YOUR_PUBLIC_SERVER_IP 25
Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: Connected to $YOUR_PUBLIC_SERVER_IP:25.
220 $YOUR_MAIL_SERVER_DOMAIN ESMTP ready
HELO $YOUR_MAIL_SERVER_DOMAIN
250 $YOUR_MAIL_SERVER_DOMAIN
MAIL FROM: $A_MAIL_NOT_MANAGED_BY_YOUR_SERVER
250 2.0.0 OK
RCPT TO: $ANOTHER_MAIL_NOT_MANAGED_BY_YOUR_SERVER
554 5.7.1 <$ANOTHER_MAIL_NOT_MANAGED_BY_YOUR_SERVER>: Relay access denied

If the last response is 250 2.1.5 Ok that means that you are an open relay and there is something wrong in your configuration but if it's not, the problem is probably you IP reputation.

[Heziode]

@rouja
I have the same issue.
I have following the doc, and after the test, I get 250 2.1.5 Ok, so it's an open-relay and I don't know why…

How can I turn off the open relay ?

[rouja]

Hi,

@Heziode What is the content of your subnet parameter ?

[Heziode]

My subnet is: 192.168.0.0/20
It's a bride network.

---

I think I found the origin of the issue.

I use traefik v2 and for some mysterious reason, mapping port in traefik conf from 25:25 doesn't work. So I have added 0.0.0.0:25:25 which worked but seemed to turn him into an open-relay. So I have put the IP of my server instead of 0.0.0.0 that seems to work. I can send and receive mail, but it is not an open relay now \o/.

[VFourneau]

@rouja Sorry for the delay, I was away and couldn't easily check.

My ip was a fresh IP, never used as a mail server.
Using the default mailu config but using nginx-ingress unlike Heziode.

It was flagged as an openrelay, The first couple days it worked fine and I had a good reputation.

My subnet is set for : 192.168.0.0/16

It went down hill really fast after those couple days.

I could switch the traffic policy of the ingress around to see if that helps as it could definitely be related to some derping with the source ip.

But it's still weird to me that it's allowing everything even the unauthenticated one.

[rouja]

Hi @VFourneau

Could you show the result of theses commands :

kubectl -n mailu get pod,svc,ingress,deployment,daemonset
ss -ltpn|grep :25

Maybe you are in something similar to Heziode even if you use nginx-ingress.

[ccbur]

I'm new to mailu, but I think a have the same problem. I'm about to migrate from a hand-configured postfix/dovecot/roundcube setup to the mailu chart and I'm not able to understand how incoming smtp traffic should be routed through Loadbalancer/NodePort or Ingress to mailu-postfix in a way that the SUBNET configuration (cp. main.cf / mynetworks) actually works as I expect it.

I configured subnet: 10.244.0.0/16 in my values.yaml file, because 10.244.0.0/16 is my pod cidr. But now I think all incoming smtp traffic through the mailu-front ingress or any other service (eg. a custom NodePort service in front of mailu-postfix) is routed from iptables on the worker nodes and therefore originated from an IP out of this range, even if its original sender is outside the pod network.

E.g. when sending a mail from a node outside of my Kubernetes cluster (192.168.1.12), I can see the following entry in the postfix log:

Apr 11 13:13:45 www postfix/smtpd[23271]: 7A7E9C5496: client=unknown[10.244.1.1]

10.244.1.1 is the CNI ip address if one of my Kubernetes worker nodes and part of the pod cidr. I expected to see 192.168.1.12 in the log!?

I'm not sure if this is a Flannel thing or Kubernetes-related in general, but the result is that all incoming traffic can be relayed to any other mail address without authentication.

Can someone confirm?

[ccbur]

Ah, my mistake. It's not a bug, it's a Kubernetes feature (...of course...). I found the solution here: https://kubernetes.io/docs/tutorials/services/source-ip/#source-ip-for-services-with-type-nodeport

Adding externalTrafficPolicy: Local to my service definition solved the problem. Incoming mails from outside my cluster are now rejected if not another postfix permit is happening (e.g. TO is my own email address, etc.).
Maybe this should be documented somewhere? Otherwise there will be a lot of open mailu relays in the future :-(

[Nebukadneza]

Hi There,

The Mailu-Project is currently in a bit of a bind! We are short on man-power, and we need to judge if it is possible for us to put in some work on this issue.

To help with that, we are currently trying to find out which issues are actively keeping users from using Mailu, which issues have someone who want to work on them — and which issues may be less important. These a less important ones could be discarded for the time being, until the project is in a more stable and regular state once again.

In order for us to better assess this, it would be helpful if you could put a reaction on this post (use the 😃 icon to the top-right).

• 👍️ if you need this to be able to use Mailu. Ideally, you’d also be able to test this on your installation, and provide feedback …
• 🎉 if you find it a nice bonus, but no deal-breaker
• 🚀 if you want to work on it yourself!
  We want to keep this voting open for 2 weeks from now, so please help out!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[nextgens]

Please see #1823 (comment)