[GH-ISSUE #545] limit external access to only use the proxy #351

New issue

Closed

opened 2026-03-15 14:02:33 +03:00 by kerem · 4 comments

kerem commented

2026-03-15 14:02:33 +03:00

Owner

Originally created by @bradfordbulger-nasa on GitHub (Jul 29, 2025).
Original GitHub issue: https://github.com/axllent/mailpit/issues/545

Is there a way to configure the access so that Apache can reach Mailpit at the direct IP:port URL (which I guess is the only way to do it?) but that nobody coming in from other IPs would have access to http://the.ip.address:mailpit_port_number? (Sorry for poor description, I am still trying to understand the subject.)

For example, a user coming from outside of the server (eg web client on their laptop) would be able to go to https://myserver.com/mailpit but not to http://237.42.666.15:8025

Our intent is to use the proxy to set some headers in the response that we can do with Apache, but if our IT security people can still access IP-address:portnumber directly, they won't see the headers they want.

Originally created by @bradfordbulger-nasa on GitHub (Jul 29, 2025). Original GitHub issue: https://github.com/axllent/mailpit/issues/545 Is there a way to configure the access so that Apache can reach Mailpit at the direct IP:port URL (which I guess is the only way to do it?) but that nobody coming in from other IPs would have access to http://the.ip.address:mailpit_port_number? (Sorry for poor description, I am still trying to understand the subject.) For example, a user coming from outside of the server (eg web client on their laptop) would be able to go to https://myserver.com/mailpit but not to http://237.42.666.15:8025 Our intent is to use the proxy to set some headers in the response that we can do with Apache, but if our IT security people can still access IP-address:portnumber directly, they won't see the headers they want.

kerem closed this issue

2026-03-15 14:02:38 +03:00

kerem commented

2026-03-15 14:02:44 +03:00

Author

Owner

@axllent commented on GitHub (Jul 29, 2025):

Hi @bradfordbulger-nasa. If I understand your question correctly (sorry, it's not 100% clear to me), yes, this should be easily possible, with the exception that your IT people would then need to access it via http://237.42.666.15:8025/mailpit if your apache proxy is set up to use the /mailpit webroot (this path is set within Mailpit too in relation to the responses it gives the browser, so you can't [easily] mix webroots).

Your IT people would need to ensure that the external port 8025 is open only to them (blocked to the rest of the world), and port 80 for HTTP (and presumably 443 for HTTPS) is open to the world to access via the domain name (apache). I don't know how your infrastructure is set up, but that's not a question for me, that's a question for your IT people. There are some examples of proxy configurations on the website, although I suspect they know what they are doing too if they also want to include extra headers etc.

@axllent commented on GitHub (Jul 29, 2025): Hi @bradfordbulger-nasa. If I understand your question correctly (sorry, it's not 100% clear to me), yes, this should be easily possible, with the exception that your IT people would then need to access it via `http://237.42.666.15:8025/mailpit` if your apache proxy is set up to use the `/mailpit` webroot (this path is set within Mailpit too in relation to the responses it gives the browser, so you can't [easily] mix webroots). Your IT people would need to ensure that the external port 8025 is open only to them (blocked to the rest of the world), and port 80 for HTTP (and presumably 443 for HTTPS) is open to the world to access via the domain name (apache). I don't know how your infrastructure is set up, but that's not a question for me, that's a question for your IT people. There are some examples of proxy configurations on [the website](https://mailpit.axllent.org/docs/configuration/proxy/), although I suspect they know what they are doing too if they also want to include extra headers etc.

kerem commented

2026-03-15 14:02:49 +03:00

Author

Owner

@bradfordbulger-nasa commented on GitHub (Jul 29, 2025):

Yeah, I didn't put it clearly. A remote group in IT security is dinging us for having a vulnerability because mailpit at port 8025 is not encrypted and doesn't have the Strict-Transport-Security header set. If I proxy it to our Apache webserver, then I'm thinking I can take care of that in Apache. But that just adds a point of access - they will still be able to get the original response on port 8025.

What I thought I might be able to do is restrict acceptable hosts to use the UI on port 8025 to the localhost. So that in practice, only Apache is allowed to access it.

A scenario:
After installation and configuration, I can access the Mailpit UI at http://123.12.12.12:8025
Our security people say that's a vulnerability.
I configure a proxy in Apache to https://myserver.com/mailpit (http is redirected to https, etc - normal stuff)
[unknown things happen]
Our security people try to access http://123.12.12.12:8025 - it's as if there's nothing listening to that port
They can only see https://myserver.com/mailpit and now they are happy.

I am trying to get the socket based interface to work, that seems like it might be the way to get to where I want to end up.

I think I get what you're saying about the webroot, that should be fine.

@bradfordbulger-nasa commented on GitHub (Jul 29, 2025): Yeah, I didn't put it clearly. A remote group in IT security is dinging us for having a vulnerability because mailpit at port 8025 is not encrypted and doesn't have the Strict-Transport-Security header set. If I proxy it to our Apache webserver, then I'm thinking I can take care of that in Apache. But that just adds a point of access - they will still be able to get the original response on port 8025. What I thought I might be able to do is restrict acceptable hosts to use the UI on port 8025 to the localhost. So that in practice, only Apache is allowed to access it. A scenario: After installation and configuration, I can access the Mailpit UI at http://123.12.12.12:8025 Our security people say that's a vulnerability. I configure a proxy in Apache to https://myserver.com/mailpit (http is redirected to https, etc - normal stuff) **[unknown things happen]** Our security people try to access http://123.12.12.12:8025 - it's as if there's nothing listening to that port They can only see https://myserver.com/mailpit and now they are happy. I am trying to get the socket based interface to work, that seems like it might be the way to get to where I want to end up. I think I get what you're saying about the webroot, that should be fine.

kerem commented

2026-03-15 14:02:54 +03:00

Author

Owner

@axllent commented on GitHub (Jul 30, 2025):

If Mailpit is configured to listen on "localhost" (127.0.0.1) and Apache is running on the same server then this should achieve what you want, with the exception of the HTTPS. Apache can then be configured to handle the https.

There's a section in the link I posted earlier which covers the proxing of websockets.

Edit: sorry, rewrote the above in English.... I was trying to write that while boarding a plane, and failed miserably 😜

@axllent commented on GitHub (Jul 30, 2025): If Mailpit is configured to listen on "localhost" (127.0.0.1) and Apache is running on the same server then this should achieve what you want, with the exception of the HTTPS. Apache can then be configured to handle the https. There's a section in the link I posted earlier which covers the proxing of websockets. Edit: sorry, rewrote the above in English.... I was trying to write that while boarding a plane, and failed miserably 😜

kerem commented

2026-03-15 14:02:59 +03:00

Author

Owner

@bradfordbulger-nasa commented on GitHub (Jul 30, 2025):

I read it on the train and I thought it was me :)

Yes, explicitly listening on 127.0.0.1 restricts it to be visible only on the server itself, so they won't get a response from http://123.12.12.12:8025, using the example scenario above. Meanwhile that's proxied to https://myserver.com/mailpit and we can set all our various headers in the Apache config.

I haven't been able to get the sockets to work yet, but that's just curiosity for possible future use.

@bradfordbulger-nasa commented on GitHub (Jul 30, 2025): I read it on the train and I thought it was me :) Yes, explicitly listening on 127.0.0.1 restricts it to be visible only on the server itself, so they won't get a response from http://123.12.12.12:8025, using the example scenario above. Meanwhile that's proxied to https://myserver.com/mailpit and we can set all our various headers in the Apache config. I haven't been able to get the sockets to work yet, but that's just curiosity for possible future use.