I'm reverse proxying from a cloud-based VPS using NGINX via a VPN to a homeserver running mailcow. - The NGINX reverse proxy setup in the Mailcow docs works great (I proxy to ports 80/443 at the mailserver though, not alternative ports). I send all traffic via a proxy_pass to the VPN address of my server. - The TCP streams on the remaining ports also seem to be working for mail and for mail client configuration. Again, I stream all traffic on ports 25 etc via a proxy_pass to the VPN address of my server. However, RSPAMD isn't fond of the fact that all the mail coming in has the VPN address of my VPS. This is the same issue as [this forum post](https://community.mailcow.email/d/3650) I believe. Essentially, you get SPOOF_AUTH and HFILTER_HOSTNAME_UNKNOWN penalties if you do nothing, and IP_REPUTATION_SPAM (though also sometimes this gets cancelled out by a LOCAL_FUZZY_WHITE?) if you add the offending IP address to Forwarding Hosts. In both cases you get SPF violation penalties. So incoming email->hits my VPS->gets streamed to my Mailcow server with the VPS VPN IP address instead of the client IP address->RSPAMD worries about it and either flat out rejects it, or puts it in spam. To add a bit of value to my request for help, since I've just been lurking here til now and there was no straightforward guide for this setup (although many people asking), I'll share how I've got it working so far. 1. I set up Mailcow on a Raspberry Pi, opening all the required ports in the firewall. It's the only thing, other than the VPN, that the Pi is doing, so I didn't make any modifications to the setup. The only thing I added was a VPN client. Let's pretend the VPN address of my Mailcow server is `10.0.0.1`. 2. I set up the VPN on the VPS (lets say with address `10.0.0.2`), then set up the NGINX config on my VPS as described in the docs [here](https://docs.mailcow.email/post_installation/reverse-proxy/r_p-nginx/) with two modifications: - I set the relevant proxy_pass lines set to `proxy_pass http://10.0.0.1:80...` - I set up the SSL with Certbot, and added those keys in rather than pointing them to Mailcow's keys (since Mailcow isn't on this server). 3. I opened all the required ports on the VPS. Then I set up TCP streams in nginx.conf for each non-HTTP port to my Mailcow server, and restarted NGINX e.g.: ``` stream { server { listen 25; proxy_pass 10.0.0.1:25; } ... ``` 4. I went back to the Mailcow server, and disabled the [IP verification](https://docs.mailcow.email/post_installation/firststeps-ssl/#force-renewal) on the acme-server, changing `SKIP_IP_CHECK=n` to `y` in mailcow.conf, then ran `docker compose up -d` so that Mailcow could set up its own SSL certificates using the proxy_passed requests from LetsEncrypt. 5. I then set up my Amazon SES as an outbound relayhost/smarthost. Plenty of advice for this around, so I won't document it. 5. At this point, everything should work. I could use the UI, and set up my mail clients, send mail (via Amazon SES) and mail was coming in direct to the server via the TCP stream. HOWEVER, RSPAMD was catching all the mail and rejecting it, because the IP address for all mails were set to the VPN IP of the VPS (again, say, `10.0.0.2`). So: 6. I added the VPS VPN IP to System->Configuration->Options->Forwarding Hosts Now, RSPAMD isn't outright rejecting mail, but it still doesn't like it and typically flags it as spam. I could raise RSPAMDs thresholds, but I reckon it'd be better to forward the actual client IP through the stream. I know NGINX [can do this](https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/), e.g.: ``` stream { server { listen 25; proxy_pass 10.0.0.1:25; proxy_protocol on; } ... ``` But I can't work out how to get Mailcow to handle the proxy_protocol. In the Postfix settings, I can see what appears to be some proxy protocol stuff in there so I thought I might just be able to add, you know, something like: ``` smtp inet n - n - - smtpd -o proxy_protocol=yes ``` to an extra.cf file. But I don't actually know if this is going to work, so if anyone has any ideas about how to proceed, that would be much appreciated. Or if there's some other way to get this working, I'm open to that too. Any help much appreciated. UPDATE: the SPF violation penalties only happen when I send to myself from another server via SES (not using Mailcow)---so I'm not sure if that's related anymore. I don't get this with other mails. But I still do get: IP_REPUTATION_SPAM (4) RDNS_NONE (2) UPDATE: the SPF violation penalties only happen when I send to myself from another server via SES (not using Mailcow)---so I'm not sure if that's related anymore. I don't get this with other mails. But I still do get: IP_REPUTATION_SPAM (4) RDNS_NONE (2) UPDATE: the SPF violation penalties only happen when I send to myself from another server via SES (not using Mailcow)---so I'm not sure if that's related anymore. I don't get this with other mails. But I still do get: IP_REPUTATION_SPAM (4) RDNS_NONE (2) Forgive this repetition. Some issue with submission made me think it wasn't working.

See also [this gist](https://gist.github.com/sussycatgirl/4bcd6508dedd21ea21ec494499c92618) for an alternative solution to TCP streaming the relevant ports with NGINX, but with [FRP](https://github.com/fatedier/frp) instead. Not sure if this will solve my problem yet though.

> @"majorminors"#p18224 really don’t want to [swap to HAProxy](https://serverfault.com/questions/922248/how-to-configure-postfix-behind-haproxy) can you please elaborate why?

> @"majorminors"#p18239 links off to the [![](https://community.mailcow.email/api/kilowhat-rich-embeds/proxy?url=https%3A%2F%2Fgithub.githubassets.com%2Ffavicons%2Ffavicon.png) commit![](https://community.mailcow.email/api/kilowhat-rich-embeds/proxy?url=https%3A%2F%2Fgithub.githubassets.com%2Ffavicons%2Ffavicon.png) GitHub[Feature] Add HAProxy listeners and an example override file · mailcow/mailcow-dockerized@0cfdd76![](https://community.mailcow.email/api/kilowhat-rich-embeds/proxy?url=https%3A%2F%2Fopengraph.githubassets.com%2F26e3b1f456efc670bdd77bbf61f3d59dd87b81c7547d2ac24ac779cd02b8bce7%2Fmailcow%2Fmailcow-dockerized%2Fcommit%2F0cfdd763f8ec530cbe6366cbd4d59441563ac11d)](https://github.com/mailcow/mailcow-dockerized/commit/0cfdd763f8ec530cbe6366cbd4d59441563ac11d) That commit doesn´t expose port 443 via proxy protocol, which is required for SOGo and EAS users.

Ah right, yeah. I didn't even look into that, just used the Mailcow [NGINX reverse proxy sample](https://docs.mailcow.email/post_installation/reverse-proxy/r_p-nginx/) for the http ports.

Reverse proxy all ports from remote VPS to Mailcow: retain client IP

majorminors

Was considering the NGINX mail proxy option for a while, but someone thought of that and it seems like a no-go (HTTP authentication server seems too hard). This stuff is hard to search for—didn’t even come up in a direct search for ‘nginx mail proxy’ on the forum. Came across it by accident.

Relatedly, some more confirmation that Mailcow + proxy protocol is a thing in this github issue. I don’t actually care about Dovecot (yet, at least), but there are some references re: what to do with a HAProxy reverse proxy and Postfix (which appear to now be integrated into the default Mailcow Postfix settings?). But NGINX doesn’t seem to like it (tested this before I posted initially).

This one has been my favourite (I can’t even recreate the search I used to find it—luckily I saved the address). Anyway:

I already succeeded using proxy protocol for postfix - smtp (25) and submission (587) - as that is almost trivial to add to the docker-compose.yml, but adding proxy protocol to dovecot - pop3 and imap - doesn´t appear that well prepared.

Trivial indeed. @[deleted] mate, this is far from trivial for poor old me. I can’t help you with your two year old issue, but can you help me with mine!?

Of course they’re deleted.

I really don’t want to swap to HAProxy. Surely this isn’t the only way proxy protocol works with Postfix.

Joachim

majorminors really don’t want to swap to HAProxy

can you please elaborate why?

majorminors

Not deleted! I was interpreting HAProxy as an additional software layer, and I didn’t want to add another one, especially since I already use NGINX to reverse proxy other services. But from your helpful comment on your post I necroed, NGINX should support HAProxy?

Do you mean natively (i.e. I can set up NGINX->Mailcow where NGINX is using the HAProxy proxy protocol or something)?

Joachim

kind of best practice is to configure proxy protocol on port 10000+original port, ifir correctly, this is true for postfix and dovecot with standard configuration, but not exposed via docker compose. For nginx you create additional listeners with the modifier proxy_protocol.
Obviously it adds some overhead as traffic has to pass through additional components but I never had to really worry about that.

majorminors

Alright, I think I understand now. Thanks very much Joachim.

So thanks to that tip, I found someone who describes in a bit more detail what I’ve been looking for and Joachim describes here, which links off to the commit where all this stuff was added into Mailcow back in 2020, including an example docker override file to open the ports Joachim mentions. I knew I saw some of this stuff in there. So that was a fun little adventure. Now to see if I can implement it, though frankly I’m a bit worried about my ability to maintain this, so I may not. But I leave this here for others to find.

Yes, a straightforward adding of the override file, bound to the mailserver’s VPN address doesn’t appear to be working on either end, so I might just give this a miss and fork out the cash to set it up in the cloud, because we’re well into territory I barely understand here.

Thanks again though, Joachim!

Joachim

majorminors links off to the commit GitHub[Feature] Add HAProxy listeners and an example override file · mailcow/mailcow-dockerized@0cfdd76

That commit doesn´t expose port 443 via proxy protocol, which is required for SOGo and EAS users.

majorminors

As an FYI, I can’t find the forum post I was reading for this, but someone else tried the NGINX mail proxy route and had the same issue—emails coming in from their VPS VPN IP address, so that also doesn’t seem like the solution.

majorminors

Obviously, I couldn’t leave this alone, because I apparently can’t live with good enough is good enough. And I think I’ve solved it, but I had to look at RSPAMD, not at the proxy itself.

RSPAMD has an external_relay module, that is disabled by default.

I enabled it, and used the ip_map strategy, adding the VPN address of the VPS as a ‘recognised’ IP address. So, just create <MAILCOW LOCATION>/data/conf/rspamd/local.d/external_relay.conf and add:

## <MAILCOW LOCATION>/data/conf/rspamd/local.d/external_relay.conf

# enable the module
enabled = true;
# from the docs: https://rspamd.com/doc/modules/external_relay.html
# i changed the strategy to ip_map, and added my VPS VPN IP address as a 'recognised' IP address
rules {
  EXTERNAL_RELAY_AUTHENTICATED {
    strategy = "ip_map";
    ip_map = ["192.168.0.1/16"]; # whatever the VPS VPN address is, and the docs want the subnet mask but I didn't test it without
  }
}

Then I restarted mailcow-rspamd.

Now, I’ve got to be honest, I’m not exactly sure what RSPAMD is doing, but emails sent from outside my infrastucture have IP addresses that are not my internal VPS IP address, so this seems positive. The RDNS complaint from RSPAMD is also gone, so I assume it’s getting the right IP address?

I haven’t solved the fact that emails from within my architecture (e.g. from my home server, from sendy on my VPS) are still registered with the VPS VPN, despite all going via amazon SES and not interacting with Mailcow at all. But that seems like a problem for another day. I’ll mark this as best answer unless I have an update.

majorminors

So, related to this internal IP address problem, mail tester is pretty enthusiastic about my internal mails (10/10), so I’m not sure if this is a problem I need to worry about outside my own Mailcow instance. Perhaps other things that use the same RSPAMD defaults? But I’m seeing equivalent deliverability+click rates for my mailing list as I was when I wasn’t doing all this nonsense, and no one but me appears to be having a problem with my day-to-day emails.

So, I think I will just whitelist the IP address in RSPAMD. Seems pretty straightforward with RSPAMD’s multimap.

Mailcow is set up with a bunch of these already (<MAILCOW_LOCATION>/data/conf/rspamd/local.d/multimap.conf). We could use the existing IP whitelist:

IP_WHITELIST {
  type = "ip";
  map = "${LOCAL_CONFDIR}/custom/ip_wl.map";
  symbols_set = ["IP_WHITELIST"];
  score = -2050;
}

So I guess I’d just add my IP to wherever this is defined. But rather than working out whether that’s a UI thing or a ‘edit the map directly’ thing, and since I’ve already added my VPN as a forwarding host I think I’ll use:

WHITELISTED_FWD_HOST {
  type = "ip";
  map = "redis://WHITELISTED_FWD_HOST";
  symbols_set = ["WHITELISTED_FWD_HOST"];
  score = -0.95; # I added this line
}

I used -0.95 which subtracts 9.5 (I don’t exactly understand this, but RSPAMD multiplies this by some metric that is defined somewhere, and with Mailcow, that appears to be 10, but I didn’t look for it, I just played with it while checking the RSPAMD history to get it right). That more-or-less cancels out the RSPAMD complaints I disagree with:

WHITELISTED_FWD_HOST (-9.5) [<IP_ADDRESS>]
IP_REPUTATION_SPAM (3.999997) [ip: <IP_ADDRESS>(1.00)]
VIOLATED_DIRECT_SPF (3.5)
RDNS_NONE (2)

With the benefit, I think, of being related only to whatever I define as a forwarding host, so I won’t need to update anything other than the forwarding host if the VPN address changes?

Let’s see. Hopefully this forum post helps me when I break something later and need to remember what I did.

It seems reasonable to assume that you could use the same map (WHITELISTED_FWD_HOST) for the external relay module. I might update if I ever bother doing that.

majorminors

Ah right, yeah. I didn’t even look into that, just used the Mailcow NGINX reverse proxy sample for the http ports.

Joachim

imho this has three disadvantages:

security: you need to share the certificate with two hosts. Specifically you need to trust your VPS.
performance: proxy needs to parse and compose http whereas ha proxy just forwards a stream
conceptual: you are using two different techniques rather than one

majorminors

Joachim Yeah it is a pain having configuration in two separate places. Didn’t think of the performance issue, nor the security concern.