Re: [Shutup] Levels of proposals

Chris Lewis <> Fri, 04 December 2015 02:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 51D1F1AD355; Thu, 3 Dec 2015 18:00:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.242
X-Spam-Level: **
X-Spam-Status: No, score=2.242 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id haJXDE0Sl7Md; Thu, 3 Dec 2015 18:00:05 -0800 (PST)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE91D1AD350; Thu, 3 Dec 2015 18:00:04 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB4201RN009320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 3 Dec 2015 21:00:03 -0500
To:, ietf-smtp <>
References: <>
From: Chris Lewis <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Thu, 3 Dec 2015 21:00:01 -0500
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/20090812 Thunderbird/ Mnenhy/
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Shutup] 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 02:00:06 -0000

On 12/03/2015 07:36 PM, Brandon Long wrote:
> The WG proposal seems to imply taking all IPs out.  The discussion has
> mostly been about submission.

The draft has been mostly about submission, but there have been some 
conversations about internals.  I've seen auditors bring up points about 
obscuring internals (corporate context, it's one of their checkoff 10 
commandments), but, we managed to convince them that ease of diagnosing 
problems outweighed the downsides.

Before getting too far into concrete proposals, we still need to decide 
whether it should be done, and what (if anything) should be done in 

That said:

> Submission IPs seem like the largest level of risk, and from my gross
> understanding of anti-spam, pretty minor.

Yes, and no...  It depends on how you use/acquire them, this is a fairly 
complex/esoteric end of spam filtering, and just doing it justice would 
take up pages of text.  I'll try to short cut - purely from a filtering 
but not-ML perspective:

Using them:

If you have a list of IPs known to be infected with AUTH-cracking 
spambots, it's of immediate/valuable use to both the MSAs themselves in 
detecting malicious injects, as well as the recipient's filtering, and 
header forgery is not an issue (certainly not to MSAs, and headers that 
forge collisions with the list you don't want anyway).

The potential yields are huge - ISPs (using a list we create of 2.2M IPs 
demonstrably capable of AUTH-cracking) can see botnet suppression rates 
at the MSA of 80% (of all submissions) or even higher, depending on the 
spam/botnet de-jour.  In just one case it's in the 1000+/second range. 
Some of these botnets are very very prolific per IP.

Which boils down to the MSAs being able to stop it at source, or the 
receivers being able to stop it at destination.  If a significant 
fraction of MSAs stopped it at source, then, maybe, the MSA Received 
line isn't important.  But where they don't (the majority), losing the 
MSA Received line is potentially a big hit.

Obtaining them:

Obviously, someone trying to authenticate to you and is demonstrably 
infected isn't spoofable.  That yields the vast majority of our list.

On a case-by-case basis with specialized knowledge it is possible to 
derive trustworthy infected submission addresses from received lines. 
Yes, actually, it really is.  Useful, but not terribly significant (or 
at least how far we've followed that rathole).

By eliminating MSA received clauses, it means that only the MSA can do 
blocking based on this technique, the receivers can't.

On one server, in a 40 minute interval, 774123 out of 1126763 
connections were AUTH spoofing from just one particular botnet.  That's 
775,000 spams that ordinary receivers couldn't filter via IP if the from 
clauses disappeared.

> Also, if the previous thread's list of large MSPs inclusion of
> submission IPs is correct, then >2 out of the top 3 have already removed
> them (ie, only a fraction of Gmail mail has them at this point).

The top 3 aren't generally large scale botnet spam sources, and botnets 
generally don't use real mail servers (except via AUTH crackers), and 
the top 3 are amply well instrumented with rate limiters etc.  So they 
really aren't relevant to this.