If using EFA in your business, where do you place it?

[ovizii]

Currently, I have 2 systems in my DMZ: a reverse proxy to allow access to certain internal services and EFA.
I'm feeling slightly uncomfortable having EFA accessible in my DMZ as it does store emails for up to 30 days as configured so I do have sensible data in my DMZ. If I stop EFA from archiving anything it looses much of its advantages.

Yes, my DMZ is properly secured only allowing necessary protocols and connections but still the risk is there.

Does anyone use say nginx to reverse proxy connections to EFA? I know it can be done but I haven't done this yet.

[pdwalker]

I personally don't allow access to EFA to the outside world, except for port 25. Even if you use reverse proxy connections to allow access to EFA externally, you are still exposing the webserver to outside attacks which is not a risk I want to take - even with the recent hardening of MailScanner.

Otherwise, setting up a reverse proxy connection using nginx is relatively simple and well documented in thousands of places.

[ovizii]

OK, I might not have been very precise with my question so lets clarify a little:

- I also don't allow external access to EFA's web interface only port 25
- When I mentioned nginx I meant that you can reverse proxy the port 25 mail traffic too. (AFAIK the method differs a little from reverse proxying http/https traffic)

Your conclusion is that by placing EFA in the DMZ with only port 25 exposed should be OK? (Reading my question again, I do realize its a silly question as obviously port 25 needs to be exposed for any email server to work

So I guess I answered my own question. Thanks for being my sounding board, it just doesn't work out the same if I talk to myself

[pdwalker]

- I also don't allow external access to EFA's web interface only port 25
- When I mentioned nginx I meant that you can reverse proxy the port 25 mail traffic too. (AFAIK the method differs a little from reverse proxying http/https traffic

ok, not allowing external access to the web interface is a relief.

proxying smtp traffic? ... that's... bizzare (translation: I've never thought of doing that before so it's taking time to sink in)

The only reasons I can of off the top of my head to proxy smtp traffic via nginx is:
a) to take advantage of the ssl encryption support of nginx possibly for SSL/TLS connections
b) to reroute mail to other servers based on <criteria> (which I can already do in efa)
c) to provide an additional layer of filtering and access control to your smtp server from external sources
d) something else completely different?

So I guess I answered my own question. Thanks for being my sounding board, it just doesn't work out the same if I talk to myself

The technical term for this is "Rubber Duck Debugging". A full description of the technique can be found here and is well worth reading for amusement value alone: https://blog.codinghorror.com/rubber-du ... m-solving/

PS: Quack!

[ovizii]

The only reasons I can of off the top of my head to proxy smtp traffic via nginx is:
a) to take advantage of the ssl encryption support of nginx possibly for SSL/TLS connections
b) to reroute mail to other servers based on <criteria> (which I can already do in efa)
c) to provide an additional layer of filtering and access control to your smtp server from external sources
d) something else completely different?

True, that more or less covers it at least I can't think of another reason either.

I'll add this link just in case anyone stumbles upon this thread to at least provide a direction to go if interested in the topic:
https://www.nginx.com/resources/admin-guide/mail-proxy/

Thanks for the rubber duck pointer I wasn't aware of the term or the method. I guess I'll start by asking my dog first, then, if she can't come up with a solution I might resort to a rubber duck