*Ouch* Seems like a variation of POP before SMTP, and that of course
experience shows will not work at scale, given all the new emerging ways
of using SMTP..
Eg, email relay, scripts, mailers etc. And there are SOME clients that
don't do what you describe.. Also, things like autoconfig, etc can break..
In 'theory' interesting, in practice, a CSR nightmare
On 2025-12-10 09:14, Jaroslaw Rafa via mailop wrote:
Dnia 10.12.2025 o godz. 12:53:36 John Fawcett via mailop pisze:
those IPs are also on Spamhaus XBL. Do you have use cases where
legitimate users need to login from exploited ips? If you don't get
a lot of need for it, i.e. if your users generally use IPs that are
not on blocklists like XBL, then you could evaluate to block up
front based on XBL and reserve your ip based login failures as a
second line of defence.
And again I suggest to reject the connection on 587/465 port, without even
going to SMTP authentication phase, if there is no IMAP session already open
from the same IP address (by "open" I mean "successfully authenticated", not
only connection established).
Real users, using real mail clients, first open IMAP session to fetch mail,
and only then send something (keeping IMAP session still open). It is a
"behavioral" factor that you can use to block access, greatly reducing the
risk of unauthorized access because password-guessing attacks on IMAP are
much more rare than on SMTP (don't know why, but that's how it is).
In case your users run some scripts that submit mail to server without
opening IMAP connection first, you may whitelist them individually. I guess
there won't be many such cases.
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
