we found that surgemail was listening on ports 993, 995 and 465 and
could not see a way to turn that off, which is why we put in the
we're still seeing some of these:
pop: ssl failed SSL error gave up after 6 seconds (20 attempts) (from IP
which i fail to understand. seems they're trying to connect using ssl on
the standard pop port (110). which makes no sense to me. looking at the
ip addresses involved, they all appear to be registered to microsoft,
which makes even less sense :-)
there was, however, some minor fallout from implementing the rules.....
customer using phones and setting them up themselves, have sometimes
failed to turn off ssl and have, as a result, been blocked. when they
turn of ssl, they're fine.
of course, when a customer asks me how to set up their phone, i tell
them explicitly to turn ssl off.
i think we'll just let this one ride.
advanced web systems
On 3/18/2016 4:08 PM, surgemail-support wrote:
> Nothing currently would block that, you could disable ssl on the non
> ssl ports but that strikes me as a bad idea.
> We could add a black listing feature for these attempts, but I'm
> reluctant to do that without being sure it's causing some
> problem other than log entries as it might knock out real users in
> some situations.
> Can you send me a bigger log section from mail.err and mail.log and
> imap.log and pop.log so I can see more context.
> On 19/03/2016 6:18 a.m., David Camm wrote:
>> over the past week or so, we been getting a tremendous number of
>> attempted logins that generate error messages like this:
>> pop: ssl failed SSL error gave up after 6 seconds (20 attempts) (from
>> IP 22.214.171.124)
>> smtp: ssl failed SSL error gave up after 6 seconds (20 attempts)
>> (from IP 126.96.36.199)
>> we added iptables rules to drop any traffic attempting to connect to
>> the secure ports (993, 995 and 465) as we don't support that, but
>> that didn't help.
>> so, clearly the attackers are attempting to connect using the
>> non-secure ports with ssl protocol.
>> is there any way, rather than allowing them 20 attempts to either ban
>> the ip or cut them off after a fewer number of attempts?
>> this has become REALLY annoying.
>> david camm
>> advanced web systems
>> keller, tx