[Top] [All Lists]

Re: [ietf-smtp] [Shutup] Levels of proposals

2015-12-04 10:00:29
On 12/4/2015 8:10 AM, Chris Lewis wrote:
On 12/03/2015 09:11 PM, Ted Lemon wrote:

Can you unpack "AUTH-cracking spambots" for the greenhorns?   I have
no idea what this means, and google unfortunately was unable to help.

Primarily botnets that connect to MSAs and use stolen (or potentially
brute-forced) userid/password credentials in order to use the MSA/MTA
combo as an open relay.


AUTH-cracking to this extent is a relatively recent phenomena, and is
clearly being used as an attempt to bypass normal direct-2-MX botnet
blocking and hijack the reputation of the MTA instead of some random
cracked PC.

Hi, I'm surprise to read you say this is "relatively recent." Are you mean in months, years or one to several decades?

I have seen tons of "auth-cracking/brute force" auth attempts done at all the IP protocol servers. Generally, they do it all in one connection session where a "Maximum Failed Login Attempt" count may is used. I always knew it was possible, but I suppose there are now increased distributed "botnet" forms of this where the Failed Login Attempt Count would be reset at the connection. I have not seen the need to do much because I am not seeing damage. Everything (robust high scale servers) have been in place for many years, you know "Set it and forget it."

Overall, having robust 24x7x365 load balancing/control IP tracking/blocking server(s) is par for the course, so this is more about relaxing the STD10/RFC2821/RFC5321.Received SMTP receiver protocol requirement to help avoid mitigate negative correlation methods with ESMTP AUTH, right?

Incidentally, what I am seeing more of late, are single or "botnet" IP connections that do nothing, i.e. they sit there idle and they don't attempt to login. What is interesting is that if you (force) close/drop it, they immediately reconnect with the same IP.


ietf-smtp mailing list