[Postfix] Prevent unwanted unauth relaying to other mailservers

[offlinehoster]

In case of unwanted spamfloods your mailcow will relay incoming mails from other mailservers because of a wrong rcpt_to or from: header. I this case you have can secue your mailcow by adding those 2 restrictions, one for external relays and also for the internal usecase, when you may accidently use the wrong relay adress with your auth.

In my case I learned that this will deny round about 20k spammails from outside, who tried to use my mailcow as "openrelay" because they used a wrong from/rcpt_to address and my mailcow thought..ok I will relay it back to the "primary" spam destination....

Contribution Guidelines

• I've read the contribution guidelines and wholeheartedly agree them

What does this PR include?

Short Description

Add 2 more settings to the smtpd_relay_restrictions key to make sure that no other auth or unwanted unauth relaying will happen under a wrong name/permission.

Affected Containers

• postfix-mailcow

Did you run tests?

Yes

What did you tested?

I tested from internal/external by script to try to relay to external mailserver an undelivered mail -> denied (expected)
-> Sender address rejected: User unknown in virtual mailbox table;

What were the final results? (Awaited, got)

The default mailcow installation is now not anylonger possible to relay a mail from external to another external mailserver and so it's not an openrelay anymore. With the default config you do not have those 2 settings which mean that you could possible use "any" default mailcow to flood by relaying any other mail instance as you want to flood.
You're also not able to relay a mail from your own mailcow from another "domain" which does not belong to your own mailcow account. You can only relay with your own credentials and your own "domains/accounts".

[mkuron]

@offlinehoster, could you please provide detailed instructions how to abuse Mailcow as open relay? I believe we already enforce that the envelope sender is an address that belongs to the logged-in user. I thus don‘t think there should be an open relay opportunity in the default config. Past reports of unauthenticated relaying were usually due to misconfigured firewalls.

Please see https://github.com/mailcow/mailcow-dockerized/blob/master/SECURITY.md for reporting security vulnerabilities — if this issue indeed occurs in a default install of Mailcow, you might not want to share too many details publicly.

[venomega]

few months ago i have this same issue, default installation acts as openrelay, you can check with something like https://mxtoolbox.com/

there was another user, not in this thread that found also a solution, i don't see it now

[venomega]

#1145

[patschi]

few months ago i have this same issue, default installation acts as openrelay, you can check with something like https://mxtoolbox.com/

Then it is some sort of other misconfiguration and issue. The issue you outlined refers to an alleged open-relay which has not been reported so by mxtoolbox.com. Which is add, is it isn't.

Please don't mix issues.

This behavior doesn't feel to be reliable reproducible, but I'm happy to be correct on this one.

[patschi]

I have re-opened issue #1145 for now. We'd need to get on the bottom of this and understand it, before merging some config options which are battle-tested and known to work (for majority/all setups for now).

[patschi]

#1145

Update on this: It has been proven being a network misconfiguration and NOT a wrong configuration. Hence, unrelated to this PR.

---

@offlinehoster Would you mind sharing the script how you tested with with us through email (not publicly)?

I'm still not sure if I get what the issue, or rather fixed issue, is here. But want to get on the bottom of this. Would appreciate more details on this.

[offlinehoster]

I did some extended tests and I will revoke my MR.