So if I'm understanding this correctly.

When SM receives these web requests they are coming from a load-balancer (or web Gateway) with the "X-Forwarded-For" header?

I could see this. We could then verify that if we do see "X-Forwarded-For" that we only accept that header when coming from a known safe IP. Otherwise client's could write this header's themselves to bypass IP checks. Thankfully we have a list for these kinds of checks already, bypassed IP's.

What specific purpose does proxy-protocol fill that 'X-Forwarded-For' doesn't? Looking at it, seems like it would be quite a bit of work.

Hi Matt,

yes right, the header is insertet by the proxy/lbl. Typically at this point all client inserted headers are replaced.

X-Forwarded-For is only usable when speaking abount http protocol but not for TCP smtps, imaps, pops ... for these protocols I only know about proxy protocol. However the "best but most complex" solution is a transparent proxy.

haproxy proxy protocol: https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt

...
The protocol is simple enough that it is expected that other implementations will appear, especially in environments such as SMTP, IMAP, FTP, RDP where the client's address is an important piece of information for the server and some intermediaries. In fact, several proprietary deployments have already done so on FTP and SMTP servers.
...

Best regards

Hi Matt, any news concerning the proxy protocoll?

Actually I have a constant 24x7 SMTP authentication probe from different countries which cant't be handeled by the SmarterMail blocking system, cause they all came from the local proxy ...

Best regards

I've submitted this for you as a feature request/discussion item as Matt is likely tied up with other tasks, and this should help keep it on the radar in the future. In the meantime, physically binding the IP address to the server should allow for your IDS system to function properly. If you're unable to bind the IP directly to the server, I recommend implementing a network level IDS system that can scan traffic during ingress so that the IDS system in SM is not necessary. 

Dear Kyle, many thanks for submitting. Alas binding is not the solution, cause I run haproxy in front of smartermail. So all client connects terminate in haproxy. Them haproxy connects to SmarterMail. In consequence SmarterMail only sees the haproxy IP. Thus fixes the proxy protocol. Running an external IDS didn't give me the opportunity to prevent e.g. then admin login to SmarterMail only from a specific IP or disable an external IP, which constantly probes login for SMTP Auth.

Best regards

Hello Kyle,

did you discuss the support for this datacenter enterprise setup internally?

Best gegards

Lars

Hello, This is a feature we are looking for too but also for mail protocols, as we are going to proxy IMAP/POP/SUBMISSION through dovecot frontend servers in proxy mode.

Some other servers support this (at least dovecot, cyrus), for example:

https://doc.dovecot.org/configuration_manual/forwarding_parameters/#forwarding-parameters 

It would be nice to have it so the logs can contain the real client IP address.

Hi all together,

are there any news to enhance SmarterMail in proxy security setups to support this?

Any time frame for implementation?

Many thanks

Lars

In this case if you use the dovecot you can get the real ip in the info.log 

+1

This has been submitted as a feature request, and so unfortunately I cannot provide you an ETA on this. This request will be re-visited and re-evaluated in the future by our Product Management team. Based on its appeal to the wide range of users of our products and the popularity of the feature, this functionality may be included in a future Build.

interested as well, especially for this use case: seamlessly migrate a tenant to another backend server without changing the IMAP/SMTP/Web addresses for them.

Would hep with migrating customers into smartermail from other  products (a few at a time, instead of all of them at once), or to balance backend server usage.

Without proxy support, all the IP filtering and logging done by smartermail would see the forwarder IP

+1 for supporting PROXY protocol for any TCP/UDP-based services offered by SmarterMail and additionally, X-Forwarded-For: from trusted source addresses for any HTTP/HTTPS-based services offered by SmarterMail through IIS.

Hi all together,

are there any plans to implement thesse security relevant functions soon?

Thanks & regards

Lars

+1 really looking forward to this

Would like to see option to use "X-Forwarded-For" from trusted source IP addresses for HTTP/HTTPS-requests, so log files about web users in and logins to webmail are correct.

Hmmm, that would be something you configure at IIS Level I guess ?

i know how to do it for apache or nginx but not IIS.

Maybe something like: https://automationtheory.org/docs/configure-iis-to-preserve-source-ip-address/

This thread is more than 3 year old. What is happening for such a simple feature?

I would really like to see the option to use "X-Forwarded-For" from trusted source IP addresses for HTTP/HTTPS-requests to webmail, so log files about web users IP address and logins to webmail are correct as all active webmail users are currently listed with IP 192.168.10.5 which is our proxy.

And i'm not sure what Sébastien is talking about as it's NOT possible to get the correct real IP from the connecting client via HTTP/HTTPS without the X-Forwared-For header. So please implement.

If you need the code for .NET Core just ask me. We always implement this in our .NET Core projects.

Thanks :-)