On 12 April 2019 18:11 Robert Kudyba via dovecot dovecot@dovecot.org wrote:
Probably there's an existing solution for both problems (subsequent attempts and dnsbl):
It was also discussed recently on this list:
Has already been on my personal todo list for some time, so I have no experience how (good) it actually works.
That was a thread I started. I got wforce to work. However the "reporting IP" in the logs always shows as 127.0.0.1, so I risk banning myself. Here's the log entry: Apr 12 10:06:12 auth: Debug: policy(ouruser,127.0.0.1,
): Policy server request JSON: {"device_id":"","login":"ouruser","protocol":"imap","pwhash":"2a","remote":"127.0.0.1","success":false,"policy_reject":false,"tls":false} I've tried setting auth_policy_server_url to examples such as:
- auth_policy_server_url = http://localhost:8084/
- auth_policy_server_url = http://0.0.0.0:8084/
- auth_policy_server_url = https://ourdomain.edu:8084/ in the custom config file for wforce and the rip (reporting IP, e.g., Apr 12 10:06:10 auth: Debug: client in: AUTH 1 PLAIN service=imap secured session=OWoLzlWGDrh/AAAB lip=127.0.0.1 rip=127.0.0.1 lport=143 rport=47118 resp=<hidden>) is either 127.0.0.1 or ourdomain.edu (http://ourdomain.edu).
You are running some kind of proxy in front of it. If you want it to show real client IP, you need to enable forwarding of said data. With dovecot it's done by setting
login_trusted_networks = your-upstream-host-or-net
in backend config file.
For webmails, this requires both login_trusted_networks and also support from the webmail software to forward client IP.
Aki