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

Chris Lewis <clewis@mustelids.ca> Tue, 01 December 2015 18:22 UTC

Return-Path: <clewis@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 D86701AD10A; Tue, 1 Dec 2015 10:22:04 -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 cLG1Qc3jBXl6; Tue, 1 Dec 2015 10:22:03 -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 8DF4A1B2E85; Tue, 1 Dec 2015 10:22:03 -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 tB1ILpVk028887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 1 Dec 2015 13:21:51 -0500
To: Ted Lemon <mellon@fugue.com>, shutup@ietf.org
References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <glJrvFDUtDXWFA87@highwayman.com> <1448923888960-cb7e590f-f443f8dd-7ec594e1@fugue.com> <565CD58D.9080403@dcrocker.net> <1448924778159-4b16d8e4-631c41b1-52b0fbf2@fugue.com> <605ee74e-863d-47cb-9089-fb83e13e4e38@gulbrandsen.priv.no> <565D9CFC.6070102@pscs.co.uk> <1448988713596-9f0a5014-48bb3a2c-8e1bc938@fugue.com>
From: Chris Lewis <clewis@mustelids.ca>
X-Enigmail-Draft-Status: N1110
Message-ID: <565DE53F.2080904@mustelids.ca>
Date: Tue, 1 Dec 2015 13:21:51 -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: <1448988713596-9f0a5014-48bb3a2c-8e1bc938@fugue.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/shutup/AU1zWZ0JUIAJjY-ww63IEwhuiq8>
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: Tue, 01 Dec 2015 18:22:05 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/01/2015 11:51 AM, Ted Lemon wrote:

| We are seeing providers right now disappearing IP address
| information for the submission IP source address, so your logic
| here would suggest that there is in fact a downside to including
| that information; otherwise it would not have disappeared.

What we have now is a very small number of providers doing this on
purpose (I can count the number of major providers doing it with the
fingers of one hand), and a still very small, but marginally larger
set of providers not providing it because their infrastructure doesn't
know what it is and/or their software just doesn't do it for one
reason or another.

On the other hand, we can see that that the lack of that information
presents difficulties to filtering technologies.  When you get a
series of harassing emails from a given site originating from a given
user that's forging from lines and mutating content, you have nothing
concrete to filter on to distinguish it from other email from the same
provider.

Leaving you with an all or nothing situation of blocking the whole
provider.  Which isn't a big drawback if the provider is good at
stopping abuse because the problem won't last long, but, the largest
provider in question often isn't, especially in the case of individual
harrassment.  Indeed, without that information being present (or not
being accessible without great effort using the provider's server
logs), it can cause significant difficulty for the provider doing
anything about it even if they wanted to.  IOW: if even the provider
doesn't know where it's coming from (or if finding out is too
expensive to do at scale), then everybody (including the poor user
with the infected box) is SOL.

One of your other points is that the received lines aren't
standardized.  Well, yes, that's true.  But that is in fact an
advantage to filters.  The simple fact of different
formats/idiosyncratic behaviour gives filtering technologies more
leverage to make filtering decisions that have nothing whatsoever to
do with IP addresses.  We use this sort of information to great
benefit - as do the largest email providers.

"Standardized" or not, Received lines provide a rich detail of fodder
for filtering, whether or not the filter manages to understand what
the received line is trying to say about where the email allegedly
came from or how it got there.  The IP could just as easily be a
non-reversible encrypted blob unique to the sending user that only the
provider understands, but the receiver can filter on.

I say "allegedly", because the actual source (personal attribution) of
the email is generally irrelevant to filtering. Our primary goal is
stopping the trash, a secondary goal is helping the infectee fix their
problem, but if the provider wants to interfere with the latter, well,
we can live with it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJWXeU/AAoJENy2YTBCU1ml+vkIALKzFFDYa3MBHn8JXzkYnkpK
9otrKipY4c07C8A4zfggMautyZWXe73msvmZDZoWng+qUE/MggKtvEYHgEIsFp0+
TUElwxOwA4Ftmb2CdtQPhtuoXQP4fIWMmkWuuZf6GuvKxGbl8dVpfWxmjvyy3LEh
RJmvKwzxw4yf+MNzbdtfEy+bveXTEemAFPnu3TO4mZI5a/3RReVdiEyC3/oi4AYG
wQTfBegLvAiHdqBeQecqh531E0e0No9n8g8ElwZS1PDShM6SG7Nk+XYNKXwYRvXg
ifNSCYu4gm0Xn/KGF1wYd/0Wfvp9jd6cRPJ1Eq5nbNm0zXOao+McZfmGDsr2aGI=
=FY2y
-----END PGP SIGNATURE-----