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 05:27 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 C07C01A899F for <shutup@ietfa.amsl.com>; Sun, 29 Nov 2015 21:27:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.487
X-Spam-Level:
X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 N-aMplnATrow for <shutup@ietfa.amsl.com>; Sun, 29 Nov 2015 21:27:19 -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 ABAC91A899D for <shutup@ietf.org>; Sun, 29 Nov 2015 21:27:18 -0800 (PST)
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14488612350320.6029548507649451"
From: Ted Lemon <mellon@fugue.com>
To: shutup@ietf.org
In-Reply-To: <01PTP8T9GMFM01729W@mauve.mrochek.com>
References: <20151129181346.9221.qmail@ary.lan> <1448849884345-6302c7ad-3551840c-2a0b598f@fugue.com> <01PTP8T9GMFM01729W@mauve.mrochek.com>
Date: Mon, 30 Nov 2015 05:27:15 +0000
Message-Id: <1448861235657-433b0be9-09d1067c-704d6f94@fugue.com>
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/shutup/9FpYm4qVbWTJf4Dj32T-xegM6FU>
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 05:27:20 -0000

Sunday, Nov 29, 2015 11:53 PM Ned Freed wrote:
> In fact this is now the most common case: Mail is submitted to a large service
> provider which if it exits the administrative domain at all goes directly to
> your administrative domain. The Received: header fields from, say, aol.com is
> entirely trustable, especially since you can check the DKIM signature.

Why would you want to check the Recieved: header fields in this case?   Under what circumstances would checking the header fields in a message known to have been received from aol.com, with a valid DKIM signature, add value over the validation you're already stipulating has happened?

>> Anything else, you have to trace back through the logs hop by hop to actually
>> know that the mail transited those systems; otherwise, an attacker can fake up
>> whatever Received: header fields they want in order to cast blame on whomever
>> they want to harm.
> 
> No, they really can't. See above.

I think we may be talking about different things.   If you are trying to identify spam, you wouldn't need to do this for mail received through aol.com.   I'm talking about the case where someone is committing some kind of illegal behavior that triggers search warrants or other requests for records.  In this case, lawful requests can be satisfied by searching logs, and could not be satisfied by looking at the text of a message.   The data in such a message could not be considered trustworthy.

> And the "from" clause d is far from the only thing of use in a Received: field.
> In fact it's far from the only thing that has privacy implications. Just
> as one example, "with" clauses can be used to indicate whether or 
> not SSL/TLS was used to secure the connection. An unbroken Received: chain
> can provide assurance (or repudiation) of end-to-end transport protection.

Why would that be useful?

> Unfortunately, so far the "analysis" that's been done of the privacy
> considerations of email trace information has been so shallow that stuff  like
> this has been missed. 

I don't think it's so much been missed as found to be of no obvious value.

> Nonsense again. In a world where almost email is spam or worse, any mechanism
> that provides benefits in the fight against spam is beneficial to end users.

Yes, let us think of the children!


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

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