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

Ted Lemon <mellon@fugue.com> Mon, 30 November 2015 22:51 UTC

Return-Path: <mellon@fugue.com>
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 3F9A31B321A; Mon, 30 Nov 2015 14:51:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level:
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 J6trsKua6TPk; Mon, 30 Nov 2015 14:51:33 -0800 (PST)
Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id B4F9E1B3216; Mon, 30 Nov 2015 14:51:31 -0800 (PST)
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14489238886600.5418677132111043"
From: Ted Lemon <mellon@fugue.com>
To: shutup@ietf.org
In-Reply-To: <glJrvFDUtDXWFA87@highwayman.com>
References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <glJrvFDUtDXWFA87@highwayman.com>
Date: Mon, 30 Nov 2015 22:51:28 +0000
Message-Id: <1448923888960-cb7e590f-f443f8dd-7ec594e1@fugue.com>
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/shutup/mLsC-3cA2HjBqF5S7Exl3-AZ7yc>
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: Mon, 30 Nov 2015 22:51:35 -0000

Monday, Nov 30, 2015 7:04 AM Richard Clayton wrote:
> In message <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com>om>, Ted
> Lemon <mellon@fugue.com> writes
> ... and one of the things that the ML will be processing will be the
> (tokenised contents of the) header fields... so having a pattern (of any
> kind) within the header fields has the potential to be extremely helpful
> in distinguishing good from bad

Very true.   And it's likely that there is some percentage, P, of messages that are prevented from being delivered because that information is in the Received: header field.   If P is 99, obviously we'd better not take that information out of the Received: header field.   If it's .0001, then this isn't a good argument for retaining the information.

> It rather escapes me how one of your users will be able to determine
> whether you received the email from a domain which had SPF at the time
> at which you received it unless you record that information along with
> the email (or do you think that DNS results are constant for all time?)

Anything that involves a volitional act on the part of some person is an exception.   The interesting question is, does SPF provide me any greater effectiveness in my system's automatic behaviors.   The answer is yes.

> If you're relaying the email on to somewhere else then you're assuming
> that there's a mechanism by which your policy regarding SPF becomes
> known to those other people.

Why would I be relaying mail on?   Only for a mailing list.   For the mailing list, what I want SPF to validate is that the mail came from the mailing list.   I'm relying on the mailing list provider to filter spam in this case; any secondary spam filtering that I do on the tail end is going to be compromised by the loss of information when the mail goes through the list relay.   Still might be worth it, but what is the value of P in this case, for a general solution, as opposed to a one-off heuristic?

>>   If there is no SPF for the domain 
>>that sent the message, I would like to just discard it as spam, but that's not 
>>safe to do because so many small sites don't implement SPF or get it wrong.   
>>But in any case where there is no SPF record, the site is definitely not 
>>trustworthy:
> 
> that's a shame, I consider myself very trustworthy and I've never
> bothered with SPF :-(

Right, and because you don't use SPF, I can't whitelist you, because anybody can send me mail claiming to be from you, and I have no prima facie basis for rejecting it (unless you use DKIM, I suppose).  The problem isn't that _you_ aren't trustworthy: it's that your system for delivering mail to me isn't.  I could maybe study your headers over time and come up with some heuristic or machine-learning system that would distinguish between you and an imposter, but you're making me do a hell of a lot of work when setting up SPF is really quite easy.


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/mellon@fugue.com