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

Brandon Long <> Fri, 04 December 2015 22:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D03831ACD70 for <>; Fri, 4 Dec 2015 14:51:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2X-uEq9vw8xG for <>; Fri, 4 Dec 2015 14:51:20 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ADE091ACD78 for <>; Fri, 4 Dec 2015 14:51:20 -0800 (PST)
Received: by igcto18 with SMTP id to18so46677300igc.0 for <>; Fri, 04 Dec 2015 14:51:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1OyIlIU3hJAyZdl6rajbK9EL9JGN0JJihI8Wl3XgX4I=; b=EUf8QR6IWedNshIe/AZqfjOYL8B/QUsBaEpmIOFWjOUltDAGdSEipTtZ90J0TC9Azk NUk3rPiaM5pAdMf2q8D5LyiXxRhpaxxj0OTldESCqAMDu5LAzob90M4Rl7ZTM+/eJROX faJT5IJPdjHaDB38Nceef1AJVWt8ol8uSXVdRylfe1WV7tEJFxv3KY1/ml9GXl1/cP9K Ne7w2OWcesAyq7aRp0Uw5xXotwWxbBrkwcXm/2NU36n0NZd+4mA2FsDHQdpzORR37R2B 7qbwJIdaS8mFYq3+KZQL3+/hniD48VgpRvcf2IPH+CzEHfdfJYyYIDnHiZvGA/2Y2fS/ td9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1OyIlIU3hJAyZdl6rajbK9EL9JGN0JJihI8Wl3XgX4I=; b=PgDWHfw2HD2cbh6pBEe1N/b4r5HibncDpQx225zh/D9f5PMSZmVXy5NmgRVgYOCkwa LL8xKOJJaGYyLa2q/Oum7A8b93I7Bzo2m6Cd4YPU2H8XckL57cuT2gSrZwNSQtGl1Je3 YhqzywblrMHnccB3FJDIXVI+LDFspHCk96N2p5qngmz4BkNsxyTqanIb60cpIKfsuHKd crpGb0sQ/ys/tDIsQn2fpIuEUopeeV8GSSGFpVm9iRQStUpocz5R07suIHtQAShS1B3y JBW/AGqSTrW9h8I+D7seoa/PvT/QAxQ5XJB0LtSpfQuhqvKE/U7/BNnrjwTzkU8uXnlY PWXQ==
X-Gm-Message-State: ALoCoQkcR1EGapKZkhfM08g7f40RHrF+QnqIkvvPFMKA/fFPT0mBJznzz3hiThCazyizL8fXaUPD4aXO+zUudXOOA5XkW5PntGraCLc7FrpquBhGLSRoiSc=
MIME-Version: 1.0
X-Received: by with SMTP id lr4mr6664613igb.69.1449269479900; Fri, 04 Dec 2015 14:51:19 -0800 (PST)
Received: by with HTTP; Fri, 4 Dec 2015 14:51:19 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Fri, 4 Dec 2015 14:51:19 -0800
Message-ID: <>
From: Brandon Long <>
To: Chris Lewis <>
Content-Type: multipart/alternative; boundary=001a11c1f7a489036005261a5847
Archived-At: <>
Cc:, ietf-smtp <>
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 22:51:23 -0000

On Thu, Dec 3, 2015 at 6:00 PM, Chris Lewis <> wrote:

> 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
> mitigation.
> 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.

We've had to deal with hijacked account spam for years at this point, and
have invested heavily against it, and why we are doing our best to sunset
"programmatic" password based auth, ie:

Of course, oauth isn't quite ready for widespread adoption, due to issues
with discoverability of end-points and software registration.
And a botnet may be able to lift the oauth tokens out of the local
software, but it has some benefits.