Blacklist IP

Ok, I've done some testing.  I'm a little calmer now but very confused.

I created a host object "Cell" that has the IP address of my smart phone. I added Cell to a "BadComputers" group.  Traffic from BadComputers was set to be DNAT'd to a non-existing internal IP address.

For good measure, I added BadComputers to the SMTP relay blacklist.

The result was as desired; I could no longer send or receive email from my phone.  

Then I removed the Cell object from the BadComputers group and I could send email once again.

BUT block-password guessing in authentication services (fail2ban?) is running. I'm still getting notifications "Too many failed logins from w.x.y.z for facility smtp", where w.x.y.z is the IP of a host in the BadComputers group.  

How can I still be getting SMTP authentication attempts from an IP that is both SMTP relay blacklisted and DNAT blackholed? [:S]

How can I still be getting SMTP authentication attempts from an IP that is both SMTP relay blacklisted and DNAT blackholed? [:S]

Let me quote myself..[;)]:

..blacklisted hosts are rejected after RCPT TO command, but UTM allows them AUTH LOGIN which comes earlier in SMTP communication.

Explained here: SMTP Attacks - Block/Blacklist IP

DNAT doesn't work anymore for SMTP (it works for HTTP/S, based on my testing).

..blacklisted hosts are rejected after RCPT TO command, but UTM allows them AUTH LOGIN which comes earlier in SMTP communication.

Thanks, that makes sense!  

I'm not happy that we can't use DNAT for SMTP (and I'd had a gut feeling that I shouldn't upgrade from 9.2) but at least I know what's going on now.  

Is anyone else using backend auth and experiencing Active Directory account lockouts as a result?

Is anyone else using backend auth and experiencing Active Directory account lockouts as a result?

Not strictly related to the topic, but my opinion is that using AD recipient verification for SMTP on UTM is not a good idea. 

Even a small break in network communication between UTM and DC can lead to denied email message to the sender, not to mention greater outages where SMTP as a protocol is very flexible (Retry) if no AUTH is involved.

EDIT: With callout is not supported by Microsoft Exchange without third party software.

The final nail in the coffin is that SMTP Auth must happen before the AD group membership lookup. I had set Relaying to be allowed only for folks in a "mailuser" group.  There was one user in particular whose account kept getting locked so I removed her from the group, and then it got locked again anyway.

The reason I had gone with SMTP relay in the first place was because I was having trouble setting up the UTM to proxy Exchange-type connections (autodiscover, offline address book, outlook web access).  I've got it working now, though not perfectly, so I plan to have mobile phone users reconfigure their settings.  Once done I will disable SMTP relay ASAP.

The final nail in the coffin is that SMTP Auth must happen before the AD group membership lookup. I had set Relaying to be allowed only for folks in a "mailuser" group.  There was one user in particular whose account kept getting locked so I removed her from the group, and then it got locked again anyway.

The reason I had gone with SMTP relay in the first place was because I was having trouble setting up the UTM to proxy Exchange-type connections (autodiscover, offline address book, outlook web access).  I've got it working now, though not perfectly, so I plan to have mobile phone users reconfigure their settings.  Once done I will disable SMTP relay ASAP.