Re: [Shutup] [ietf-smtp] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG (fwd)

Chris Lewis <ietf@mustelids.ca> Wed, 02 December 2015 01:09 UTC

Return-Path: <ietf@mustelids.ca>
X-Original-To: shutup@ietfa.amsl.com
Delivered-To: shutup@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747491B2FF3; Tue, 1 Dec 2015 17:09:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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_20=-0.001, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srRnNeFSwF7N; Tue, 1 Dec 2015 17:09:21 -0800 (PST)
Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F191B2FEF; Tue, 1 Dec 2015 17:09:21 -0800 (PST)
Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB219JFJ023994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 1 Dec 2015 20:09:19 -0500
To: shutup@ietf.org
References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <lGTaHvC8ygXWFAuu@highwayman.com> <1449005349724-ffd73ebb-f70e368e-426663a1@fugue.com> <565E2926.1050900@mustelids.ca> <1449013554783-b461d703-192d4623-50f6eda5@fugue.com>
From: Chris Lewis <ietf@mustelids.ca>
Message-ID: <565E44BE.9060303@mustelids.ca>
Date: Tue, 1 Dec 2015 20:09:18 -0500
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
In-Reply-To: <1449013554783-b461d703-192d4623-50f6eda5@fugue.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/shutup/jux8Vn5oAnpIM4ANEjSCqBpBlYI>
Cc: ietf-smtp@ietf.org
Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG (fwd)
X-BeenThere: shutup@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SMTP Headers Unhealthy To User Privacy <shutup.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/shutup>, <mailto:shutup-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/shutup/>
List-Post: <mailto:shutup@ietf.org>
List-Help: <mailto:shutup-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shutup>, <mailto:shutup-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Dec 2015 01:09:22 -0000

On 12/01/2015 06:45 PM, Ted Lemon wrote:
 > Tuesday, Dec 1, 2015 6:11 PM Chris Lewis wrote:
 >> When your cat's litter box gets infected with, say, cutwail,
 >> spewing gazillions of copies of randomized "come do X to my Y!"
 >> exhortations, you're not giving the receiver (ML or ad-hoc) very
 >> much to distinguish between that and your pearls of wisdom.
 >
 > Er, no, the cat box doesn't have my credentials nor know my email
 > address, so it can't send spam from me.   If it sends spam from
 > someone other than me, the Received header field makes my
 > /legitimate/ email look more like spam, because both the cat's spam
 > and my legitimate email have the same IP address in the Received
 > header field.   In this case I /definitely/ don't want the Received
 > header field.

Er yes, without the MSA-enforced IP address (or unique blob indicating
something similar) the filter can't necessarily tell whether your
legitimate email is different than the cat litter box.  By omitting
the MSA's received line your legitimate mail becomes _less_
distinguishable from the flying litter ... the ML has more chance of
lumping both of youse into the same bucket and so your, er, email ends 
up in the toilet too.

Even when everything is forged/forgeable (eg: regardless of whether
the MSA's headers are forged or decided to be trustworthy), the
uniformity of your Received/From tuples stands out in stark contrast
to the forged stuff (random or otherwise) to the ML - it gives the ML
more to "grab onto".

Now, with my piddly little mail server (which your steam punk mail
server doesn't seem to like BTW), the ML will rarely see enough signal
to do a proper analysis.  But at scale, the ML often will.