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

[Hector Santos <[e-mail]>]

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.

-- 
HLS