From nobody Wed Nov 25 08:10:23 2015 Return-Path: X-Original-To: shutup@ietf.org Delivered-To: shutup@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEBD1B2C5F; Wed, 25 Nov 2015 07:50:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151125155025.6781.94353.idtracker@ietfa.amsl.com> Date: Wed, 25 Nov 2015 07:50:25 -0800 Archived-At: X-Mailman-Approved-At: Wed, 25 Nov 2015 08:10:22 -0800 Cc: alexey.melnikov@isode.com, shutup@ietf.org, linus@nordberg.se Subject: [Shutup] New Non-WG Mailing List: Shutup -- SMTP Headers Unhealthy To User Privacy X-BeenThere: shutup@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: SMTP Headers Unhealthy To User Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 15:50:26 -0000 A new IETF non-working group email list has been created. List address: shutup@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=shutup To subscribe: https://www.ietf.org/mailman/listinfo/shutup Purpose: Discuss ways in which user privacy can be protected when sending email, by making changes to the way header fields are used. For additional information, please contact the list administrators. From nobody Thu Nov 26 05:46:58 2015 Return-Path: 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 6A54D1B39C0 for ; Thu, 26 Nov 2015 05:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.585, 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 yzoWlUOT4hCQ for ; Thu, 26 Nov 2015 05:46:55 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id C92E31B39BF for ; Thu, 26 Nov 2015 05:46:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1448545611; d=isode.com; s=selector; i=@isode.com; bh=klU7qq9TkRemSu4UDTwMEP8GCNhYVZUIQiDyoWHyQ6Y=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ZFOZNw7KjRRMLJKWKLmdjsU9LTTy2czOVQP0YiC1EuqxTggikLclq2R22fKUsz/wAPaBCP oAwgWVpnpvqbPMjHQRaToTuyHjCWWS9sd7H4aWJq5GDV4QivPJAKVE3fu49Zj4JUWWFJQF +bGiX1G0brlHW9hfLIVV7D9UYk5PI5s=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 26 Nov 2015 13:46:50 +0000 Message-ID: <56570D35.1050806@isode.com> Date: Thu, 26 Nov 2015 13:46:29 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 To: shutup@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Murray S. Kucherawy" Subject: [Shutup] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG X-BeenThere: shutup@ietf.org 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: Thu, 26 Nov 2015 13:46:56 -0000 Hi, I will repost updated charter proposal after a few more people join the mailing list, but in order to bootstrap the public discussion, here is the latest version. I've used the version provided by Patrik Wallstrom and addressed private comments received from Murray Kucherawy. Other then fixing typos, he suggested to describe what is out of scope and he also asked to clarify relationship with DMARC WG which might be going in the opposite direction in regards to data minimization in the Received header fields. I also replaced "SMTP protocol" with "Email" in a couple of places where the former was not correct. So the latest proposal is below: -------------------------- Charter for SMTP Headers Unhealthy To User Privacy Header fields in Email messages can reveal private information to an observer that might be used for attacking an organization or an individual. The goal of this working group is to reduce the amount of private information exposed by Email header fields through: * well-engineered improvements to the SMTP protocol and * guidance for SMTP implementors and deployments on privacy-preserving practices Some examples of privacy-sensitive header fields: SMTP [RFC5321] requires that each successive SMTP relay adds a "Received" header field to the mail headers. These fields are used for audit and debugging of mail transmission, mail loop prevention, and as input to spam detection algorithms. However, Received header fields also leak address and timing information that can expose user location, internal network operational details, and inter-organizational peering arrangements that may not otherwise be public knowledge and may increase risks to those users and organizations. Other header fields also contain sensitive information that is not strictly needed for SMTP transport but are sometimes used for debugging, such as comment fields in header fields like Mime-Version [RFC2045], or common extension header fields like User-Agent, X-Mailer, etc. Indication of a specific Mail User Agent or toolchain may expose users to tailored attacks. When e-mail messages are end-to-end encrypted (e.g. PGP/MIME [RFC3156] or S/MIME [RFC5751] multipart/encrypted messages), some header fields expose substantial amounts of metadata that are not relevant or necessary for functional SMTP service but are customarily expected by the recipient of the mail, including Subject, From, To, Cc, References, and In-Reply-To. While some work has been done previously to specify protection for these header fields in encrypted messages [RFC2634], these solutions are not widely deployed and messages using them often have interoperability and end-user UI/UX problems due to their structure. The working group will prioritize privacy-preserving Email header field minimization techniques that are interoperable with existing e-mail deployments and that avoid unnecessary degradation of mail service and user experience. The working group with liaise with DMARC WG to make sure that changes to email handling are compatible with DMARC or at least discuss cons and pros of using DMARC with changes suggested in this working group. The working group can discuss related work, but work on any items other then the 3 listed below would require rechartering. Work items: * draft-josefsson-email-received-privacy * https://modernpgp.org/memoryhole/ * Privacy-preserving mail loop prevention From nobody Thu Nov 26 09:40:26 2015 Return-Path: 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 7D6841B2CD2 for ; Thu, 26 Nov 2015 09:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.567 X-Spam-Level: ** X-Spam-Status: No, score=2.567 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=1.004, 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 Uq69YxzQLCEo for ; Thu, 26 Nov 2015 09:40:24 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495BD1B2CCB for ; Thu, 26 Nov 2015 09:40:24 -0800 (PST) Received: (qmail 25874 invoked from network); 26 Nov 2015 17:40:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6511.56574407.k1511; bh=MrZNLmE6aOjouHlb79bTcozFDd9QPtDUihdv0uo1xuc=; b=A5dEQ0dmXAbqZx5UGilhglEvJReBxDRhxwZSGasJLDeqqTvQFXDgOfEnBO+VfqOHuYK+Y/fw/WMexAjMlZ4W3YGZTYs0N8taqfFi26LcpJ2C83199ig05pVCky+9oxRtijys21KsxKD07ivVpQe6j/OiBfnVyB1QRcx51SZzH+9z6ZchdaqHCbeUWz3btSFyPOUuV+4nQzkp+rwlHypkxrZ1o1lRL+31VczeT4yFzZJ7TSbRskDdTNhoRMJzLoiR DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6511.56574407.k1511; bh=MrZNLmE6aOjouHlb79bTcozFDd9QPtDUihdv0uo1xuc=; b=lw+GhWUOgGaRCUmObz+sT7dpnHVI969xrLCRnaKYsqxHw5Dxb+vOAyRl7FxTJi/cXZqb5uHJzIvOiDRHEBaS/EVgClI1BCBX4HL/aM9ohcAdVczrMcrVU8QwX9PPccazIiuZHAXfHbAKEVbXxx2gw3Qx/6Zzx/twiuZjWyNNNVcNPKidiNP2uQwOhsKGgnj3v3+hChVWfqmkDheEVxJfWo9ApczYd2QuLTay2gvXWUsDDDnWk3pTinfxNd6/2IS9 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 26 Nov 2015 17:40:22 -0000 Date: 26 Nov 2015 12:40:22 -0500 Message-ID: From: "John R Levine" To: "Alexey Melnikov" In-Reply-To: <56570D35.1050806@isode.com> References: <56570D35.1050806@isode.com> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: shutup@ietf.org Subject: Re: [Shutup] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG X-BeenThere: shutup@ietf.org 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: Thu, 26 Nov 2015 17:40:25 -0000 For most Internet mail users, the main privacy threat they face from e-mail is getting their personal and financial information stolen by malware and phishes. I can assure you from extensive experience that ISPs, security nonprofits like Team Cymru, and law enforcement in many countries exert huge efforts to identify and shut down and, sometimes, arrest and jail the criminals who do that. We use all the information in mail headers to do that. I even have taught courses to law enforcement people to explain how to decode mail messages so they can use them as evidence to build cases against botnet operators and malware authors and distributors. The charter needs to be rewritten to acknowledge the real issues that users face, the reality that personal security is as important a human right as privacy*, and the fact that the tradeoffs are difficult and subtle. R's, John * - See the Universal Declaration of Human Rights, articles 3, 8, 12, and 17. From nobody Sun Nov 29 09:25:51 2015 Return-Path: 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 0B6821A9097; Sun, 29 Nov 2015 09:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 dymdk3pMRrXa; Sun, 29 Nov 2015 09:25:48 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0694E1A9053; Sun, 29 Nov 2015 09:25:48 -0800 (PST) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id tATHPlfn028352 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sun, 29 Nov 2015 09:25:47 -0800 References: <565A7234.7010000@alameth.org> <072F93223CD351A88ECCDB69@JcK-HP5.jck.com> To: Chris Newman , ietf-smtp@ietf.org, shutup@ietf.org From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <565B351B.7090104@dcrocker.net> Date: Sun, 29 Nov 2015 09:25:47 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 29 Nov 2015 09:25:47 -0800 (PST) Archived-At: 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 Reply-To: dcrocker@bbiw.net List-Id: SMTP Headers Unhealthy To User Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 17:25:49 -0000 On 11/29/2015 9:12 AM, Chris Newman wrote: > ==== > This WG will investigate mechanisms to conceal the information exposed > by the submission client's IP address in the mandatory received header > generated by the submission server. The output of this WG will provide a > mechanism as effective at tracing abuse and fraud as current use of the > submission client's IP address. Changing other rules related to received > headers in SMTP is out of scope for this WG. > ==== Chris's approach is reasonable, but I fear it is premature. The foundational issue here is a trade-off between information hiding and information disclosure. Privacy vs. ops support. I've seen essentially no public discussions, here or anywhere else, about the technical aspects of this policy tradeoff. Absent some community-based sense of the underlying technical issues here, targeting a specification is, in my view, not ready for prime time. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Nov 29 10:33:04 2015 Return-Path: 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 0DA261B3152; Sun, 29 Nov 2015 10:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.585, 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 md49FjnrIqqr; Sun, 29 Nov 2015 10:33:01 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 9126A1B314F; Sun, 29 Nov 2015 10:33:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1448821980; d=isode.com; s=selector; i=@isode.com; bh=+IrniIDXvCr7hmPcq1Z0p/RX+OEXOcdDdG/ljaLBORo=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=N0fniHtPbnPS12uDesBYVwDeSMtweSpDoMy82w2Vwvk9tsJ8soh8/+wWtvLBdvljQrtAlJ rALvd++N2OpAY+jVd5UqouxVFPG8y7276HYruGHjCVGsoW/OqYh+dgnryJlhvVqNe/pDS7 EndhewO2vSXpl/f5q+UPcUnl5kI6kE4=; Received: from [192.168.0.6] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 29 Nov 2015 18:33:00 +0000 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (13B143) In-Reply-To: Date: Sun, 29 Nov 2015 18:34:46 +0000 Message-Id: <5A108ED8-1EDB-42CD-85A5-9BC536D6419D@isode.com> References: <565A7234.7010000@alameth.org> <072F93223CD351A88ECCDB69@JcK-HP5.jck.com> To: Chris Newman MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-A6483F38-C84A-41F9-B818-18881E3E0BF5 Content-Transfer-Encoding: 7bit Archived-At: Cc: shutup@ietf.org, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 18:33:03 -0000 --Apple-Mail-A6483F38-C84A-41F9-B818-18881E3E0BF5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Chris, > On 29 Nov 2015, at 17:12, Chris Newman wrote: >=20 > I oppose the current shutup charter text and draft-josefsson-email-receive= d-privacy as both promote the elimination of mechanisms that protect users f= rom fraud and abuse. >=20 > As I do care about user privacy, here's a strawman charter that I would su= pport: >=20 > =3D=3D=3D=3D > This WG will investigate mechanisms to conceal the information exposed by t= he submission client's IP address in the mandatory received header generated= by the submission server. The output of this WG will provide a mechanism as= effective at tracing abuse and fraud as current use of the submission clien= t's IP address. Changing other rules related to received headers in SMTP is o= ut of scope for this WG. > =3D=3D=3D=3D I think this is a very reasonable counter proposal. To address concerns from other people it might be worth tweaking it, so that= if after investigation no reasonable proposal can be produced, the group sh= ould produce a document describing why the problem is not tractable or not w= orth solving considering tradeoffs. >=20 > I believe RFC 2442 combined with PGP or S/MIME adequately protects email h= eaders. I worked on an implementation of that in the 1990s. I'm doubtful the= memory-hole proposal is sufficiently better or sufficiently likely to deplo= y to be worth IETF effort. There might be more will to implement something this time around. Whether th= e memory-hole proposal is it, I don't know. Best Regards, Alexey= --Apple-Mail-A6483F38-C84A-41F9-B818-18881E3E0BF5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Chris,

On 29 Nov 2015= , at 17:12, Chris Newman <chri= s.newman@oracle.com> wrote:

I oppose the current shutup charter text and draft-josefss= on-email-received-privacy as both promote the elimination of mechanisms that= protect users from fraud and abuse.

As I do care about user privacy, here's a strawman charter that I woul= d support:

=3D=3D=3D=3D
This WG will investigate mechanisms to conceal= the information exposed by the submission client's IP address in the mandat= ory received header generated by the submission server. The output of this W= G will provide a mechanism as effective at tracing abuse and fraud as curren= t use of the submission client's IP address. Changing other rules related to= received headers in SMTP is out of scope for this WG.
=3D=3D=3D=3D

I think this is a very reasonable counter proposal.

To address concerns from other people it might be worth tweaking it, s= o that if after investigation no reasonable proposal can be produced, the gr= oup should produce a document describing why the problem is not tractable or not worth so= lving considering tradeoffs.

<= div id=3D"bloop_customfont" style=3D"margin: 0px; ">

I believe RFC 2442 combined with PGP or S/MIME adequately protects email he= aders. I worked on an implementation of that in the 1990s. I'm doubtful the m= emory-hole proposal is sufficiently better or sufficiently likely to deploy t= o be worth IETF effort.

There m= ight be more will to implement something this time around. Whether the memor= y-hole proposal is it, I don't know.

Best Regards,<= /div>
Alexey
= --Apple-Mail-A6483F38-C84A-41F9-B818-18881E3E0BF5-- From nobody Sun Nov 29 13:02:32 2015 Return-Path: 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 EE63E1B3B07 for ; Sun, 29 Nov 2015 13:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.567 X-Spam-Level: ** X-Spam-Status: No, score=2.567 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=1.004, 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 OIZr3QzWsDp9 for ; Sun, 29 Nov 2015 13:02:30 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C86C31B3B03 for ; Sun, 29 Nov 2015 13:02:29 -0800 (PST) Received: (qmail 36125 invoked from network); 29 Nov 2015 21:02:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=resent-date:resent-from:resent-to:resent-message-id:date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=8d1c.565b67e4.k1511; bh=7Rzt1u3EXI6ZY4yLFtRPZYMhr74t9i0/QahslVO/y0M=; b=roOuyexlaiV1DTLOX6o6oBC3YEugatKNGSYtZ2U+yCpu5rn9lZg6b1bL9mxplTOUD1y/A+qvfkZ3UKjrehPzaARdV9QdCl2U+y7CoIS1rAmHM90Bws3sUP15Kwrotm/WjauC1Z5y6x/TKCDJEV4Vp2gwse7UB2oqWmOPRSD5pxNJyuunYQ9zQ6p5qi1ZBHtU0MSIsZ2fDZy6lZspxM3dhg0WBe+HvfYS2Dq6diTPOTDWXZWDEygwGBAlXBpcSa3L DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=resent-date:resent-from:resent-to:resent-message-id:date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=8d1c.565b67e4.k1511; bh=7Rzt1u3EXI6ZY4yLFtRPZYMhr74t9i0/QahslVO/y0M=; b=XJxG3A1HKzqrZkCoJwJy31pHABU/VU73CeyFoCaI+veFx/1pSHXpFPkKlUGpYnEfDhLt5ZacXxeL193cOLeoGsC5j0xH80Ig5XrZDwUX+keKWlJSoV7fc8QgkW/QvDcVn4Hb6YltgKBuizuPF7fr+rgVrKbLS3IoprDukP5c6mmKbeGRhtr730sXg+LwiFd31C0jWCedsKpf3TpCh3ZWsTzDefu+0MyuaeQ0fgMaSgE27KSGN7A8ZhMYJaeDvX98 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 29 Nov 2015 21:02:28 -0000 ReSent-Date: Sun, 29 Nov 2015 16:02:15 -0500 (EST) ReSent-From: "John R. Levine" ReSent-To: shutup@ietf.org ReSent-Message-ID: Date: 29 Nov 2015 18:13:46 -0000 Message-ID: <20151129181346.9221.qmail@ary.lan> From: "John Levine" To: ietf-smtp@ietf.org X-Return-Path: X-Delivered-To: johnl-sent@iecc.com X-Received: (qmail 13882 invoked from network); 29 Nov 2015 18:14:08 -0000 X-Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 29 Nov 2015 18:14:08 -0000 In-Reply-To: <565B351B.7090104@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit ReSent-Subject: Re: [ietf-smtp] [Shutup] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG (fwd) ReSent-User-Agent: Alpine 2.11 (OSX 23 2013-08-11) Archived-At: Cc: dcrocker@bbiw.net, shutup@ietf.ort 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 21:02:31 -0000 >The foundational issue here is a trade-off between information hiding >and information disclosure. Privacy vs. ops support. It's not even privacy vs. ops support, it's privacy issues via some hints of sender's location vs. privacy issues via the recipient getting spammed, phished, and malware'd. You are completely correct that there's been no discussion at all of the tradeoffs. After all, the vast majority of mail these days is malicious, and the largest mail provider in the world already redacts most senders' location info. R's, John From nobody Sun Nov 29 13:58:58 2015 Return-Path: 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 852411B35A0; Sun, 29 Nov 2015 13:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.886 X-Spam-Level: X-Spam-Status: No, score=-4.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, 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 4aVLDrOXK2qE; Sun, 29 Nov 2015 13:58:54 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8221B359E; Sun, 29 Nov 2015 13:58:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4C828BE2C; Sun, 29 Nov 2015 21:58:46 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJf3U_IEyhfu; Sun, 29 Nov 2015 21:58:45 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.20.32]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 73532BE5D; Sun, 29 Nov 2015 21:58:44 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1448834325; bh=B5/SyN/nfAOS7kdDhdAC/NoJyeMTFs3kSOGIdLadPnY=; h=From:Subject:To:References:Cc:Date:In-Reply-To:From; b=MvU8jHUnhNhyGewjX3dmAdmJYgE6bvY0Z13mPSvSWb6nfVoh5FL2NBsbxrJ/MtOzP bjYCM3jdKQcAHs4Sw3U++WDm4zMTQQvnd/0XGtAbb1nurZCOmgw31S+8Lzup/Qi6te spWKkgch1n7KhwVMlVMO7FHT2F6j64QIu+bhd92c= From: Stephen Farrell To: John Levine , ietf-smtp@ietf.org References: <20151129181346.9221.qmail@ary.lan> Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <565B7514.70102@cs.tcd.ie> Date: Sun, 29 Nov 2015 21:58:44 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151129181346.9221.qmail@ary.lan> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: shutup@ietf.org, dcrocker@bbiw.net 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 21:58:55 -0000 (Re-tx - there was an address typo in the earlier message) On 29/11/15 18:13, John Levine wrote: > the largest mail provider in the world already redacts > most senders' location info. As I understood it, one of the possible outcomes of this effort might be to document the kinds of redactions that have been done so that others could do similarly. I've no clue as to whether that'd result in a menu of "things one can do," or if there are parts of that that may end up as standards, but a good first step might be to document what's been done already, esp if it's different in different mail providers and if those variations have different impacts elsewhere in the overall mail infrastructure. Seems like the above would be a useful start anyway. (If it's not been done already - there's no reason such stuff absolutely has to be in an RFC.) S. From nobody Sun Nov 29 14:53:45 2015 Return-Path: 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 B96C11B384A; Sun, 29 Nov 2015 14:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6, RP_MATCHES_RCVD=-0.585, 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 5n0CfJehtwIk; Sun, 29 Nov 2015 14:53:43 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1551C1B3847; Sun, 29 Nov 2015 14:53:43 -0800 (PST) Received: from [IPv6:2001:470:1f05:bfe:a06d:6a7c:4078:aebf] ([IPv6:2001:470:1f05:bfe:a06d:6a7c:4078:aebf]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id tATMrfPA024552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 29 Nov 2015 14:53:42 -0800 To: ietf-smtp@ietf.org, shutup@ietf.org References: <565A7234.7010000@alameth.org> <072F93223CD351A88ECCDB69@JcK-HP5.jck.com> From: Jim Fenton X-Enigmail-Draft-Status: N1110 Message-ID: <565B81F4.8090401@bluepopcorn.net> Date: Sun, 29 Nov 2015 14:53:40 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------070004060306030506090107" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1448837622; bh=Sgg9krUwaXPkP+Jq1Kayd7nsI+zlMaff++YhhTxRhd4=; h=Subject:To:References:From:Date:In-Reply-To; b=cVGlQurlmkeLtRvzFkvIpnU9ONhj8vxBgZx2uVYDSYpYfLPCzy12BriqFBKg/o3Bb 18tD5u6EXNNixqxFlgiJeA0esdwdfF3F5ruJCuhnkL8Gr1sTgAxrKQ1R+dhMt3PyYU YvRaoeLxoJrn0v+AJBaiq3/N6JHw/7vRUZFnUN00= Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 22:53:44 -0000 This is a multi-part message in MIME format. --------------070004060306030506090107 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/29/2015 09:12 AM, Chris Newman wrote: > I oppose the current shutup charter text > and draft-josefsson-email-received-privacy as both promote the > elimination of mechanisms that protect users from fraud and abuse. Agreed, and to be more specific: The proposed charter speaks of Received header fields leaking address information that can expose user location. Yes, they can. But, in general, that information is essential to identifying spoofed header fields: it's by tracing the chain of "from" addresses in Received header fields that one can determine that someone is attempting to do something fraudulent. Further, I don't have a lot of sympathy for organizations that rely on the secrecy of their network topologies as an essential security component. We're trying to increase the trust in email, not reduce it. There are users for whom their privacy is critically important, such as press informants in totalitarian societies. There are many other ways to determine their location (network monitoring coupled with a STARTTLS downgrade attack, for one), and it would be harmful (potentially life-threatening) if anyone thought that this would truly protect them. They should be using something like SecureDrop and not using email at all= =2E draft-josefsson-email-received-privacy mentions the issue of senders' locations appearing on mailing lists and in mailing list archives. I have long felt that we are conflicted on whether the output of a mailing list is a new message or the same as the one sent to the mailing list. It usually has a different MAIL FROM address, and often has text added to the message body, which I would think is enough of a change to make it a new message. Yet the Message-ID and Received header fields are preserved. I would think that an entire new message should be created,a new Message-ID assigned, and DKIM signed by the mailing list's domain (of course!). Only selected header fields would be transferred to the new message. The original incoming header fields should be available only to the list administrators, who deal with abuse issues. What would the motivation be for anyone to implement any header privacy improvements? There is far too much deployed infrastructure to get a change to be made, absent a very strong business case. We could spend a lot of time on this and not have it matter a bit. I would support some work on the mailing list issue resulting in a set of recommended practices, and possibly guidance on obscuring the source IP address when an authenticated submission is made to an MSA. But that's it. -Jim --------------070004060306030506090107 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 11/29/2015 09:12 AM, Chris Newman wrote:
I oppose the current shutup charter text and draft-josefsson-email-received-privacy as both promote the elimination of mechanisms that protect users from fraud and abuse.

Agreed, and to be more specific:

The proposed charter speaks of Received header fields leaking address information that can expose user location. Yes, they can. But, in general, that information is essential to identifying spoofed header fields: it's by tracing the chain of "from" addresses in Received header fields that one can determine that someone is attempting to do something fraudulent. Further, I don't have a lot of sympathy for organizations that rely on the secrecy of their network topologies as an essential security component. We're trying to increase the trust in email, not reduce it.

There are users for whom their privacy is critically important, such as press informants in totalitarian societies. There are many other ways to determine their location (network monitoring coupled with a STARTTLS downgrade attack, for one), and it would be harmful (potentially life-threatening) if anyone thought that this would truly protect them. They should be using something like SecureDrop and not using email at all.

draft-josefsson-email-received-privacy mentions the issue of senders' locations appearing on mailing lists and in mailing list archives. I have long felt that we are conflicted on whether the output of a mailing list is a new message or the same as the one sent to the mailing list. It usually has a different MAIL FROM address, and often has text added to the message body, which I would think is enough of a change to make it a new message. Yet the Message-ID and Received header fields are preserved. I would think that an entire new message should be created, a new Message-ID assigned, and DKIM signed by the mailing list's domain (of course!). Only selected header fields would be transferred to the new message. The original incoming header fields should be available only to the list administrators, who deal with abuse issues.

What would the motivation be for anyone to implement any header privacy improvements? There is far too much deployed infrastructure to get a change to be made, absent a very strong business case. We could spend a lot of time on this and not have it matter a bit.

I would support some work on the mailing list issue resulting in a set of recommended practices, and possibly guidance on obscuring the source IP address when an authenticated submission is made to an MSA. But that's it.

-Jim

--------------070004060306030506090107-- From nobody Sun Nov 29 17:02:30 2015 Return-Path: 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 BBBCE1B3D5A for ; Sun, 29 Nov 2015 17:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] 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 W1ThJwjKTwni for ; Sun, 29 Nov 2015 17:02:27 -0800 (PST) Received: from xsmtp06.mail2web.com (xsmtp26.mail2web.com [168.144.250.193]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672911B3D57 for ; Sun, 29 Nov 2015 17:02:27 -0800 (PST) Received: from [10.5.2.11] (helo=xmail01.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1a3CrJ-0006v3-8v for shutup@ietf.org; Sun, 29 Nov 2015 20:02:26 -0500 Received: (qmail 29163 invoked from network); 30 Nov 2015 01:02:24 -0000 Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[72.235.151.78]) (envelope-sender ) by xmail01.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 30 Nov 2015 01:02:23 -0000 From: "Christian Huitema" To: "'Jim Fenton'" , , References: <565A7234.7010000@alameth.org> <072F93223CD351A88ECCDB69@JcK-HP5.jck.com> <565B81F4.8090401@bluepopcorn.net> In-Reply-To: <565B81F4.8090401@bluepopcorn.net> Date: Sun, 29 Nov 2015 15:02:57 -1000 Message-ID: <015801d12b0a$dc8731d0$95959570$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQDViSzVEAomjdiWLJi2G+4e/BH4eQBMFf/cAsRad00CzkP00wJ+WwCBAQ2ZiU2gX6mjYA== Content-Language: en-us Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 01:02:28 -0000 On Sunday, November 29, 2015 12:54 PM, Jim Fenton wrote: > > There are users for whom their privacy is critically important, such > as press informants in totalitarian societies. There are many other > ways to determine their location (network monitoring coupled with > a STARTTLS downgrade attack, for one), and it would be harmful > (potentially life-threatening) if anyone thought that this would truly > protect them. They should be using something like SecureDrop and > not using email at all. Uh, No. This is the classic "the other side of the boat is leaking too" argument, coupled with a dollop of "no security is better than imperfect security." Yes, there are many ways for metadata to leak. But that does not mean that we should not plugs the leaks that we do know about. The discussion so far shows that one hand many people believe that we are disclosing too much metadata in mail headers, while many more believe that the metadata disclosure is actually useful to fight various forms of abuse, some of which may well compromise users' privacy. We also heard that some of the big providers have already unilaterally decided to suppress some of the metadata, like the first hop address. So we have at least one data point showing that not all metadata needs to be preserved. The "submission" hop may be a special case, but as Jim points out, mailing lists may well another special case, for which some guidance would be useful. The concern about topology disclosure may or may not justify pruning some of the metadata. In short, it appears that there is enough concern and enough uncertainty to justify working at least on an analysis document, and depending on the outcome on a best practice document. Let's have this debate, and let's make some progress on email privacy. -- Christian Huitema From nobody Sun Nov 29 18:18:11 2015 Return-Path: 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 E7B341A1B98 for ; Sun, 29 Nov 2015 18:18:10 -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 bCoxWiNsVHId for ; Sun, 29 Nov 2015 18:18:09 -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 4775A1A1B86 for ; Sun, 29 Nov 2015 18:18:08 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14488498833040.29079446429386735" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <20151129181346.9221.qmail@ary.lan> References: <20151129181346.9221.qmail@ary.lan> Date: Mon, 30 Nov 2015 02:18:03 +0000 Message-Id: <1448849884345-6302c7ad-3551840c-2a0b598f@fugue.com> MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 02:18:11 -0000 ------sinikael-?=_1-14488498833040.29079446429386735 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Sunday, Nov 29, 2015 1:13 PM John Levine wrote: > It's not even privacy vs. ops support, it's privacy issues via some > hints of sender's location vs. privacy issues via the recipient > getting spammed, phished, and malware'd. The only Received: header fields that you can trust are the ones that were = added by servers in your administrative domain. 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. That being the case, all the Received: header field needs = to contain is a token that can be used to backtrace the message to its = origin using the logs: anything else is superfluous. So postcarding all = kinds of private information about the end user is not only not actually = useful for the reason you suggest, it is actively harmful to the end user. > You are completely correct that there's been no discussion at all of > the tradeoffs. After all, the vast majority of mail these days is > malicious, and the largest mail provider in the world already redacts > most senders' location info. The conclusion I would draw here is that we ought to advice all the other = providers to do this as well. IOW, this argument supports the proposed = work, rather than showing that it is unnecessary or harmful. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14488498833040.29079446429386735 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWW7HcCRAMw8Nu0HeKywAAmEcIAM0RM3NQi6oeV839hRgF 3ODstKyiI63zxTKo+L7idGoC0MzPXn5cTnT3Munq8tZuNPMh4UJqd3xXMH2a oLWjt3kTxPt1tRz8xe6RJWew1TjJtoboIJiPJwUQ7gukzO7V+45nIfWbyKzb 80ubhZ0397MwvFV5klIuhTWgxF8/aUkwTAcRRpbZScOEWT19fn1xX3cL6tRs a/2QfkI9gP/qFsekChgWsFE/aMfUEKsuBHN7TzNyU0OQY1akuKWL5Zn1jDh+ cw6xeGsGOjJRkdMWxTt7ZCJl0gJ8pOo8Ap2GCgwejolfoMMJC/ZmVGdErcxl xUY6jwMJzpqsKPtim1fjN2M= =/qoq -----END PGP SIGNATURE----- ------sinikael-?=_1-14488498833040.29079446429386735-- From nobody Sun Nov 29 18:25:46 2015 Return-Path: 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 C11BC1A1BAC for ; Sun, 29 Nov 2015 18:25:45 -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 sjpalMFkTrLJ for ; Sun, 29 Nov 2015 18:25:44 -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 070181A1BA9 for ; Sun, 29 Nov 2015 18:25:43 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14488503407460.5043638930656016" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <565B81F4.8090401@bluepopcorn.net> References: <565A7234.7010000@alameth.org> <072F93223CD351A88ECCDB69@JcK-HP5.jck.com> <565B81F4.8090401@bluepopcorn.net> Date: Mon, 30 Nov 2015 02:25:40 +0000 Message-Id: <1448850341365-b08f5b3e-08a47499-bf0b1639@fugue.com> MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 02:25:45 -0000 ------sinikael-?=_1-14488503407460.5043638930656016 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Sunday, Nov 29, 2015 5:53 PM Jim Fenton wrote: > But, in > general, that information is essential to identifying spoofed header > fields: it's by tracing the chain of =22from=22 addresses in Received = header > fields that one can determine that someone is attempting to do something > fraudulent. Can you cite a real-world example of a case where you did something like = this recently, and explain how you were able to do what you claim, above, = is possible using just the header fields in the message=3F -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14488503407460.5043638930656016 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWW7OlCRAMw8Nu0HeKywAAK2wIALyddQG97bvSiq0IP8RP qnyn93LtCZbxPGNXV5KszfPflN8/gAq9Fc8486dCwazdWYvXnBqqUywmtTuN kqfQODMCd9DWkW0Sq80lO8rxtbKJJWV0PoGtJP0Rk9+nvuKN9oNoChCGFNVZ 1hPTPau0ZAmVAH7646aKcu0tcaR1RCVq5V7MwSKdr9ja8fGnHk9Cwapnq7zq PLFG+xP5+fi3DBWiYCG3hEwBOelrRegTlMYJLPVELKns9wq3HYq/LGaPn4Q+ 5nGgfK0T7U+R+22yoIxvvXB5zmkBdGFmkcn5qk9kE89Bp7B4SxdK/r8oJh4k 1xVnOzfi58uPiW+UPugPzOo= =9O+D -----END PGP SIGNATURE----- ------sinikael-?=_1-14488503407460.5043638930656016-- From nobody Sun Nov 29 19:12:15 2015 Return-Path: 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 A36001A6F41 for ; Sun, 29 Nov 2015 19:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.667 X-Spam-Level: ** X-Spam-Status: No, score=2.667 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=1.004, 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 EIoSG5QDgckm for ; Sun, 29 Nov 2015 19:12:13 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FFD81A6F40 for ; Sun, 29 Nov 2015 19:12:13 -0800 (PST) Received: (qmail 93662 invoked from network); 30 Nov 2015 03:12:12 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 30 Nov 2015 03:12:12 -0000 Date: 30 Nov 2015 03:11:50 -0000 Message-ID: <20151130031150.10420.qmail@ary.lan> From: "John Levine" To: shutup@ietf.org, ietf-smtp@ietf.org In-Reply-To: <1448850341365-b08f5b3e-08a47499-bf0b1639@fugue.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: mellon@fugue.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 03:12:14 -0000 >> But, in general, that information is essential to identifying spoofed header >> fields: it's by tracing the chain of "from" addresses in Received header >> fields that one can determine that someone is attempting to do something >> fraudulent. > >Can you cite a real-world example of a case where you did something like this recently, and explain how you were able to do what you >claim, above, is possible using just the header fields in the message? Spam filters have been doing Received chain analysis for about 20 years. The principle is straightforward, the source in each header should match the recipient in the header below it, and timestamps should be in the right order. There's also heuristics based on knowing what real headers from popular mail systems should look like. The scripts I use to send off spam complaints do header analysis to figure out who to complain to, and not to complain to addresses in fake headers, so I'd say I do this about 100 times a day, every day, in addition to spamassassin doing it on every incoming message that it filters. If you want to look at some code, spamassassin is at http://spamassassin.apache.org/. R's, John From nobody Sun Nov 29 19:24:12 2015 Return-Path: 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 D17E31A00C0 for ; Sun, 29 Nov 2015 19:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.667 X-Spam-Level: ** X-Spam-Status: No, score=2.667 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=1.004, 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 pZPGQZSlgdO9 for ; Sun, 29 Nov 2015 19:24:10 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE9FE1A0091 for ; Sun, 29 Nov 2015 19:24:09 -0800 (PST) Received: (qmail 95714 invoked from network); 30 Nov 2015 03:24:08 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 30 Nov 2015 03:24:08 -0000 Date: 30 Nov 2015 03:23:46 -0000 Message-ID: <20151130032346.10484.qmail@ary.lan> From: "John Levine" To: shutup@ietf.org, ietf-smtp@ietf.org In-Reply-To: <1448849884345-6302c7ad-3551840c-2a0b598f@fugue.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: mellon@fugue.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 03:24:11 -0000 >Sunday, Nov 29, 2015 1:13 PM John Levine wrote: >> It's not even privacy vs. ops support, it's privacy issues via some >> hints of sender's location vs. privacy issues via the recipient >> getting spammed, phished, and malware'd. > >The only Received: header fields that you can trust are the ones that were added by servers in your administrative domain. Not at all. If you get mail from a provider you know to be trustworthy, you can trust the headers they add. Given that mail is dominated by large providers, and any individual mail system tends to exchange mail with the same people over and over, you can cover a great deal of your mail with a modest number of sort of special cases for providers you know. For example, I live near Ithaca NY so I exchange a lot of mail with Cornell, which is full of students who never saw a malware-infested game they wouldn't install. So it's useful to have scripts that can look at their headers so I can tell them who needs to be thwacked today. >the Received: header field needs to contain is a token that can be used to backtrace the message to its origin using the logs: Um, we have some scaling issues here. Large providers send and receive billions of messages a day so looking up stuff in the logs is non-trivial. Also, when you're trying to shut down a phish campaign, you want to do it ideally in minutes, at worst hours, not whenever someone can get around to pulling some log info from a distant server. There are a lot of people on ietf-smtp familiar with large mail systems, so perhaps it would be more productive to ask questions about how stuff actually works. R's, John From nobody Sun Nov 29 19:25:08 2015 Return-Path: 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 4E68B1A0102 for ; Sun, 29 Nov 2015 19:25:06 -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 mqQv7g_0g-qZ for ; Sun, 29 Nov 2015 19:25:05 -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 6B3021A00FE for ; Sun, 29 Nov 2015 19:25:04 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14488539010280.9295437661930919" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <20151130031150.10420.qmail@ary.lan> References: <20151130031150.10420.qmail@ary.lan> Date: Mon, 30 Nov 2015 03:25:01 +0000 Message-Id: <1448853901597-329fed8f-51e32284-4f77ee26@fugue.com> MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 03:25:06 -0000 ------sinikael-?=_1-14488539010280.9295437661930919 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Sunday, Nov 29, 2015 10:11 PM John Levine wrote: > Spam filters have been doing Received chain analysis for about 20 > years. Yes, I know. A friend of mine founded a company that worked using this = principal. Unfortunately, it got less and less effective as spammers got = better and better at faking things. The reason I asked for recent = experience is that I'm curious if anyone is =5Fstill=5F getting real = benefit from this. Since the only header-field you can actually trust is the first one that = your own MTA adds, SPF works just as well (actually, a =5Flot=5F better) as= a validation mechanism. If SPF isn't in use, the sender can just claim = to be a legitimate agent for the source domain, and you have no way to = check that claim. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14488539010280.9295437661930919 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWW8GNCRAMw8Nu0HeKywAAySAIAJQXnkLhluYHTYKjpz5y GhYj8f3E96V3TglIWJQqnUZAPZzLL4GuD1rH6LFn7GrZVf0oFLxvMfch5w3p BV6ktPke+PwesEZ6CeblM6L7NJPZK6GkA+bFq+J3APsuvXO5DtbIM2s+Y54e uRx9IgWFXUyYuWOdICwTuu4iHP7UPsNrTCpffpytrhsJTtQcweRyobAItkOO MZsqDGtlgsj8vIr+jHQf865y/oTluaEElpLL+Dg/jQxCnAOlgGxwYYqfve8l 68rh8VAPdlA2QNUPbrZ0yL51mH0BrMZwsSejmoTuKyEtZBecjlyy2znhJn/h 0nk+sD3Z8pBptXShtNw+cZo= =u/Kq -----END PGP SIGNATURE----- ------sinikael-?=_1-14488539010280.9295437661930919-- From nobody Sun Nov 29 20:28:45 2015 Return-Path: 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 391E31A871D for ; Sun, 29 Nov 2015 20:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.667 X-Spam-Level: ** X-Spam-Status: No, score=2.667 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=1.004, 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 I7KG4_cuE5pv for ; Sun, 29 Nov 2015 20:28:43 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 282841A871B for ; Sun, 29 Nov 2015 20:28:43 -0800 (PST) Received: (qmail 5198 invoked from network); 30 Nov 2015 04:28:41 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 30 Nov 2015 04:28:41 -0000 Date: 30 Nov 2015 04:28:19 -0000 Message-ID: <20151130042819.10658.qmail@ary.lan> From: "John Levine" To: shutup@ietf.org, ietf-smtp@ietf.org In-Reply-To: <1448853901597-329fed8f-51e32284-4f77ee26@fugue.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: mellon@fugue.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 04:28:44 -0000 >> Spam filters have been doing Received chain analysis for about 20 years. > >Yes, I know. A friend of mine founded a company that worked using this principal. Unfortunately, it got less and less effective as >spammers got better and better at faking things. The reason I asked for recent experience is that I'm curious if anyone is _still_ >getting real benefit from this. Yes. See the message you just replied to. >Since the only header-field you can actually trust is the first one that your own MTA adds, ... No, that's not correct. See recent message. SPF works just as well (actually, a _lot_ better) as a validation mechanism. What? Header chains say "this message came through this IP". SPF says "I assert that these IPs are allowed to send mail for this domain." They're completely unrelated. We don't use header chains for validation, we use it to figure out who to blame, who to alert, and who to block. R's, John From nobody Sun Nov 29 20:46:54 2015 Return-Path: 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 7901F1A87C9; Sun, 29 Nov 2015 20:46:52 -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 VcYWPA7Ze6wQ; Sun, 29 Nov 2015 20:46:50 -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 EAFE31A87C8; Sun, 29 Nov 2015 20:46:49 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14488587748030.14020563219673932" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <20151130042819.10658.qmail@ary.lan> References: <20151130042819.10658.qmail@ary.lan> Date: Mon, 30 Nov 2015 04:46:14 +0000 Message-Id: <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 04:46:52 -0000 ------sinikael-?=_1-14488587748030.14020563219673932 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Sunday, Nov 29, 2015 11:28 PM John Levine wrote: > Yes. See the message you just replied to. The experience you related sounds like hobbyist activity, no offense. I = can't see how what you described could possibly scale to anything a large = email provider would ever do, and indeed it's not something I would ever = take the trouble to do, even though my domain has exactly two users. If I= get spam, I delete it. I do not complain about it. I do not attempt to = understand where it originated. >>Since the only header-field you can actually trust is the first one that = your own MTA adds, ... >=20 > No, that's not correct. See recent message. I saw the recent message, and again, what you described is something that = doesn't scale. If that is your model for how header-field messages are = used for validation, I think what I said is actually more generally = accurate. Do you seriously think that Google has special-case header = parsing to deal with spam from Cornell students' infected computers=3F No= , they just use machine learning. > SPF works just as well (actually, a =5Flot=5F better) as a validation = mechanism. >=20 > What=3F Header chains say =22this message came through this IP=22. SPF > says =22I assert that these IPs are allowed to send mail for this > domain.=22 They're completely unrelated. SPF allows me to discard all messages that claim to be from domain X but = come from IP addresses not listed for domain X, which means that I never = have to write a Received: header for that message. 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: I cannot rely on the Received: header fields= it included in the message. And if the site =5Fis=5F trustworthy, then = modulo a few small exceptions like Cornell, it's not originating anything = that can be reasonably identified as spam, because if it could have been = reasonably identified as spam, it would never have been forwarded. So I = can't see how the experiences you are describing would motivate the = inclusion of something like an unobfuscated Received: header field across = organizational boundaries if SMTP were being designed today. > We don't use header chains for validation, we use it to figure out who > to blame, who to alert, and who to block. I don't know who =22we=22 is here. Is this really how Google, et al., = operate=3F It sounds like something people like you and me used to do ten= years ago, that some of us old-timers are still doing (I only stopped = using spamassassin recently, for example). I would be okay with being = proven wrong, but the fact that you are still doing this isn't persuasive = to me. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14488587748030.14020563219673932 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWW9SXCRAMw8Nu0HeKywAAqSgIAKg0hckLT8BCgJd3dfag HY/aPJdAbli9Rp+iJkdr/0PbBsXepFMDs0gdtOKWj13H/hMACBiUrTIjNIJm EAIjdbLvsZZBJB8qIAxUhlD49fWBpH4Viw8mJqg8EXXZrksYT/aysCKgY9uY 5mdhQllP4LVIhGlo6nbgBzxzWh0UgisGj+DwohEb5eBIIRF8LcH7Hj3YomvH QUcHdGvkYlkRGsinic8oqirYw8O4M+9bOjJuX3jT26ZSyM1wTlQgGtPoWl+g C3YnZ4dgMxrETYGh8PbsrK5oiYtBW1Nl6PYdXWDqhNwfbeExtqtP6WZdWmSA DK6LH/P/k+7fry9Q+aqhuLk= =ygIE -----END PGP SIGNATURE----- ------sinikael-?=_1-14488587748030.14020563219673932-- From nobody Sun Nov 29 21:18:59 2015 Return-Path: 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 779131A8934 for ; Sun, 29 Nov 2015 21:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 FOsB5YKA13yC for ; Sun, 29 Nov 2015 21:18:57 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id EC6AC1A8928 for ; Sun, 29 Nov 2015 21:18:56 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PTP8TD5Q4W00AR8C@mauve.mrochek.com> for shutup@ietf.org; Sun, 29 Nov 2015 21:13:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1448860431; bh=BFNdmK7CLYtTVcHU45W2LOgh8pXgkv3JJQemoO0xr9k=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=VzieBhhinkv8lar+jwD/9PPQCmHCeuBVVtLlRCUVxsj6IUl9Pdxfjnb3AVAk+SKjM RTDh7RtxVkh6YoeMv+1tXBjbhlPooI0iEqigwxEdoX1E6Ki8KLGyvZsUFeIRBAC4gv /Tr899HJFBZSHw4wqsk2sPH40matGAPornU1QhoQ= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PTC2EECTPC01729W@mauve.mrochek.com>; Sun, 29 Nov 2015 21:13:45 -0800 (PST) Message-id: <01PTP8T9GMFM01729W@mauve.mrochek.com> Date: Sun, 29 Nov 2015 20:53:17 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 30 Nov 2015 02:18:03 +0000" <1448849884345-6302c7ad-3551840c-2a0b598f@fugue.com> References: <20151129181346.9221.qmail@ary.lan> <1448849884345-6302c7ad-3551840c-2a0b598f@fugue.com> To: Ted Lemon Archived-At: Cc: shutup@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 05:18:58 -0000 > Sunday, Nov 29, 2015 1:13 PM John Levine wrote: > > It's not even privacy vs. ops support, it's privacy issues via some > > hints of sender's location vs. privacy issues via the recipient > > getting spammed, phished, and malware'd. > The only Received: header fields that you can trust are the ones that were > added by servers in your administrative domain. Nonsense. The most obvious counterexample is when you receive mail from a trusted server in some other trusted domain. 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. A certain amount of heurisitics are involved, but these are well understood. > 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. > That being the case, all the Received: header field needs to contain is a > token that can be used to backtrace the message to its origin using the > logs: anything else is superfluous. Nope. For one thing, the use of a token would require some means of accessing logs across administrative domains. That's not going to happen for a whole bunch of reasons. 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. 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. > So postcarding all kinds of private > information about the end user is not only not actually useful for the > reason you suggest, it is actively harmful to the end user. 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. Ned From nobody Sun Nov 29 21:27:21 2015 Return-Path: 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 ; 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 ; 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 ; 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 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 05:27:20 -0000 ------sinikael-?=_1-14488612350320.6029548507649451 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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=3F = 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=3F >> 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. >=20 > 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 =22from=22 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, =22with=22 clauses can be used to indicate whether or=20 > 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=3F > Unfortunately, so far the =22analysis=22 that's been done of the privacy > considerations of email trace information has been so shallow that stuff = like > this has been missed.=20 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 ------sinikael-?=_1-14488612350320.6029548507649451 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWW94zCRAMw8Nu0HeKywAATT0H+weC7q1iRSLgX5l+fo6U wZAOJjLl303g5jOxoESIBQa0z0h0sLUnuvzPN/bj0oQfDZW7zoR92r/dwYfa VrSMiFG2hN30ETfPFarICb31z8VXrl1sd/5SQM4MOgx0VICCRamwqxNNHqHB c73DyiamJ/pViDoXbB8BSq3VRFxI0AtM6EsWOjr4esd2iGOtWMeaP0jdodhI Ou1fsiHMc+o18+B2RdhIcUYGm0EUNnTt7wZFxqiYuLJeGOIlzFt8OeqUyBm5 jXzJMs+xlA+Wxl86G77/OlLjIrPxOl4mfbEdUiBM5+abJkZVDDGA2jVFJJb/ e6gY7XlAa2f6O7ZEzFp1DUM= =cCqF -----END PGP SIGNATURE----- ------sinikael-?=_1-14488612350320.6029548507649451-- From nobody Sun Nov 29 21:52:48 2015 Return-Path: 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 E96BF1A1EF7 for ; Sun, 29 Nov 2015 21:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.667 X-Spam-Level: ** X-Spam-Status: No, score=2.667 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=1.004, 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 DNZOHJh3q6Pz for ; Sun, 29 Nov 2015 21:52:43 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781281A1BF4 for ; Sun, 29 Nov 2015 21:52:43 -0800 (PST) Received: (qmail 18300 invoked from network); 30 Nov 2015 05:52:41 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 30 Nov 2015 05:52:41 -0000 Date: 30 Nov 2015 05:52:20 -0000 Message-ID: <20151130055220.10923.qmail@ary.lan> From: "John Levine" To: shutup@ietf.org, ietf-smtp@ietf.org In-Reply-To: <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: mellon@fugue.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 05:52:45 -0000 > I can't see how what you described could >possibly scale to anything a large email provider would ever do, ... This argument is going into the weeds. The question is whether the information in Received headers is useful for mail system management (which is not a synonym for spam filtering) and your apparent assertion that it only matters what giant mail systems do is pretty creepy. > Do you seriously think that Google has special-case header parsing to deal with spam from Cornell students' infected computers? No, they just use machine learning. Unfortunately, due to NDA's I can't talk about Google's spam filtering. >SPF allows me to discard all messages that claim to be from domain X but come from IP addresses not listed for domain X, Yeah, we know what SPF does, and the many and wonderful ways that it doesn't quite do what it's supposed to. But since nobody has ever said that we use Received headers for sender authorization, there's still no point here. > And if the site _is_ trustworthy, then modulo a few small exceptions > like Cornell, it's not originating anything that can be reasonably > identified as spam, because if it could have been reasonably > identified as spam, it would never have been forwarded. Aw, come on. I get plenty of spam from Gmail and Yahoo, all of which is 100% SPF, DKIM, and DMARC compliant and has 100% real Received headers. Unless you are extremely unusual, you do too. Crooks sign up for public mail systems to send spam, and on mail systems of all sizes they steal or guess AUTH credentials to spam through compromised accounts, or compromise web servers and spam through buggy old drupal and wordpress setups. >> We don't use header chains for validation, we use it to figure out who >> to blame, who to alert, and who to block. > >I don't know who "we" is here. Is this really how Google, et al., operate? I can't talk about Google, but I can tell you from direct experience working around their DMARC damage that some other large mail systems use Received headers as part of their spam filtering process, which is not just checking sender authorization. Some of us go to conferences like MAAWG where we spend a lot of time talking to people who run all sorts of medium and large mail systems, and other conferences where we talk about security problems and responses to them with various combinations of cops and nerds. It's OK that you're not as familiar with all this stuff, just as I am not as familiar with a lot of the DNS and IPv6 stuff you do. But you might consider the possibility that we actually do know something about the areas in which we work. R's, John From nobody Mon Nov 30 01:35:06 2015 Return-Path: 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 59B751B2DD4; Mon, 30 Nov 2015 01:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 HQqhr6iK7GHx; Mon, 30 Nov 2015 01:35:01 -0800 (PST) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id AF1461B2DD6; Mon, 30 Nov 2015 01:34:59 -0800 (PST) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3p8Lxs5PVXz1L8n7; Mon, 30 Nov 2015 10:34:57 +0100 (CET) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3p8Lxs445rz5Mgfl; Mon, 30 Nov 2015 10:34:57 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 2E89B123552; Mon, 30 Nov 2015 10:34:57 +0100 (CET) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mFF9pvXbCzF2; Mon, 30 Nov 2015 10:34:53 +0100 (CET) Received: from [192.168.3.49] (unknown [192.168.1.1]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id C04801234EE; Mon, 30 Nov 2015 10:34:52 +0100 (CET) To: Christian Huitema , 'Jim Fenton' , ietf-smtp@ietf.org, shutup@ietf.org References: <565A7234.7010000@alameth.org> <072F93223CD351A88ECCDB69@JcK-HP5.jck.com> <565B81F4.8090401@bluepopcorn.net> <015801d12b0a$dc8731d0$95959570$@huitema.net> From: "Rolf E. Sonneveld" Message-ID: <565C183B.4030109@sonnection.nl> Date: Mon, 30 Nov 2015 10:34:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <015801d12b0a$dc8731d0$95959570$@huitema.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1448876097; bh=p0j4x5p1domfRwP+xPpOWWlktEecm6W1vtqBHxv1eg4=; h=Subject:To:From:Message-ID:Date:From; b=YD57Rgh7RE45t1nOjDJ2AgSyXqM106le+bV+CHgsTiV/KvwNwlAd4W11ctUr/SQs7 +/+VTUSL4pnS4u5HN4OGHwEMnO5PBkbrUq7YuxKWCuOvuwabnL7rcTcrYSJltVlA3A qaN6tarUuL3Ju7OYkc6XDk31edZyIqQXqo6WT0u4= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3p8Lxs5PVXz1L8n7 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 09:35:03 -0000 On 30-11-15 02:02, Christian Huitema wrote: > On Sunday, November 29, 2015 12:54 PM, Jim Fenton wrote: >> There are users for whom their privacy is critically important, such >> as press informants in totalitarian societies. There are many other >> ways to determine their location (network monitoring coupled with >> a STARTTLS downgrade attack, for one), and it would be harmful >> (potentially life-threatening) if anyone thought that this would truly >> protect them. They should be using something like SecureDrop and >> not using email at all. > Uh, No. This is the classic "the other side of the boat is leaking too" > argument, coupled with a dollop of "no security is better than imperfect > security." Yes, there are many ways for metadata to leak. But that does not > mean that we should not plugs the leaks that we do know about. > > The discussion so far shows that one hand many people believe that we are > disclosing too much metadata in mail headers, while many more believe that > the metadata disclosure is actually useful to fight various forms of abuse, > some of which may well compromise users' privacy. > > We also heard that some of the big providers have already unilaterally > decided to suppress some of the metadata, like the first hop address. Can anyone share some information about which providers made which decision? > So we > have at least one data point showing that not all metadata needs to be > preserved. I fail to see the causality with the first sentence here: do you mean: the worlds e-mail ecosystem did not collapse, so this proves that not all metadata needs to be preserved? > > The "submission" hop may be a special case, but as Jim points out, mailing > lists may well another special case, for which some guidance would be > useful. > > The concern about topology disclosure may or may not justify pruning some of > the metadata. > > In short, it appears that there is enough concern and enough uncertainty to > justify working at least on an analysis document, and depending on the > outcome on a best practice document. Let's have this debate, and let's make > some progress on email privacy. There has been done some work on this, which might be useful input to the discussion: see the report "Investigating the leakage of sensitive personal and organisational information in email headers" [1]. /rolf [1] https://www.cs.ox.ac.uk/publications/publication9347-abstract.html. From nobody Mon Nov 30 03:14:38 2015 Return-Path: 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 084341A1A93; Sun, 29 Nov 2015 09:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, 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 enD6RVHEcmZX; Sun, 29 Nov 2015 09:12:32 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 C21A11A1A8D; Sun, 29 Nov 2015 09:12:32 -0800 (PST) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tATHCUi4018214 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 29 Nov 2015 17:12:31 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tATHCUXI010076; Sun, 29 Nov 2015 17:12:30 GMT MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_MNizgw3uUAkE/EWpBFj4YQ)" Received: from dhcp-whq-twvpn-1-vpnpool-10-159-139-85.vpn.oracle.com (dhcp-whq-twvpn-1-vpnpool-10-159-139-85.vpn.oracle.com [10.159.139.85]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 8.0.0.0.0 64bit (built Mar 19 2015)) with ESMTPSA id <0NYL00ECV6GQL500@gotmail.us.oracle.com>; Sun, 29 Nov 2015 09:12:28 -0800 (PST) Date: Sun, 29 Nov 2015 09:12:20 -0800 From: Chris Newman To: ietf-smtp@ietf.org, shutup@ietf.org Message-id: In-reply-to: <072F93223CD351A88ECCDB69@JcK-HP5.jck.com> References: <565A7234.7010000@alameth.org> <072F93223CD351A88ECCDB69@JcK-HP5.jck.com> X-Mailer: Airmail (335) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: X-Mailman-Approved-At: Mon, 30 Nov 2015 03:14:36 -0800 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 17:12:34 -0000 --Boundary_(ID_MNizgw3uUAkE/EWpBFj4YQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Content-disposition: inline I oppose the current shutup charter text and=C2=A0draft-josefsson-email-r= eceived-privacy as both promote the elimination of mechanisms that protec= t users from fraud and abuse. As I do care about user privacy, here's a strawman charter that I would s= upport: =3D=3D=3D=3D This WG will investigate mechanisms to conceal the information exposed by= the submission client's IP address in the mandatory received header gene= rated by the submission server. The output of this WG will provide a mech= anism as effective at tracing abuse and fraud as current use of the submi= ssion client's IP address. Changing other rules related to received heade= rs in SMTP is out of scope for this WG. =3D=3D=3D=3D I believe R=46C 2442 combined with PGP or S/MIME adequately protects emai= l headers. I worked on an implementation of that in the 1990s. I'm doubtf= ul the memory-hole proposal is sufficiently better or sufficiently likely= to deploy to be worth IET=46 effort. - Chris --Boundary_(ID_MNizgw3uUAkE/EWpBFj4YQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Content-disposition: inline