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

Hector Santos <> Fri, 04 December 2015 16:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 16A951A88F3 for <>; Fri, 4 Dec 2015 08:00:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.137
X-Spam-Status: No, score=-101.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CMIR9lIsini1 for <>; Fri, 4 Dec 2015 08:00:11 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D0CDB1A8913 for <>; Fri, 4 Dec 2015 08:00:10 -0800 (PST)
DKIM-Signature: v=1;; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1919; t=1449244804;; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=lqCF8+s9oU7bYNzyi7lFCwuqRvU=; b=uf9eeu255jcN08w9b6cS5KQaJGuB6HXaJNMtsOheo2by6hnHZL8NbpzoB8Qq+y 2o4J6AWsLarvnCGBv3BZjhV3akPj2xaQhT9WTkG74GYErLFUVk77wzVmlJygC3D1 8qFdc9+ZWAfjKFYpFumMR0V6RurZDyh8P2QHOVQGlEjbs=
Received: by (Wildcat! SMTP Router v7.0.454.4) for; Fri, 04 Dec 2015 11:00:04 -0500
Authentication-Results:; dkim=pass header.s=tms1; adsp=pass policy=all; dmarc=pass policy=none (atps signer);
Received: from ( []) by (Wildcat! SMTP v7.0.454.4) with ESMTP id 1132996886.3357.1700; Fri, 04 Dec 2015 11:00:02 -0500
DKIM-Signature: v=1;; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1919; t=1449244688; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=6uZdf4B qeQ+4wFsOCTW0cKxrCvSVALqhNydXq04DxBI=; b=oG2o9UlC/QxMJSpoDkk+M9Q 8n4Rvt0MnCXvD8qmB7SAQmoNy0MnbfqCFyA3fARRoZNCWd+cb8GO5KATbz+95d4A K7uX5/+6jevh6CplqdweCVh8FcHdsHus+jABgveK24+GhbePJTCjU9nwI/vfsJmd X0atE+TzxMuPeWmXUwNs=
Received: by (Wildcat! SMTP Router v7.0.454.4) for; Fri, 04 Dec 2015 10:58:08 -0500
Received: from [] ([]) by (Wildcat! SMTP v7.0.454.4) with ESMTP id 71854243.9.95524; Fri, 04 Dec 2015 10:58:07 -0500
Message-ID: <>
Date: Fri, 04 Dec 2015 10:59:00 -0500
From: Hector Santos <>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: Chris Lewis <>,
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Shutup] [ietf-smtp] Levels of proposals
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SMTP Headers Unhealthy To User Privacy <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Dec 2015 16:00:13 -0000

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.