From nobody Tue Dec 1 06:07: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 607451B3AE0; Tue, 1 Dec 2015 06:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89lk3qlgl_sz; Tue, 1 Dec 2015 06:05:51 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) (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 75A741B3AE2; Tue, 1 Dec 2015 06:05:51 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:36761) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1a3lYy-00007h-Yw (Exim 4.86_36-e07b163) (return-path ); Tue, 01 Dec 2015 14:05:48 +0000 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1a3lYy-00036g-Pm (Exim 4.72) (return-path ); Tue, 01 Dec 2015 14:05:48 +0000 Date: Tue, 1 Dec 2015 14:05:48 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Ted Lemon In-Reply-To: <1448924778159-4b16d8e4-631c41b1-52b0fbf2@fugue.com> Message-ID: References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <1448923888960-cb7e590f-f443f8dd-7ec594e1@fugue.com> <565CD58D.9080403@dcrocker.net> <1448924778159-4b16d8e4-631c41b1-52b0fbf2@fugue.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: X-Mailman-Approved-At: Tue, 01 Dec 2015 06:07:57 -0800 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: Tue, 01 Dec 2015 14:05:56 -0000 Ted Lemon wrote: > Monday, Nov 30, 2015 6:02 PM Dave Crocker wrote: > > On 11/30/2015 2:51 PM, Ted Lemon wrote: > >> Why would I be relaying mail on? Only for a mailing list. > > > > The most obvious is mailbox aliasing, such as for vanity addresses such > > as university alumni associations provide. > > That's a mailing list with one subscriber. Same scenario. Not really. Mailing lists have very different administrative behaviour to aliases - they change the return path to an administrative address when forwarding the message whereas aliases do not. RFC 5321 section 3.9. Tony. -- f.anthony.n.finch http://dotat.at/ South Biscay, Southeast Fitzroy: Variable 4, becoming southerly 4 or 5. Moderate or rough. Fair. Good. From nobody Tue Dec 1 06:55:22 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 F1ED81A916B for ; Tue, 1 Dec 2015 06:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 4gWmmIATE0Cr for ; Tue, 1 Dec 2015 06:55:16 -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 E4E771A0100 for ; Tue, 1 Dec 2015 06:55:15 -0800 (PST) Received: (qmail 13664 invoked from network); 1 Dec 2015 14:55:14 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 1 Dec 2015 14:55:14 -0000 Date: 1 Dec 2015 14:54:52 -0000 Message-ID: <20151201145452.17944.qmail@ary.lan> From: "John Levine" To: ietf-smtp@ietf.org, shutup@ietf.org In-Reply-To: <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: arnt@gulbrandsen.priv.no 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: Tue, 01 Dec 2015 14:55:21 -0000 >I think it might be helpful if someone would name or describe a largish >site or service provider that uses Recived, and describe how in useful >detail. "A spam/virus filter company that handles mail for about x million >mailboxes does ...", that kind of thing. AOL famously uses the second received header to filter mail from providers that are too large to block but too lazy or incompetent to do proper outbound filtering on their users' mail. A few years ago, there was a largish cable ISP* that was gushing spam from customers through their MTAs and ignored the complaints. I forgt whether it was bots, or just customers using desktop spam blasters. So AOL started 4xx soft failing mail that originated at the naughty customers, and the ISP's mail servers predictably melted down. That finally got their attention and the situation soon improved for everyone, not just AOL. R's, John * - I know who it was but since they've mended their ways there's no need to embarass them here. From nobody Tue Dec 1 06:56:44 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 DF5491A92F2; Tue, 1 Dec 2015 06:56:42 -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 fvkjv6rrYQmD; Tue, 1 Dec 2015 06:56:41 -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 D19D91A92F1; Tue, 1 Dec 2015 06:56:41 -0800 (PST) Received: from [192.168.1.99] (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 tB1EufEd005486 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 1 Dec 2015 06:56:41 -0800 References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <1448923888960-cb7e590f-f443f8dd-7ec594e1@fugue.com> <565CD58D.9080403@dcrocker.net> <1448924778159-4b16d8e4-631c41b1-52b0fbf2@fugue.com> To: shutup@ietf.org, ietf-smtp@ietf.org From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <565DB532.70407@dcrocker.net> Date: Tue, 1 Dec 2015 06:56:50 -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]); Tue, 01 Dec 2015 06:56:41 -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: Tue, 01 Dec 2015 14:56:43 -0000 On 12/1/2015 6:05 AM, Tony Finch wrote: > Ted Lemon wrote: >> Monday, Nov 30, 2015 6:02 PM Dave Crocker wrote: >>> On 11/30/2015 2:51 PM, Ted Lemon wrote: > >>>> Why would I be relaying mail on? Only for a mailing list. >>> >>> The most obvious is mailbox aliasing, such as for vanity addresses such >>> as university alumni associations provide. >> >> That's a mailing list with one subscriber. Same scenario. > > Not really. Mailing lists have very different administrative behaviour to > aliases - they change the return path to an administrative address when > forwarding the message whereas aliases do not. RFC 5321 section 3.9. Yes. And further... They typically also have very different formal -- that's meant as 'official', not 'math' -- semantics. Alias behavior tends to be /very/ close to pure relaying. It changes very little in the message, other than the rfc5321.Rcpt-To address. Mailing lists tend to make massive changes to the original message; they are taking formal delivery of the message and then post a new message. For end users, the view is of a single message from original author to final recipient. To the email infrastructure it is two (or more) post/deliver sequences. Folks seeking to discuss email at this level should consider becoming familiar with RFC 5598. It will make careful discussion of email behavior a lot more consistent... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Dec 1 07:42:29 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 E96BC1ACCEA; Tue, 1 Dec 2015 07:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqmNZvjzR-NA; Tue, 1 Dec 2015 07:42:22 -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 7F5E11ACCE6; Tue, 1 Dec 2015 07:42:20 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14489845368790.5686263863462955" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <20151201145452.17944.qmail@ary.lan> References: <20151201145452.17944.qmail@ary.lan> Date: Tue, 01 Dec 2015 15:42:16 +0000 Message-Id: <1448984537206-50414304-4f4a1b54-63e09b42@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: Tue, 01 Dec 2015 15:42:28 -0000 ------sinikael-?=_1-14489845368790.5686263863462955 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tuesday, Dec 1, 2015 9:54 AM John Levine wrote: > >I think it might be helpful if someone would name or describe a = largish=20 >>site or service provider that uses Recived, and describe how in = useful=20 >>detail. =22A spam/virus filter company that handles mail for about x = million=20 >>mailboxes does ...=22, that kind of thing. >=20 > AOL famously uses the second received header to filter mail from > providers that are too large to block but too lazy or incompetent to > do proper outbound filtering on their users' mail. Can you describe (or refer to a description) of what was done in sufficient= technical detail that we can evaluate whether or not whatever gets = proposed here would break that functionality, and also whether there was = any other way to accomplish the same purpose=3F I don't doubt that this = story is true, and worth considering, but at the level of detail you've = provided, it's just a story. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14489845368790.5686263863462955 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXb/ZCRAMw8Nu0HeKywAAbBoH/0UFNM04fXlFJI+lEApe S/UTEtqlEu15U8PzinaCuIePBdKtQnCQSVtPxNMlbIOBVNoOIM9V5fs7rIdX nB9I5XBGJ7G7dnaaRMDB/Val1E+8OK52PCH1BNOSmd+3Yd+7n8Uw/zY9b3+N rxoDlG/5WQPj6g6ZqGpZL1yClD1FcOQiPwpIq4oSSjsK1OpjsgTFwK8AzLk5 sZICSy1WIjNtxqzfycI/woBejhVrtQu8AV1n8BxhdwQt6D/y/+UtvZ2TPIpk 9030lbhYfqQXCa/75T6O72Oh+LDDSo3ECHetTMG2hpHwj8E6YUh6kdy3UB0a /9Nfj/gaBrcpFeSoWKlqGmE= =hLMM -----END PGP SIGNATURE----- ------sinikael-?=_1-14489845368790.5686263863462955-- From nobody Tue Dec 1 08:52: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 60DF71ACE0F; Tue, 1 Dec 2015 08:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azhIkGm4pjqm; Tue, 1 Dec 2015 08:52: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 9C4031ACE07; Tue, 1 Dec 2015 08:51:56 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14489887132630.24058211967349052" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <565D9CFC.6070102@pscs.co.uk> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <1448923888960-cb7e590f-f443f8dd-7ec594e1@fugue.com> <565CD58D.9080403@dcrocker.net> <1448924778159-4b16d8e4-631c41b1-52b0fbf2@fugue.com> <605ee74e-863d-47cb-9089-fb83e13e4e38@gulbrandsen.priv.no> <565D9CFC.6070102@pscs.co.uk> Date: Tue, 01 Dec 2015 16:51:53 +0000 Message-Id: <1448988713596-9f0a5014-48bb3a2c-8e1bc938@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: Tue, 01 Dec 2015 16:52:07 -0000 ------sinikael-?=_1-14489887132630.24058211967349052 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tuesday, Dec 1, 2015 8:13 AM Paul Smith wrote: > Once that document exists, then no one will add the trace fields, because= people are paranoid (often rightly so, but not, I believe, in this case). = They won't read the document fully. It may say 'you can remove IP address = information from trace headers, but should think long and hard about it = because doing so may come back to bite you and leaving the information in = has minimal risk unless you're so stupid you haven't bothered with a = firewall'. They'll get as far as the first comma, and stop. I had no idea RFCs were so powerful. > To be honest, I'm (pleasantly) surprised IP address information is still = put in Received headers nowadays. IMHO, the fact that it is suggests that = there's a very good reason for it to stay there. No, it doesn't. It suggests that there are one or more reasons why it has= stayed there, zero or more of which may be good reasons. > Many service providers and software publishers 'stretch' the rules = somewhat, so if this was a big problem without any down-sides, then IP = addresses would have disappeared from Received: headers some years ago. We are seeing providers right now disappearing IP address information for = the submission IP source address, so your logic here would suggest that = there is in fact a downside to including that information; otherwise it = would not have disappeared. > If there were compatibility issues (eg some SMTP servers rejecting mail = without the IP address info there), then that would still be a problem even= if a new RFC comes out, unless SMTP is totally deprecated and a new mail = standard replaces it.=20 There is no such compatibility issue, because there is no required content = in Received: header fields (the only thing that's even strongly recommended= is =22via=22) . There is advice about what should be in them. People = are able to extract data from them anyway, because implementations tend to = have default behavior which nobody bothers to change; this behavior tends = to follow the examples in e.g. RFC 5821. >If there are no compatibility issues with removing the IP address, then = why aren't most providers/systems already removing it nowadays=3F We've already heard that some Email SPs =5Fare=5F removing IP addresses in = the most obviously problematic case. The reason they aren't removing IP = addresses in more cases is quite likely that they are using stock software = (probably Postfix, but could also be MS Exchange or other products) that = have default behavior, and they have not been motivated to override the = default behavior for cases other than the submit source address case, which= has the biggest doxing potential. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14489887132630.24058211967349052 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXdApCRAMw8Nu0HeKywAA7YgH/3jeue8G3yDsEhhI7CSn KalDh2Magxle2Z3WYT2igGXn112Ud14gWsuLvk6hG3NWRsMoAlyDd91ENMpD Kfm3dLkYSFKbXyzTu26nmgA8Ov19HFRNKNE+zVpCiLi/M5TW29Vsp/d2iT9v cyYhUEUJg1AlVSdIAn7mtvDpXfT6ztuM26oWKqe8D7RZlg5KNY7dMcewi360 spoXgxTIvb0I3Jqb9ApNZq2lCOvyZS6RQ6vs/sVDRzDVOxXkJasE339u9juR FFK5N9ZifYx35oCLw0tsRyzvxp67svw8C7mD1vvzcDE4oQ/olDMD16vZovZP tGJu0erNBzQRBUTcWiIk090= =NVL+ -----END PGP SIGNATURE----- ------sinikael-?=_1-14489887132630.24058211967349052-- From nobody Tue Dec 1 08:54: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 E68ED1A0AF8; Tue, 1 Dec 2015 08:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12wWuk4G-Ict; Tue, 1 Dec 2015 08:54:56 -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 96E031ACDFA; Tue, 1 Dec 2015 08:54:55 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14489888920950.38193703768774867" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <605ee74e-863d-47cb-9089-fb83e13e4e38@gulbrandsen.priv.no> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <1448923888960-cb7e590f-f443f8dd-7ec594e1@fugue.com> <565CD58D.9080403@dcrocker.net> <1448924778159-4b16d8e4-631c41b1-52b0fbf2@fugue.com> <605ee74e-863d-47cb-9089-fb83e13e4e38@gulbrandsen.priv.no> Date: Tue, 01 Dec 2015 16:54:52 +0000 Message-Id: <1448988892426-3d90e6a3-1691ce74-693e6fae@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: Tue, 01 Dec 2015 16:54:58 -0000 ------sinikael-?=_1-14489888920950.38193703768774867 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tuesday, Dec 1, 2015 7:27 AM Arnt Gulbrandsen wrote: >> Sure, but in this case wouldn't deferring to the end systems> argue in = favor of allowing end systems to make the decision as> to whether their = private information should be exposed=3F >=20 > As I see it, that's not the question here. The question is: Should there = be an RFC that can be used/misused to apply pressure regarding trace fields= etc=3F Yes, I agree that this is what we are discussing. I think it's pretty = clear that for Received header fields that refer to the IP address of the = end-user, the answer is =22yes, there should be such an RFC.=22 I haven't= heard anyone seriously propose that this is not true, although I'd be = interested to hear such an argument! -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14489888920950.38193703768774867 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXdDcCRAMw8Nu0HeKywAA0P8IALIy0lI+Q2jApdRAexRb FWkqZjPGz5kiKmKK8PjJahaiJ2NHdPuQGYYxL+HdF++5fhQ6cmsOS3YlNHZu Y9tpxlZYYv2xcpa6k8v0GbcS7kiuk9dc45gnsLdEPEhGpvB2i6LtQ7YhJHk9 h6K2fTogMQetmaUwWQUedVdAJr/zBufmkh9qPyyngURVgf9WL7zmuI7DR9Kz 8JdTqxQZS+fI4GNGY9eigQaiFbKxAwpSaGqYHr1ZPSe68569/3ncoJ7swDSm dVPFq8hgDr4daeyspQwg4eNUio+XllkrYipFc2WsGeoDAxOEuh5Jfc6kkUK1 x227lt6vKC0jAfdH/kYuBtQ= =z6T8 -----END PGP SIGNATURE----- ------sinikael-?=_1-14489888920950.38193703768774867-- From nobody Tue Dec 1 09:03:23 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 C63C01ACE6C; Tue, 1 Dec 2015 09:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxVVy-zDAc0J; Tue, 1 Dec 2015 09:03:13 -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 DC2DC1ACE6B; Tue, 1 Dec 2015 09:03:11 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14489893887610.2566924970597029" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <1448988713596-9f0a5014-48bb3a2c-8e1bc938@fugue.com> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <1448923888960-cb7e590f-f443f8dd-7ec594e1@fugue.com> <565CD58D.9080403@dcrocker.net> <1448924778159-4b16d8e4-631c41b1-52b0fbf2@fugue.com> <605ee74e-863d-47cb-9089-fb83e13e4e38@gulbrandsen.priv.no> <565D9CFC.6070102@pscs.co.uk> <1448988713596-9f0a5014-48bb3a2c-8e1bc938@fugue.com> Date: Tue, 01 Dec 2015 17:03:08 +0000 Message-Id: <1448989389082-e2a07101-65c2325c-03b5a77b@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: Tue, 01 Dec 2015 17:03:20 -0000 ------sinikael-?=_1-14489893887610.2566924970597029 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tuesday, Dec 1, 2015 11:51 AM Ted Lemon wrote: > There is no such compatibility issue, because there is no required = content in Received: header fields (the only thing that's even strongly = recommended is =22via=22) .=20 Oops, this isn't true--as Arnt mentioned, RFC 5321 does require the = presence of a from clause in the Received header field, although it says it= SHOULD, not MUST, contain the name and IP address of host that was the = previous hop. This doesn't change anything, since there's explicit advice= not to drop messages simply because they fail to meet this requirement. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14489893887610.2566924970597029 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXdLNCRAMw8Nu0HeKywAAsukH/0lCdbbR3ui7GR1vwyKe i+yefMgsMJ20G5gYNFUsYWfsmx/3kZZ2x+erD03ouvLdQHowWUnTCwzDvncR 4zu7R+9ey2W1F5AupGwAB0nQzrovegdu46ahr6flU/yFyWJj3mPO3ynhJctg aVp9M48aRZ4VSUNgS/ElR0i4iyyOFM95fYKJPmf4rLN8GFFaHGulIRjIC88t csr3onOx2VjihjkW6/wq9xug8Cd2em82Cb48Jy3Jv5K49uiy/S3A8UgS/pBh eQB+4yk4YpxhoAv69ugrTRD2HakEkdh6vrzCQOb44y86VpT9s8nr5Z1ffkV1 +nFJ0WhmIU1ISGGFsuGAWZ4= =PMKd -----END PGP SIGNATURE----- ------sinikael-?=_1-14489893887610.2566924970597029-- From nobody Tue Dec 1 09:29:24 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 B9D301B2B7F; Tue, 1 Dec 2015 09:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlWq_KpLVMwM; Tue, 1 Dec 2015 09:29:21 -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 0E1D81B2B79; Tue, 1 Dec 2015 09:29:19 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14489909566920.23402652656659484" From: Ted Lemon To: shutup@ietf.org In-Reply-To: References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <1448923888960-cb7e590f-f443f8dd-7ec594e1@fugue.com> <565CD58D.9080403@dcrocker.net> <1448924778159-4b16d8e4-631c41b1-52b0fbf2@fugue.com> <605ee74e-863d-47cb-9089-fb83e13e4e38@gulbrandsen.priv.no> <1448988892426-3d90e6a3-1691ce74-693e6fae@fugue.com> Date: Tue, 01 Dec 2015 17:29:16 +0000 Message-Id: <1448990957002-8a4e2ed6-df73b97f-9b769f82@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: Tue, 01 Dec 2015 17:29:22 -0000 ------sinikael-?=_1-14489909566920.23402652656659484 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tuesday, Dec 1, 2015 12:11 PM Steve Atkins wrote: > > On Dec 1, 2015, at 8:54 AM, Ted Lemon wrote: >>=20 >> Tuesday, Dec 1, 2015 7:27 AM Arnt Gulbrandsen wrote: >>>> Sure, but in this case wouldn't deferring to the end systems> argue in= favor of allowing end systems to make the decision as> to whether their = private information should be exposed=3F >>>=20 >>> As I see it, that's not the question here. The question is: Should = there be an RFC that can be used/misused to apply pressure regarding trace = fields etc=3F >>=20 >> Yes, I agree that this is what we are discussing. I think it's pretty = clear that for Received header fields that refer to the IP address of the = end-user, the answer is =22yes, there should be such an RFC.=22 I haven't= heard anyone seriously propose that this is not true, although I'd be = interested to hear such an argument! > When people routinely hide their identities - to the extent that a = recipient cannot tell that two emails were sent by the same person - that = eliminates many social and technical pressures on bad behaviour. But it = *also* removes the ability for people to help them when their endpoints = have been compromised. Your entire argument relies on this point, so I will just respond to this = one point; I don't disagree with what you say afterwards, but I think that = you are wrong in suggesting that obfuscating the Received: header field for= the email submission causes the problem you say it does. The claim you have made is that the person submitting the email is hiding = their identity, but this is not the case. First, they have to prove their= identity in order to submit the mail in the first place, most likely. = Secondly, their IP address is visible to the submit server, and is likely = logged. It is the submit server that, we are theorizing, should hide = their identity. The entity responsible for providing support to =5Fthat person=5F is the = entity that operates the SMTP submit server. That entity knows the end = user's identity, and knows what IP address they used to submit the email. = So they are not prevented from providing the support that you rightly say = they should provide. It is certainly true that if the submit server is not operated by a = responsible entity, then we have a problem. The right fix for that = problem is probably something similar to what John has said AOL did in a = similar situation: start greylisting mail from that provider so that the = high rate of spam chokes their queues, and they will start to be more = proactive in addressing problems. There is no need to violate the privacy of legitimate end-users who are = doing nothing wrong in order to address this problem. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14489909566920.23402652656659484 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXdjtCRAMw8Nu0HeKywAAJ+oIAMbQRQx+OixYS3+X4KDD lqFTKe8qQ7CEmuDnNFISJ2NaQgLIcr5d3hpmX9O9me/6NkA1ziSwf+IG6mC3 Pd8yBSgiOWtRHWrbbq9Fw0dwZNa/aE/tgbqHnQey9kpWlj5KsAKSvZMMYGaM +DUlOzoayqiq2bCtB308DJra83g1P+33gGzZ48eCNd4hLI8mX/ULGZ+uD/iu 26ETnLhAv0lLXwXn6VDPYhNLZXFawsAP46XfcwAZd1Kc60Q1y8fe+gPSnKho UaOTOXf6EtuAuqaqCPXIVPdhEgFWwlnfSbJziU4xmNScIRNEc0dCc9OmcKPa fdWBnSSYtRczG6n1klTTJsU= =fJev -----END PGP SIGNATURE----- ------sinikael-?=_1-14489909566920.23402652656659484-- From nobody Tue Dec 1 09:40:50 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 4E3DE1B2B85 for ; Tue, 1 Dec 2015 09:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 8EtTE-be3BIC for ; Tue, 1 Dec 2015 09:40:48 -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 288781AD2C0 for ; Tue, 1 Dec 2015 09:40:48 -0800 (PST) Received: (qmail 61984 invoked from network); 1 Dec 2015 17:40:46 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 1 Dec 2015 17:40:46 -0000 Date: 1 Dec 2015 17:40:25 -0000 Message-ID: <20151201174025.18409.qmail@ary.lan> From: "John Levine" To: ietf-smtp@ietf.org, shutup@ietf.org In-Reply-To: <1448988892426-3d90e6a3-1691ce74-693e6fae@fugue.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit 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: Tue, 01 Dec 2015 17:40:49 -0000 >Yes, I agree that this is what we are discussing. I think it's pretty clear that for >Received header fields that refer to the IP address of the end-user, the answer is "yes, >there should be such an RFC." I haven't heard anyone seriously propose that this is not >true, although I'd be interested to hear such an argument! Of course there is such an RFC. RFC 6409 refers to RFC 5321 which describes the content of the Received header in section 4.4. It includes the IP address from which the message was received. If, perhaps, you are wondering if there should be an RFC that updates that advice to say to do something else, that's totally unresolved, since nobody yet has made a plausible argument of what to change and why there would be an overall benefit from doing so. Until we look at the actual costs and benefits, it's grossly premature to propose any changes. R's, John From nobody Tue Dec 1 09:50:53 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 01AA71B29BB for ; Tue, 1 Dec 2015 09:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 nDV8mtMRrx6L for ; Tue, 1 Dec 2015 09:50:51 -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 151C51B29B2 for ; Tue, 1 Dec 2015 09:50:50 -0800 (PST) Received: (qmail 64605 invoked from network); 1 Dec 2015 17:50:49 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 1 Dec 2015 17:50:49 -0000 Date: 1 Dec 2015 17:50:28 -0000 Message-ID: <20151201175028.18462.qmail@ary.lan> From: "John Levine" To: ietf-smtp@ietf.org, shutup@ietf.org In-Reply-To: <1448990957002-8a4e2ed6-df73b97f-9b769f82@fugue.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit 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: Tue, 01 Dec 2015 17:50:52 -0000 >It is certainly true that if the submit server is not operated by a responsible entity, then >we have a problem. The right fix for that problem is probably something similar to what >John has said AOL did in a similar situation: start greylisting mail from that provider so >that the high rate of spam chokes their queues, and they will start to be more proactive in >addressing problems. Ah, OK. As I said, AOL used the IP addresess of the naughty users, logged in the received headers in the incoming mail, to decide what to reject. (It wasn't greylisting since they rejected it every time the ISP retried.) Without those IPs they couldn't have done it, since they certainly weren't going to reject legitimate mail from the other users. I'm glad to see that we now agree that logging the submission IP addresses provides important security benefits. R's, John From nobody Tue Dec 1 09:58:13 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 739051B2E24; Tue, 1 Dec 2015 09:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsxrw9iZ2Mfl; Tue, 1 Dec 2015 09:58: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 A7C9D1B2E1F; Tue, 1 Dec 2015 09:58:07 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14489926844720.06153230415657163" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <20151201174025.18409.qmail@ary.lan> References: <20151201174025.18409.qmail@ary.lan> Date: Tue, 01 Dec 2015 17:58:04 +0000 Message-Id: <1448992684773-4c6d4a39-ded58e7b-128cca51@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: Tue, 01 Dec 2015 17:58:10 -0000 ------sinikael-?=_1-14489926844720.06153230415657163 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tuesday, Dec 1, 2015 12:40 PM John Levine wrote: > Of course there is such an RFC. RFC 6409 refers to RFC 5321 which > describes the content of the Received header in section 4.4. It > includes the IP address from which the message was received. That's the latest version of the SMTP submit spec, not a document about = Received: header field privacy. > If, perhaps, you are wondering if there should be an RFC that updates > that advice to say to do something else, that's totally unresolved, > since nobody yet has made a plausible argument of what to change and > why there would be an overall benefit from doing so. The benefit is pretty obvious. If my IP address and identity information = appears in a Received: header field, then I can't send mail to a public = mailing list without revealing to the world geolocation information that = could be used for doxxing/swatting me, or for various other nefarious = activities, and I can't send email to an individual unless I am willing to = reveal that information to that individual. And I can't send email = through any server operated by anyone to whom I do not wish to reveal that = information. These may not feel like important issues to you, but for some people they = are life-or-death issues, and there really is a tradeoff to be made between= the freedom of people in that situation to speak, and the freedom of the = operators of mail servers to surveil them, even when that surveillance has = a good motive behind it. The problem is that it's not =5Fjust=5F the = people who need the information who get it. > Until we look at the actual costs and benefits, it's grossly premature > to propose any changes. Right, that's why I keep asking questions. It's easy to read a series of = questions as leading to a conclusion, and of course there is a conclusion = that seems to be indicated here, but if I didn't care about your opinion = and knowledge on this topic, I wouldn't be asking you questions. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14489926844720.06153230415657163 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXd+sCRAMw8Nu0HeKywAAfE0H/0CU+hAWOU7tzpV6kMFU HoYNsKAhcZBCYsT4BEwz3cXwmmMDUmFffvfY5m0eFIGXShIi+h88mZ8j1kYp cbAy+6dgHR2nJg7kICmOGTHJ6CSjDyiGk1gPAbz7f4hXIgGQVEVs+EZJ+hZT grLAGvyqDay/LX6UAsaLEPrXY0AuNY9e9DTIRfrG4By/xkv/NpsORhOBNw7W fpWEvVmQbtCFCMCeaZV51gUzJiwkLXVOu4ESblMwepgEiFGOKqYIZIiqiYrO 3KeUrcj5uLyaMyWhIYaIiU4p6yRge8hIWbVE2H0L7/ImkloYkc3SmkD5G4Ot irxayU04gNC/C13hk2LtZ8w= =MKGU -----END PGP SIGNATURE----- ------sinikael-?=_1-14489926844720.06153230415657163-- From nobody Tue Dec 1 10:06: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 4098E1B2E47 for ; Tue, 1 Dec 2015 10:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 n1Ts2HZqMAKR for ; Tue, 1 Dec 2015 10:06:44 -0800 (PST) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EEC91B2E19 for ; Tue, 1 Dec 2015 10:06:41 -0800 (PST) Received: by qgeb1 with SMTP id b1so12046451qge.1 for ; Tue, 01 Dec 2015 10:06:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=yQY70JbRnUZPfWowW6zbjVpov3wc86lNvo0vXL/BJoc=; b=KfLmRyA0cI1UBki+MlPIsHcdVLSb5yRDT73bx/TJgRCJCByX2Jc97c3rfj6DC6D5AH bBYDJPeJv2sDPsv3VbA6x/UKQUAaPfqWysKLx4wtu1XRjlyx82nEPMVCfyKP8pNBfZb3 Frk8gp6IabyufPkHgB69sxEaASCO3BpgIorcs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:cc:content-type; bh=yQY70JbRnUZPfWowW6zbjVpov3wc86lNvo0vXL/BJoc=; b=cny5fk9cJxpYR8a8QJ/kMX2vpyadbo7bc2DN/o740P2EycFdFcFOdALNlx4lIafPwf h3jlpP+F5FkqMPX+PN/3cwU7yaduCMddm5myVjnmLb5G2fYW02Yao9T/bt9xhgbQINEQ Vh/zTVVAjH2Wa/oAiPT8dqgbVJHX6eedMZmnCmb4y/GLLvR3MfbEIkMClGDPAUJcZoG5 Xgn+fWN5uw0d3lxYFyOY3mjhQgpBBkOTuxRvyeAxp4X9HCreALiocb0aX8gg2i1DdWGj FBiknAGiIky3rGOn63UVatIlaPSd4hZu5CFJBgRFZKIjyn1xsyGAmQkUKvoPSSWxLUDj JbqA== X-Gm-Message-State: ALoCoQn3NCcdunDEAG7cAR/vDn0HemLwhPiaonPxJRoprSlsiOswc3GkQIvjyMeZdrpA+YTV5R/A MIME-Version: 1.0 X-Received: by 10.140.84.40 with SMTP id k37mr83820458qgd.33.1448993200711; Tue, 01 Dec 2015 10:06:40 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.55.198.219 with HTTP; Tue, 1 Dec 2015 10:06:40 -0800 (PST) Date: Tue, 1 Dec 2015 10:06:40 -0800 X-Google-Sender-Auth: 5_2c5zipMckEye88R-rU4JR-zHg Message-ID: From: "Kurt Andersen (b)" To: Dave Crocker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: shutup@ietf.org, SMTP Discuss Subject: Re: [Shutup] [ietf-smtp] 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: Tue, 01 Dec 2015 18:06:45 -0000 On Tue, Dec 1, 2015 at 6:56 AM, Dave Crocker wrote: > Folks seeking to discuss email at this level should consider becoming > familiar with RFC 5598. It will make careful discussion of email > behavior a lot more consistent... And in regard to indirect mail flows, may I recommend https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ --Kurt Andersen From nobody Tue Dec 1 10:19: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 A93031B2E9E; Tue, 1 Dec 2015 10:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.343 X-Spam-Level: X-Spam-Status: No, score=0.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwvOwIVetp4k; Tue, 1 Dec 2015 10:19:04 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 693CF1B2E9C; Tue, 1 Dec 2015 10:19:04 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB1IIqao027662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 1 Dec 2015 13:18:52 -0500 To: Ted Lemon , shutup@ietf.org References: <20151201174025.18409.qmail@ary.lan> <1448992684773-4c6d4a39-ded58e7b-128cca51@fugue.com> From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <565DE48C.2070000@mustelids.ca> Date: Tue, 1 Dec 2015 13:18:52 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <1448992684773-4c6d4a39-ded58e7b-128cca51@fugue.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: Tue, 01 Dec 2015 18:19:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/01/2015 12:58 PM, Ted Lemon wrote: | These may not feel like important issues to you, but for some | people they are life-or-death issues, and there really is a | tradeoff to be made between the freedom of people in that situation | to speak, and the freedom of the operators of mail servers to | surveil them, even when that surveillance has a good motive behind | it. The problem is that it's not _just_ the people who need the | information who get it. We appreciate that, but there already are plenty of special purpose infrastructures that are perfectly capable of doing what you want when you want. People who want it already have it. No reason to encourage the breakage of "good purpose surveillance" (such as spam/abuse filtering or infected machine remediation) all the time, because a very small number perhaps only occasionally needs it. It doesn't have to be either/or. It's both now. Not sure we need to rock that boat. Hence a WG to answer that question. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJWXeSMAAoJENy2YTBCU1mlpPQH/3jIcTLjP7cOpHmWqegot33o eF76kxEOrO5oTfLjCZS/CfTe2mD7bcTxjaLK79JemNWkUB2U+4/cEXOhh2e+5xz7 jk9PPn4ye559Wt8NMa3SqBkd47JnDy9JROLzLZVrh+btY5+aS/405betYgnMksPN nx828n36zOXn07bl2viHyCGs1HrNDoWOrujphFYGbx/Foklmso3fBI/354zHKduY yO9LIiP6bwQeVUu3Tyo2pXTeYojNx3PIyPDTU1edOwgjeBoBpZDZjyRFk2/a3Rjo smnE4vAqHdN3vif7HzZruxF6AQSp6u4MNSO23kEyDxlHbF2VRF6tJ6aOB77lRt8= =47Il -----END PGP SIGNATURE----- From nobody Tue Dec 1 10:22: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 D86701AD10A; Tue, 1 Dec 2015 10:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.242 X-Spam-Level: ** X-Spam-Status: No, score=2.242 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLG1Qc3jBXl6; Tue, 1 Dec 2015 10:22:03 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DF4A1B2E85; Tue, 1 Dec 2015 10:22:03 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB1ILpVk028887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 1 Dec 2015 13:21:51 -0500 To: Ted Lemon , shutup@ietf.org References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <1448923888960-cb7e590f-f443f8dd-7ec594e1@fugue.com> <565CD58D.9080403@dcrocker.net> <1448924778159-4b16d8e4-631c41b1-52b0fbf2@fugue.com> <605ee74e-863d-47cb-9089-fb83e13e4e38@gulbrandsen.priv.no> <565D9CFC.6070102@pscs.co.uk> <1448988713596-9f0a5014-48bb3a2c-8e1bc938@fugue.com> From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <565DE53F.2080904@mustelids.ca> Date: Tue, 1 Dec 2015 13:21:51 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <1448988713596-9f0a5014-48bb3a2c-8e1bc938@fugue.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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: Tue, 01 Dec 2015 18:22:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/01/2015 11:51 AM, Ted Lemon wrote: | We are seeing providers right now disappearing IP address | information for the submission IP source address, so your logic | here would suggest that there is in fact a downside to including | that information; otherwise it would not have disappeared. What we have now is a very small number of providers doing this on purpose (I can count the number of major providers doing it with the fingers of one hand), and a still very small, but marginally larger set of providers not providing it because their infrastructure doesn't know what it is and/or their software just doesn't do it for one reason or another. On the other hand, we can see that that the lack of that information presents difficulties to filtering technologies. When you get a series of harassing emails from a given site originating from a given user that's forging from lines and mutating content, you have nothing concrete to filter on to distinguish it from other email from the same provider. Leaving you with an all or nothing situation of blocking the whole provider. Which isn't a big drawback if the provider is good at stopping abuse because the problem won't last long, but, the largest provider in question often isn't, especially in the case of individual harrassment. Indeed, without that information being present (or not being accessible without great effort using the provider's server logs), it can cause significant difficulty for the provider doing anything about it even if they wanted to. IOW: if even the provider doesn't know where it's coming from (or if finding out is too expensive to do at scale), then everybody (including the poor user with the infected box) is SOL. One of your other points is that the received lines aren't standardized. Well, yes, that's true. But that is in fact an advantage to filters. The simple fact of different formats/idiosyncratic behaviour gives filtering technologies more leverage to make filtering decisions that have nothing whatsoever to do with IP addresses. We use this sort of information to great benefit - as do the largest email providers. "Standardized" or not, Received lines provide a rich detail of fodder for filtering, whether or not the filter manages to understand what the received line is trying to say about where the email allegedly came from or how it got there. The IP could just as easily be a non-reversible encrypted blob unique to the sending user that only the provider understands, but the receiver can filter on. I say "allegedly", because the actual source (personal attribution) of the email is generally irrelevant to filtering. Our primary goal is stopping the trash, a secondary goal is helping the infectee fix their problem, but if the provider wants to interfere with the latter, well, we can live with it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJWXeU/AAoJENy2YTBCU1ml+vkIALKzFFDYa3MBHn8JXzkYnkpK 9otrKipY4c07C8A4zfggMautyZWXe73msvmZDZoWng+qUE/MggKtvEYHgEIsFp0+ TUElwxOwA4Ftmb2CdtQPhtuoXQP4fIWMmkWuuZf6GuvKxGbl8dVpfWxmjvyy3LEh RJmvKwzxw4yf+MNzbdtfEy+bveXTEemAFPnu3TO4mZI5a/3RReVdiEyC3/oi4AYG wQTfBegLvAiHdqBeQecqh531E0e0No9n8g8ElwZS1PDShM6SG7Nk+XYNKXwYRvXg ifNSCYu4gm0Xn/KGF1wYd/0Wfvp9jd6cRPJ1Eq5nbNm0zXOao+McZfmGDsr2aGI= =FY2y -----END PGP SIGNATURE----- From nobody Tue Dec 1 10:43: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 59F011B2ED6 for ; Tue, 1 Dec 2015 10:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 cTQ_pKWzOFU7 for ; Tue, 1 Dec 2015 10:43:51 -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 4C8C11B2ED5 for ; Tue, 1 Dec 2015 10:43:51 -0800 (PST) Received: (qmail 75248 invoked from network); 1 Dec 2015 18:43:50 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 1 Dec 2015 18:43:50 -0000 Date: 1 Dec 2015 18:43:28 -0000 Message-ID: <20151201184328.18674.qmail@ary.lan> From: "John Levine" To: ietf-smtp@ietf.org, shutup@ietf.org In-Reply-To: <1448992684773-4c6d4a39-ded58e7b-128cca51@fugue.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit 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: Tue, 01 Dec 2015 18:43:52 -0000 >These may not feel like important issues to you, but for some people they are life-or-death issues, and >there really is a tradeoff to be made between the freedom of people in that situation to speak, and the >freedom of the operators of mail servers to surveil them, even when that surveillance has a good motive >behind it. The problem is that it's not _just_ the people who need the information who get it. If you're depending on the header writing practices of random submission servers to keep you from being doxxed, you're not very bright. The doxxing crowd routinely use social engineering to call up and get people to provide the information from the logs. If you really need to keep your location private, use a Tor connection to gmail or yahoo webmail. R's, John From nobody Tue Dec 1 10: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 AF2271B2E53; Tue, 1 Dec 2015 10:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5tKPjpGKl_n; Tue, 1 Dec 2015 10:46:53 -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 899DC1B2EDD; Tue, 1 Dec 2015 10:46:52 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14489956100780.8990543824620545" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <01PTRE1WMUMQ01729W@mauve.mrochek.com> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <01PTRE1WMUMQ01729W@mauve.mrochek.com> Date: Tue, 01 Dec 2015 18:46:50 +0000 Message-Id: <1448995610381-36d96644-173d7bf5-b94de12d@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: Tue, 01 Dec 2015 18:46:55 -0000 ------sinikael-?=_1-14489956100780.8990543824620545 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tuesday, Dec 1, 2015 12:57 PM Ned Freed wrote: >> I think it might be helpful if someone would name or describe a largish >> site or service provider that uses Recived, and describe how in useful >> detail. =22A spam/virus filter company that handles mail for about x = million >> mailboxes does ...=22, that kind of thing. >=20 > First, people have already been referred to SpamAssassin, which most = definitely > does perform various checks on Received: fields. The code is out there; = all > you need to do is look. Looking at the code isn't all that interesting, but given that it's = available, what =5Fwould=5F be interesting would be to try Spamassassin = with and without, e.g., the Received: header field from the initial submit,= on the same corpus of mail, and see how the effectiveness of the filtering= changes. > Second, good luck on getting anyone to comment on the details of their = own > secret sauce, or for that matter getting anyone who has learned such = details > through business relationships. All such information is pretty much = guaranteed > to be covered by confidentiality or nondisclosure agreements. This is probably true, but the effect of it is that we should not consider = assertions people make that they can't justify. It's actually not that = useful to know what specific heuristics people are using. What would be = more interesting would be to do A/B testing as I suggest above, using their= proprietary solution. It seems to me that that could in principle happen= without disclosing the information that these organizations don't want to = disclose. If they don't care enough to make such information available, = it's likely that it's because they don't see the issue as being = sufficiently important, which is to say they don't think Received: headers = make enough difference to be worth arguing about. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14489956100780.8990543824620545 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXesaCRAMw8Nu0HeKywAA9g8H/RshVz7e+lzkdgJL33e3 Fk6ik5oLKThms1fgkeO7hBfGt0vagcpjFqrIWGcRxe8UrK82kHsTiw/uP1ad O51l0yoSSjHZXNp0yPQRksu2IlRFrhln99+fOQ6e5QimwPdsf6hV7gXfMT6M AGwLCWPrOxe9W/BnIJgoBGF790IIW6cYoN+uAO1XASY9eZ2P/ByfEYmL3v6g PRyQhLJaHKsHcqJM92I93+h2Ex+6J7IYZCFiKDFZ8I/euEeHsm9ghcRKXwzd +iCIj+la8r++K13y8tcZvmrNzRHlGNcyxSBVO7SIpI+HGbRhODLfie/Sz/Jz 0jNGjhPx/cNp5MfOahfJ714= =tpzZ -----END PGP SIGNATURE----- ------sinikael-?=_1-14489956100780.8990543824620545-- From nobody Tue Dec 1 11:04:23 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 0AD941B2F22; Tue, 1 Dec 2015 11:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vo9Dq3jCHipJ; Tue, 1 Dec 2015 11:04: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 E29C31B2F28; Tue, 1 Dec 2015 11:04:17 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14489966548200.7075463170185685" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <20151201184328.18674.qmail@ary.lan> References: <20151201184328.18674.qmail@ary.lan> Date: Tue, 01 Dec 2015 19:04:14 +0000 Message-Id: <1448996655129-d579be8c-03e00e5b-24fb7ed0@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: Tue, 01 Dec 2015 19:04:21 -0000 ------sinikael-?=_1-14489966548200.7075463170185685 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tuesday, Dec 1, 2015 1:43 PM John Levine wrote: > If you're depending on the header writing practices of random > submission servers to keep you from being doxxed, you're not very > bright. Can we dispense with the insults=3F How does this add value to the = discussion=3F > The doxxing crowd routinely use social engineering to call up > and get people to provide the information from the logs. Yes, and sometimes they succeed, and the times that they succeed, that's = when the harm they do makes the news. The times they fail, we don't hear = about. > If you really need to keep your location private, use a Tor connection > to gmail or yahoo webmail. As a rule, people don't know they need a specific kind of privacy until = it's too late. People who are, at present, in the happy state of not = knowing they need privacy are in that state for one of two reasons. One, = they haven't actually said anything to offend some random 13-year-old = sociopath out on the Internet yet. Two, the privacy safeguards that they = need are in place, and the sociopath they offended fails to get their info.= What we are talking about doing here is making the second case more likely.= This is important work that's worth doing. It's not the case at all = that people who fail to protect their own privacy are =22not very bright.= =22 Frequently they are very bright, but simply didn't imagine that they = would be screwed over by the infrastructure they are using in such a = blatant and unpleasant way. The reason that people get screwed over in this way is because we, who = understand about privacy and understand how to deliver it, did not make it = a priority. That's what this discussion is about. So please don't = belittle people whom we have failed by claiming that they should somehow = have anticipated the problem. That really is our job, not theirs. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14489966548200.7075463170185685 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXe8vCRAMw8Nu0HeKywAAodoH/2AxM3f8FQg1yYIiqyvX Ar6m2E2DTTD5iSR1F7ppp78HpRrU5VXITb89WCEhAF6xpDbVyk/wAtnxzAht +yZ4jhO2w5/H3t5TdI7o++CB6S49dmUkAfLT+seDuo33lCxCSZqF37K5eSWE DtRVdNcwWj7iyNIaRujf5q76ALE8Xp0nlOjftZA7dQFPjd98IcSKHJPHPZiA 6DnnksTPoP2F4je/gb87sXozFH/hvOyhB768glbizXC1wrkSXiaXlc5TWCzq TA3PVk0S1x3E7rYv7B3CxDu30+TdKu3KPF8mjHDBr2+D9+Hmjv4BxQGF2VRF L5w6uO3yLUKcwE1sS7kG2N4= =ez69 -----END PGP SIGNATURE----- ------sinikael-?=_1-14489966548200.7075463170185685-- From nobody Tue Dec 1 11:10:10 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 01DDB1B2F31; Tue, 1 Dec 2015 11:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPlsDC_M90ws; Tue, 1 Dec 2015 11:10:06 -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 CDD061AD481; Tue, 1 Dec 2015 11:10:05 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14489970028750.4777916958555579" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <565DE53F.2080904@mustelids.ca> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <1448923888960-cb7e590f-f443f8dd-7ec594e1@fugue.com> <565CD58D.9080403@dcrocker.net> <1448924778159-4b16d8e4-631c41b1-52b0fbf2@fugue.com> <605ee74e-863d-47cb-9089-fb83e13e4e38@gulbrandsen.priv.no> <565D9CFC.6070102@pscs.co.uk> <1448988713596-9f0a5014-48bb3a2c-8e1bc938@fugue.com> <565DE53F.2080904@mustelids.ca> Date: Tue, 01 Dec 2015 19:10:02 +0000 Message-Id: <1448997003203-0f18cc67-428b3ca3-9de10229@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: Tue, 01 Dec 2015 19:10:08 -0000 ------sinikael-?=_1-14489970028750.4777916958555579 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tuesday, Dec 1, 2015 1:21 PM Chris Lewis wrote: > What we have now is a very small number of providers [...] e.g., gmail. =20 > When you get a > series of harassing emails from a given site originating from a given > user that's forging from lines and mutating content, you have nothing > concrete to filter on to distinguish it from other email from the same > provider. This is why against our protestations DKIM is seeing wide deployment. The= fact that there is nothing in the mail submit process that prevents the = user from forging headers is the problem. Violating non-evil users' = privacy in order to solve that problem is stealing from Peter to pay Paul. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14489970028750.4777916958555579 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXfCLCRAMw8Nu0HeKywAA+uEIAJqnTvHqbLldX/CjzpbG OGn8JA1DPMLqpP15lRPadcS70sliGg4D1vav+DzTTYU2LFOLmusLUoPCa4GE 81c4QmGKt07hFqgnSpjY2yvLFVmbCdvzMyj8PxX/33dcKKeEf/sHWSS4/L0y 2bWwITdAxoB+7UnFpqZhAhI/7DmXNn3H1PhCoJ7zFXZUTuD0Pvm8dFOZVRkF XLpHgMvYdPbXQzv7cosJ+w7U8OXC22lpwAMJ/dwR/eS0xtXmb5xaE+WACIis DPjqAf8kCuYLzZWD30Rbar3Pe/D+nqln5k4fz3aFZ3lVItPmiUsoWvZscOId 07W2ADPEpd4TVJKAZWdu4iM= =7A/A -----END PGP SIGNATURE----- ------sinikael-?=_1-14489970028750.4777916958555579-- From nobody Tue Dec 1 11:23: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 18D5B1B2F4E; Tue, 1 Dec 2015 11:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.321 X-Spam-Level: X-Spam-Status: No, score=0.321 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, 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 HOyPc_jbg6Cx; Tue, 1 Dec 2015 11:23:54 -0800 (PST) Received: from mail.lapsedordinary.net (thinksmall.vps.bitfolk.com [85.119.83.85]) by ietfa.amsl.com (Postfix) with ESMTP id 069721B2F34; Tue, 1 Dec 2015 11:23:54 -0800 (PST) Received: by mail.lapsedordinary.net (Postfix, from userid 1000) id 74B6E343FE; Tue, 1 Dec 2015 19:23:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lapsedordinary.net; s=mail; t=1448997833; bh=QJ/ODCQC6N4yAxjVtgksmJoQ8ySw1Df0pRPClgvjZQU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=Yv0M4I+gddiNv96pkqUUS1/az6FfQU1XXzWQUKKHKRGDM4HlrThQpmBRJuZd1gCU3 TgQG4WgESCng3fWF2YBxlwB8zgup3HDvoomnuc1bsgGHFrEL5gGPxfTFZ7mG+k/Csx sIZ8U/xYbuRFG6L3h8uD9X6WEKyVfZ/IUn16EouI= Date: Tue, 1 Dec 2015 19:23:53 +0000 From: Martijn Grooten To: ietf-smtp@ietf.org Message-ID: <20151201192353.GA23999@lapsedordinary.net> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <1448923888960-cb7e590f-f443f8dd-7ec594e1@fugue.com> <565CD58D.9080403@dcrocker.net> <1448924778159-4b16d8e4-631c41b1-52b0fbf2@fugue.com> <605ee74e-863d-47cb-9089-fb83e13e4e38@gulbrandsen.priv.no> <565D9CFC.6070102@pscs.co.uk> <1448988713596-9f0a5014-48bb3a2c-8e1bc938@fugue.com> <565DE53F.2080904@mustelids.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline In-Reply-To: <565DE53F.2080904@mustelids.ca> User-Agent: Mutt/1.5.20 (2009-06-14) 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: Tue, 01 Dec 2015 19:23:56 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 01, 2015 at 01:21:51PM -0500, Chris Lewis wrote: > "Standardized" or not, Received lines provide a rich detail of fodder > for filtering, whether or not the filter manages to understand what > the received line is trying to say about where the email allegedly > came from or how it got there. The IP could just as easily be a > non-reversible encrypted blob unique to the sending user that only the > provider understands, but the receiver can filter on. >=20 > I say "allegedly", because the actual source (personal attribution) of > the email is generally irrelevant to filtering. Our primary goal is > stopping the trash, a secondary goal is helping the infectee fix their > problem, but if the provider wants to interfere with the latter, well, > we can live with it. I think this is a very good point. A recommendation to substitute a "non-reversible encrypted blob" for the sender's IP address seems to me a good balance between privacy and security. I agree that if keeping your geolocation is a matter of life and death, you shouldn't use email, but for me that is not a reason for the IP address to be visible for anyone who can read the email. I think privacy matters, even when it's not about life and death. Martijn. --DocE+STaALJfprDB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWXfPJAAoJEI5dMs9dIv8ZM9wH/1vo8N2U4pvYwF3pQbaiReGY /HDCBDHCwbftmCD90L6tJxKzqaFHjcV+4eZiqoe3rSXudJWW8U2mjLvEI0SzvXkQ nX/FUnMLWZVhr1SMUjipXV666qv4sprHga8teZ0LiqVG0p6Sn3ObJvVMX/eDK0EE ZgeKxmeuAYEFFdzthClEkRsP9aa+vtMLajCuynQkIR0XrVUvpw8zFlJXrG3HhKQf Ma9GUqsc2vOGfKbWtufuE7n1ht090OeTmkyC+AvhwCzhLCsYdGP+2NC8/OO4dMi+ Lz7rG1KElvZYF7LLb9EbENJ21uXpVr1DdY3DUFGHXFaCS/9uZY80qTGAusgCcSk= =8kJq -----END PGP SIGNATURE----- --DocE+STaALJfprDB-- From nobody Tue Dec 1 11:50: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 4B90D1B2B04 for ; Tue, 1 Dec 2015 11:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 g-T7_xt9Icc0 for ; Tue, 1 Dec 2015 11:50:54 -0800 (PST) Received: from xsmtp12.mail2web.com (xsmtp12.mail2web.com [168.144.250.177]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C938B1B2AF6 for ; Tue, 1 Dec 2015 11:50:54 -0800 (PST) Received: from internal.xmail02.myhosting.com ([10.5.2.12] helo=xmail02.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1a3qwv-0005Zs-JJ for shutup@ietf.org; Tue, 01 Dec 2015 14:50:54 -0500 Received: (qmail 22531 invoked from network); 1 Dec 2015 19:50:52 -0000 Received: from unknown (HELO huitema2) (Authenticated-user:_huitema@huitema.net@[131.107.147.15]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 1 Dec 2015 19:50:51 -0000 From: "Christian Huitema" To: "'Martijn Grooten'" , References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <1448923888960-cb7e590f-f443f8dd-7ec594e1@fugue.com> <565CD58D.9080403@dcrocker.net> <1448924778159-4b16d8e4-631c41b1-52b0fbf2@fugue.com> <605ee74e-863d-47cb-9089-fb83e13e4e38@gulbrandsen.priv.no> <565D9CFC.6070102@pscs.co.uk> <1448988713596-9f0a5014-48bb3a2c-8e1bc938@fugue.com> <565DE53F.2080904@mustelids.ca> <20151201192353.GA23999@lapsedordinary.net> In-Reply-To: <20151201192353.GA23999@lapsedordinary.net> Date: Tue, 1 Dec 2015 11:50:59 -0800 Message-ID: <07bf01d12c71$9b88b790$d29a26b0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHQTY9q0QzQziT/XW3kp2qSufFoDwEVmeDFAlgyR/kCe0wEMwI7WjM7Af3kr9QCeIAPFgGJdFE5Ax3NhecBybfgpwGC/pY+nhPMF+A= Content-Language: en-us 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: Tue, 01 Dec 2015 19:50:56 -0000 On Tuesday, December 1, 2015 11:24 AM, Martijn Grooten wrote: > > I agree that if keeping your geolocation is a matter of life and death, you > shouldn't use email, but for me that is not a reason for the IP address to be > visible for anyone who can read the email. I think privacy matters, even > when it's not about life and death. > I am also concerned with automated mass surveillance, including traffic analysis. The basic traffic analysis produces "5-tupple" logs. Since a lot of the Internet usage is now mobile, there is no direct mapping between IP addresses and user identities. To move from traffic analysis to surveillance, the analyzers need to restore that mapping. There are multiple ways to do that, as explained in RFC 7624, and email headers are one of them. Clearly, there are also other sources of correlation between IP address and identity. Various IETF working groups are busy closing these other sources as well: MAC Address randomization to suppress direct mapping of identities to roaming devices; DHCP anonymity profile to remove the leakage of metadata in DNS packets; or, HTTPS to prevent observation of HTTP cookies. To break the correlation between IP address and identity, we need to also close the leakage in the SMTP traces. Everybody understands that there is a tension there between privacy and fighting spam. I get the use case of the virus-infected home PC that originates spam through the permissive SMTP relay of some local ISP. But then many mail providers feel the need to provide privacy to their users, which drives them to deploy their own formatting of the "received" field. We do have a tension there, and that tension is precisely why we want to study the alternatives and come up with a proposed recommendation. Hence the WG charter. -- Christian Huitema From nobody Tue Dec 1 13:29: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 912461A01A1; Tue, 1 Dec 2015 13:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTlX3G7XWAFD; Tue, 1 Dec 2015 13:29:13 -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 0347B1A032D; Tue, 1 Dec 2015 13:29:11 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14490053494380.7812004333827645" From: Ted Lemon To: shutup@ietf.org In-Reply-To: References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> Date: Tue, 01 Dec 2015 21:29:09 +0000 Message-Id: <1449005349724-ffd73ebb-f70e368e-426663a1@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: Tue, 01 Dec 2015 21:29:20 -0000 ------sinikael-?=_1-14490053494380.7812004333827645 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tuesday, Dec 1, 2015 4:10 PM Richard Clayton wrote: > If you want to have very limited data in your email header fields then > you should look at the systems that you operate yourself and clean up > the information at that point. You'll probably get a poorer delivery > experience when sending to MAGY and others -- but that's your tradeoff. Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com = (Postfix) with ESMTP id 01DDB1B2F31; Tue, 1 Dec 2015 11:10:08 -0800 (PST) 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 BPlsDC=5FM90ws; Tue, 1= Dec 2015 11:10:06 -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 CDD061AD481; Tue, 1 Dec = 2015 11:10:05 -0800 (PST) Here are the Received: headers from the previous message I sent to the list= . As you can see, there is no Received header at all for the submit = server. My submit server doesn't add one, because there's no good reason = to. I have had zero issues with mail I send not being delivered to any of= the big providers. When I do have issues, the issues I have tend to be = really small servers (typically IETF participants who, like me, run their = own mail servers) that have all sorts of exciting steampunk gadgets = filtering spam. The issues that I have tend to be that mail to those users is delayed, not = that it never arrives. It's their choice to set up greylisting, and = slowing down the reply rate for discussions like this isn't a bad thing, so= I really wouldn't describe this as a =22poorer delivery experience.=22 -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14490053494380.7812004333827645 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXhElCRAMw8Nu0HeKywAAa60IAKHZBc9ZLe3/m6kNqcCD MMenJSWRzZdQec+Q71PPK9uErmyG2e7PteUg32LUu9Jcqb8ci8ZaRi7hp0K0 /F0NUaeJZMf3CGRNJ18El+tbuzWAmCNYGpIjwYuV2iSYZlSupIdxLdd693oP 5uzSOF3c9YwpPDyGNnm//V29fH9A92y6TpdUp8DiMj4a3QCKEfmnUucdFexL MAJZ0MdptEbidnCQHCM+oVI4UWXaN/wthzwCVd/iJedZYMbYDqHptc84x56s kj3U2BviuLukc01AZdL3Tix8Ie2DRyFjmGhDDUhZmPhxKGqMUm7Dwy+IDi41 muE2efsrzYOoOS93N6TkBl0= =XHQn -----END PGP SIGNATURE----- ------sinikael-?=_1-14490053494380.7812004333827645-- From nobody Tue Dec 1 14:51:36 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 7F1D21AD324; Tue, 1 Dec 2015 14:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlrEu26q4GhH; Tue, 1 Dec 2015 14:51:27 -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 04EE41AD350; Tue, 1 Dec 2015 14:51:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0D8A7BE64; Tue, 1 Dec 2015 22:51:24 +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 XZTSsYrYvCXH; Tue, 1 Dec 2015 22:51:23 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.20.32]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id ABACFBE55; Tue, 1 Dec 2015 22:51:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449010282; bh=KDTqLNlMxddVhy4q2JWV9+yPKPpMXcR8GCKUXYJAAvc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=sY6lN+HDyFxkg/3BQ7aYno7ZUPVuCpWlUyNtUk1OHBGPDe/6z9+mokltm7F8SpxgT 6S8jDFekttwfB800uYJsfcdncQFoHjRcrZ7s5TKpR/ZqqGqUjpzjDrNiMwiRwX1Z8z PBlwGZZ4Y2st21wLdodsSMNMlg7U/i0xQEY0Onns= To: shutup@ietf.org References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <1448923888960-cb7e590f-f443f8dd-7ec594e1@fugue.com> <565CD58D.9080403@dcrocker.net> <1448924778159-4b16d8e4-631c41b1-52b0fbf2@fugue.com> <605ee74e-863d-47cb-9089-fb83e13e4e38@gulbrandsen.priv.no> <565D9CFC.6070102@pscs.co.uk> <1448988713596-9f0a5014-48bb3a2c-8e1bc938@fugue.com> <565DE53F.2080904@mustelids.ca> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <565E2461.6000608@cs.tcd.ie> Date: Tue, 1 Dec 2015 22:51:13 +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: <565DE53F.2080904@mustelids.ca> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="j3f94Fantq3xsKAk0eM0WBLWrmCkkj5gF" 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: Tue, 01 Dec 2015 22:51:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --j3f94Fantq3xsKAk0eM0WBLWrmCkkj5gF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/12/15 18:21, Chris Lewis wrote: >=20 > On the other hand, we can see that that the lack of that information > presents difficulties to filtering technologies. When you get a > series of harassing emails from a given site originating from a given > user that's forging from lines and mutating content, you have nothing > concrete to filter on to distinguish it from other email from the same > provider. If you assume the MSA in that case isn't rogue, then there are a variety of options that could be used in place of the actual IP address that would have better privacy properties without being particularly onerous on anyone. For example one could imagine replacing the MUA IP address value in a Received header field with something like E(k-epoch, MUA-IP-address) where k-epoch is some key that changes now and then, perhaps in a way that requires very little state in the MSA. The point (for now) is not to recommend that the above be done but just to note that there are other options that may not have been considered in the past. Or maybe they were but the reasonable trade-offs have changed. Cheers, S. --j3f94Fantq3xsKAk0eM0WBLWrmCkkj5gF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWXiRmAAoJEC88hzaAX42iYtgIALZUTLNvFlpRb5Z7SbTHY+Vn v6LxEzzN9lBZ6mAIZh7LgkUF9qeOWeuCLcuGCWcEpCUxpltFZuqxjuul1p3QPDCc iI9qn5LCVE82GoLU8g9t9iWQ3sCwbt9JtvPq7JRTZVHgfJnexW9SPAiIrl7n5lco mdmXvTr5f3rRpy8GT3yk7dIxj2v6uBuFsp9D2rl27/gubqkSgrDK86EAkqJUGz5a D3YvcHLa2sJsie9CHHI1O5SCOQuCZ3DULe6URzfPTnIBu2CtfxKZ0EeybtbKFm9k 4n6k9E8OWs6fhx6N5RMdhq2eFrstps0BWkNi4Y0IYv08CWZcCCRsS1X8ssjr5d8= =YVId -----END PGP SIGNATURE----- --j3f94Fantq3xsKAk0eM0WBLWrmCkkj5gF-- From nobody Tue Dec 1 14:58: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 E42721AD367; Tue, 1 Dec 2015 14:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vqt9koFzXAp1; Tue, 1 Dec 2015 14:58:45 -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 BB15E1AD373; Tue, 1 Dec 2015 14:58:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5BB9ABE64; Tue, 1 Dec 2015 22:58:43 +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 KHUWACHqi7pt; Tue, 1 Dec 2015 22:58:42 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.20.32]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 68D01BE55; Tue, 1 Dec 2015 22:58:41 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449010722; bh=AxqQCdnYGaETlB+24I9O+p4ncdK/EWbJ2nFF5x1SYB8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=vUraE3A93PEW7lbHsyJx2rX/KdReOCz3FIT+ta5saSI/8ZbLOcMLO3nZVpNT8VlA9 4g0/p6aS+ZGry7SNfYDLvMoIDn1+HdIvZOVylCmzedAEMG1BLHg7x6xhhndEGUywxu B4CRG/Xzu81uUpNUWgPMFG2Mw7YqcsV3g109humQ= To: Christian Huitema , 'Martijn Grooten' , ietf-smtp@ietf.org References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <1448923888960-cb7e590f-f443f8dd-7ec594e1@fugue.com> <565CD58D.9080403@dcrocker.net> <1448924778159-4b16d8e4-631c41b1-52b0fbf2@fugue.com> <605ee74e-863d-47cb-9089-fb83e13e4e38@gulbrandsen.priv.no> <565D9CFC.6070102@pscs.co.uk> <1448988713596-9f0a5014-48bb3a2c-8e1bc938@fugue.com> <565DE53F.2080904@mustelids.ca> <20151201192353.GA23999@lapsedordinary.net> <07bf01d12c71$9b88b790$d29a26b0$@huitema.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <565E2620.4020901@cs.tcd.ie> Date: Tue, 1 Dec 2015 22:58:40 +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: <07bf01d12c71$9b88b790$d29a26b0$@huitema.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: Tue, 01 Dec 2015 22:58:47 -0000 On 01/12/15 19:50, Christian Huitema wrote: > On Tuesday, December 1, 2015 11:24 AM, Martijn Grooten wrote: >> >> I agree that if keeping your geolocation is a matter of life and death, > you >> shouldn't use email, but for me that is not a reason for the IP address to > be >> visible for anyone who can read the email. I think privacy matters, even >> when it's not about life and death. >> > > I am also concerned with automated mass surveillance, including traffic > analysis. The basic traffic analysis produces "5-tupple" logs. Since a lot > of the Internet usage is now mobile, there is no direct mapping between IP > addresses and user identities. To move from traffic analysis to > surveillance, the analyzers need to restore that mapping. There are multiple > ways to do that, as explained in RFC 7624, and email headers are one of > them. > > Clearly, there are also other sources of correlation between IP address and > identity. Various IETF working groups are busy closing these other sources > as well: MAC Address randomization to suppress direct mapping of identities > to roaming devices; DHCP anonymity profile to remove the leakage of metadata > in DNS packets; or, HTTPS to prevent observation of HTTP cookies. To break > the correlation between IP address and identity, we need to also close the > leakage in the SMTP traces. > > Everybody understands that there is a tension there between privacy and > fighting spam. I get the use case of the virus-infected home PC that > originates spam through the permissive SMTP relay of some local ISP. But > then many mail providers feel the need to provide privacy to their users, > which drives them to deploy their own formatting of the "received" field. We > do have a tension there, and that tension is precisely why we want to study > the alternatives and come up with a proposed recommendation. +1 to all the above. > Hence the WG > charter. Well... the charter text proposed (perhaps combined with the draft posted before) does seem to have caused a bit of an allergic reaction from many mail folks;-) I suspect those of us who would like to see work done to improve the privacy properties of mail may need to understand that reaction some more before trying to move stuff ahead. Cheers, S. From ietf@mustelids.ca Tue Dec 1 15:11:37 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 A6B6E1ADBFC; Tue, 1 Dec 2015 15:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.343 X-Spam-Level: X-Spam-Status: No, score=0.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYOQHQG5KMlA; Tue, 1 Dec 2015 15:11:36 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782601B29AD; Tue, 1 Dec 2015 15:11:36 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB1NBYuD020966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 1 Dec 2015 18:11:35 -0500 To: shutup@ietf.org References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <1449005349724-ffd73ebb-f70e368e-426663a1@fugue.com> From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <565E2926.1050900@mustelids.ca> Date: Tue, 1 Dec 2015 18:11:34 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <1449005349724-ffd73ebb-f70e368e-426663a1@fugue.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: Tue, 01 Dec 2015 23:27:13 -0000 On 12/01/2015 04:29 PM, Ted Lemon wrote: > Tuesday, Dec 1, 2015 4:10 PM Richard Clayton wrote: >> If you want to have very limited data in your email header fields then >> you should look at the systems that you operate yourself and clean up >> the information at that point. You'll probably get a poorer delivery >> experience when sending to MAGY and others -- but that's your tradeoff. > > Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DDB1B2F31; Tue, 1 Dec 2015 11:10:08 -0800 (PST) > 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 BPlsDC_M90ws; Tue, 1 Dec 2015 11:10:06 -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 CDD061AD481; Tue, 1 Dec 2015 11:10:05 -0800 (PST) > > Here are the Received: headers from the previous message I sent to the list. As you can see, there is no Received header at all for the submit server. My submit server doesn't add one, because there's no good reason to. I have had zero issues with mail I send not being delivered to any of the big providers. When I do have issues, the issues I have tend to be really small servers (typically IETF participants who, like me, run their own mail servers) that have all sorts of exciting steampunk gadgets filtering spam. > > The issues that I have tend to be that mail to those users is delayed, not that it never arrives. It's their choice to set up greylisting, and slowing down the reply rate for discussions like this isn't a bad thing, so I really wouldn't describe this as a "poorer delivery experience." The inevitable result is your mail server is treated no differently than grandma's PC. When your cat's litter box gets infected with, say, cutwail, spewing gazillions of copies of randomized "come do X to my Y!" exhortations, you're not giving the receiver (ML or ad-hoc) very much to distinguish between that and your pearls of wisdom. Hence your entire infrastructure gets blocked, you end up annoyed, the cat ain't admitting anything, and nothing gets fixed very quickly. Also remember that at scale, you CANNOT afford to talk to everybody who has trouble with email. Not when the loaded labor rate of just one support call dwarfs the income you make with the associated customer. If you have to get noticed by a human being, you're already cost them more than they'll make. Of course many systems operate this way without much difficulty. Because they are either already clean or expend the effort to remain clean. Which is fine until that one day when something goes wrong. From nobody Tue Dec 1 15:37: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 3180C1B2A79 for ; Tue, 1 Dec 2015 15:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.137 X-Spam-Level: X-Spam-Status: No, score=-101.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 NfDlRPdjOooP for ; Tue, 1 Dec 2015 15:37:45 -0800 (PST) Received: from ntbbs.santronics.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFC51B2A78 for ; Tue, 1 Dec 2015 15:37:44 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1970; t=1449013056; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=jQlrRF5BSvT74hYTqX3/KsGh4qE=; b=mJO6/xzxvpOXxqVBOr8BK7k/F4/fXlufxxizY4ZDwNX+9kEGYGzlm4HnndSDcx BXCWRXNJJbqqgpdT3ZLO8zh6tC7GVZlwDqQ4am3av0NSuOIcD14Exn0fZBjK+UGa X24euNRLIZl+327bfRxEQvG5VIiJgn+PDbr59ylJ1olvQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for shutup@ietf.org; Tue, 01 Dec 2015 18:37:36 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 901252581.19165.4024; Tue, 01 Dec 2015 18:37:35 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1970; t=1449012948; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=tB3rgp2 kxsHEqqsRWpzk667jn59z2jsHJrEtSu1XoJ0=; b=Gp8+mx2YRCxY2drTBloyN57 MOS8yymtcuk+ZPcSHvrUXAoJOqvC9kmyOFwKKsKOSF6CNuH/7+bPEatGrrd5LiL6 GbGkpI1Hma4UQi5kwQkCZN4QaPm2XA6CdtrLulT29qzA4g7zu6ulKTS3DxEUvqKW A/RukFGCoG1F3dVDvCfg= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for shutup@ietf.org; Tue, 01 Dec 2015 18:35:48 -0500 Received: from [192.168.1.2] ([99.121.4.202]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4135081414.9.91180; Tue, 01 Dec 2015 18:35:47 -0500 Message-ID: <565E2F38.8060408@isdg.net> Date: Tue, 01 Dec 2015 18:37:28 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Christian Huitema , 'Martijn Grooten' , ietf-smtp@ietf.org References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <1448923888960-cb7e590f-f443f8dd-7ec594e1@fugue.com> <565CD58D.9080403@dcrocker.net> <1448924778159-4b16d8e4-631c41b1-52b0fbf2@fugue.com> <605ee74e-863d-47cb-9089-fb83e13e4e38@gulbrandsen.priv.no> <565D9CFC.6070102@pscs.co.uk> <1448988713596-9f0a5014-48bb3a2c-8e1bc938@fugue.com> <565DE53F.2080904@mustelids.ca> <20151201192353.GA23999@lapsedordinary.net> <07bf01d12c71$9b88b790$d29a26b0$@huitema.net> In-Reply-To: <07bf01d12c71$9b88b790$d29a26b0$@huitema.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: Tue, 01 Dec 2015 23:37:47 -0000 On 12/1/2015 2:50 PM, Christian Huitema wrote: > > I am also concerned with automated mass surveillance, including traffic > analysis. The basic traffic analysis produces "5-tupple" logs. Since a lot > of the Internet usage is now mobile, there is no direct mapping between IP > addresses and user identities. To move from traffic analysis to > surveillance, the analyzers need to restore that mapping. There are multiple > ways to do that, as explained in RFC 7624, and email headers are one of > them. > > Clearly, there are also other sources of correlation between IP address and > identity. Various IETF working groups are busy closing these other sources > as well: MAC Address randomization to suppress direct mapping of identities > to roaming devices; DHCP anonymity profile to remove the leakage of metadata > in DNS packets; or, HTTPS to prevent observation of HTTP cookies. To break > the correlation between IP address and identity, we need to also close the > leakage in the SMTP traces. > > Everybody understands that there is a tension there between privacy and > fighting spam. I get the use case of the virus-infected home PC that > originates spam through the permissive SMTP relay of some local ISP. But > then many mail providers feel the need to provide privacy to their users, > which drives them to deploy their own formatting of the "received" field. We > do have a tension there, and that tension is precisely why we want to study > the alternatives and come up with a proposed recommendation. Hence the WG > charter. I'm all for "generalized" product enhancement features. So you are proposing for SMTP developers to consider adding SMTP Receiver options such as: [X] Add "Received:" Header [_] Mask User IP address Should this be at the USER or SYSTEM level? Both? Effectively, we would be changing RFC5321 from a MUST to a SHOULD|MAY where a required protocol feature becomes optional. -- HLS From nobody Tue Dec 1 15:45: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 BB7DA1B2A9C; Tue, 1 Dec 2015 15:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLsx02oqJF9X; Tue, 1 Dec 2015 15:45:57 -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 966891B2A9A; Tue, 1 Dec 2015 15:45:56 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14490135544770.6843698341399431" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <565E2926.1050900@mustelids.ca> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <1449005349724-ffd73ebb-f70e368e-426663a1@fugue.com> <565E2926.1050900@mustelids.ca> Date: Tue, 01 Dec 2015 23:45:54 +0000 Message-Id: <1449013554783-b461d703-192d4623-50f6eda5@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: Tue, 01 Dec 2015 23:45:58 -0000 ------sinikael-?=_1-14490135544770.6843698341399431 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tuesday, Dec 1, 2015 6:11 PM Chris Lewis wrote: > When your cat's litter box gets infected with, say, cutwail, spewing = gazillions of copies of randomized =22come do X to my Y!=22 exhortations, = you're not giving the receiver (ML or ad-hoc) very much to distinguish = between that and your pearls of wisdom. Er, no, the cat box doesn't have my credentials nor know my email address, = so it can't send spam from me. If it sends spam from someone other than = me, the Received header field makes my /legitimate/ email look more like = spam, because both the cat's spam and my legitimate email have the same IP = address in the Received header field. In this case I /definitely/ don't = want the Received header field. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14490135544770.6843698341399431 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXjEyCRAMw8Nu0HeKywAAgjwIAKZWa7d5QaeqUU1ofeNG ff3lfVZtB2KJ3BBUAXU0/ENkAHw5+BT4OQ9VlsUN+brUGwAJ4zqmxpRMZR0B aGI0vbpLpeCO5CVYy9ym/4EZ+o+KFSYKPa2rGTPD/lhJfa6UfHkLDIZmzLfE TJkZbFH0Cm32PXkrwDUz67WR3FYHPmUMY+TJytH4XMKydlwVnASaHfMNBc+B SN1PjK8Fwrcrkqnp2c+xACutycOxVPMhBo0MMiyEwj5Z9oyYnWXqpxtbi9N+ 8ucVUy7vqzXJMUw8zkuEW2HRkqGe11N8dVOUJwjpAYS/czrZLs7oeeGE1F5D Jcw0+lCYYvdlfoq37+Os/b8= =oQZ1 -----END PGP SIGNATURE----- ------sinikael-?=_1-14490135544770.6843698341399431-- From nobody Tue Dec 1 15:49:56 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 3D4421B2AAD; Tue, 1 Dec 2015 15:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.079 X-Spam-Level: X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, 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 Rv5tCX-qw37G; Tue, 1 Dec 2015 15:49:52 -0800 (PST) Received: from mail.lapsedordinary.net (thinksmall.vps.bitfolk.com [85.119.83.85]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE431B2AAB; Tue, 1 Dec 2015 15:49:52 -0800 (PST) Received: by mail.lapsedordinary.net (Postfix, from userid 1000) id 49B0B343FE; Tue, 1 Dec 2015 23:49:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lapsedordinary.net; s=mail; t=1449013791; bh=20V2cjOezqFDyAOmZvq6AXHwrkU56Pwnd+xxo3//PJQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=tVuYUaKpk/4wBt25PG0GTOFg256AqyZ6g3gk79FplxdeN3GGcqsQn//t0HBhktFE3 4wiBDlWa3p2JsNe6roL7xqHNjsJdQiG48tgF+cbtQKRD5VhwfQdsbc0tHEqmVPYMXu WZ7nkzWCNy0zY+gcCCtssuQoVOGhcyInOMrweReM= Date: Tue, 1 Dec 2015 23:49:51 +0000 From: Martijn Grooten To: ietf-smtp@ietf.org Message-ID: <20151201234951.GA8176@lapsedordinary.net> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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: Tue, 01 Dec 2015 23:49:53 -0000 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 01, 2015 at 09:10:20PM +0000, Richard Clayton wrote: > If you want to have very limited data in your email header fields then > you should look at the systems that you operate yourself and clean up > the information at that point. You'll probably get a poorer delivery > experience when sending to MAGY and others -- but that's your tradeoff. Sure, making such changes on your own is probably going to hurt more = = = =20 than it helps. Which seems a good argument in favour of some kind of = = = =20 RFC, or at least a WG discussing whether one is needed. = = = =20 = = = =20 Martijn. --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWXjIfAAoJEI5dMs9dIv8ZJOoH/3Xwo1tiaWVbw4Ny1DmsxmGR kxL7iB42i+9kANUui6ykfchfjOI8ujwVieoxljHYHPRqadrkD5YrwcAVLh4CDfpt K7CNWEvElMSRQjzzI/zE3GgELHD+tNgbB8XRZbBHopZunv2RJROfRkXfDOTtnKVv 30USMceiM4jhYGKJ6U7h9oXwshBEZKqH0miC4rrMVKPmq2z95iFjy2g1PeYD0wlH o25Ja0EwbAMRhQQS/dMpQU/vtHyvS01IQEcCWQQvLBabxucc16sBJmNCy8Q7IJsA F+DFrvOb5EMSeYDSefQaT7BPnAFCGkk2C8DRbGRHL4DqFaAxTXkR/AiR6Q3GvhM= =oUoD -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW-- From nobody Tue Dec 1 15:55:07 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 2DE441B2ADE; Tue, 1 Dec 2015 15:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKBgo9VnhPR6; Tue, 1 Dec 2015 15:55:04 -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 190321B2ACF; Tue, 1 Dec 2015 15:55:02 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14490141011360.4420234963763505" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <20151201234951.GA8176@lapsedordinary.net> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <20151201234951.GA8176@lapsedordinary.net> Date: Tue, 01 Dec 2015 23:55:01 +0000 Message-Id: <1449014101455-fe92733c-7c74504b-77e15fc4@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: Tue, 01 Dec 2015 23:55:05 -0000 ------sinikael-?=_1-14490141011360.4420234963763505 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tuesday, Dec 1, 2015 6:49 PM Martijn Grooten wrote: > Sure, making such changes on your own is probably going to hurt more = = = =20 > than it helps. Which seems a good argument in favour of some kind of = = = =20 > RFC, or at least a WG discussing whether one is needed. = = = =20 Yup, what I'm getting from this conversation is that we ought to try to = gain a bit more clarity than we currently have on this question. I'm = hearing a lot of hand-wavey protests, but when I try to dig deeper it's not= clear that much analysis has actually occurred. That analysis would be = worthwhile to do and to write up as an informational draft. I think the = informational draft should =5Fmake no recommendations=5F but should just = talk about the various use cases. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14490141011360.4420234963763505 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXjNVCRAMw8Nu0HeKywAAencH/Rq2Zc7Vh3fniW8adXgY cukEdohB912ynERWdg3M8bFLLmzElSjZGixtkFs+hiuIobQf0ObxvnGOSjl5 u2RJGnOOiUuk4TgoTk3HWgyX1KfHfyWTL7wl4uwcjJUdta6zWNInikfojKBe y0wQ6EiUx801fNtLONltxzw8At13Ha6XpjCyKu9fQPYog7UWGeZGeM8o/xYA ObjpLHZkJLCLu9evnnpC1BlEFV9LKNyEDThNH9tvZunZDJ3RMqGTumZZgZcX XO+bxXGhzlJgYiIgCXnaUD2LVbVics2OjuSgf0V2xlyz4z0tGpOKD+P44ppZ 92AQIuCvXRVl+ZKwhZA/ORg= =IeOm -----END PGP SIGNATURE----- ------sinikael-?=_1-14490141011360.4420234963763505-- From nobody Tue Dec 1 16:00:02 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 98A671B2B02; Tue, 1 Dec 2015 15:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzGVN5eZt5vQ; Tue, 1 Dec 2015 15:59:57 -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 4BBCF1B2AB6; Tue, 1 Dec 2015 15:59:55 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14490143938550.4831642177887261" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <57B818513A0069189BA3CF41@JcK-HP8200.jck.com> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <57B818513A0069189BA3CF41@JcK-HP8200.jck.com> Date: Tue, 01 Dec 2015 23:59:53 +0000 Message-Id: <1449014394167-7d2dec58-2c6a9ae8-33fc8e7a@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: Tue, 01 Dec 2015 23:59:58 -0000 ------sinikael-?=_1-14490143938550.4831642177887261 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tuesday, Dec 1, 2015 6:52 PM John C Klensin wrote: > Suppose that, > instead, the question was closer to: =22if a user had a serious > desire to protect her location, especially against pervasive > surveillance by state actors and too-curious message recipients, > how would she do that with existing systems=3F=22 John, I think that I already explained why this isn't a good question to = ask. We don't want privacy just for people who think in advance, =22hm, = email in general isn't private, and I know that I am going to need privacy,= so I will use this other service in order to gain privacy.=22 We want = the email to already have been private when the need for it to be private = arises, without the user who needs this privacy having a mental model that = would allow the aforementioned questions to be asked, to say nothing of = being answered. Regarding my personal mail server, one instance is in Dallas and the other = in Frankfurt. Regardless of where I happen to be on any given day, any = geolocation done on the headers will reveal that I am in a data center in = one of those two cities. Since I am not in either of those data centers, = I am protected from any revelations about my actual location through header= fields in my email. Of course, you can tell that the mail came from me, = but that's what I want, so it's okay. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14490143938550.4831642177887261 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXjR6CRAMw8Nu0HeKywAAzlAIAN3OBOsEi7NS57aPkmSx C4LXzur5hi0Y+xZ87hjjfKDiZnB8Aft6WcN/78iSpeVCk0932mI7dsAIK3E2 WNmam6h0ukjhjWMdtepcPgQ+eOxxel28pIrOGIw0W6W4tkBTQulBYEzerZii eTG9eLtkXUQbbLz22r7pd9mfSNj+h4xHcSE2CXb7tk47orEM49cZWLGj7sOk nsO5Ii9bH5Al4yrSx40RczXZPPWEY7Hrqz0MbVBy0kKBpJcqXJZgOYBjh5W2 JbLhxwKv3zrWE05OQq4nMvfozFtkiYmFDv0SK4PDzJNPiJPGfTvOfVzyGuYA ULB/0gjd9tJP6eSyjkBkQwU= =NQ5V -----END PGP SIGNATURE----- ------sinikael-?=_1-14490143938550.4831642177887261-- From nobody Tue Dec 1 17:09:24 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 747491B2FF3; Tue, 1 Dec 2015 17:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.242 X-Spam-Level: ** X-Spam-Status: No, score=2.242 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srRnNeFSwF7N; Tue, 1 Dec 2015 17:09:21 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F191B2FEF; Tue, 1 Dec 2015 17:09:21 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB219JFJ023994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 1 Dec 2015 20:09:19 -0500 To: shutup@ietf.org References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <1449005349724-ffd73ebb-f70e368e-426663a1@fugue.com> <565E2926.1050900@mustelids.ca> <1449013554783-b461d703-192d4623-50f6eda5@fugue.com> From: Chris Lewis Message-ID: <565E44BE.9060303@mustelids.ca> Date: Tue, 1 Dec 2015 20:09:18 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <1449013554783-b461d703-192d4623-50f6eda5@fugue.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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: Wed, 02 Dec 2015 01:09:22 -0000 On 12/01/2015 06:45 PM, Ted Lemon wrote: > Tuesday, Dec 1, 2015 6:11 PM Chris Lewis wrote: >> When your cat's litter box gets infected with, say, cutwail, >> spewing gazillions of copies of randomized "come do X to my Y!" >> exhortations, you're not giving the receiver (ML or ad-hoc) very >> much to distinguish between that and your pearls of wisdom. > > Er, no, the cat box doesn't have my credentials nor know my email > address, so it can't send spam from me. If it sends spam from > someone other than me, the Received header field makes my > /legitimate/ email look more like spam, because both the cat's spam > and my legitimate email have the same IP address in the Received > header field. In this case I /definitely/ don't want the Received > header field. Er yes, without the MSA-enforced IP address (or unique blob indicating something similar) the filter can't necessarily tell whether your legitimate email is different than the cat litter box. By omitting the MSA's received line your legitimate mail becomes _less_ distinguishable from the flying litter ... the ML has more chance of lumping both of youse into the same bucket and so your, er, email ends up in the toilet too. Even when everything is forged/forgeable (eg: regardless of whether the MSA's headers are forged or decided to be trustworthy), the uniformity of your Received/From tuples stands out in stark contrast to the forged stuff (random or otherwise) to the ML - it gives the ML more to "grab onto". Now, with my piddly little mail server (which your steam punk mail server doesn't seem to like BTW), the ML will rarely see enough signal to do a proper analysis. But at scale, the ML often will. From nobody Tue Dec 1 17:43: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 533A81B3097; Tue, 1 Dec 2015 17:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.043 X-Spam-Level: *** X-Spam-Status: No, score=3.043 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlxyyMBNU9W9; Tue, 1 Dec 2015 17:43:47 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6326F1B3087; Tue, 1 Dec 2015 17:43:47 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB21hh7t001819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 1 Dec 2015 20:43:45 -0500 To: shutup@ietf.org References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <57B818513A0069189BA3CF41@JcK-HP8200.jck.com> <1449014394167-7d2dec58-2c6a9ae8-33fc8e7a@fugue.com> From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <565E4CCF.3080901@mustelids.ca> Date: Tue, 1 Dec 2015 20:43:43 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <1449014394167-7d2dec58-2c6a9ae8-33fc8e7a@fugue.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Wed, 02 Dec 2015 01:43:48 -0000 On 12/01/2015 06:59 PM, Ted Lemon wrote: > Tuesday, Dec 1, 2015 6:52 PM John C Klensin wrote: >> Suppose that, >> instead, the question was closer to: "if a user had a serious >> desire to protect her location, especially against pervasive >> surveillance by state actors and too-curious message recipients, >> how would she do that with existing systems?" > > John, I think that I already explained why this isn't a good question to ask. We don't want privacy just for people who think in advance, "hm, email in general isn't private, and I know that I am going to need privacy, so I will use this other service in order to gain privacy." We want the email to already have been private when the need for it to be private arises, without the user who needs this privacy having a mental model that would allow the aforementioned questions to be asked, to say nothing of being answered. The reality is that if the user wasn't already conscious of their privacy and striving to preserve it through continuous vigilance, they've already completely outed themselves. For example, if you're expecting to use a nicknamed gmail account, that email conversation with Amazon with your credit card info or Facebook with your real name last year, has outed that gmail account forever - gmail hides received lines remember? It's far better to train them in the reality of what they need to do to preserve their own privacy, than the impossibility of trying to privacy-protect everything (and still have something anybody wants to use). From nobody Tue Dec 1 17:57: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 3E77D1B30E4; Tue, 1 Dec 2015 17:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtv5YSzjO1eX; Tue, 1 Dec 2015 17:57:05 -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 8D9381B30DF; Tue, 1 Dec 2015 17:57:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9A458BE7C; Wed, 2 Dec 2015 01:57:03 +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 0XFVFjE5StrJ; Wed, 2 Dec 2015 01:57:02 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.20.32]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4DE1ABE75; Wed, 2 Dec 2015 01:57:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449021422; bh=7rxzRTZ/baTyD+zS7LG0QNadPqiQ50cI1axZ7CjEiVQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=I0rtztu9DeNrZSjDpMfkAgmODFwIORVpbnzpsNyLSwHcW2sGPHZNHbrIuyqnWNu3Y cAn1YMPT49vsa/OSHhr4mn3L1zQZurFSfA6Lf9nid1oxgEkMlxYfCAdwLpLq+BIxS5 btXX8N/H18dbDpXjXMCn63eZx2cNaEdfPS8NKrfI= To: Chris Lewis , shutup@ietf.org References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <57B818513A0069189BA3CF41@JcK-HP8200.jck.com> <1449014394167-7d2dec58-2c6a9ae8-33fc8e7a@fugue.com> <565E4CCF.3080901@mustelids.ca> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <565E4FEC.2000607@cs.tcd.ie> Date: Wed, 2 Dec 2015 01:57:00 +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: <565E4CCF.3080901@mustelids.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: Wed, 02 Dec 2015 01:57:11 -0000 On 02/12/15 01:43, Chris Lewis wrote: > > It's far better to train them in the reality of what they need to do to > preserve their own privacy, than the impossibility of trying to > privacy-protect everything (and still have something anybody wants to use). Do you have any evidence for the above? But in any case, I think your argument is clearly wrong because we know that it is not possible to "train them" in security or privacy. (That leaves open the possibility that your conclusion is correct based on some other argument, but very much weakens confidence in your conclusion for me.) IMO the onus is on us as technology developers to ensure that what we make allows those who deploy that to do a good enough job. In this case there is room for debate about the cumulative privacy exposure from many messages including MUA IP addresses (or of popular implementations defaulting to do so) vs. the benefits accruing to anti-spam techniques. For me, claims that any of this is so obvious as to not even need to be looked are not at all convincing. And in that I do include claims that "all we need to do is X and it'll be privacy friendly" (for any X) as well as claims to "move on, there's nothing to see here." S. From nobody Tue Dec 1 18:31: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 013CA1B314A; Tue, 1 Dec 2015 18:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgJ5d8-GQFe0; Tue, 1 Dec 2015 18:31:01 -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 CACFB1B3149; Tue, 1 Dec 2015 18:31:00 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14490234583980.09015750465914607" From: Ted Lemon To: shutup@ietf.org In-Reply-To: References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <1449005349724-ffd73ebb-f70e368e-426663a1@fugue.com> <565E2926.1050900@mustelids.ca> <1449013554783-b461d703-192d4623-50f6eda5@fugue.com> Date: Wed, 02 Dec 2015 02:30:58 +0000 Message-Id: <1449023458722-c64be47a-bac7cd73-e20f750d@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: Wed, 02 Dec 2015 02:31:03 -0000 ------sinikael-?=_1-14490234583980.09015750465914607 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tuesday, Dec 1, 2015 6:52 PM Al Iverson wrote: > Is that a hobbyist configuration=3F Is it relevant=3F It sounds a bit = like > a cat and the hat both sharing a NAT. But in a very common high volume > production email scenario used by email service providers, clients and > types of mail are segregated by sending IP address. My answer applies to both the gmail scenario and the private server = scenario. In both cases, putting my IP address in the Received header = field means that my legitimate mail is more likely to be dropped as spam, = not less likely. > Noted that you don't. Just adding my voice: I do want it. Correction: by =22I do not want it,=22 I mean =22it do not want my mail = legitimate getting dropped as spam,=22 not =22On a personal level, I don't = like it.=22 -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14490234583980.09015750465914607 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXlfiCRAMw8Nu0HeKywAAvYMIAJj7/0GtiedwOMGEQhAi yHzB4bohGhq0YN3n86ShtpsXUt4rHMxkNs3YPaBqIjaQQ/0ocXqEZymkz2ib GeoekGfNDZYF+a1RszwnHGQ63K5gz4lbTmsZQozNH5MCiQBa1SHz6P7Zb1v6 0aUdI+QB0BAgStInN++E4gmr0zFVuiuGnOubzeNd7Osnzc/wqPVngLbiqx4c Cvsbb6Oy1MJzMN4GUdhxi7CsgqWL1ERC4SthB9rYHBR64+Mmm4gLHzlrnMCX yRICBnyKSVuzpkXnes1hPmNckaDjA0it7FwfhaydQDWfcXWqvfDmhb+TBfp6 w7x4lMlLXhiCFXoRIJwHsbk= =xaMZ -----END PGP SIGNATURE----- ------sinikael-?=_1-14490234583980.09015750465914607-- From nobody Tue Dec 1 18:55: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 EF0071B31AD; Tue, 1 Dec 2015 18:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EAxuVYeLo4F; Tue, 1 Dec 2015 18:55:22 -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 7F1461B31A8; Tue, 1 Dec 2015 18:55:21 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14490249146060.39559955755248666" From: Ted Lemon To: ietf@mustelids.ca In-Reply-To: <565E4CCF.3080901@mustelids.ca> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <57B818513A0069189BA3CF41@JcK-HP8200.jck.com> <1449014394167-7d2dec58-2c6a9ae8-33fc8e7a@fugue.com> <565E4CCF.3080901@mustelids.ca> Date: Wed, 02 Dec 2015 02:55:14 +0000 Message-Id: <1449024914920-c367c12b-5b2db232-b118a379@fugue.com> MIME-Version: 1.0 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: Wed, 02 Dec 2015 02:55:24 -0000 ------sinikael-?=_1-14490249146060.39559955755248666 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tuesday, Dec 1, 2015 8:43 PM Chris Lewis wrote: > The reality is that if the user wasn't already conscious of their privacy= and striving to preserve it through continuous vigilance, they've already = completely outed themselves. >=20 > For example, if you're expecting to use a nicknamed gmail account, that = email conversation with Amazon with your credit card info or Facebook with = your real name last year, has outed that gmail account forever - gmail = hides received lines remember=3F I think you are misunderstanding the reasoning behind hiding the IP address= in the received header. It is not because the IP address associates the = email address with your identity. In all likelihood, the email address is= very strongly associated with your identity, as you say. One of the = primary uses of email addresses =5Fis=5F to establish an identity, after = all. The purpose of obscuring the IP address is to avoid an association between = the =5FIP address=5F and your identity. This accomplishes several useful = privacy benefits: - If you regularly post to a public mailing list, as we both do, nobody can= scrape the mailing list for Received headers and figure out whether or not= I am at home, in order to find an opportune time to break into my home. - If you post to a public mailing list, that doesn't reveal information = about where you live to people who might want to harass you. - An MiTM attack on your email service provider that prevents TLS = encryption of your mail will not give the attacker information linking your= identity to specific IP addresses. Whether these are issues that we need to be concerned about it certainly = something we can debate. I definitely agree that =5Fjust=5F obscuring the= IP address in the Received header isn't enough to protect you. But if = it's not obscured, that's definitely enough to out you. > It's far better to train them in the reality of what they need to do to = preserve their own privacy, than the impossibility of trying to = privacy-protect everything (and still have something anybody wants to use).= This is literally impossible. We don't demand that airline passengers = take part in making sure that the airplane is safe to fly. Why do we = expect people with similar levels of knowledge about the operation of email= to understand how to preserve their privacy=3F -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14490249146060.39559955755248666 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXl2TCRAMw8Nu0HeKywAAdxQIAKWlnXLyCHH+bmC2T5P8 CIUx17bplgMgwPxFvImrnaepUYdjCeXnbpPoL1+J1jPXD9CUVuleHn3wGp6a o4a6ycxaL2sDNM36MPnTuCMS8Oo8XIa6LfNACuP5aQZNgdK1u0Zv3WOBE8HS FP5wdJS2etqEPai6lATQhxOv4wQ5tzC2Q4GaDCvWbwGN7fjZRE1J4tbLASXv GqpL++XTjhzRHngR10gJyot3re6wTUPDpBR3+b0Gyzay2TYaMhmy+rd1XF0t J0FganUhShY4a4jl5Typ47NkHd+HUCU1yk204i4HDXbQhV5KpDr/dsiPgot6 eZrDVS3yPbNyJ38BQKV67iU= =yCm5 -----END PGP SIGNATURE----- ------sinikael-?=_1-14490249146060.39559955755248666-- From nobody Tue Dec 1 19:09:57 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 289F41B31DB; Tue, 1 Dec 2015 19:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwAJxk7bTeyX; Tue, 1 Dec 2015 19:09:53 -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 774631B31DA; Tue, 1 Dec 2015 19:09:52 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14490257896920.9116729779634625" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <565DF2F0.6050207@mustelids.ca> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <01PTRE1WMUMQ01729W@mauve.mrochek.com> <1448995610381-36d96644-173d7bf5-b94de12d@fugue.com> <565DF2F0.6050207@mustelids.ca> Date: Wed, 02 Dec 2015 03:09:49 +0000 Message-Id: <1449025790038-5861f0d7-9427eca4-6b12d71f@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: Wed, 02 Dec 2015 03:09:55 -0000 ------sinikael-?=_1-14490257896920.9116729779634625 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tuesday, Dec 1, 2015 2:20 PM Chris Lewis wrote: >> If they don't care enough to make such information available, it's >> likely that it's because they don't see the issue as being >> sufficiently important, which is to say they don't think Received: >> headers make enough difference to be worth arguing about. >=20 > That's not what it means at all. >=20 > For any such information to be even remotely meaningful, it has to be = tested on very large real environments. >=20 > Imagine, if you will, our approached our largest customers (which are = certainly big enough to matter in this context), and asked them to either: >=20 > - sacrifice filtering effectiveness for a week and tell us the > result, or > - re-instrument thousands of receiving MTAs to distinguish and report > on the differential based on a new indicator I provide >=20 > So that we could satisfy your curiousity, they'd laugh in our faces. That is literally what I said. They don't care enough about satisfying my= curiosity to do the work. Perfectly understandable. If they thought = that the IETF producing a document recommending that the Received header = field be obfuscated were a serious problem, they would care enough to do = the work--it's really not that much work, and chances are they already have= a test harness that would allow them to do it. > I could tell you the differential in our instrumentation. But if you = don't accept my previous assertions, you won't accept this one either. Again, this is literally what I asked for. I do not trust your assurances= that you speak from authority. IETF people are always trying to argue = from authority--if we held that against each other we would never get = anything done. I am very curious to hear your numbers, as long as you explain how you got = them. I don't mean explain your spam algorithm--I mean characterize your = sample, and explain why you think it's a good sample, and explain your = methodology: what you did to the sample for test A versus what you did for = test B. Interesting things to do for the test sample to differentiate it = from the control sample would be removing the last Received header field = entirely (last in sequence, meaning first added), modifying the From clause= for example as Stephen Farrell suggested, or simply deleting the From = clause but keeping the rest of the last Received header field. BTW, turning off the Received header field testing for a week isn't a valid= methodology, since there's no way to control for the rather substantial = variation in amounts and types of spam from week to week. > In an ideal world, when everybody here was under NDA, I could give you = some of the obvious, compelling and overwhelming evidence.=20 I don't think you could. You've said enough things that don't actually = make sense at this point that I would really need you to show your work, = not just give me assurances like the following: > It's huge. Really. Sorry. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14490257896920.9116729779634625 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXmD+CRAMw8Nu0HeKywAA3RcIANuHBQA1CZQCHxfVOhv9 E+oTvMEQYgPD5sNX/Qj7GC5ptI4tyHwRjIyXFSd53AF3p1j/8EEfeZ6ij90K 9hFbmsAsLzy1blU8uVkzpy/RQGuMsfYDEBILGsZgjqFMQEX40bRWOxvibKtr SOjT2iaprSTb1kw7+ECCTtmELLthifT0MKiroU2nkHSzL2eDIbdq8FZT8o8e flMWkFDYNdcl46prs62+w0+rJlXKlBW67PR3t52RoCEuyO5x+++bOen/kz4L X0n4MVT09QyJuE8xWcRty13Z0Mo7ZEDKg4JmIb7ccNlTooWBQSk9tpWeQUA8 3AMBHZXI14laeNuCpu+4O+0= =Smug -----END PGP SIGNATURE----- ------sinikael-?=_1-14490257896920.9116729779634625-- From nobody Tue Dec 1 19:35: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 D420E1B323D; Tue, 1 Dec 2015 19:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKeNG6yG8OQN; Tue, 1 Dec 2015 19:35:08 -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 6391C1B323A; Tue, 1 Dec 2015 19:35:07 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14490273044320.11421541660092771" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <20151202032522.GB12713@gsp.org> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <57B818513A0069189BA3CF41@JcK-HP8200.jck.com> <1449014394167-7d2dec58-2c6a9ae8-33fc8e7a@fugue.com> <565E4CCF.3080901@mustelids.ca> <20151202032522.GB12713@gsp.org> Date: Wed, 02 Dec 2015 03:35:04 +0000 Message-Id: <1449027304809-2b32a944-6d383650-49f2a64c@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: Wed, 02 Dec 2015 03:35:10 -0000 ------sinikael-?=_1-14490273044320.11421541660092771 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tuesday, Dec 1, 2015 10:25 PM Rich Kulawiec wrote: > The same user that might -- and I emphasize =22might=22 -- in some way = have > a fraction of their privacy protected is the same one that has a 9-line > email signature with the URLs of their social network profiles, their > phone number, their title and employer, and other far more = readily-useful > information. This is a stereotype, which very clearly is not grounded in any kind of = serious, statistically sound survey of real-world users. Are you = seriously proposing that the IETF should base its decisions on reasoning of= this quality=3F -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14490273044320.11421541660092771 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXmboCRAMw8Nu0HeKywAAA6IH/R4gXXoeN+t+H8B5epQG h60SC++b8LBRtbYYBOXtpvYUEqpFnQ8zAWhbtYQr7Z7O10yoQvyHGgoCqvna vXodyUD0dCNdtA0tX27TfRDjfYDSCyUuOJMCcXMiAVOGs4ZhFamEiTiYnHO9 cxk4cSFbT21UiV5XvOVNes6V66V9TE9IYTQ0PWnVeR4VOtM6KRTrRYIvowkn hn58pq9+UagHcf1CzUlT3807Y+h+4Gb8f+iFZ0sH57E+8MmcsidiotX/FWCl AupCfgwUTRNKFKK2SSBl2O3lEgu022vVN4355IjObioVbX7g0D/IOf0brXb5 BkIHdspfU0N5T9kz6wV7jA0= =T/nF -----END PGP SIGNATURE----- ------sinikael-?=_1-14490273044320.11421541660092771-- From nobody Wed Dec 2 05:50: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 CDEEE1A8F41; Wed, 2 Dec 2015 05:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dItOb2mJwMis; Wed, 2 Dec 2015 05:50:55 -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 B713F1A8F3F; Wed, 2 Dec 2015 05:50:54 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14490642509200.3453761243727058" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <565EB238.6060207@pscs.co.uk> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <57B818513A0069189BA3CF41@JcK-HP8200.jck.com> <1449014394167-7d2dec58-2c6a9ae8-33fc8e7a@fugue.com> <565E4CCF.3080901@mustelids.ca> <1449024914920-c367c12b-5b2db232-b118a379@fugue.com> <565EB238.6060207@pscs.co.uk> Date: Wed, 02 Dec 2015 13:50:50 +0000 Message-Id: <1449064251263-c451a28b-ba1e4af8-62e69b69@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: Wed, 02 Dec 2015 13:50:58 -0000 ------sinikael-?=_1-14490642509200.3453761243727058 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Wednesday, Dec 2, 2015 3:56 AM Paul Smith wrote: > The thing is that whatever you do to email, the weak link is always the = human. Humans are the ones who respond to Nigerian princes, they're the = ones who think it's OK to send their bank password by email to anyone who = asks for it in an authoritative way, etc. >=20 > So, training HAS to be done, otherwise people will lose privacy. Look, I'm really sorry to keep harping on this, because I know it's a bit = off topic and probably annoying, but your model of how to do security for = end users is simply wrong. The way you prevent people from getting = scammed is to by default not deliver email from people they don't know. I= realize this is anathema to a lot of email folks, but that's why facebook = is more popular than email now: facebook doesn't deliver spam from people = you haven't friended. The way you prevent people from getting their passwords ripped is to not = give them passwords. The tokbind working group is working this problem, = and the solution they have is a good one, which we will undoubtedly see = deployed in the future. It's true that it's not available now, and the = vulnerability that you cite does exist now. This is a problem we need to = solve, not an inevitable quality of online technology. Security = technology based on physical tokens is also getting better/more accessible.= It's worth noting that Nigerian scammers typically scam people who have = actual cognitive deficits, not regular people. People aren't actually all= equally gullible, and there are lots of people who are skeptical enough = that they can benefit from privacy protections even in the absence of = secure token binding and physical tokens. > Of course, most people don't really care about privacy whatever they say = (witness all the personal information posted to Facebook/Twitter/etc) so it= doesn't matter that they can't be trained. The ones who do really care = about their privacy are the ones who will train themselves if the = information is available to them. This doesn't reflect what people who actually study this issue are saying. = People do care about privacy. They just can't get it. Even though = they can't get it, they do take measures to get it to the extent that they = can. It's true that not everybody does this, but it is not true that most= people just don't care. If you ask them =22do you care about privacy,=22= they might say no, but if for example you ask them =22do you care if = thieves know whether or not you are out of town,=22 they will say yes. So saying that because people don't care about privacy, we shouldn't try to= protect their privacy, is wrong on two counts: first it's wrong that = people don't care about privacy, and second it's wrong that we shouldn't = try to protect people from threats of which they are not presently aware. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14490642509200.3453761243727058 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXvc7CRAMw8Nu0HeKywAAN0MH/2rt/B4kfKpUje9QY7iC ckiPUqvdRoX7h07m2l3df58Tesk2jsm3yV1+k3vGdY6LKXGoToh0kUAOHlKp pdqZW+mVxx5xuPa+XSnJpIQ9kKRycSYkV4JAFeATIP+35/Qv2PsB6/hfpKqA RqkanGO6/LHjT/70r6CDqCvFTHPxz7yVyWKHfV5WvahY2f2lpx/0MRJzU3R9 faiDb1rTrSNaHfK0BuPaYTdj+71f9Ihg/NJyxyO8n/xRND+ymWi0aj0g6fgT DFdLnvJVyRe7Rgt6Hg7vNBjZAqUNdw586uAkz5WrI5SgkNuXMNIrv8FZ9GAc tEkBsQHnfRDXqC6dd5sKo30= =/Ob9 -----END PGP SIGNATURE----- ------sinikael-?=_1-14490642509200.3453761243727058-- From nobody Wed Dec 2 06:05: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 77E251A903F; Wed, 2 Dec 2015 06:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydXkQkIdff4a; Wed, 2 Dec 2015 06:05:55 -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 DC3E21A9045; Wed, 2 Dec 2015 06:05:53 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14490651508080.5139855369925499" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <565EBD82.2030600@pscs.co.uk> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <565EBD82.2030600@pscs.co.uk> Date: Wed, 02 Dec 2015 14:05:50 +0000 Message-Id: <1449065151122-b9505bf5-be5f0e83-f9cdd79b@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: Wed, 02 Dec 2015 14:05:56 -0000 ------sinikael-?=_1-14490651508080.5139855369925499 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Wednesday, Dec 2, 2015 4:44 AM Paul Smith wrote: > This is the bit that worries me. As a small mail server publisher & = hosting company, we try to actually help our customers with their problems = (unlike some of the big providers). The information in the Received headers= is vital to us when trying to narrow down why their messages bounced, or = why their incoming mail was delayed, or whatever. This is all true, and definitely a matter of concern. The question is, is= there some way that we can give you enough information to do the debugging= you need to do, without leaking private information=3F E.g., when would = you need the sender's home IP address to do debugging=3F -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14490651508080.5139855369925499 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXvq/CRAMw8Nu0HeKywAAB1MH/iZQDOqcNmVeiR5MRIOQ /1S66eCh7Gq6GQiBrvw4NMF9r7LjVDObS4+dVDxRKONmCkd/ce10y3BO4qAc 7xyoICrdSEWXvRWSO9jihtZ1YuFNUz7rxFE9G8s9vmLhr4l3Cle4/36xCAu3 UV7UiJYYARK4X3vTeghXBVNFOa7L7APBfK3rBmLWtVsfNNs7s4sDPFcn2YHn YZHrfepr++HP2wXLHuwWjhg04OQnXYOLzk//FYyDYPmPcoYDwFpYuvMio4ZF G8BNinImGAxnaWhzY6KTNZbCSXoC5MXx6AtsWRrhV3Fu2zgB4vkrjDX5bDgr ZAQUWb18Xajyl+/46wnJXh4= =A6eT -----END PGP SIGNATURE----- ------sinikael-?=_1-14490651508080.5139855369925499-- From nobody Wed Dec 2 06:24:56 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 18D311A90A2; Wed, 2 Dec 2015 06:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKtH1grYk9Ig; Wed, 2 Dec 2015 06:24:54 -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 D36541A90A0; Wed, 2 Dec 2015 06:24:51 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14490662872370.6522229702677578" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <565EFDDB.3060406@pscs.co.uk> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <1448923888960-cb7e590f-f443f8dd-7ec594e1@fugue.com> <565CD58D.9080403@dcrocker.net> <1448924778159-4b16d8e4-631c41b1-52b0fbf2@fugue.com> <605ee74e-863d-47cb-9089-fb83e13e4e38@gulbrandsen.priv.no> <565D9CFC.6070102@pscs.co.uk> <1448988713596-9f0a5014-48bb3a2c-8e1bc938@fugue.com> <565DE53F.2080904@mustelids.ca> <20151201192353.GA23999@lapsedordinary.net> <565EBBC9.7040804@pscs.co.uk> <1449065001755-39fae123-57885a2a-dc631a3a@fugue.com> <565EFDDB.3060406@pscs.co.uk> Date: Wed, 02 Dec 2015 14:24:47 +0000 Message-Id: <1449066287570-32e0c086-3cd36f70-e2a9218a@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: Wed, 02 Dec 2015 14:24:55 -0000 ------sinikael-?=_1-14490662872370.6522229702677578 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Wednesday, Dec 2, 2015 9:19 AM Paul Smith wrote: > Maybe the US is different. In the UK, it generally gives random locations= which have no relation to reality, or probably just the ISP's location. Possibly the UK has better privacy laws=3F The EU as a whole certainly = does. It may also depend on how much information the ISP is willing or = able to sell about you. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14490662872370.6522229702677578 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXv8vCRAMw8Nu0HeKywAA6bgIAKCCtj+KJYe+S5rRfP+z KsXvwmaIevXEsyfdXUu9Mk7fB4t3v4hIad4L4/ybCnfHY41GdN7LEZD7JWon /h/vhtUc4M3rXtd0wOTaHvVlNY54p44lC5GAwHbV52ecl5fyN9yB5hVr4R70 chCwulEHxOdhFMrsFINV71YdI3986dSsLkkO502w50Wz6RMeDm+qbA7gHQBI Y7U+QkEgYzTeZ2rOULx2el4j3Nmeo2QEEpSczdpi4NFuiaRikAAYNc6WcLlp yDMMszewu/h97kh9V8KCZHjTfe6b30PRt74eIobJYZQDGCriWlfAQgdmJB3e leXEu0E8PutFWH5+59fAqkQ= =4Dtj -----END PGP SIGNATURE----- ------sinikael-?=_1-14490662872370.6522229702677578-- From nobody Wed Dec 2 06:50:25 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 516E11A9119 for ; Wed, 2 Dec 2015 06:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 oTSL5I5VFy7z for ; Wed, 2 Dec 2015 06:50:20 -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 70F261A00B6 for ; Wed, 2 Dec 2015 06:50:16 -0800 (PST) Received: (qmail 99112 invoked from network); 2 Dec 2015 14:50:15 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 2 Dec 2015 14:50:15 -0000 Date: 2 Dec 2015 14:49:53 -0000 Message-ID: <20151202144953.22592.qmail@ary.lan> From: "John Levine" To: ietf-smtp@ietf.org, shutup@ietf.org In-Reply-To: <1449064251263-c451a28b-ba1e4af8-62e69b69@fugue.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Shutup] [ietf-smtp] real life privacy tradeoffs, was Proposed Charter 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: Wed, 02 Dec 2015 14:50:21 -0000 >> So, training HAS to be done, otherwise people will lose privacy. > >Look, I'm really sorry to keep harping on this, because I know it's a bit off topic and probably >annoying, but your model of how to do security for end users is simply wrong. ... Different people are different and it is not helpful to pretend that all end users are the same. Most people say they care about privacy, but their actions show that they actually don't, e.g., they'll trade their password and SSN for a candy bar. Some people really do care about privacy. I don't know if you've ever talked to someone who runs a battered women's shelter, but I have. For them, their privacy is really a matter of life and death, and they have to deal with impressively complex threats. I've heard direct reports of malware that installs keyloggers that report back to the hostile spouse. These people boot their computers from a CD to use webmail through Tor, and buy burner phones in bulk. The kind of stuff we're talking about redacting here is completely irrelevant to them, since as I said, they are not so dim as to depend on their mail provider's logging practices for their safety. Christian's point about bulk collection is a reasonable one, but just as the collection affects a lot of people, the security benefits from good header logging affect a lot of people, too. We need to start by understanding how they're really used and what the benefits are. >From what we've heard here from people who run significant mail systems for real users, the benefits are substantial. R's, John From nobody Wed Dec 2 07:11:44 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 758091A0025; Wed, 2 Dec 2015 07:11:41 -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 tny3V5Cl5OFO; Wed, 2 Dec 2015 07:11:40 -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 2CCD01A0022; Wed, 2 Dec 2015 07:11:40 -0800 (PST) Received: from [192.168.1.99] (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 tB2FBc27002575 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2015 07:11:39 -0800 References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <57B818513A0069189BA3CF41@JcK-HP8200.jck.com> <1449014394167-7d2dec58-2c6a9ae8-33fc8e7a@fugue.com> <565E4CCF.3080901@mustelids.ca> <1449024914920-c367c12b-5b2db232-b118a379@fugue.com> <565EB238.6060207@pscs.co.uk> <1449064251263-c451a28b-ba1e4af8-62e69b69@fugue.com> To: Ted Lemon , shutup@ietf.org From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <565F0A42.2070402@dcrocker.net> Date: Wed, 2 Dec 2015 07:12:02 -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: <1449064251263-c451a28b-ba1e4af8-62e69b69@fugue.com> 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]); Wed, 02 Dec 2015 07:11:39 -0800 (PST) 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 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: Wed, 02 Dec 2015 15:11:41 -0000 On 12/2/2015 5:50 AM, Ted Lemon wrote: > Wednesday, Dec 2, 2015 3:56 AM Paul Smith wrote: >> > The thing is that whatever you do to email, the weak link is always the human. Humans are the ones who respond to Nigerian princes, they're the ones who think it's OK to send their bank password by email to anyone who asks for it in an authoritative way, etc. >> > >> > So, training HAS to be done, otherwise people will lose privacy. > Look, I'm really sorry to keep harping on this, because I know it's a bit off topic and probably annoying, but your model of how to do security for end users is simply wrong. The way you prevent people from getting scammed is to by default not deliver email from people they don't know. I realize this is anathema to a lot of email folks, Absent hard data that shows efficacy, both of you are wrong. At base, we don't know how to prevent folks from getting scammed, while still allowing them to interact with the outside world. Lots of people are sure they know the right answer here, but none of them can document efficacy. Worse, most of the ways people cite have already been demonstrated to be inadequate or unachievable. So yeah, this line of discussion is entirely out of scope. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Dec 2 07:12: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 84C471A0065; Wed, 2 Dec 2015 07:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.013 X-Spam-Level: X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pxl1wSkVPr28; Wed, 2 Dec 2015 07:12:48 -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 BD0221A0049; Wed, 2 Dec 2015 07:12:47 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14490691644980.015955416252836585" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <20151202144953.22592.qmail@ary.lan> References: <20151202144953.22592.qmail@ary.lan> Date: Wed, 02 Dec 2015 15:12:44 +0000 Message-Id: <1449069164873-53573cc1-d1798c08-2eeb118d@fugue.com> MIME-Version: 1.0 Archived-At: Cc: ietf-smtp@ietf.org Subject: Re: [Shutup] [ietf-smtp] real life privacy tradeoffs, was Proposed Charter 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: Wed, 02 Dec 2015 15:12:50 -0000 ------sinikael-?=_1-14490691644980.015955416252836585 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Wednesday, Dec 2, 2015 9:49 AM John Levine wrote: > Different people are different and it is not helpful to pretend that > all end users are the same. Most people say they care about privacy, > but their actions show that they actually don't, e.g., they'll trade > their password and SSN for a candy bar. Show your data or please stop making generalizations like this. This is = really not helpful. > Some people really do care about privacy. I don't know if you've ever > talked to someone who runs a battered women's shelter, but I have. > For them, their privacy is really a matter of life and death, and they > have to deal with impressively complex threats. I've heard direct > reports of malware that installs keyloggers that report back to the > hostile spouse. These people boot their computers from a CD to use > webmail through Tor, and buy burner phones in bulk. The kind of stuff > we're talking about redacting here is completely irrelevant to them, > since as I said, they are not so dim as to depend on their mail > provider's logging practices for their safety. So what you are saying is that there are two kinds of caring about privacy:= not at all, or extremely. I'm sure these stereotypes are based in real = personal experience, but anecdotes are not data. This is not what actual = research on this topic appears to show. We tend not to remember = reasonable people in ordinary situations: we remember complete idiots, = because it's funny/disturbing, and we remember people in trouble. Basing = policy decisions on personal recollections tends to get things badly wrong.= > Christian's point about bulk collection is a reasonable one, but just > as the collection affects a lot of people, the security benefits from > good header logging affect a lot of people, too. We need to start by > understanding how they're really used and what the benefits are. I agree that we need to understand this. I've been asking people who say = they are in the know if they could share some data with us, and since I = asked yesterday, it's unreasonable to think that someone would already have= answered. Hopefully we will get some data. >From what we've heard here from people who run significant mail > systems for real users, the benefits are substantial. We've heard unsubstantiated assertions to this effect, not accompanied by = any data, yes. The reason I'm skeptical about this is twofold. First, the one example = someone presented that seemed to support the case for including IP address = identifying information from the mail submission server actually looks to = me like it makes things worse, not better, at least in the presence of a = competently operated mail submit server. Second, I'm pretty sure that if you are filtering spam, and then you add a = heuristic that pays attention to the initial sender's source address, you = will see some increase in messages identified as spam. However, if you = saw that effect five years ago when you installed that heuristic, and your = filtering software has gotten a lot more sophisticated in its reliance on = ML since then, you might still believe that the heuristic is making a big = difference, when it's really making a small difference.=20 And you might never have instrumented it in such a way that you could = discover the present truth of the matter. And that's precisely the = perfectly reasonable mindset from which claims that =22it makes a big = difference=22 would come without any data at all to back them up. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14490691644980.015955416252836585 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXwptCRAMw8Nu0HeKywAAMOwIAMjc1YGHcIFNeUzjOxtA WIdBFn5kej40zam/KzQmpeHJl/mEr1slU9UWtymFzLyATemZbswXn4Jqfjzo FA2DzD5v4z/IQKoQFdy2j5D2/fyNMUGFZBJWp71yEmiDgSaPFhZardt3EuQv MjshnvoMb+aC9BPeJDHlVAwMCexC0o92AUzasCmSiYAvNxsGwu5139/ucOSL pn4iPe7OM8s2QqE9nGXgIQgdwNAzmmibuhsSgadA7RJR9BWGH89wfD4BAepM PLrzKYy8/1Rgi1TBtk57RkYfJC3pAOA7rWhOmr1dm68RJC8UIm7n64IIGEPf Cx506GpKAxT1rXrShVzEJFo= =faam -----END PGP SIGNATURE----- ------sinikael-?=_1-14490691644980.015955416252836585-- From nobody Wed Dec 2 07:20:24 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 F26A91A013F; Wed, 2 Dec 2015 07:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxBVGZ7fNZLO; Wed, 2 Dec 2015 07:20: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 6CD741A0125; Wed, 2 Dec 2015 07:20:18 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14490696098940.9147816265467554" From: Ted Lemon To: dcrocker@bbiw.net In-Reply-To: <565F0A42.2070402@dcrocker.net> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <57B818513A0069189BA3CF41@JcK-HP8200.jck.com> <1449014394167-7d2dec58-2c6a9ae8-33fc8e7a@fugue.com> <565E4CCF.3080901@mustelids.ca> <1449024914920-c367c12b-5b2db232-b118a379@fugue.com> <565EB238.6060207@pscs.co.uk> <1449064251263-c451a28b-ba1e4af8-62e69b69@fugue.com> <565F0A42.2070402@dcrocker.net> Date: Wed, 02 Dec 2015 15:20:09 +0000 Message-Id: <1449069610234-da77a7a5-9aad0b81-0070a67b@fugue.com> MIME-Version: 1.0 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: Wed, 02 Dec 2015 15:20:21 -0000 ------sinikael-?=_1-14490696098940.9147816265467554 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Wednesday, Dec 2, 2015 10:12 AM Dave Crocker wrote: > Absent hard data that shows efficacy, both of you are wrong. Not leaking data is 100% effective at not leaking data. > At base, we don't know how to prevent folks from getting scammed, while > still allowing them to interact with the outside world. We know that revealing their personal information is harmful. We know = that this information is used, in real world situations, to cause harm to = real people. We do not know which specific sources are used, so it may = well be that nobody is currently using the Received header field to do it. = It may be that the Received header field is not currently the weakest = link. However, it is clearly a weak link: as soon as I wanted to see what= information my email was revealing, all I had to do was go to the = ietf-smtp archive and look at my recent messages to the archive, and there = the Received headers were, available for the world to see. > Lots of people are sure they know the right answer here, but none of > them can document efficacy. Worse, most of the ways people cite have > already been demonstrated to be inadequate or unachievable. Redacting IP address information from SMTP submission servers is very = achievable, as witness the fact that the major email providers are doing it= . Whether it actually prevents peoples' demonstrably violated privacy = from being used against them is indeed unknown. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14490696098940.9147816265467554 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXwwqCRAMw8Nu0HeKywAAK1UH/1aw/NOcvCckmQujd9G0 I7PVBvxoTZaMmZOrxgOPlYgNI1Q2hcyrLpIv8CgSr5x2TtTVM4dhmX0Rrw8u yc0cgfXainBTc/cnbZ+1Gywr2w++e/7syC4+/zWfDjZ7thmf/BTaP0uKF/kZ QeqGuVfFnM2o9uc1ZqJREUIUKNdiXLCeiWuH928RQ3SPDh0ipHClbVj/wlDd 41qJMC33Q1XFwt+6fWOkAVPRNTzCn/bEqZnqD3I16thPIKcZawRMCIvJTVMF f2MMhMtRp/R2xx668YAb7g6TO8nZR0XeKsDnWHXWzqyKY6kxkHerPF/5etc0 VAQxbFErjr8LMaOzFxYLM9k= =tATn -----END PGP SIGNATURE----- ------sinikael-?=_1-14490696098940.9147816265467554-- From nobody Wed Dec 2 07:28:23 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 0EBA71A8745; Wed, 2 Dec 2015 07:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rc0jjUUJHdHQ; Wed, 2 Dec 2015 07:28: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 948761A86EE; Wed, 2 Dec 2015 07:28:18 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14490700954770.9738120217807591" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <565EFD93.2060507@pscs.co.uk> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <565EBD82.2030600@pscs.co.uk> <1449065151122-b9505bf5-be5f0e83-f9cdd79b@fugue.com> <565EFD93.2060507@pscs.co.uk> Date: Wed, 02 Dec 2015 15:28:15 +0000 Message-Id: <1449070095816-c64690a8-829c0c47-fd944ab9@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: Wed, 02 Dec 2015 15:28:21 -0000 ------sinikael-?=_1-14490700954770.9738120217807591 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Wednesday, Dec 2, 2015 9:17 AM Paul Smith wrote: > Eg, someone says to me =22so and so received this message from me, but I = didn't send it - has my laptop got a virus on it=3F=22 I can look at the IP= address in the Received header and say, =22no, that message came from = China, someone's just spoofing your address=22, or =22it may have done, is= your ISP 'bigisp.com'=3F=22 (or in some cases, =22is your home IP address = 1.2.3.4=3F=22 (if they have a static IP address)) This is email that your customer sent through your server (or didn't). = Suppose you didn't have the Received header with the user's IP address on = it. Are you really going to tell me that you couldn't use information at = your disposal to give both of the answers that you proposed=3F If it was not sent through your server, you don't even need to look at your= logs to see that--it's in the Received header fields that you didn't = redact, or rather, it's evident because your mail servers probably aren't = mentioned in the Received header fields. If they are, then you can go = look at the logs to see what IP address connected to the server to drop = that email; if the logs don't match the headers, it's fake, and if they do,= you have the submitter's IP address. I will grant you that the Received header field saves you some time, but it= doesn't prevent you from answering the particular question that you are = proposing as a motivating use case for not redacting it. If this were a = serious problem, you would spend a half hour to write a script that = eliminated the time difference. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14490700954770.9738120217807591 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXw4PCRAMw8Nu0HeKywAA8yMIALUlLVf+vWj3ieccx/98 9/2ojkRRWfdEcMSM8xGrFGSFjpjLsGumu1704twh01EHmrnzviNWYLjkpDGz 9gi5K3F4SVTp1Klmhvi6a+UO6gTUiOOaP5zs9IlKMsw65uPBr7QLwADJAEV/ D3pc5BFyqx5M0VeVtoD8jHsF6AqY5LgblOWsh3XSiZrrXzeDuwNuvjsfmKLT TdQ+6i2W92w24UFE6p9ZvUdnocabOO+ppmhlWO6+CJzI+Zl0Z2Fl3301RKvW TaK+jt6VBFYX1cyDemPASEatSQ3qwp2fOR03PLYmYm/01j7XVenhXZGCoX9c Yz49qbs5t66S2NNsLxrhiKI= =dWug -----END PGP SIGNATURE----- ------sinikael-?=_1-14490700954770.9738120217807591-- From nobody Wed Dec 2 08:02:42 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 E5DE61AC412; Wed, 2 Dec 2015 08:02:36 -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 LfOHM7rY0m1g; Wed, 2 Dec 2015 08:02:32 -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 4C5FE1AC3F9; Wed, 2 Dec 2015 08:02:32 -0800 (PST) Received: from [192.168.1.99] (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 tB2G2VJ6004080 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2015 08:02:31 -0800 References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <565EBD82.2030600@pscs.co.uk> <1449065151122-b9505bf5-be5f0e83-f9cdd79b@fugue.com> <565EFD93.2060507@pscs.co.uk> <1449070095816-c64690a8-829c0c47-fd944ab9@fugue.com> To: shutup@ietf.org From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <565F162F.7010109@dcrocker.net> Date: Wed, 2 Dec 2015 08:02:55 -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: <1449070095816-c64690a8-829c0c47-fd944ab9@fugue.com> 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]); Wed, 02 Dec 2015 08:02:32 -0800 (PST) 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 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: Wed, 02 Dec 2015 16:02:37 -0000 Gentle folk, There have been several days of postings from folk expert in this domain of discourse, each carefully explaining the problems with various assertions being made. None of those postings seems to be effecting much improvement in the conduct of this thread. So it's time for folk making assertions of efficacy or inadequacy to take the burden of documenting the validity of their assertions, as well as explaining how they are relevant to a discussion of whether to charter this wg. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Dec 2 08:07:24 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 0BEC51AD0AB for ; Wed, 2 Dec 2015 08:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 i2hrQ7u_2qln for ; Wed, 2 Dec 2015 08:07:22 -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 380D71AD160 for ; Wed, 2 Dec 2015 08:06:51 -0800 (PST) Received: (qmail 20145 invoked from network); 2 Dec 2015 16:06:48 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 2 Dec 2015 16:06:48 -0000 Date: 2 Dec 2015 16:06:26 -0000 Message-ID: <20151202160626.22889.qmail@ary.lan> From: "John Levine" To: ietf-smtp@ietf.org, shutup@ietf.org In-Reply-To: <1449069164873-53573cc1-d1798c08-2eeb118d@fugue.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Shutup] [ietf-smtp] real life privacy tradeoffs, was Proposed Charter 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: Wed, 02 Dec 2015 16:07:23 -0000 In article <1449069164873-53573cc1-d1798c08-2eeb118d@fugue.com> you write: >-=-=-=-=-=- >-=-=-=-=-=- > >Wednesday, Dec 2, 2015 9:49 AM John Levine wrote: >> Different people are different and it is not helpful to pretend that >> all end users are the same. Most people say they care about privacy, >> but their actions show that they actually don't, e.g., they'll trade >> their password or SSN for a candy bar. > >Show your data or please stop making generalizations like this. This is really not helpful. Hmmn. If people are this unfamilar with practical user security, and are unable to type "trade password for a candy bar" into Google, this is going to be a very slow slog. R's, John From nobody Wed Dec 2 08:26:57 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 805961B2B81; Wed, 2 Dec 2015 08:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDBn9_b05g80; Wed, 2 Dec 2015 08:26:53 -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 B39051B2B75; Wed, 2 Dec 2015 08:26:52 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14490736094280.4613548668567091" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <20151202160626.22889.qmail@ary.lan> References: <20151202160626.22889.qmail@ary.lan> Date: Wed, 02 Dec 2015 16:26:49 +0000 Message-Id: <1449073609748-d67ce695-2d04f2ef-aaba9619@fugue.com> MIME-Version: 1.0 Archived-At: Cc: ietf-smtp@ietf.org Subject: Re: [Shutup] [ietf-smtp] real life privacy tradeoffs, was Proposed Charter 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: Wed, 02 Dec 2015 16:26:55 -0000 ------sinikael-?=_1-14490736094280.4613548668567091 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Wednesday, Dec 2, 2015 11:06 AM John Levine wrote: >>Show your data or please stop making generalizations like this. This is= really not helpful. > Hmmn. If people are this unfamilar with practical user security, and > are unable to type =22trade password for a candy bar=22 into Google, = this > is going to be a very slow slog. John, what is deeply frustrating about this conversation is that every time= I ask a serious question, I get an answer like this. Did you look into = that study=3F Can you describe their methodology=3F Did they identify = potentially confounding factors that would introduce bias into the = results=3F Does their methodology account for those factors=3F Do they = make any sort of case at all for why their sample is a representative = sample=3F You don't know, do you=3F You just read one of the clickbait = articles that Google offered you. The very study you are citing is actually used as an example of bad = methodology in a textbook, =5FElementary Statistics: Looking at the Big = Picture=5F, by Nancy Pfenning. Did the researchers check to see if the = people they surveyed gave their actual birthday, or their actual = password=3F Or were they the ones who were scammed=3F The survey was = also done in 2004. Do you think nothing has changed since then=3F The reason this has become a slog is that nearly every answer I've gotten = for a question I've asked, and nearly every criticism I've seen of a = statement I've made, is of a similar level of quality to the answer you = just gave me. I don't mean to single you out--your example study is just = too good an example not to use. What this conversation has told me is that nobody on this mailing list = actually knows the answer to this question: =22what are the costs and = benefits of redacting information from the Received header fields in email = messages=3F=22 You all think you know the answer, and your intuition is = probably not completely invalid, but if we actually care what the answer to= this question is, we probably do need to form a working group to study it = a bit more seriously than we have done thus far, and we definitely can't = rely on the assurances of supposed subject matter experts as to what the = actual cost is. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14490736094280.4613548668567091 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXxvJCRAMw8Nu0HeKywAAqKUH/joqYRfUHFAI+UED44i6 RXnAiWXOiaWMaKs7kRMNQFN7kuRQYSFvI9hPhIt/SbdVLURjkXjRFB0r8ztZ Q6mErkRpowSDjjysL0VmspkGuBHHMwpAPuTxGII80jj30Bl9cOFleQ/fnjXt M+IB0e3ioiJC/D3VEg1gJKJaR2QbqYjrNMJdgTjwWORNUuYyP9Vgd4TgA3iG Ky2MyBmTHMo4OOvlexq8Uqx8NC1pfUDc8+JrotgcdG+wwNX3fD0YIZrHIIKR 3S+wsy50bolwO+SSjd+SUDoqPr4Xt6mhPpfPi8rISCyZwHzvJX04Uqi2buTQ sxlInQokUQrv3KePJjK3Xns= =IpXh -----END PGP SIGNATURE----- ------sinikael-?=_1-14490736094280.4613548668567091-- From nobody Wed Dec 2 08:32:40 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 DE8531B2BA7 for ; Wed, 2 Dec 2015 08:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_21=0.6] 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 byhO-FbxVb0D for ; Wed, 2 Dec 2015 08:32:38 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFE981B2BB0 for ; Wed, 2 Dec 2015 08:32:35 -0800 (PST) Received: by qgeb1 with SMTP id b1so37555919qge.1 for ; Wed, 02 Dec 2015 08:32:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=megacity-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=ykJi0bQo6KluD1mx/Zle8BpTPGh5Fu7kltgqxTYRlzs=; b=bIPk9EE2v2u4SUewY/g7sfEs79RnUshzFi4Kxs10B6+6UK+RDMA5kyUsh3fX0ZHMke +XjFY6GAm8xaPXnTIPqaBJrEvWw5h2iDnfLOElxFcWcExMZ/E8Ak8AY02WWGAUUA0kF8 OYNqsR4rs+5YXpaj+Xu8Va2FnKDBvl1uaw5TgUwN10dHc8SQCadpoH6pP1HflN5qVY7I +rmnUdIm2I5SSwAz+go3N5lN77lMvTvnKDg6VhkZ432OQugYydYH9MRZU2PB/pDgQ957 YBA9wT3SLFVcXSZ2s8wqREwyUoHmT6RVzS0qBrF7ErZKhWv+T6Im6+lUDD3/voMZeZKR T8ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=ykJi0bQo6KluD1mx/Zle8BpTPGh5Fu7kltgqxTYRlzs=; b=L9NDE5txuYRIpYh4HpzzjsvhgoFQ1SvpxtES0B/HTdpsDrYcQ/M4omkbDG6GwO1/tG Nzb8pyNE3WZYKjkzXEsFTfymieYsYKsLqFAo0TZjyact9ZNbWioUk8G8artW1gZT72W5 tZmzZJmGzR6NsEqWmOpNxSgAsVKB0c+U9Jl7JK/uE4Rm7Fyo78pEj8R/9QDY4094xS07 olVawA0Z2cg2/Aw1vVUXo3zOZHk0/ekVut8PC3l5EWFzaSShvLkL2P+rJZpNYrl24bBT GkXsrbwUvPAVCVc2hPOYNkwTysbc5UKx5RrOCCeb0QR1uxgTRxL5vWWksY7ZnMEr0/3s h9JQ== X-Gm-Message-State: ALoCoQnp4l5nlcM7nT06gwETorbFY/JqB213nZEbJ/StUlgvYdq3GsUm2+ehqgZsZnkXFfFiKyJ5 X-Received: by 10.140.17.102 with SMTP id 93mr5231019qgc.32.1449073954927; Wed, 02 Dec 2015 08:32:34 -0800 (PST) Received: from Akebono.local (cpe-67-243-53-192.hvc.res.rr.com. [67.243.53.192]) by smtp.googlemail.com with ESMTPSA id a5sm1501809qga.19.2015.12.02.08.32.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Dec 2015 08:32:33 -0800 (PST) To: ietf-smtp@ietf.org References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <565EBD82.2030600@pscs.co.uk> <1449065151122-b9505bf5-be5f0e83-f9cdd79b@fugue.com> <565EFD93.2060507@pscs.co.uk> <1449070095816-c64690a8-829c0c47-fd944ab9@fugue.com> <565F162F.7010109@dcrocker.net> From: "Derek J. Balling" X-Enigmail-Draft-Status: N1110 Message-ID: <565F1D1F.6080307@megacity.org> Date: Wed, 2 Dec 2015 11:32:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <565F162F.7010109@dcrocker.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hVi681si3ka088PiaEnRRwnmXXQ0mDtiP" 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: Wed, 02 Dec 2015 16:32:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hVi681si3ka088PiaEnRRwnmXXQ0mDtiP Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I've been uncharacteristically (for me) quiet up 'til now, so let me -- perhaps naively -- say what, to me, seems like a simple thing. 1.) It's axiomatic that Received headers disclosure some level of private data 2.) It's a matter of debate how valuable that data is to those who would abuse it 3.) It's a matter of debate as to what impact redaction/removal of that data from message headers would cause Why isn't this as simple as chartering the WG to go off and: 1.) Document the answers to questions 2 and 3 above, with data 2.) If they so choose after doing #1, propose remedies or changes to the existing methodologies consistent with the data they found above At that point, everyone can observe the data, attempt to replicate it (almost like a peer-review process, one would think) and then the discussion can be about whether or not any proposal that came out of the WG meets the larger goals of the net at-large. It seems that it shouldn't be this hard to charter them to go off and "crunch data" and "come up with a proposed solution consistent with that data". Nobody's "committed" to anything by letting folks go off and work on this. so why is there such vociferous debate over letting them go do that? What am I missing? (it's possible I have missed something, because this debate is the most traffic we've seen in years on this list). D --=20 I prefer to use encrypted mail. My public key fingerprint is FD6A 6990 F035 DE9E 3713 B4F1 661B 3AD6 D82A BBD0. You can download it at http://www.megacity.org/gpg_dballing.txt Learn how to encrypt your email with the E-Mail Self Defense Guide: https://emailselfdefense.fsf.org/en/ --hVi681si3ka088PiaEnRRwnmXXQ0mDtiP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0 Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWXx0fAAoJEGYbOtbYKrvQalAQAJOEHaumzgBkN7RwEXRbbGEb 0EOSlO6S4TDogPOrFoVKTYDBSy/c9KPNCH09cTsSNZG5Kvai/oZXr+KCv4CPbr7h +u7Q6A1QXgTiIvgA3/KkoIAcp9dYWVCiTbIsvXlmGPsOv6VEjY98eyYJVSiGqg+M MePLN/4JRmCtKJwkZD0PmCx6S+5q7j3pGTAsB6jF/3myVmh+pEBarKYyMbRWGyGx KaQ0QIv4bnlDkjBKh3dmDtF6yiatA5gw1ELn8qOCT5KvIVkr3j/7PfeFejYq46de Yu3+/XGWCcJCIPkFQrPxzK2L/FrAk/UvW+M2e2cxBhAhVq7x788SQbKludTr3ywN O/4N9nL0khHWebjzKsiwaeRdykFKE+G5ec16QGfi4J+Q+d4vYdsq9cfhziFxIYxh oIqj5iAUITQIW6rteKWceGQWU9vz/62+yyLSlwSmZPp+eaNeOoo3EbtwcIbxA74S IpSqgaiU33zZ56qZ5XUQTvVfUMMVHT2wapsg/c8RzsnchGI8C3muRp6Jn96eeHCI 2aYE5v6pSeX5Z6bzssHnZ2eyXEA7TKHgWs2wrqQH/tmp1WhbT32G9vtdACIdOj7f T9pFqf4EhUErg0lDPYj3h+nY8iJh4EYSD//yhPPxrQTzzoTrS8onyXx9KRvbsI0Q GnbTEvnrW1zweRtioQXI =c+Ag -----END PGP SIGNATURE----- --hVi681si3ka088PiaEnRRwnmXXQ0mDtiP-- From nobody Wed Dec 2 08:44:09 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 974831B2BF1; Wed, 2 Dec 2015 08:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0w24mA_tyYK; Wed, 2 Dec 2015 08:44:06 -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 A05C01B2BF0; Wed, 2 Dec 2015 08:44:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6ACFCBE3E; Wed, 2 Dec 2015 16:44:04 +0000 (GMT) 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 PX-tURAl3SFD; Wed, 2 Dec 2015 16:44:04 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B87E5BE4D; Wed, 2 Dec 2015 16:44:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449074643; bh=upH66G2UcGENxo/sNb4ip65lQDmuuYKlv0KsWJ5JqfQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=EuiU/1oHJLkF0/b8VGgs5MBf7uVLhh+nP3zzY8GizpP4rjXfvwtGPbJx1wcDVaIIb e5PvG2u/H0jlEuT/8/VZe1W9IoneL8K6mV7Rphu55oyh4h3/frV840d3fNh1hOE4/w CoYa6LefHcAqPvNyCKyhl/O1vI7IA24keI3ERxiU= To: "Derek J. Balling" , ietf-smtp@ietf.org References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <565EBD82.2030600@pscs.co.uk> <1449065151122-b9505bf5-be5f0e83-f9cdd79b@fugue.com> <565EFD93.2060507@pscs.co.uk> <1449070095816-c64690a8-829c0c47-fd944ab9@fugue.com> <565F162F.7010109@dcrocker.net> <565F1D1F.6080307@megacity.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <565F1FCE.9040702@cs.tcd.ie> Date: Wed, 2 Dec 2015 16:43:58 +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: <565F1D1F.6080307@megacity.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QrF671Dilv9MPvBM0iokoeDAUfrP1MQE5" 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: Wed, 02 Dec 2015 16:44:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QrF671Dilv9MPvBM0iokoeDAUfrP1MQE5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/12/15 16:32, Derek J. Balling wrote: > Why isn't this as simple as chartering the WG to go off and: >=20 > 1.) Document the answers to questions 2 and 3 above, with data > 2.) If they so choose after doing #1, propose remedies or changes to th= e > existing methodologies consistent with the data they found above (With no hats) That seems eminently sensible to me. I'm sure the specific text to describe the questions would need a bit of work, but that oughtn't be too hard. S. --QrF671Dilv9MPvBM0iokoeDAUfrP1MQE5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWXx/SAAoJEC88hzaAX42iBPsH/1CYRTRiVaS90/O0up27pES0 s6QdC4ZX3ny/RwBsWIG0rmlD+ry6+MaPmnET1yTTmBIo40k35dindBZmv+Hb+vDv NtFW+/L4U6lzFr7Tu+w9PwYbFEgx7RAjynazH+Kb1y3QYVUVg5fowjiMuRtXWESm fukirfltdOdA3UTxW3mYKAI73ifN8ZRiyICF3Rw5Dzm/vCdyd6lP6dSwstXoqpIf +Nx8Z3uo9s4/tExfRzPIgmnAnOWgSQ7U7KnYExrqMelr3nVelJHkq/DrQwXxNYVr TQV+kKOiXXGE8kffxQcB/4bRUYAeWsPDjGpIR3Mz5/vjxbXksZ7vzPaHewXPqds= =jOa/ -----END PGP SIGNATURE----- --QrF671Dilv9MPvBM0iokoeDAUfrP1MQE5-- From nobody Wed Dec 2 08:54:41 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 7D7381B2BF8; Wed, 2 Dec 2015 08:54:39 -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 XfOP2JQS0eiG; Wed, 2 Dec 2015 08:54:38 -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 30A6B1B2C33; Wed, 2 Dec 2015 08:54:38 -0800 (PST) Received: from [192.168.1.99] (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 tB2GsYj5005320 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2015 08:54:34 -0800 References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <565EBD82.2030600@pscs.co.uk> <1449065151122-b9505bf5-be5f0e83-f9cdd79b@fugue.com> <565EFD93.2060507@pscs.co.uk> <1449070095816-c64690a8-829c0c47-fd944ab9@fugue.com> <565F162F.7010109@dcrocker.net> <565F1D1F.6080307@megacity.org> <565F1FCE.9040702@cs.tcd.ie> To: Stephen Farrell From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <565F2262.9080002@dcrocker.net> Date: Wed, 2 Dec 2015 08:54:58 -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: <565F1FCE.9040702@cs.tcd.ie> 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]); Wed, 02 Dec 2015 08:54:35 -0800 (PST) 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 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: Wed, 02 Dec 2015 16:54:39 -0000 On 12/2/2015 8:43 AM, Stephen Farrell wrote: > > > On 02/12/15 16:32, Derek J. Balling wrote: >> Why isn't this as simple as chartering the WG to go off and: >> >> 1.) Document the answers to questions 2 and 3 above, with data >> 2.) If they so choose after doing #1, propose remedies or changes to the >> existing methodologies consistent with the data they found above > > (With no hats) That seems eminently sensible to me. I'm sure > the specific text to describe the questions would need a bit > of work, but that oughtn't be too hard. 1. That's an IRTF type of task, not an IETF type of task. 2. As sensible as the task might seem, the IETF pretty much never requires documentation about expected efficacy. That makes imposition of such a requirement, here, discriminatory. The original approach to chartering working groups was rather simpler: 1. Is there clear indication that 'the community' wants to do this, by virtue of there being folk who want spend time on wg development and they or other folk making noises about interest in implementing and developing it? 2. Is there a clear understanding of potential /danger/ from doing this? These days, we mostly stop at the first half of Question 1. But we have pretty much always left the question of 'efficacy' to the market. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Dec 2 08:59: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 CD8361B2C59 for ; Wed, 2 Dec 2015 08:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_21=0.6] 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 6OIBe6LWbpMQ for ; Wed, 2 Dec 2015 08:59:28 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7756B1B2C58 for ; Wed, 2 Dec 2015 08:59:27 -0800 (PST) Received: by qgcc31 with SMTP id c31so37796458qgc.3 for ; Wed, 02 Dec 2015 08:59:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=megacity-org.20150623.gappssmtp.com; s=20150623; h=subject:references:cc:to:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=bBONNjogsCEf5xhwgU0veEVlTF6Xpk3jCW5ceBLBHFE=; b=TbV35NdsOwDPFdxHB6Z8abIgOM7po0ui/Js2LNeoOI7+IvAuwj/XRMXrzTm86WDKvG sHBu8N8oauTRlRuoSrHeP4vF5bg7pLGHX317fp9ZLw6MEq65tFQls+gqv9lIM2SY3aKl Edb2uEy6e58IakMxVqrlBKu96CQ7/QTfw6LLOn1MY+tXqUzKlKY9fjXAz0NHRvoPOSIZ xqnrzxJnkgKYk1bJV6Cnjkog9VN6GYHC4rnNVL/Lau6klJgQvPgT7JmZtan19Blwz04a QJl5ECAkeHCsmkgjOImecjUftfigkVW/0nJaO1i6/hl61JikUypTtgtQoM5K8/k7wzjV fb8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:cc:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=bBONNjogsCEf5xhwgU0veEVlTF6Xpk3jCW5ceBLBHFE=; b=aZQElQJjXWU8zs+a+aN0UMgJwMi/Ar8loIydOA4LpvdNsUvSqMFS5Un5qclRyImHAn T1NwQRYka4PZqZM6RcIXdFpjdDKNf0QP7yMTwSGsIomgufG3t0scmTVc/yIg+cfgQo9m DThdqxs1wjqILxeQQIQZIciWPPOwsG3tT70nsM5LDx+MPx/r92PJjer1uA4Se1qG9hXh Y+Ej/Jb9mNyvfKxLKHb+L39OZ0hGM6cP9bWIEiHmNFXugTMH/tRWFjzV+lW4qIsmasWE a1ZIlLk5mHy8COwr0K0sJbzFgbpb09vFWIwLc1G/3WPLhXhVkXU4tON+myHCvj+VKKKn CtVQ== X-Gm-Message-State: ALoCoQmS7fL46KJtZefHx0yJ8q//QqvtHcex7+X8BWCOIBcjWlzu8y7WaCiTp4Axsm9BSdp5/ntC X-Received: by 10.140.101.51 with SMTP id t48mr5384039qge.71.1449075566705; Wed, 02 Dec 2015 08:59:26 -0800 (PST) Received: from Akebono.local (cpe-67-243-53-192.hvc.res.rr.com. [67.243.53.192]) by smtp.googlemail.com with ESMTPSA id c140sm1551874qkb.30.2015.12.02.08.59.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Dec 2015 08:59:24 -0800 (PST) References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <565EBD82.2030600@pscs.co.uk> <1449065151122-b9505bf5-be5f0e83-f9cdd79b@fugue.com> <565EFD93.2060507@pscs.co.uk> <1449070095816-c64690a8-829c0c47-fd944ab9@fugue.com> <565F162F.7010109@dcrocker.net> <565F1D1F.6080307@megacity.org> <565F1FCE.9040702@cs.tcd.ie> <565F2262.9080002@dcrocker.net> To: ietf-smtp@ietf.org From: "Derek J. Balling" Message-ID: <565F236A.8060609@megacity.org> Date: Wed, 2 Dec 2015 11:59:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <565F2262.9080002@dcrocker.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5ETKRdpE5EDsKdPFgCmFah0htQ08CXRa1" 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: Wed, 02 Dec 2015 16:59:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5ETKRdpE5EDsKdPFgCmFah0htQ08CXRa1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/2/2015 11:54 AM, Dave Crocker wrote: > On 12/2/2015 8:43 AM, Stephen Farrell wrote: >> >> On 02/12/15 16:32, Derek J. Balling wrote: >>> Why isn't this as simple as chartering the WG to go off and: >>> >>> 1.) Document the answers to questions 2 and 3 above, with data >>> 2.) If they so choose after doing #1, propose remedies or changes to = the >>> existing methodologies consistent with the data they found above >> (With no hats) That seems eminently sensible to me. I'm sure >> the specific text to describe the questions would need a bit >> of work, but that oughtn't be too hard. > > 1. That's an IRTF type of task, not an IETF type of task. > > 2. As sensible as the task might seem, the IETF pretty much never > requires documentation about expected efficacy. That makes imposition > of such a requirement, here, discriminatory. > > The original approach to chartering working groups was rather simpler: > > 1. Is there clear indication that 'the community' wants to do this, > by virtue of there being folk who want spend time on wg development and= > they or other folk making noises about interest in implementing and > developing it? > > 2. Is there a clear understanding of potential /danger/ from doing t= his? > > These days, we mostly stop at the first half of Question 1. But we hav= e > pretty much always left the question of 'efficacy' to the market. > It seems to me that #1 is covered by virtue of the request existing in the first place. I would argue that #2 will be covered in whatever work-product the WG comes up with (just as any other RFC would have to document negative-impacts, lack of backward compatibility, etc.). D --=20 I prefer to use encrypted mail. My public key fingerprint is FD6A 6990 F035 DE9E 3713 B4F1 661B 3AD6 D82A BBD0. You can download it at http://www.megacity.org/gpg_dballing.txt Learn how to encrypt your email with the E-Mail Self Defense Guide: https://emailselfdefense.fsf.org/en/ --5ETKRdpE5EDsKdPFgCmFah0htQ08CXRa1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0 Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWXyNrAAoJEGYbOtbYKrvQ22YP/1OnpuTKMa/9Ng6z0IGtFCJ+ /zvTcMR7cYxYYPiTCCDd+45FAFrTEPp+15lQLKQD0ZWFsASJJoaqGi2I0GWsQ+m2 03BQyQ6HWbpjvna9k/bbqexUfAPGodpVvXIjEgo7mGW1BkGE4oN0QRyqCUMNY9gx mG5VHKK8rRUSflw9LqSMsMfeQp3xpJ/fgl3ciww/+j+FKNWrXASWQ/ZaE6cP/I2p JnvwColzab7rxuKmozELA7uWuRSRdx2hOusOTjN1wRQPfLIeUiVIpZP96AbaZFP6 4MydtPexu2+oPz6o8xZfvohSrE/C6eEJkFJhLMPOTpKACnglzqKBjLgOts/vzwBG 8h22RMjqrBjt/jpUkC8XoC4DvZ786hwPIomAAGd06166DysmFEyPqLZv21oLB/GI 5I+fbDPJ4Bzsn9J7eVO3EGEvSRcGevk3gTUa0VW6OWAVDuOmBX1OGfdCzsvuU/7X IWpZGo16ADBVoNFHTt2yWLv2qNK7dA1+NsuVq2HeekIysu/KiT4lYq/d7LfC4CB1 jkL92JDGZ3Vc01us39SPKXK4mRWGbmjEo2eSXq4e+sxvF60dIKw8SS1AXrRK3o1W SSD1nUPwWCiYJBA5wawrMLaxjjcXIT3TK/yGW7mBJwtVbIMdQ8B/tk4xXBG3V4+Z W1WC++3NjrzRHOFwivf+ =u4Kw -----END PGP SIGNATURE----- --5ETKRdpE5EDsKdPFgCmFah0htQ08CXRa1-- From nobody Wed Dec 2 08:59:52 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 A48E21B2C65; Wed, 2 Dec 2015 08:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 d8ZlokIHA6ex; Wed, 2 Dec 2015 08:59:41 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 D76231B2C56; Wed, 2 Dec 2015 08:59:40 -0800 (PST) Received: from iller (c-c5b7e355.014-1001-73746f1.cust.bredbandsbolaget.se [85.227.183.197]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tB2GxajT003484 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 2 Dec 2015 17:59:37 +0100 Message-ID: <1449075573.7123.27.camel@josefsson.org> From: Simon Josefsson To: "Derek J. Balling" Date: Wed, 02 Dec 2015 17:59:33 +0100 In-Reply-To: <565F1D1F.6080307@megacity.org> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <565EBD82.2030600@pscs.co.uk> <1449065151122-b9505bf5-be5f0e83-f9cdd79b@fugue.com> <565EFD93.2060507@pscs.co.uk> <1449070095816-c64690a8-829c0c47-fd944ab9@fugue.com> <565F162F.7010109@dcrocker.net> <565F1D1F.6080307@megacity.org> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-pcDIt7HcwaIrmbUop140" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean 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: Wed, 02 Dec 2015 16:59:42 -0000 --=-pcDIt7HcwaIrmbUop140 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I believe that spending any time on answering #2 in a quantitative way is a waste of time and will derail useful work in this area. For me to be able to geolocate Derek with sufficient probability as being close to Kingston, NY, USA by looking at the email he sent below is sufficient motivation for me to work on this. I do appreciate and welcome help from experts on #3 so we can describe the best solution to this problem. I hope that some well-known larger domains will implement draft-josefsson-email-received-privacy-01 (or something like it that we can describe) so we can get more data to #3. However, I suspect that we will find that the majority of "use-cases" for Received data are harmful to users, and that we can support the few good use-cases (like loop detection) anyway. /Simon ons 2015-12-02 klockan 11:32 -0500 skrev Derek J. Balling: > I've been uncharacteristically (for me) quiet up 'til now, so let me -- > perhaps naively -- say what, to me, seems like a simple thing. >=20 > 1.) It's axiomatic that Received headers disclosure some level of > private data > 2.) It's a matter of debate how valuable that data is to those who would > abuse it > 3.) It's a matter of debate as to what impact redaction/removal of that > data from message headers would cause >=20 > Why isn't this as simple as chartering the WG to go off and: >=20 > 1.) Document the answers to questions 2 and 3 above, with data > 2.) If they so choose after doing #1, propose remedies or changes to the > existing methodologies consistent with the data they found above >=20 > At that point, everyone can observe the data, attempt to replicate it > (almost like a peer-review process, one would think) and then the > discussion can be about whether or not any proposal that came out of the > WG meets the larger goals of the net at-large. >=20 > It seems that it shouldn't be this hard to charter them to go off and > "crunch data" and "come up with a proposed solution consistent with that > data". >=20 > Nobody's "committed" to anything by letting folks go off and work on > this. so why is there such vociferous debate over letting them go do > that? What am I missing? (it's possible I have missed something, because > this debate is the most traffic we've seen in years on this list). >=20 > D >=20 >=20 > _______________________________________________ > Shutup mailing list > Shutup@ietf.org > https://www.ietf.org/mailman/listinfo/shutup --=-pcDIt7HcwaIrmbUop140 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJWXyN1AAoJEIYLf7sy+BGdRDAH/05f7B3eiZny2XzU8UcarJ8D HNwzDx6QNN22fHjyQ7faHjJmexWBvEjXbCMYhcRIYtA/M7QquboNiujhpZRfC5Hi xMOWzzItkC5wDmKb3C5/eRaL6hKoLvecXJAqg3BEX+xSnMv7Ocn4TrPlhAQAG50b I8e8oblf60WkIRggo28nFRbOLRYp5/4YMRTJHfzwYt7pj2KOZJfWl2RKkJTNx3hU prkTq69YTfC+iwtOs2N3cv3EKdsH84/PfMT2PCzAJz4B30lDQeew2ijQ/3DWrO48 LemQ0f2BoHNZsRIM0lf8A4iW0RG+Wk/nbVZn6BYPd1eMVqBxU6FdUhzn54rNLkY= =oYl1 -----END PGP SIGNATURE----- --=-pcDIt7HcwaIrmbUop140-- From nobody Wed Dec 2 09:24:23 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 3F9D41AC3E4; Wed, 2 Dec 2015 09:24:20 -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 U0VhDefpqtct; Wed, 2 Dec 2015 09:24:18 -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 7B1AB1AC3DE; Wed, 2 Dec 2015 09:24:18 -0800 (PST) Received: from [192.168.1.99] (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 tB2HOHDC006033 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2015 09:24:17 -0800 References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <565EBD82.2030600@pscs.co.uk> <1449065151122-b9505bf5-be5f0e83-f9cdd79b@fugue.com> <565EFD93.2060507@pscs.co.uk> <1449070095816-c64690a8-829c0c47-fd944ab9@fugue.com> <565F162F.7010109@dcrocker.net> <565F1D1F.6080307@megacity.org> <565F1FCE.9040702@cs.tcd.ie> <565F2262.9080002@dcrocker.net> <565F236A.8060609@megacity.org> To: "Derek J. Balling" From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <565F2959.2080606@dcrocker.net> Date: Wed, 2 Dec 2015 09:24:41 -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: <565F236A.8060609@megacity.org> 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]); Wed, 02 Dec 2015 09:24:18 -0800 (PST) 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 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: Wed, 02 Dec 2015 17:24:20 -0000 On 12/2/2015 8:59 AM, Derek J. Balling wrote: > On 12/2/2015 11:54 AM, Dave Crocker wrote: >> On 12/2/2015 8:43 AM, Stephen Farrell wrote: >>> >>> On 02/12/15 16:32, Derek J. Balling wrote: >>>> Why isn't this as simple as chartering the WG to go off and: >>>> >>>> 1.) Document the answers to questions 2 and 3 above, with data >>>> 2.) If they so choose after doing #1, propose remedies or changes to the >>>> existing methodologies consistent with the data they found above >>> (With no hats) That seems eminently sensible to me. I'm sure >>> the specific text to describe the questions would need a bit >>> of work, but that oughtn't be too hard. >> >> 1. That's an IRTF type of task, not an IETF type of task. >> >> 2. As sensible as the task might seem, the IETF pretty much never >> requires documentation about expected efficacy. That makes imposition >> of such a requirement, here, discriminatory. >> >> The original approach to chartering working groups was rather simpler: >> >> 1. Is there clear indication that 'the community' wants to do this, >> by virtue of there being folk who want spend time on wg development and >> they or other folk making noises about interest in implementing and >> developing it? >> >> 2. Is there a clear understanding of potential /danger/ from doing this? >> >> These days, we mostly stop at the first half of Question 1. But we have >> pretty much always left the question of 'efficacy' to the market. >> > It seems to me that #1 is covered by virtue of the request existing in > the first place. Please re-read what I wrote a bit more carefully and consider the part I said is mostly ignored, namely the second half of #1. If you still hold the view you stated, please explain how the second half has been satisfied. > I would argue that #2 will be covered in whatever work-product the WG > comes up with (just as any other RFC would have to document > negative-impacts, lack of backward compatibility, etc.). If there is no obvious problem with doing work in this space, then yeah waiting until it's done to look for specific problems makes sense. But that's not applicable for the current type of work, as dangers of the /category/ of work have already been cited. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Dec 2 09:33: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 EE3C61ACCE0 for ; Wed, 2 Dec 2015 09:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_21=0.6] 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 VIjbDHUGNTKJ for ; Wed, 2 Dec 2015 09:33:45 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78341ACC86 for ; Wed, 2 Dec 2015 09:33:43 -0800 (PST) Received: by qkas77 with SMTP id s77so19335989qka.0 for ; Wed, 02 Dec 2015 09:33:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=megacity-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=5iEa2svKZxfDdamOgTekgui8LdrcxscCuFgsGR30H7I=; b=aXJ64fLSnK4Kom3pGkY2RxE90s/v/tnwU1vi+UoPJ0q9rDbOaOQn/XkhLsjwx1rBko R0BMWZrPlleJvRsSvrwW+XqqP49gvTCxFl29WIk2udYG60Qe6iwAacOTI5QJ43QyfdTO ZIBBRz3TKkAIA71AhHZqQmLS/2qkcvxZbOXMLppbZcADle4gpRDySUiRWM8HlEiZUEGo qe6TChfW2hNyWdxrRiv8H/5TOmvDPkqoj0b/n/SCmpQtUQ3+eHePveMIeflmMOD1VLH8 Avv9wXXjIhXyi/WpgHj1ZaYTqRQXERq0FL01uIWDO0A1BP+Ij+LAk4Kgm1cjEekWFsU2 QgcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=5iEa2svKZxfDdamOgTekgui8LdrcxscCuFgsGR30H7I=; b=XfyF+iMOocF1EmanGHuuRTXYd04zaHSlUkfOTGOITku+NrRI2v0XSYklfP+0fQ/Df1 3qO+xZK7T5+XM9iGq03M9/hnmVYdgzCtp+Bv2xHGOBBFGiZLXKVxeZzSPgdrZAk8BTMu vRkVOa3yM5prytHcJK2PxKTS61c8Ou+ALD8HN8HChDs2+fYAAbmPoZ+DhdXFINWE5eRo pBM/VDDUCyIsCDOGRkOKdVFScnXrVe6uV+NzTeSv2A7uaOCl4ImWI5tv5CZk7z37p2g0 CrC+La83Z5vTP6MtGwHbTZFdDACAsBAoNcCPxpr7VdJdPsPIVWMCKeptgNITSCdGDVdN D+xQ== X-Gm-Message-State: ALoCoQnt99EH77fZQUU9iWRPAKZac+EcqqdvZlnJGUAWFEEaZ1IZ8iElXIXB/JimPgj2Q3Ilojz2 X-Received: by 10.55.72.10 with SMTP id v10mr5149879qka.14.1449077622808; Wed, 02 Dec 2015 09:33:42 -0800 (PST) Received: from Akebono.local (cpe-67-243-53-192.hvc.res.rr.com. [67.243.53.192]) by smtp.googlemail.com with ESMTPSA id q133sm1597764qhq.20.2015.12.02.09.33.40 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Dec 2015 09:33:40 -0800 (PST) To: dcrocker@bbiw.net References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <565EBD82.2030600@pscs.co.uk> <1449065151122-b9505bf5-be5f0e83-f9cdd79b@fugue.com> <565EFD93.2060507@pscs.co.uk> <1449070095816-c64690a8-829c0c47-fd944ab9@fugue.com> <565F162F.7010109@dcrocker.net> <565F1D1F.6080307@megacity.org> <565F1FCE.9040702@cs.tcd.ie> <565F2262.9080002@dcrocker.net> <565F236A.8060609@megacity.org> <565F2959.2080606@dcrocker.net> From: "Derek J. Balling" X-Enigmail-Draft-Status: N1110 Message-ID: <565F2B73.3000407@megacity.org> Date: Wed, 2 Dec 2015 12:33:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <565F2959.2080606@dcrocker.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="H3ptEENuDK3wC6BRT6BpPjIpsqBGTlKEI" 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: Wed, 02 Dec 2015 17:33:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --H3ptEENuDK3wC6BRT6BpPjIpsqBGTlKEI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/2/2015 12:24 PM, Dave Crocker wrote: >> It seems to me that #1 is covered by virtue of the request existing in= >> the first place. > Please re-read what I wrote a bit more carefully and consider the part = I > said is mostly ignored, namely the second half of #1. If you still hol= d > the view you stated, please explain how the second half has been satisf= ied. "Is there clear indication that 'the community' wants to do this". OK, how do we determine that? "by virtue of there being folk who want spend time on wg development"?=20 It seems to be case that such people exist, or we wouldn't be having this discussion. "(and) they or other folk making noises about interest in implementing and developing it" It seems like this whole discussion is that of "them and other folks" making noises about implementing and developing it. > If there is no obvious problem with doing work in this space, then > yeah waiting until it's done to look for specific problems makes > sense. But that's not applicable for the current type of work, as > dangers of the /category/ of work have already been cited. d/=20 As the proponents of the WG have noted, the "big four" webmail providers are already to some extent doing things similar to what the WG-proponents are considering, and the Internet hasn't collapsed in pain from their so doing. It seems, then, that any problems are, in fact, non-obvious, as the ones which have been raised have been shown to be (to some extent) overblown. --=20 I prefer to use encrypted mail. My public key fingerprint is FD6A 6990 F035 DE9E 3713 B4F1 661B 3AD6 D82A BBD0. You can download it at http://www.megacity.org/gpg_dballing.txt Learn how to encrypt your email with the E-Mail Self Defense Guide: https://emailselfdefense.fsf.org/en/ --H3ptEENuDK3wC6BRT6BpPjIpsqBGTlKEI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0 Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWXytzAAoJEGYbOtbYKrvQO5wP/R6Kq2r4bDWq32M+cCHOgm6K I9CWLjUSgVRC/ODJzjsYefX/wnD2g5w3Uh+LQdJTWk7a9GnewnmO9P6d18Jkkzo1 ky27K+NzZOMHy1GGu4tbZSow21GSO+k6Z15Rpr77izu4ERmS3PjxeiakJS3VIjBg aU0yVkAwHPgmXTxczafVM/lEZNqMF0xvIXxcl53Pd5S6Zo7A3aOG1dWvmMQ1B8CT kF6fn2By0uuK80Kciym4RtA0rgA07IzcYlxYy3Ps+/hu3w1eTXxutinKtLwaBIRd dmsoYoiN8XW90SxQTSQm3Quu5z2Qd6RV/JzmjYYM4NPJHcy7b+2mmLL4/Ij0k30H PTJpoe7oOgATOjoqdLM0ltWm4QJm5ZUD6wleo2MLJpU0icZ6b349W0zUfhNh7Utu B5Y5ujvx2yHaEUmktXAkK0MxKLK+Z10vrvqDl37UJjOUn/iiHWraXsfJi9aiQCYu v0B7qEFlPszz3VnIqrVpxJoehtvCTHi3aRlvtMhAmIbMxeJ/sUOuJnCi3g6MBlzq 8c3xbcZETMvNtgMvCEv+9OiyyGkxtYxVv42fyCxaLpxqCKLXNSPzMQneitHvv48A YhprrMQhXpFpFHY3wKtsEvm6PoOy+yebfsWHyv7VQjGzusUHgn4/PkPOWpCZLxLN gBE7wIXjv3oFuwxm9Vgg =0SCO -----END PGP SIGNATURE----- --H3ptEENuDK3wC6BRT6BpPjIpsqBGTlKEI-- From nobody Wed Dec 2 09:40: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 0C82D1ACD37 for ; Wed, 2 Dec 2015 09:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 5op7iRxYMYvC for ; Wed, 2 Dec 2015 09:40:28 -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 BA4AD1ACD2F for ; Wed, 2 Dec 2015 09:40:27 -0800 (PST) Received: (qmail 47164 invoked from network); 2 Dec 2015 17:40:26 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 2 Dec 2015 17:40:26 -0000 Date: 2 Dec 2015 17:40:04 -0000 Message-ID: <20151202174004.23134.qmail@ary.lan> From: "John Levine" To: ietf-smtp@ietf.org, shutup@ietf.org In-Reply-To: <1449075573.7123.27.camel@josefsson.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: simon@josefsson.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: Wed, 02 Dec 2015 17:40:33 -0000 >can describe) so we can get more data to #3. However, I suspect that we >will find that the majority of "use-cases" for Received data are harmful >to users, ... Not surprisingly, I suspect the exact opposite, that there's a long list of ways that networks and mail operators use Received data to help and protect their users, and the harm is at this point largely, maybe entirely, speculative. Over on ietf-smtp, we've heard from actual mail system operators describing the uses they make of it. The fact that you can tell approximately where someone is is not a harm unless and you can explain how that information has been used to his detriment. You can kind of tell where I am from my mail headers, but since my name and address and phone number are in the phone book, it's hard to imagine what the damage would be. Arguments along the lines of well, somebody might do this are not persuasive. Anyone might do anything. I would also be pretty surprised if any non-trivial mail provider changed their practices beyond what they do now. I presume you've seen Ned's list of how large mail providers do and do not display submission IPs. R's, John From nobody Wed Dec 2 10:02:43 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 DA7101ACDB4; Wed, 2 Dec 2015 10:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZ9z7JX_kySR; Wed, 2 Dec 2015 10:02:40 -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 C08151ACD9B; Wed, 2 Dec 2015 10:02:39 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14490793567410.06759281037375331" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <20151202174004.23134.qmail@ary.lan> References: <20151202174004.23134.qmail@ary.lan> Date: Wed, 02 Dec 2015 18:02:36 +0000 Message-Id: <1449079357057-1f8e007c-8d601e39-07ee75a7@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: Wed, 02 Dec 2015 18:02:42 -0000 ------sinikael-?=_1-14490793567410.06759281037375331 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Wednesday, Dec 2, 2015 12:40 PM John Levine wrote: > You can kind of tell where I am from my mail headers, > but since my name and address and phone number are in the phone book, > it's hard to imagine what the damage would be. The damage is that there are quite a few John Levines in the world. If = you say something that triggers someone's desire to harass you, they will = be able to use your IP address to determine that it is the John Levine who = lives in Trumansburg who offended them, and then they can just google = =22John Levine Trumansburg=22 to dox or swat you. This is =5Fprecisely=5F= the problem with revealing your IP address. It took me about ten minutes= to get your home address, and that's because I don't have any practice. = Without the IP address, I would have had no chance of figuring out = =5Fwhich=5F John Levine to target with my notional swatting or pizza = delivery. It would have taken <1 minute to find your street address except= that you did a good job of chaffing by using a P.O. Box. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14490793567410.06759281037375331 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWXzI9CRAMw8Nu0HeKywAAoGwIAMsH/kT1cx4RsbevAe2m qvZXMOHpjoxHNDyg61KKHEAwB5+6s09a6lb2nQ9/OfEu+RUC3PLN7znPaokx LN6oCRx039vMo1YXcUdyJK+sSZbkuZ36BFwEZC9g2uVY3+tPba10TK8SuVit t83zQEnEQ7YlanxObqQy13UBhzhSC4tz7EHTyPTSZHlse2vvNUnoIKqaDUDx FtDwZZR+mQlq9opZBANIlIqNvtX4bMpxUR96GzNvz5bvOaOr1WdO0SBfcITI 5tCcAwQ2Z4Rznb19ACJT/JNsxdqRbc6BbHqi+sQ9RtFuFt+hfVwawY3i34M3 vChREQREvXxpXiqM7XewR4k= =sqg+ -----END PGP SIGNATURE----- ------sinikael-?=_1-14490793567410.06759281037375331-- From nobody Wed Dec 2 10:23:53 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 EB0CB1ACDEB; Wed, 2 Dec 2015 10:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.353 X-Spam-Level: * X-Spam-Status: No, score=1.353 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553] 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 tqH20wh5wyDW; Wed, 2 Dec 2015 10:23:50 -0800 (PST) Received: from mail.highwayman.com (happyday.demon.co.uk [80.177.121.10]) (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 8A9921ACDF2; Wed, 2 Dec 2015 10:23:50 -0800 (PST) Received: from localhost ([127.0.0.1]:52892 helo=happyday.al.cl.cam.ac.uk) by mail.highwayman.com with esmtp (Exim 4.86) (envelope-from ) id 1a4C4C-0000ag-Jo; Wed, 02 Dec 2015 18:23:48 +0000 Message-ID: Date: Wed, 2 Dec 2015 18:22:18 +0000 To: ietf-smtp@ietf.org From: Richard Clayton References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <565EBD82.2030600@pscs.co.uk> <1449065151122-b9505bf5-be5f0e83-f9cdd79b@fugue.com> <565EFD93.2060507@pscs.co.uk> <1449070095816-c64690a8-829c0c47-fd944ab9@fugue.com> <565F162F.7010109@dcrocker.net> <565F1D1F.6080307@megacity.org> <565F1FCE.9040702@cs.tcd.ie> <565F2262.9080002@dcrocker.net> <565F236A.8060609@megacity.org> <565F2959.2080606@dcrocker.net> <565F2B73.3000407@megacity.org> In-Reply-To: <565F2B73.3000407@megacity.org> MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.03 M 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: Wed, 02 Dec 2015 18:23:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <565F2B73.3000407@megacity.org>, Derek J. Balling writes >"Is there clear indication that 'the community' wants to do this". OK, >how do we determine that? >"by virtue of there being folk who want spend time on wg development"? >It seems to be case that such people exist, or we wouldn't be having >this discussion. "(and) they or other folk making noises about interest >in implementing and developing it" It seems like this whole discussion >is that of "them and other folks" making noises about implementing and >developing it. I'm unclear how many implementors and developers have chimed in so far. The people whose names I have recognised have pretty much all been anti- spam experts (working or consulting for large providers). A concern would be that some of the enthusiasm for the process is people may be planning to use the existence of an RFC as a stick with which to beat into submission the implementors and the developers ("but you have to do this, the IETF said so"). Now that may be the right way to proceed, but I'm not entirely sure if the implementors and developers would entirely concur. Of course a sophisticated understanding of the different types of RFC (and the precise meaning of SHOULD) makes this a non-issue, but that understanding is thinly spread. >> If there is no obvious problem with doing work in this space, then >> yeah waiting until it's done to look for specific problems makes >> sense. But that's not applicable for the current type of work, as >> dangers of the /category/ of work have already been cited. d/ >As the proponents of the WG have noted, the "big four" webmail providers >are already to some extent doing things similar to what the >WG-proponents are considering, I'm not quite sure what is being considered, so I would disagree for that reason alone. >and the Internet hasn't collapsed in pain >from their so doing. I know many in Law Enforcement who are extremely pained that what used to be a trivial exercise in processing header field data from MAGY to assess whether an investigation will be easy is no longer practical. This has put a big delay in the way of determining how best to pursue an email related lead (or indeed to decide whether or not a case is tractable at all). That may not pain you, but I assure you it pains the victims, and no I'm not going to spend the rest of the day providing references as to the accuracy of that claim. but reading this might give some clues: Of course the triage that I describe would be in most cases satisfied by a "blob" that gave AS number and a user identifier (allowing a view to be taken regarding jurisdiction and number of incidents that would be linked). In fact a user identifier would work better than IP addresses which can vary considerably and in the case of mobile are pretty much useless as identifiers of people. But any work schedule needs to make clear if the aim is to hide identity or location or both -- there's separate trade- offs for each. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBVl822uINNVchEYfiEQKtiwCfc3a6uo22E+63YeNmHOHE62jhROUAnAl/ okbW+O+pLQIPpNYd08b6R/FD =tXBF -----END PGP SIGNATURE----- From nobody Wed Dec 2 11:18:07 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 B12F41ACEEC; Wed, 2 Dec 2015 11:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CibXCyYLNm6; Wed, 2 Dec 2015 11:18:02 -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 05B5E1ACEE0; Wed, 2 Dec 2015 11:18:00 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14490838769280.24943302781321108" From: Ted Lemon To: richard@highwayman.com In-Reply-To: References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <565EBD82.2030600@pscs.co.uk> <1449065151122-b9505bf5-be5f0e83-f9cdd79b@fugue.com> <565EFD93.2060507@pscs.co.uk> <1449070095816-c64690a8-829c0c47-fd944ab9@fugue.com> <565F162F.7010109@dcrocker.net> <565F1D1F.6080307@megacity.org> <565F1FCE.9040702@cs.tcd.ie> <565F2262.9080002@dcrocker.net> <565F236A.8060609@megacity.org> <565F2959.2080606@dcrocker.net> <565F2B73.3000407@megacity.org> Date: Wed, 02 Dec 2015 19:17:56 +0000 Message-Id: <1449083877251-a6f03969-939ef4b3-cfd12dcd@fugue.com> MIME-Version: 1.0 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: Wed, 02 Dec 2015 19:18:03 -0000 ------sinikael-?=_1-14490838769280.24943302781321108 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Wednesday, Dec 2, 2015 1:22 PM Richard Clayton wrote: > I know many in Law Enforcement who are extremely pained that what used > to be a trivial exercise in processing header field data from MAGY to > assess whether an investigation will be easy is no longer practical. >=20 > This has put a big delay in the way of determining how best to pursue an > email related lead (or indeed to decide whether or not a case is > tractable at all). >=20 > That may not pain you, but I assure you it pains the victims, and no I'm > not going to spend the rest of the day providing references as to the > accuracy of that claim. but reading this might give some clues: >=20 > cybercrime/> Does the linked article say anything to support the point you made above=3F= It's a study about the emotional impact of fraud, which I can tell you = from personal experience, without reading the study, is pretty overwhelming= , for many of the reasons cited in the study. This is why I don't want 419 scammers to be able to scrape identifying info= about my elderly relatives off of their email. As for the cops to whom you refer, who aren't mentioned in the article you = mentioned, they would probably benefit from reading the RFC we've been = talking about writing, since I suspect some of the information they need = would be captured in it. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14490838769280.24943302781321108 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWX0PlCRAMw8Nu0HeKywAAXOQH/3gYgvHRb/Q5w2xnZ01a wEtkEMB8SUFG/fvE6zuranJK2yXAOmltiD4p1rSC07Ck2Zzs0RcfGVdec1vv kFloQd6gSrhVaKlcN5p+EiwPZNJdl+/2qphH9Bj9UXNLp556FEAY6Wyh+mOl CRpVdmfk+JL0AeK/VDEPynpsbA3W7fjlqy6DXYFoc06A311DnilNM38/BPfF qJheM2E2Hlwmvzv43GTeZoHAXRLcPAR2qrANNK0hGFvAwn/pdnypfGLADM9m ArSOVGhA9W5qzbgJ0AJy0VZWIBpW61hEuWXJ6Scp4FB29+3BzBRhxeuWbUE9 pld7IJvJA1MqArgXUIcZU4U= =fhkq -----END PGP SIGNATURE----- ------sinikael-?=_1-14490838769280.24943302781321108-- From nobody Wed Dec 2 11:50:13 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 F33AE1B29D9 for ; Wed, 2 Dec 2015 11:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 9naV_camVg2X for ; Wed, 2 Dec 2015 11:50:11 -0800 (PST) Received: from xsmtp03.mail2web.com (xsmtp03.mail2web.com [168.144.250.223]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC6F1AD09A for ; Wed, 2 Dec 2015 11:50:11 -0800 (PST) Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1a4CLD-0000GC-ST for shutup@ietf.org; Wed, 02 Dec 2015 13:41:24 -0500 Received: (qmail 14203 invoked from network); 2 Dec 2015 18:41:22 -0000 Received: from unknown (HELO huitema2) (Authenticated-user:_huitema@huitema.net@[131.107.147.15]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 2 Dec 2015 18:41:22 -0000 From: "Christian Huitema" To: "'Richard Clayton'" , References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <565EBD82.2030600@pscs.co.uk> <1449065151122-b9505bf5-be5f0e83-f9cdd79b@fugue.com> <565EFD93.2060507@pscs.co.uk> <1449070095816-c64690a8-829c0c47-fd944ab9@fugue.com> <565F162F.7010109@dcrocker.net> <565F1D1F.6080307@megacity.org> <565F1FCE.9040702@cs.tcd.ie> <565F2262.9080002@dcrocker.net> <565F236A.8060609@megacity.org> <565F2959.2080606@dcrocker.net> <565F2B73.3000407@megacity.org> In-Reply-To: Date: Wed, 2 Dec 2015 10:41:32 -0800 Message-ID: <09ca01d12d31$112219f0$33664dd0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHQTY9q0QzQziT/XW3kp2qSufFoDwEVmeDFAXxnC/ECirALKAG7utnTAfV0aTAA4KkRkwLmJ7o7ActuDx0B/BxLTwJ6zHcrAWqRrr8DNG/DZgKgBlmIAVdv0SMCOeWnoQG/BdmKnb6R/9A= Content-Language: en-us 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: Wed, 02 Dec 2015 19:50:12 -0000 > A concern would be that some of the enthusiasm for the process is people > may be planning to use the existence of an RFC as a stick with which to beat > into submission the implementors and the developers ("but you have to do > this, the IETF said so"). Now that may be the right way to proceed, but I'm > not entirely sure if the implementors and developers would entirely concur. What makes you think that the pressure is not happening right now? Why do you think that so many of the big-name e-mail providers are already redacting some of the "Received" information? Do you really believe that the pressure would stop if the IETF just remained silent? The WG process will ensure that the IETF provides careful and balanced guidance, and hopefully uniform implementations. The absence of IETF process will only ensure that the pressure and implementations will happen without IETF guidance. -- Christian Huitema From nobody Wed Dec 2 16:21:44 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 9576B1B2EDE; Wed, 2 Dec 2015 16:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.343 X-Spam-Level: X-Spam-Status: No, score=0.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVy54Lxloe9q; Wed, 2 Dec 2015 16:21:39 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EACBD1B2EE5; Wed, 2 Dec 2015 16:21:38 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB30LZxJ027608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 2 Dec 2015 19:21:36 -0500 References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <565EBD82.2030600@pscs.co.uk> <1449065151122-b9505bf5-be5f0e83-f9cdd79b@fugue.com> <565EFD93.2060507@pscs.co.uk> <1449070095816-c64690a8-829c0c47-fd944ab9@fugue.com> <565F162F.7010109@dcrocker.net> <565F1D1F.6080307@megacity.org> <565F1FCE.9040702@cs.tcd.ie> <565F2262.9080002@dcrocker.net> <565F236A.8060609@megacity.org> <565F2959.2080606@dcrocker.net> <565F2B73.3000407@megacity.org> <1449083877251-a6f03969-939ef4b3-cfd12dcd@fugue.com> To: shutup@ietf.org From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <565F8B0F.6080006@mustelids.ca> Date: Wed, 2 Dec 2015 19:21:35 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <1449083877251-a6f03969-939ef4b3-cfd12dcd@fugue.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 03 Dec 2015 00:21:40 -0000 On 12/02/2015 02:17 PM, Ted Lemon wrote: > Wednesday, Dec 2, 2015 1:22 PM Richard Clayton wrote: >> > cybercrime/> > Does the linked article say anything to support the point you made above? It's a study about the emotional impact of fraud, which I can tell you from personal experience, without reading the study, is pretty overwhelming, for many of the reasons cited in the study. The linked article does support why it's so important to prevent things like this happening, and why people like Richard (and myself and many others here) use items of information like we're talking about here to do just that. Prevent it where we can, stop it getting through when we can, and help LE catch the guys doing it. This is (part of) what many of us do for a living. > This is why I don't want 419 scammers to be able to scrape identifying info about my elderly relatives off of their email. Do you have any evidence that 419 scammers have any email from your elderly relatives that's amenable to scrape such info off of, let alone, have any use for such identifying information? All they need is an email address and a trickable recipient. Your elderly relatives have probably already put their street address, phone numbers, and photos of their pets (complete with geolocation in the JPGs) into the emails. The perceived threat presented by archived mailing lists isn't so much about received lines (archives often don't contain much header detail anyway), but the addresses themselves. That is what is of interest to 419 scammers (and the spammer that spammed me less than 3 hours after creating this address for the sole purpose of this discussion!). Shouldn't this RFC be about obfuscating email addresses in mailing list archives? It'd have more effect on 419 scammers. > As for the cops to whom you refer, who aren't mentioned in the article you mentioned, they would probably benefit from reading the RFC we've been talking about writing, since I suspect some of the information they need would be captured in it. Here's the draft in question: [This is brief draft critique, which you can ignore, except for the fact that it indicates why a WG is necessary] https://tools.ietf.org/html/draft-josefsson-email-received-privacy-01 The only operative content is: The purpose of this document is to propose a mechanism that implementers and operators of SMTP agents may adopt to mitigate the privacy violation. Note the "may adopt" - sounds optional right? and then: The "from clause" of the Received header MUST NOT be added by SMTP entities concerned with the privacy of their clients. 1) Is there anybody out there dumb enough to assert that they're NOT concerned with the privacy of their customers? This is therefore tantamount to an absolute requirement, not an option, and could be treated as such and potentially enforced through the courts, as well as by providers using this as an easy-out to do nothing whatsoever when abuse is reported to them. 2) I don't see anything in there that would mitigate the loss of this information in either the descriptive text nor the example given - since the from clause is simply omitted rather than, for example, translated into a interpretable-only-by-the-provider identifier blob. 3) It entirely begs the question of when the information of potential privacy concern isn't in a "from" clause. Such as providers who issue X-Originating-IP headers, "authenticated as x on y" clauses in Received or other headers, and perhaps even details of personal crypto key identifiers. Protocol specifications are intended to be taken literally, a protocol specification that doesn't effectively do what you want is useless. 4) The security section has nothing about the downsides of removing this information or even hint at less-privacy invasive alternatives. How much of this is really a social issue that has to be addressed with societal action compared to a technical bandaid that only helps in rare circumstances? If you're concerned about, say, governmental surveillance, I'm thinking that fixing your government is better than (only occasionally) hiding just this teensy bit of information from them. From nobody Wed Dec 2 19:58:36 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 32FB71A0126; Wed, 2 Dec 2015 19:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.043 X-Spam-Level: *** X-Spam-Status: No, score=3.043 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-eDj4wU67s9; Wed, 2 Dec 2015 19:58:34 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 402441B2EF7; Wed, 2 Dec 2015 19:58:33 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB33wUMo029190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 2 Dec 2015 22:58:30 -0500 To: shutup@ietf.org References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <57B818513A0069189BA3CF41@JcK-HP8200.jck.com> <1449014394167-7d2dec58-2c6a9ae8-33fc8e7a@fugue.com> <565E4CCF.3080901@mustelids.ca> <565E4FEC.2000607@cs.tcd.ie> From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <565FBDE6.8020001@mustelids.ca> Date: Wed, 2 Dec 2015 22:58:30 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <565E4FEC.2000607@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: Thu, 03 Dec 2015 03:58:35 -0000 On 12/01/2015 08:57 PM, Stephen Farrell wrote: > > > On 02/12/15 01:43, Chris Lewis wrote: >> >> It's far better to train them in the reality of what they need to do to >> preserve their own privacy, than the impossibility of trying to >> privacy-protect everything (and still have something anybody wants to use). > > Do you have any evidence for the above? > But in any case, I think your argument is clearly wrong because we > know that it is not possible to "train them" in security or privacy. > (That leaves open the possibility that your conclusion is correct > based on some other argument, but very much weakens confidence in > your conclusion for me.) You will find no person more in agreement that we cannot train 100% of people with PSAs and similar (the fact that 419s still flow is certainly proof of that), but the reality is that most people do learn such things one way or another. You have and I have, otherwise, we'd not be having this discussion. Did you get your knowledge from a PSA? Your parents? School? The media? Nope. But you still got it. Trying to "measure" the result of training is usually futile, because correctly posing the questions, and getting useful answers is equally complicated and fraught with definitional/terminology problems. I groan whenever these surveys are published, because the questions are badly crafted, the answers irrelevant, the interpretation is completely out to lunch, and the media scrambles it unrecognizeably. And indeed, does the fact that 1% of people are still liable to fall for a 419 mean that the training, education, PSAs, news media coverage of such things etc was all in vain? No. is it effective? Somewhat. Perfect? No. The subject is mushy. People are mushy. Measuring things that are mushy in 2+ dimensions is worse. But most of us have managed to survive vastly more dangerous circumstances by learning how to avoid them along the way. It's slow, but it happens. Just type in "how to use email anonymously" into your search engine, and voila! > IMO the onus is on us as technology developers to ensure that what > we make allows those who deploy that to do a good enough job. Is hiding from clauses sufficient to do that? No, not when the people who use email don't understand that what they put in the bodies of the emails is usually FAR more revealing than a temporary IP address in an Internet cafe does, or the fact that my MTA's IP address indicates, at best, I'm "somewhere in south, maybe eastern ontario". Nothing you can do with from clauses will affect the bad guys looking at you. Only the people already conscious/understanding of personal safety/privacy are going understand and make the choices that they need to make to preserve their privacy. A mere from clause is not going to it, and claiming that eliding from clauses does anything significant to preserve privacy is in the end a dangerous lie even just in an email context. > In > this case there is room for debate about the cumulative privacy > exposure from many messages including MUA IP addresses (or of > popular implementations defaulting to do so) vs. the benefits > accruing to anti-spam techniques. Please don't minimize it as just being "anti-spam". I say I'm "anti-spam", but what that really means is anti-spam, anti-fraud, anti-malware. The latter two have serious real-world consequences. LE uses this to try to find people contemplating suicide, or equally, people making death/bomb threats or engaging in harassment. ISPs use this to identify and inform customers that are infected with malware. I (and several others here) could "document" some of what I've seen/been involved with where this matters, but that would in many cases (a) violate NDAs, (b) give the bad guys intel on how to avoid us, (c) probably violate privacy, and (d) since it's just me and not a vetted journal or something equally "reputable", some here will ignore it anyway as hearsay or self-serving BS. [Which is ironic, because my work almost never involves MSA submission addresses, and it's not parsed let alone recorded. I don't really have a horse in this race.] This is real life too: user's savings and lives depend on some of this, not just a few annoying spam messages. Yes, it would be nice for LE to say something, but the approvals required to say _anything_ whatsoever in public take a very long time, it'd probably get dismissed as self-serving hearsay, and as I've seen often, some people get all wobbly when LE is around. It would also be nice for providers to say something, but the legal constraints of "speaking on behalf of/in public" are even worse. When I did that once for a topic near to this, it took four months to get approvals and I had to go through a media relations course (until I pointed out that they didn't have to worry about be bleating out company future plans/finances because, unlike the senior executives normally taking the course, I couldn't possibly know any of that to leak). From nobody Thu Dec 3 06:28:41 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 0E5841A87A3; Thu, 3 Dec 2015 06:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLB4Rdkgt059; Thu, 3 Dec 2015 06:28:36 -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 D07111A88DE; Thu, 3 Dec 2015 06:28:34 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14491529107950.29890814144164324" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <20151203113749.GA15410@gsp.org> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <57B818513A0069189BA3CF41@JcK-HP8200.jck.com> <1449014394167-7d2dec58-2c6a9ae8-33fc8e7a@fugue.com> <565E4CCF.3080901@mustelids.ca> <565E4FEC.2000607@cs.tcd.ie> <565FBDE6.8020001@mustelids.ca> <20151203113749.GA15410@gsp.org> Date: Thu, 03 Dec 2015 14:28:30 +0000 Message-Id: <1449152911110-fa63a5d7-c60b1849-5f9c637e@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: Thu, 03 Dec 2015 14:28:38 -0000 ------sinikael-?=_1-14491529107950.29890814144164324 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thursday, Dec 3, 2015 6:37 AM Rich Kulawiec wrote: > This is an excellent point which bears repeating. No point bears repeating, particularly an assertion that solution X works = for problems Y and Z without giving specifics. Repeating the same = assertion over and over again does not make it more true, and it is not the= case that the other readers of this mailing list did not understand it = when you said it the first time. That said, as Dave Crocker pointed out, the actual topic of this thread is = supposed to be whether we want to have a working group that does an = analysis of this problem. It seems that you care quite a bit about this, = and given the current industry trend toward more header privacy, it seems = to me that you would want to be able to take some time to do the work to = provide data to back up the assertion that you are saying is so important. = So can we take your assertion as support for forming such a working group= , and a willingness to participate in it=3F -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14491529107950.29890814144164324 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWYFGPCRAMw8Nu0HeKywAAifcH/jXGE7nawoK4D358C7Ma P67vTh6s8FR3ESci8+vggzmWMK9Z+iYoxnFTxIPrl+z7I4WEqz2EYFXYOlMW JdZC4KtaCdhG2s2E1/ZLdXFApmTuku7xdbmGeHjQhWLTtCbP5/B2CarFX2FR XQe6aH2/XWGdd6a6aFudcV63RB0UGB7BAxwEka/wbWB/9ufwkNeEOF5JikD/ pHL0nczzZhE053RZgLnYt+ytJJfk5d9in/eNVqogil/2f5ohyNiIPufsBcwH ApmgcMC1DPmhFmzu9ji+ZctY0j2CpYzOSaB9t29R05yfd/TvlOP7oNIFQ1rH ITzqLLhvlmHSsm2/2d5flRM= =q2Nl -----END PGP SIGNATURE----- ------sinikael-?=_1-14491529107950.29890814144164324-- From nobody Thu Dec 3 06:44:01 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 46EA51A894A; Thu, 3 Dec 2015 06:43:59 -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 i4OaOKmJLS4C; Thu, 3 Dec 2015 06:43:58 -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 EA51B1A8952; Thu, 3 Dec 2015 06:43:57 -0800 (PST) Received: from [192.168.1.99] (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 tB3EhvB6005720 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 3 Dec 2015 06:43:57 -0800 References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <57B818513A0069189BA3CF41@JcK-HP8200.jck.com> <1449014394167-7d2dec58-2c6a9ae8-33fc8e7a@fugue.com> <565E4CCF.3080901@mustelids.ca> <565E4FEC.2000607@cs.tcd.ie> <565FBDE6.8020001@mustelids.ca> To: Chris Lewis From: Dave Crocker X-Enigmail-Draft-Status: N1110 Organization: Brandenburg InternetWorking Message-ID: <56605545.3010207@dcrocker.net> Date: Thu, 3 Dec 2015 06:44:21 -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: <565FBDE6.8020001@mustelids.ca> 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]); Thu, 03 Dec 2015 06:43:57 -0800 (PST) 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 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: Thu, 03 Dec 2015 14:43:59 -0000 On 12/2/2015 7:58 PM, Chris Lewis wrote: > You will find no person more in agreement that we cannot train 100% of > people with PSAs and similar (the fact that 419s still flow is certainly > proof of that), but the reality is that most people do learn such things > one way or another. "Most people" do not. Not even close to most people and very nearly never any people consistently, since the ability of humans to perform real-time and nuanced monitoring reliably like this, reliably and over time, borders on no ability at all. Feel free to provide documentation to the contrary. The issue isn't whether people generally understand the general issue. It's whether they can develop very specific understandings and apply them in real time, to useful effect over extended time. > Trying to "measure" the result of training is usually futile, because > correctly posing the questions, and getting useful answers is equally > complicated and fraught with definitional/terminology problems. Right. That should alert us all to the challenges of the training itself. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Dec 3 06:53:43 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 F0EE81A89A0; Thu, 3 Dec 2015 06:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5fao-bt_ydS; Thu, 3 Dec 2015 06:53:39 -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 D67571A899C; Thu, 3 Dec 2015 06:53:38 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14491544162070.8844442260451615" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <56600AC7.4060208@pscs.co.uk> References: <20151202174004.23134.qmail@ary.lan> <1449079357057-1f8e007c-8d601e39-07ee75a7@fugue.com> <56600AC7.4060208@pscs.co.uk> Date: Thu, 03 Dec 2015 14:53:36 +0000 Message-Id: <1449154416521-a0b6c7e1-efd00f6a-1796633b@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: Thu, 03 Dec 2015 14:53:41 -0000 ------sinikael-?=_1-14491544162070.8844442260451615 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thursday, Dec 3, 2015 4:26 AM Paul Smith wrote: > Try finding which town *I* live in without using my email address... :-) Wow, you've got some =5Fepic=5F chaffing going on! First, Melbourne, UK, = not Melbourne, Oz. And then apparently =22Paul Smith=22 is a retailer of = some sort, in both countries, and there's a Derbyshire council member named= Paul Smith, etc. I will admit that I am stumped, but this is a bit of a perfect storm. = Having a last name of Smith and a common first name is certainly a great = way to avoid being targeted, although it's also been known to get people in= trouble. There is a Paul Smith who got in a bit of a jam for growing pot= in his garage who lives fairly close to you. (Or perhaps =5Fis=5F you! = :) -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14491544162070.8844442260451615 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWYFdwCRAMw8Nu0HeKywAApfcIAImTSCSiD8gkvzrejiLo 47eZsH/xqB2bisYurTuGvrTLEEXcVpYpTM5HFKjb1yIxQ4B9mBylodJC/Xkx jd+fUvrJmBifQHREdDpmtWlsAUcoFCR2iH9yc3xQEPzoDda3ZwUs6X2dPxgZ osU/gsO8L9jP40KSYK2dCo+p43EvmAET2/4fAb3i5I+HpWyNVZ5AUuFj7ut4 Q3p7NlUf8K1HSI8Xzpa+aGtHZWQGMrPqmrrQWJWYfYrvi7VZDguBpX4ygWJB hf1JoVEKhX9y47t2lB4v0PxbpA8kbZqxFnKOVBRRmD4Lxw/RJYB8jKYClW9H r6kwrkzyL875tkzl6oAAqZI= =7e9J -----END PGP SIGNATURE----- ------sinikael-?=_1-14491544162070.8844442260451615-- From nobody Thu Dec 3 08:15:03 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 94F9D1ACECF; Tue, 1 Dec 2015 09:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFtaqCPHhFQM; Tue, 1 Dec 2015 09:11:24 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 588D61ACECD; Tue, 1 Dec 2015 09:11:24 -0800 (PST) Received: from satsuke.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 11CF08052D; Tue, 1 Dec 2015 09:11:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1448989884; bh=fKjpGrkT5CJKc2s+lSOc0dyWx8V7BXFIGz5x3mF+1zQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=elHKmFD2FJ+nBq7xhpp+Xu+3PFSsz+7LFcYoh1wE4MFDWz7BCBFTDumBCCI84Exyx 3CQbxCmpmv/H/LgpFhOCbsAzPn13+s69o9zT3/C5QCzDffD1NkCmSF8I6tbAj7q1KQ EsVL691/UIZ98zcVSIcPhdkuiCKYlGhiFwWc967g= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Steve Atkins In-Reply-To: <1448988892426-3d90e6a3-1691ce74-693e6fae@fugue.com> Date: Tue, 1 Dec 2015 09:11:23 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <1448923888960-cb7e590f-f443f8dd-7ec594e1@fugue.com> <565CD58D.9080403@dcrocker.net> <1448924778159-4b16d8e4-631c41b1-52b0fbf2@fugue.com> <605ee74e-863d-47cb-9089-fb83e13e4e38@gulbrandsen.priv.no> <1448988892426-3d90e6a3-1691ce74-693e6fae@fugue.com> To: ietf-smtp@ietf.org X-Mailer: Apple Mail (2.3096.5) Archived-At: X-Mailman-Approved-At: Thu, 03 Dec 2015 08:14:58 -0800 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: Tue, 01 Dec 2015 17:11:25 -0000 > On Dec 1, 2015, at 8:54 AM, Ted Lemon wrote: >=20 > Tuesday, Dec 1, 2015 7:27 AM Arnt Gulbrandsen wrote: >>> Sure, but in this case wouldn't deferring to the end systems> argue = in favor of allowing end systems to make the decision as> to whether = their private information should be exposed? >>=20 >> As I see it, that's not the question here. The question is: Should = there be an RFC that can be used/misused to apply pressure regarding = trace fields etc? >=20 > Yes, I agree that this is what we are discussing. I think it's = pretty clear that for Received header fields that refer to the IP = address of the end-user, the answer is "yes, there should be such an = RFC." I haven't heard anyone seriously propose that this is not true, = although I'd be interested to hear such an argument! Well, I'll be the first, then. When people routinely hide their identities - to the extent that a = recipient cannot tell that two emails were sent by the same person - = that eliminates many social and technical pressures on bad behaviour. = But it *also* removes the ability for people to help them when their = endpoints have been compromised. The biggest email-related risk to peoples privacy is malware that = compromises their computers (followed by phishing, that compromises = their online accounts). If someone is sending mail through a smarthost provider that a) hides = the source of mail sent through them and b) has an abuse/security team = that is anything less than top-tier then there is no way to identify = that mail originated with them. When their machine is compromised, it = can then send out malware and phishing itself, compromising others. And = there's no way to contact the people responsible for the security of = that machine - whether it be the end-user themself, the end-users = employers IT department or the end-users residential ISP. The infection = spreads faster, more people's privacy is violated. *Routinely* removing end-user identifiers harms privacy. Cheers, Steve From nobody Thu Dec 3 08:15:05 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 AB9CE1B2E32; Tue, 1 Dec 2015 09:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.343 X-Spam-Level: X-Spam-Status: No, score=0.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4nFBANcH5SZ; Tue, 1 Dec 2015 09:58:16 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE6A31B2E31; Tue, 1 Dec 2015 09:58:15 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB1HwDI5021498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 1 Dec 2015 12:58:14 -0500 To: John Levine , ietf-smtp@ietf.org, shutup@ietf.org References: <20151201174025.18409.qmail@ary.lan> From: Chris Lewis Message-ID: <565DDFB5.7030909@mustelids.ca> Date: Tue, 1 Dec 2015 12:58:13 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <20151201174025.18409.qmail@ary.lan> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Thu, 03 Dec 2015 08:14:58 -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: Tue, 01 Dec 2015 17:58:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/01/2015 12:40 PM, John Levine wrote: | Until we look at the actual costs and benefits, it's grossly | premature to propose any changes. Yes, I think that would be very valuable. Educational at least. I'm in support of a WG for that purpose. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJWXd+1AAoJENy2YTBCU1mlD0MH/0FR0Pp7/Bk7Ef0nHEVVElJq Mv9qAnJTpAl8+yJpoFK+23UQ01bYb76AVI+btByvIhRHGoRZqDaq4icBrx+ttlSq fNSzmj9mn9mvpYRMScOtH+j2ijFhgEUDiqOA8+0C3PDGSsAELcFstNEMVIjCPqi2 7ov0h0k1L/Yqb0wR9Nfax3PmMGqSuGSl+WC90eI5Dw1vj26A6/WjnqvHFtY+kBQG 0XIwz2vJV/KzhF77lVuTLuR6FIpZ7ReHAGr7tRQh2Tuy49kT0mbey57M2MYfHTFc E+7vx326PmSydnIcW8eN+I+HMsKP4OaHqLgmTv94hR1Qaj+epynvfIj3J+ChapE= =x3hI -----END PGP SIGNATURE----- From nobody Thu Dec 3 08:15: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 E8D051B29D5; Tue, 1 Dec 2015 15:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.343 X-Spam-Level: X-Spam-Status: No, score=0.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-yCEFa3_--9; Tue, 1 Dec 2015 15:17:20 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AA5D1B29DB; Tue, 1 Dec 2015 15:17:20 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB1NHIUC022577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 1 Dec 2015 18:17:18 -0500 To: shutup@ietf.org References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <1448923888960-cb7e590f-f443f8dd-7ec594e1@fugue.com> <565CD58D.9080403@dcrocker.net> <1448924778159-4b16d8e4-631c41b1-52b0fbf2@fugue.com> <605ee74e-863d-47cb-9089-fb83e13e4e38@gulbrandsen.priv.no> <565D9CFC.6070102@pscs.co.uk> <1448988713596-9f0a5014-48bb3a2c-8e1bc938@fugue.com> <565DE53F.2080904@mustelids.ca> <565E2461.6000608@cs.tcd.ie> From: Chris Lewis Message-ID: <565E2A7E.1060208@mustelids.ca> Date: Tue, 1 Dec 2015 18:17:18 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <565E2461.6000608@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Thu, 03 Dec 2015 08:14:58 -0800 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: Tue, 01 Dec 2015 23:17:21 -0000 On 12/01/2015 05:51 PM, Stephen Farrell wrote: > > > On 01/12/15 18:21, Chris Lewis wrote: > For example one could imagine replacing the MUA IP address value in > a Received header field with something like E(k-epoch, > MUA-IP-address) where k-epoch is some key that changes now and > then, perhaps in a way that requires very little state in the MSA. If you read on a little further, you'll note where I mentioned (and Martin reiterated) "one-way encrypted blob". Which I proposed to, for example, senior MTA people at gmail almost a decade ago. From nobody Thu Dec 3 08:15:07 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 D2E4B1B2ACC for ; Tue, 1 Dec 2015 15:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 s99BUcW84sBo for ; Tue, 1 Dec 2015 15:52:42 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A232B1B29C7 for ; Tue, 1 Dec 2015 15:52:42 -0800 (PST) Received: by igvg19 with SMTP id g19so106493154igv.1 for ; Tue, 01 Dec 2015 15:52:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spamresource.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=HaE2B1cCWuYgjgbYOhB/zzts5CmAU+amrMsbm7TkQ9g=; b=a7MLZ6F5L2Khtcd53HSeLc/5vhpLeL/h03m7mBA/Qm7zaq0JENAnlrkK3rcsNfxKQP A5bo92xW4Avp6g3JkkZ1/r55lQ4Sot4DwR2yIi0AtQ3Io/2ikGE1iqSFiWjtaLqEFJ7m L1DgMfKsNzs0HZZUHSnWmmy6t7EPoKZ2IaqcM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=HaE2B1cCWuYgjgbYOhB/zzts5CmAU+amrMsbm7TkQ9g=; b=Aj9wfddSo+4hmH5t9k0UMOsQz+zTHSUudOpd95LJbruyRqOGTByfz701iVmw1Tufa9 9xRZ0UNxerw9ZjnnOkr9/Eno8IxFowoAuFBj4AVxi830LOc9N3U1ohGCQbeT6hqvCj8Z Y7nJkGmhIz1rrVZQt7JOuiVRYCQ7qjUZDI7KzTwvZgPJ22rl02oBDfiUpuXTF3JpiAg7 VDu0/AzA7+4XuskXHjpyuSmulI5oNW9Cp/DH5MmkF76/KPGjZsx1jDc/5sXmC+Y8K5Bv YmLI1gna7KSKGmIu4L4xsKCI8Smxo/E/+6phQJTA1DMtg/x6FXSeZUPM1sX+UoEmpqmD PD/w== X-Gm-Message-State: ALoCoQklMLWuW3IprJa6tTYrZt6DoDXtSdH42Zuy66/STOfxitj8PKEdGeRxWLzjPVfUpX5MTSFa MIME-Version: 1.0 X-Received: by 10.50.43.199 with SMTP id y7mr24705249igl.47.1449013962069; Tue, 01 Dec 2015 15:52:42 -0800 (PST) Received: by 10.36.184.68 with HTTP; Tue, 1 Dec 2015 15:52:41 -0800 (PST) In-Reply-To: <1449013554783-b461d703-192d4623-50f6eda5@fugue.com> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <1449005349724-ffd73ebb-f70e368e-426663a1@fugue.com> <565E2926.1050900@mustelids.ca> <1449013554783-b461d703-192d4623-50f6eda5@fugue.com> Date: Tue, 1 Dec 2015 17:52:41 -0600 Message-ID: From: Al Iverson To: shutup@ietf.org, ietf-smtp@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Thu, 03 Dec 2015 08:14:58 -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: Tue, 01 Dec 2015 23:52:44 -0000 On Tue, Dec 1, 2015 at 5:45 PM, Ted Lemon wrote: > Tuesday, Dec 1, 2015 6:11 PM Chris Lewis wrote: >> When your cat's litter box gets infected with, say, cutwail, spewing gaz= illions of copies of randomized "come do X to my Y!" exhortations, you're n= ot giving the receiver (ML or ad-hoc) very much to distinguish between that= and your pearls of wisdom. > > Er, no, the cat box doesn't have my credentials nor know my email address= , so it can't send spam from me. If it sends spam from someone other than= me, the Received header field makes my /legitimate/ email look more like s= pam, because both the cat's spam and my legitimate email have the same IP a= ddress in the Received header field. Is that a hobbyist configuration? Is it relevant? It sounds a bit like a cat and the hat both sharing a NAT. But in a very common high volume production email scenario used by email service providers, clients and types of mail are segregated by sending IP address. > In this case I /definitely/ don't want the Received header field. Noted that you don't. Just adding my voice: I do want it. Regards, Al Iverson -- Al Iverson - Minneapolis - (312) 275-0130 Simple DNS Tools since 2008: xnnd.com www.spamresource.com & aliverson.com From nobody Thu Dec 3 08:15: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 496AC1B2E17 for ; Tue, 1 Dec 2015 09:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 wi_8CLcx7_Ac for ; Tue, 1 Dec 2015 09:53:05 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A31151B2E11 for ; Tue, 1 Dec 2015 09:52:57 -0800 (PST) Received: by qkda6 with SMTP id a6so5764076qkd.3 for ; Tue, 01 Dec 2015 09:52:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oo686d1+I6VCQVRBqK8SHK5LmaA+tBzy7FCVNUhM668=; b=FeR+dD3FYLVRVcA4DQHuyxyaXZDDBCEv/Bk78fhd+lJjSbEMyV3+y4rtH6e8vHCi13 flLluWTHuua6u2bfKlDdgonhemCvLleNnap7/Ach6Qvuw2SMvUL2deCmfUM5TqD3vaTC rGwoQU9/EMZpTLfo6NfGA9wtGuZMEix7Pj2JY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oo686d1+I6VCQVRBqK8SHK5LmaA+tBzy7FCVNUhM668=; b=BgAC5PWY3Dq4A5DJpKz/n5VaOn41l3iZp33/3AANwqdf+ooToo6sggb85APCT/PlKq 7uR3yg7SlNRKvnbb23egtlMkX6yDKYU0JbWnGszqtY8OsiMie+ShQXf6ynKzj3cH00tg JA3ghtiI/CBrSKtN0Ery75Yz/HJDNDy5GODeCGi+MYRV46yy0KORssXCQpm+YLcP5pJp iBnCUw/X5Xuq8T8pPf2PWLQiJ4q2OWju7B8RwY8FI8fwnIZfsMP8BX8rP2kfVK9vhr6+ p01Ig1sl2SAE3ALJXxr9x4OWYrI9jnk7DAFeqlReCXoo4LjJEtsHI5XZYxB8xrG05HDV HlEg== X-Gm-Message-State: ALoCoQmtreEy1KPDBBRWl2UpvC9TJgPm5PQ/3G4KbMwNwdxB+vjZ5jXrOHNQlnZvE7/st65lH8yI MIME-Version: 1.0 X-Received: by 10.55.82.193 with SMTP id g184mr85530496qkb.65.1448992376754; Tue, 01 Dec 2015 09:52:56 -0800 (PST) Received: by 10.55.198.219 with HTTP; Tue, 1 Dec 2015 09:52:56 -0800 (PST) In-Reply-To: <565DB532.70407@dcrocker.net> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <1448923888960-cb7e590f-f443f8dd-7ec594e1@fugue.com> <565CD58D.9080403@dcrocker.net> <1448924778159-4b16d8e4-631c41b1-52b0fbf2@fugue.com> <565DB532.70407@dcrocker.net> Date: Tue, 1 Dec 2015 09:52:56 -0800 Message-ID: From: Kurt Andersen To: Dave Crocker Content-Type: multipart/alternative; boundary=001a114a6fcce630e50525d9d393 Archived-At: X-Mailman-Approved-At: Thu, 03 Dec 2015 08:14:59 -0800 Cc: shutup@ietf.org, SMTP Discuss 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: Tue, 01 Dec 2015 17:53:06 -0000 --001a114a6fcce630e50525d9d393 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 1, 2015 at 6:56 AM, Dave Crocker wrote: > Folks seeking to discuss email at this level should consider becoming > familiar with RFC 5598. It will make careful discussion of email > behavior a lot more consistent... > And in regard to indirect mail flows, may I recommend https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ --001a114a6fcce630e50525d9d393 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 1, 2015 at 6:56 AM, Dave Crocker <dhc@dcrocker.net> w= rote:
Folks seeking to discuss email at this level should consider becoming<= br> familiar with RFC 5598.=C2=A0 It will make careful discussion of email
behavior a lot more consistent...

And in regard= to indirect mail flows, may I recommend=C2=A0https://datatracker.ietf= .org/doc/draft-ietf-dmarc-interoperability/
--001a114a6fcce630e50525d9d393-- From nobody Thu Dec 3 08:15:10 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 E30121B2F67; Tue, 1 Dec 2015 11:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBuXC4a5TJWc; Tue, 1 Dec 2015 11:43:14 -0800 (PST) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 713741ACD05; Tue, 1 Dec 2015 11:43:14 -0800 (PST) Received: from [192.168.2.103] (adsl-070-145-114-055.sip.pns.bellsouth.net [70.145.114.55]) by mailbackend.panix.com (Postfix) with ESMTPA id 2C7A016DAA; Tue, 1 Dec 2015 14:43:11 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <1448992684773-4c6d4a39-ded58e7b-128cca51@fugue.com> References: <20151201174025.18409.qmail@ary.lan> <1448992684773-4c6d4a39-ded58e7b-128cca51@fugue.com> X-Mailer: Eudora for Mac OS X 6.2.4 (MacOS 10.5.8) Date: Tue, 1 Dec 2015 13:36:04 -0600 To: Ted Lemon From: "Robert A. Rosenberg" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Archived-At: X-Mailman-Approved-At: Thu, 03 Dec 2015 08:14:59 -0800 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: Tue, 01 Dec 2015 19:43:16 -0000 At 17:58 +0000 on 12/01/2015, Ted Lemon wrote about Re: [ietf-smtp] [Shutup] Proposed Charter for the "SMTP Hea: >The benefit is pretty obvious. If my IP address and identity >information appears in a Received: header field, then I can't send >mail to a public mailing list without revealing to the world >geolocation information that could be used for doxxing/swatting me, >or for various other nefarious activities, and I can't send email to >an individual unless I am willing to reveal that information to that >individual. And I can't send email through any server operated by >anyone to whom I do not wish to reveal that information. I remember that years ago (but no longer) there was a remailer server somewhere in Europe that handled most of this situation. You sent it your message (with routing info in the message body) and it stripped off the identification info and headers and sent it to the desired destination using a new identity. All replies (and other messages to that identity) went back to the server which then repackaged the message and sent it back to you. Of course you had to trust the remailer's operator and accept the fact that you were talking to it might be an exposure. From nobody Thu Dec 3 08:15: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 C2D0B1B2F75; Tue, 1 Dec 2015 16:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.242 X-Spam-Level: ** X-Spam-Status: No, score=2.242 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7jsYE7Emgnb; Tue, 1 Dec 2015 16:38:32 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D3A61B2F70; Tue, 1 Dec 2015 16:38:32 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB20cTjl014907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 1 Dec 2015 19:38:30 -0500 To: shutup@ietf.org References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <1449005349724-ffd73ebb-f70e368e-426663a1@fugue.com> <565E2926.1050900@mustelids.ca> <1449013554783-b461d703-192d4623-50f6eda5@fugue.com> From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <565E3D85.70209@mustelids.ca> Date: Tue, 1 Dec 2015 19:38:29 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <1449013554783-b461d703-192d4623-50f6eda5@fugue.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Thu, 03 Dec 2015 08:14:58 -0800 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: Wed, 02 Dec 2015 00:38:33 -0000 On 12/01/2015 06:45 PM, Ted Lemon wrote: > Tuesday, Dec 1, 2015 6:11 PM Chris Lewis wrote: >> When your cat's litter box gets infected with, say, cutwail, >> spewing gazillions of copies of randomized "come do X to my Y!" >> exhortations, you're not giving the receiver (ML or ad-hoc) very >> much to distinguish between that and your pearls of wisdom. > > Er, no, the cat box doesn't have my credentials nor know my email > address, so it can't send spam from me. If it sends spam from > someone other than me, the Received header field makes my > /legitimate/ email look more like spam, because both the cat's spam > and my legitimate email have the same IP address in the Received > header field. In this case I /definitely/ don't want the Received > header field. Er yes, without the MSA-enforced IP address (or unique blob indicating something similar) the filter can't necessarily tell whether your legitimate email is different than the cat litter box. By omitting the MSA's received line your legitimate mail becomes _less_ distinguishable from the flying litter ... the ML has more chance of lumping both of youse into the same bucket and so your email ends up in the toilet too. Even when everything is forged/forgeable (eg: regardless of whether the MSA's headers are forged or decided to be trustworthy), the uniformity of your Received/From tuples stands out in stark contrast to the forged stuff (random or otherwise) to the ML - it gives the ML more to "grab onto". Now, with my piddly little mail server (which your steam punk mail server doesn't seem to like BTW), the ML will rarely see enough signal to do a proper analysis. But at scale, the ML often will. From nobody Thu Dec 3 08:15:13 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 A8C611B2BDF for ; Tue, 1 Dec 2015 19:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 FXAFfWNyZDmL for ; Tue, 1 Dec 2015 19:00:27 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C7A1B319A for ; Tue, 1 Dec 2015 19:00:25 -0800 (PST) Received: by ioc74 with SMTP id 74so31756274ioc.2 for ; Tue, 01 Dec 2015 19:00:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spamresource.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=bG+mT3J5XCku5Yj+YgKkFjv66uMF7f+s4m1EpL/SvYQ=; b=opdTMSv7ZZMyLVEAOEOoQqihdsEJuWrfbOH03qpSEoC9+HiT1IzFf6ErZUGyC9YQ5I F1zHEpVCE1zt6TWb4/wpd1UAp/VoDLM6n4UtSSKVgLJ0t+cZo3XkEgCmthLYmIddE5M9 MggQNRf2Xtzsg4oUrDDuk6iVYWCDYiOzZ5wiQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=bG+mT3J5XCku5Yj+YgKkFjv66uMF7f+s4m1EpL/SvYQ=; b=VOHyJXxDXAUTy5cLCppDdsXW8Gnq9apNuTLbuYlSALQg3CQEsNOVs+nkAFRTlRJq72 ePldDSUP8hHi/ekFWnCI02zB2cgTUog8Zmedfz6RlwElw9trRwiIJ7uwSMptFrZIzNhf ZiNZdpOMXgWaTsHL9HHsBm0TIOJQVNGEnS1bTl6bGobNLlPVX5jD8QNn9593PuJkYwC+ de852x2YZTmINlRiwGtoZXPXoM2CFrgkoEXKoj+RWeW/0fnYW1XaZZ8vBgmTH0LfqhET 07ad78t6LHyVJRco1Fbhz31551D+/FFP7vSGBCOubQP3mR+80epQv8zbgoAwFGHYOy1q tsRw== X-Gm-Message-State: ALoCoQl0WX8dmNZm8L+8sjZQxF0rIBq29t5MPql6vS2raE+vvT8t3SrMfZM05zEqItMjG98KdlPB MIME-Version: 1.0 X-Received: by 10.107.131.40 with SMTP id f40mr1378663iod.189.1449025225326; Tue, 01 Dec 2015 19:00:25 -0800 (PST) Received: by 10.36.184.68 with HTTP; Tue, 1 Dec 2015 19:00:24 -0800 (PST) In-Reply-To: <1449023458722-c64be47a-bac7cd73-e20f750d@fugue.com> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <1449005349724-ffd73ebb-f70e368e-426663a1@fugue.com> <565E2926.1050900@mustelids.ca> <1449013554783-b461d703-192d4623-50f6eda5@fugue.com> <1449023458722-c64be47a-bac7cd73-e20f750d@fugue.com> Date: Tue, 1 Dec 2015 21:00:24 -0600 Message-ID: From: Al Iverson To: shutup@ietf.org, ietf-smtp@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Thu, 03 Dec 2015 08:14:58 -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: Wed, 02 Dec 2015 03:00:29 -0000 On Tue, Dec 1, 2015 at 8:30 PM, Ted Lemon wrote: > Tuesday, Dec 1, 2015 6:52 PM Al Iverson wrote: >> Is that a hobbyist configuration? Is it relevant? It sounds a bit like >> a cat and the hat both sharing a NAT. But in a very common high volume >> production email scenario used by email service providers, clients and >> types of mail are segregated by sending IP address. > > My answer applies to both the gmail scenario and the private server scenario. In both cases, putting my IP address in the Received header field means that my legitimate mail is more likely to be dropped as spam, not less likely. > >> Noted that you don't. Just adding my voice: I do want it. > > Correction: by "I do not want it," I mean "it do not want my mail legitimate getting dropped as spam," not "On a personal level, I don't like it." Clarification: 1. Received headers and the IP addresses therein are currently valuable for filtering today, for me, for others, and as I've observed for others as big as AOL. 2. When I say "I do want it," I mean I think it would be a great loss to lose the current information (IP address and/or received headers) valuable for filtering purposes today under existing use cases. I want received headers and IP address source information to remain in email headers. 3. Your concern about your sending reputation being commingled with your cats is already the way the world works today if your mail streams are commingled. This is not a new problem and the proposed potential solution of redacting IP addresses or removing received headers takes data way instead of adding more data for filtering purposes. It's sort of cutting off a leg because we don't like how the arm works. Too much of spam filtering and reputation today is still IP address-based to throw out that identifier today. Like Chris said, the machine learning out there now almost always uses that identifier as an input today. Regards, Al Iverson -- Al Iverson - Minneapolis - (312) 275-0130 Simple DNS Tools since 2008: xnnd.com www.spamresource.com & aliverson.com From nobody Thu Dec 3 08:15:14 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 0F8F41A037C; Wed, 2 Dec 2015 07:23:23 -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 51ThtJB5gUy6; Wed, 2 Dec 2015 07:23:20 -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 ABF721A015D; Wed, 2 Dec 2015 07:23:20 -0800 (PST) Received: from [192.168.1.99] (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 tB2FNJjt003042 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2015 07:23:19 -0800 References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <57B818513A0069189BA3CF41@JcK-HP8200.jck.com> <1449014394167-7d2dec58-2c6a9ae8-33fc8e7a@fugue.com> <565E4CCF.3080901@mustelids.ca> <1449024914920-c367c12b-5b2db232-b118a379@fugue.com> <565EB238.6060207@pscs.co.uk> <1449064251263-c451a28b-ba1e4af8-62e69b69@fugue.com> <565F0A42.2070402@dcrocker.net> <1449069610234-da77a7a5-9aad0b81-0070a67b@fugue.com> To: Ted Lemon , dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <565F0CFF.5010501@dcrocker.net> Date: Wed, 2 Dec 2015 07:23:43 -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: <1449069610234-da77a7a5-9aad0b81-0070a67b@fugue.com> 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]); Wed, 02 Dec 2015 07:23:19 -0800 (PST) Archived-At: X-Mailman-Approved-At: Thu, 03 Dec 2015 08:14:58 -0800 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 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: Wed, 02 Dec 2015 15:23:23 -0000 On 12/2/2015 7:20 AM, Ted Lemon wrote: > Wednesday, Dec 2, 2015 10:12 AM Dave Crocker wrote: >> Absent hard data that shows efficacy, both of you are wrong. > > Not leaking data is 100% effective at not leaking data. A shame that has nothing to do with this thread or what I said. >> At base, we don't know how to prevent folks from getting scammed, >> while still allowing them to interact with the outside world. > > We know that revealing their personal information is harmful. A shame that has nothing to do with this thread or what I said. >> Lots of people are sure they know the right answer here, but none >> of them can document efficacy. Worse, most of the ways people cite >> have already been demonstrated to be inadequate or unachievable. > > Redacting IP address information from SMTP submission servers is very > achievable, A shame that has nothing to do with this thread or what I said. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Dec 3 08:15:16 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 D8B121B2B71 for ; Wed, 2 Dec 2015 08:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_21=0.6] 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 QSVEduxuaKWI for ; Wed, 2 Dec 2015 08:11:20 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2058F1B2B66 for ; Wed, 2 Dec 2015 08:11:19 -0800 (PST) Received: by qkas77 with SMTP id s77so18180983qka.0 for ; Wed, 02 Dec 2015 08:11:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=megacity-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=d5/BMWPuhhyIQBOXo/HLXsmlPRoAmabU1bTwrHnUF3E=; b=AsXzOmdJRx77Z/tWf7uWgj7cXomRNx7zIRdK6wcJ+tzUsNQgFZP7qFSm0dqLWBA+yx sye3z1PoodjRaTYi/TTU+OyyKjWFMl7xpSrgngweG21yUJbxBioalnZ7Aof589Aw9pud 0IY/pqWoGsw1v2pmH/G1IRpBXUburzaHveWyF5LOPZsH165EmczsOedmY9tafipe2rzV xxXI7TDuEB2ledvHRVPKrw0Jbtd1CdUuUVYHXHlxVR+t/T+N2qLa+TPKmPAc1cyL8gBO ap2OtG5wR+lRmD48RoG61WB7jBFTSP+gbyGA+Gy6XFhKoXFzp8GJ46cIbqasrxY2iD5m ehrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=d5/BMWPuhhyIQBOXo/HLXsmlPRoAmabU1bTwrHnUF3E=; b=WfyyyYb2DxB0EfGC+vX7iYs+nBl9CkP+OkZZyoMgt+RageLV9mJlNGjxbeQMCNsWoe OGGNsoDblTn+5bPSjigCE3xtiKurQC0llXjEf1ULVR0B25daIk1SUKndy622V4J/5cjf QQNWrLp5nu9Y4d3AyABi2kNYSQpwvxnLbP4FDpw2OTOHQY4qjSNgcLuAkhahw9o3S4CY HLKCjl/YhrQxkokrMtFFxhNOsmtaP+gYPrMFV65TA7pFJSsp4XEVLvpaMPpJmUaKKUi5 C8cIP+3MDsdkr8amcTShO7qAWAeW/ny6drU0do8pT5FZLoG7AiH+O61zTWBtffvZveMS Cg9Q== X-Gm-Message-State: ALoCoQmTObJl1lJLFfvclTKlwZy2aSjl+LPB47/SGHyS+6gN0YraPsAMNp27vBFJz7Lf45xPn1GR X-Received: by 10.55.21.168 with SMTP id 40mr4844517qkv.70.1449072678045; Wed, 02 Dec 2015 08:11:18 -0800 (PST) Received: from Akebono.local (cpe-67-243-53-192.hvc.res.rr.com. [67.243.53.192]) by smtp.googlemail.com with ESMTPSA id 79sm1479810qkv.23.2015.12.02.08.11.15 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Dec 2015 08:11:16 -0800 (PST) To: ietf-smtp@ietf.org References: <20151202144953.22592.qmail@ary.lan> <1449069164873-53573cc1-d1798c08-2eeb118d@fugue.com> From: "Derek J. Balling" Message-ID: <565F181D.8020500@megacity.org> Date: Wed, 2 Dec 2015 11:11:09 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <1449069164873-53573cc1-d1798c08-2eeb118d@fugue.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SDxsrCTMMcTHSIUi4oP9jlNwsp5183AlN" Archived-At: X-Mailman-Approved-At: Thu, 03 Dec 2015 08:14:58 -0800 Cc: shutup@ietf.org Subject: Re: [Shutup] [ietf-smtp] real life privacy tradeoffs, was Proposed Charter 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: Wed, 02 Dec 2015 16:11:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SDxsrCTMMcTHSIUi4oP9jlNwsp5183AlN Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/2/2015 10:12 AM, Ted Lemon wrote: > Wednesday, Dec 2, 2015 9:49 AM John Levine wrote: >> Different people are different and it is not helpful to pretend that >> all end users are the same. Most people say they care about privacy, >> but their actions show that they actually don't, e.g., they'll trade >> their password and SSN for a candy bar. > Show your data or please stop making generalizations like this. This = is really not helpful. > http://news.bbc.co.uk/2/hi/technology/3639679.stm --=20 I prefer to use encrypted mail. My public key fingerprint is FD6A 6990 F035 DE9E 3713 B4F1 661B 3AD6 D82A BBD0. You can download it at http://www.megacity.org/gpg_dballing.txt Learn how to encrypt your email with the E-Mail Self Defense Guide: https://emailselfdefense.fsf.org/en/ --SDxsrCTMMcTHSIUi4oP9jlNwsp5183AlN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0 Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWXxgiAAoJEGYbOtbYKrvQtAsQAMdxFcNpUuteCVljJvecKr33 6eIcWVpWHuPjBF886ainqeErg6l7KDB9IBxhUVmmC8pV+iY+ZaFDxF4UwuMkVHZl T/uHsYVF2YM/z4+52PU8Fs6u54vkCYfKyyALNgiL8lPzqqteEB3o85bB6tnzRMk3 rMJ+YBIXzREJQfXClMKZpipeUJF74i3PrYNZx1agiVnOWQfGYW1p9Rr/fHriOrhQ CNsd92LJkA8dn+Uw/OCht8Yp1qw3k+YI+aK4yiSL1IrKLZzaM+mcsfxH8UeHz7fX 4qweC1iI9lzm1j1ndeFxfsB7pphggImoDMb8nF79+/3R7ebLy48Kf2r17kmWjexO SFoYtj4Rn2Xrt3GIpUyN55NHTsbFMzbTX0v7fBQI7h8xyXK0LeAbCUfI6Oh6jV4L mA+ZCdfjnXMlmb6XOMce3xoG4Q9fCPmNaACFD4jZyORYDnMAf2y/L3z61ZynnsmX nmbbGcKstGRU7ujP6iqz0K7YQ7i2ojfIgmnimDdHD9mgVGb9cK3HP8IXkWWPyTi/ VhpR+fStMZO2SuX2b9Z5jmeXjGfynHBKEJEdkjL9x3u6P4fQdefQI3msEbgJEr5o iHs5e4eJjbuYu4USHZeEPef+MPZF78Yhj0PwrKVfM/faO35NuVUFa/JgPfPBgiFk di9C69pAX0yBa5DgIXQr =vEyP -----END PGP SIGNATURE----- --SDxsrCTMMcTHSIUi4oP9jlNwsp5183AlN-- From nobody Thu Dec 3 08:15:17 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 0109D1ACDEB; Wed, 2 Dec 2015 10:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.191 X-Spam-Level: X-Spam-Status: No, score=-1.191 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TY_79EVCkIaw; Wed, 2 Dec 2015 10:23:31 -0800 (PST) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.31]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BFE11ACDF4; Wed, 2 Dec 2015 10:23:22 -0800 (PST) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES533.agna.amgreetings.com ([::1]) with mapi id 14.03.0266.001; Wed, 2 Dec 2015 13:23:21 -0500 From: "MH Michael Hammer (5304)" To: "shutup@ietf.org" , "ietf-smtp@ietf.org" Thread-Topic: [ietf-smtp] [Shutup] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG (fwd) Thread-Index: AQHRLSh6QEC/jQ62IUCw/aN1tJvJXJ64UMAA//+xS8A= Date: Wed, 2 Dec 2015 18:23:20 +0000 Message-ID: References: <20151202174004.23134.qmail@ary.lan> <1449079357057-1f8e007c-8d601e39-07ee75a7@fugue.com> In-Reply-To: <1449079357057-1f8e007c-8d601e39-07ee75a7@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.200] x-kse-attachmentfiltering-interceptor-info: protection disabled x-kse-serverinfo: USCLES533.agna.amgreetings.com, 9 x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean, bases: 12/2/2015 5:19:00 PM x-kse-dlp-scaninfo: Skipped Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 03 Dec 2015 08:14:58 -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: Wed, 02 Dec 2015 18:23:33 -0000 > -----Original Message----- > From: ietf-smtp [mailto:ietf-smtp-bounces@ietf.org] On Behalf Of Ted > Lemon > Sent: Wednesday, December 02, 2015 1:03 PM > To: shutup@ietf.org > Cc: ietf-smtp@ietf.org > Subject: Re: [ietf-smtp] [Shutup] Proposed Charter for the "SMTP Headers > Unhealthy To User Privacy" WG (fwd) >=20 > Wednesday, Dec 2, 2015 12:40 PM John Levine wrote: > > You can kind of tell where I am from my mail headers, but since my > > name and address and phone number are in the phone book, it's hard to > > imagine what the damage would be. >=20 > The damage is that there are quite a few John Levines in the world. If = you > say something that triggers someone's desire to harass you, they will be = able > to use your IP address to determine that it is the John Levine who lives = in > Trumansburg who offended them, and then they can just google "John > Levine Trumansburg" to dox or swat you. This is _precisely_ the problem > with revealing your IP address. It took me about ten minutes to get you= r > home address, and that's because I don't have any practice. Without the= IP > address, I would have had no chance of figuring out _which_ John Levine t= o > target with my notional swatting or pizza delivery. It would have taken = <1 > minute to find your street address except that you did a good job of chaf= fing > by using a P.O. Box. >=20 It took me 20 seconds using google and no IP Addresses were harmed in the t= esting - https://www.google.com/?gws_rd=3Dssl#q=3Djohn+levine. BTW John, co= ngratulations on your page ranking.=20 I've refrained from getting into this conversation but increasingly my sens= e is that Ted has a solution that is seeking a problem. Mike From nobody Thu Dec 3 11:13: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 E00EF1A001C for ; Thu, 3 Dec 2015 11:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 NvBdcPfJEe3d for ; Thu, 3 Dec 2015 11:13:23 -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 9FA741A001A for ; Thu, 3 Dec 2015 11:13:22 -0800 (PST) Received: (qmail 26706 invoked from network); 3 Dec 2015 19:13:20 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 3 Dec 2015 19:13:20 -0000 Date: 3 Dec 2015 19:12:59 -0000 Message-ID: <20151203191259.36292.qmail@ary.lan> From: "John Levine" To: ietf-smtp@ietf.org, shutup@ietf.org In-Reply-To: <56605758.8090107@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Shutup] [ietf-smtp] Well Known Bad Anti-spam Idea - paid network 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, 03 Dec 2015 19:13:24 -0000 >On 12/3/2015 5:44 AM, Jacob Palme wrote: >> I think that the only workable method of getting rid of spam is to charge the sender of messages a price of perhaps 0.10 >$/recipient for sending messages. >There are many approaches to solving spam that will work quite >effectively, if only they were able to work at all. > >Your view is one of many that is oft-repeated, very appealing, and >entirely unworkable in the current real-world. > >As such proposals always warrant, please carefully review Cory >Doctorow's famous checklist: > > http://craphound.com/spamsolutions.txt For more details, see this white paper I wrote. It's ten years old but nothing of importance has changed other than that you might add the occasional extra zero to orders of magnitude. http://www.taugh.com/epostage.pdf R's, John From nobody Thu Dec 3 12:13:35 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 70CD51A90EE; Thu, 3 Dec 2015 12:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.064 X-Spam-Level: **** X-Spam-Status: No, score=4.064 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, MISSING_HEADERS=1.021, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eai07cyN4-Wd; Thu, 3 Dec 2015 12:13:31 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25CDA1A9105; Thu, 3 Dec 2015 12:13:31 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB3KDTt3000788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 3 Dec 2015 15:13:29 -0500 References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <57B818513A0069189BA3CF41@JcK-HP8200.jck.com> <1449014394167-7d2dec58-2c6a9ae8-33fc8e7a@fugue.com> <565E4CCF.3080901@mustelids.ca> <565E4FEC.2000607@cs.tcd.ie> <565FBDE6.8020001@mustelids.ca> <56605545.3010207@dcrocker.net> From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <5660A269.50405@mustelids.ca> Date: Thu, 3 Dec 2015 15:13:29 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <56605545.3010207@dcrocker.net> Content-Type: text/plain; charset=windows-1252; format=flowed 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: Thu, 03 Dec 2015 20:13:32 -0000 On 12/03/2015 09:44 AM, Dave Crocker wrote: > On 12/2/2015 7:58 PM, Chris Lewis wrote: >> You will find no person more in agreement that we cannot train 100% of >> people with PSAs and similar (the fact that 419s still flow is certainly >> proof of that), but the reality is that most people do learn such things >> one way or another. > "Most people" do not. Not even close to most people and very nearly > never any people consistently, since the ability of humans to perform > real-time and nuanced monitoring reliably like this, reliably and over > time, borders on no ability at all. > Feel free to provide documentation to the contrary. I'm going to appear flippant, but I think it's appropriate. Neither you nor I have been killed by a bus. Every time we meet I "document" that fact by saying "hi Dave" and chatting a bit (or do you want to see my passport next time?). In fact, very few people have been killed by buses. That success is not part of our genetic makeup, it's not wired in. It required training to achieve that, it's very real-time, and requires nuanced monitoring ("is that thing possibly going to hit me?" to a degree that technology cannot make us immune). Nor does the fact that a few people have been killed by a bus mean that the training didn't work. We can build the signs, the fences, the traffic signals and so on, but, none of that's going to save me if I walk around the center of the city with my eyes closed. The reality is that trying to retain the privacy level that some people think they need to have cannot be done "reliably" and still permit the use of the Internet in the way that most people want. If we want to "nanny" privacy to this level, we really should be talking about filters that prevent people from giving out their phone numbers, addresses, pictures of pets (with geolocation in the jpgs), and vacation schedules in email or anywhere else. People have to partition what they do between "what must be kept private" and what doesn't need to, and use measures appropriate to their actions at the time. > The issue isn't whether people generally understand the general issue. > It's whether they can develop very specific understandings and apply > them in real time, to useful effect over extended time. I contend that people can acquire general understandings (at least in this area) that requires no deep-dive into understanding the underlying technology to achieve the level of privacy they want, and in fact it's quite easy to a level far exceeding just removing "from" clauses. To whit: "If you want email privacy, use an anon remailer, there's lots listed on , and check out the reviews". [My advice would also be "don't subscribe to IETF lists". I've gotten 11 spams in the few days since I created this email address to participate in this discussion.] >> Trying to "measure" the result of training is usually futile, because >> correctly posing the questions, and getting useful answers is equally >> complicated and fraught with definitional/terminology problems. > Right. That should alert us all to the challenges of the training itself. Or, alert us that our measurement methods are completely bogus, and we really should be measuring it some other way. While I have no way to prove this, I should think that the success rates of 419s is lower than it would have been in the society of 20 years ago. If not, the human race is far stupider than anyone thought and we're all doomed. [I should be careful in saying that, after having one experience intervening with one allegedly hi-tech astute husband and wife who were about to fall for the exact same phish for the second time.] From nobody Thu Dec 3 12:27: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 3F9BB1A92E2 for ; Thu, 3 Dec 2015 12:27:29 -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=unavailable 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 JihFE4J9YxTB for ; Thu, 3 Dec 2015 12:27:27 -0800 (PST) Received: from xsmtp02.mail2web.com (xsmtp02.mail2web.com [168.144.250.215]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70F271A92B6 for ; Thu, 3 Dec 2015 12:27:27 -0800 (PST) Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1a4aTK-0008EI-RE for shutup@ietf.org; Thu, 03 Dec 2015 15:27:26 -0500 Received: (qmail 30194 invoked from network); 3 Dec 2015 20:27:22 -0000 Received: from unknown (HELO huitema2) (Authenticated-user:_huitema@huitema.net@[131.107.147.15]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 3 Dec 2015 20:27:21 -0000 From: "Christian Huitema" To: "'Derek J. Balling'" , References: <20151202144953.22592.qmail@ary.lan> <1449069164873-53573cc1-d1798c08-2eeb118d@fugue.com> <565F181D.8020500@megacity.org> In-Reply-To: <565F181D.8020500@megacity.org> Date: Thu, 3 Dec 2015 12:27:32 -0800 Message-ID: <0b7701d12e09$0a7295c0$1f57c140$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQEEjZ0ZUh/BSp7lb1CP/JAkW0CMHgIAAQjXAfpifCOgMyBcUA== Content-Language: en-us Archived-At: Cc: shutup@ietf.org Subject: Re: [Shutup] [ietf-smtp] real life privacy tradeoffs, was Proposed Charter 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, 03 Dec 2015 20:27:29 -0000 On Wednesday, December 2, 2015 8:11 AM, Derek J. Balling wrote: > On 12/2/2015 10:12 AM, Ted Lemon wrote: > > Wednesday, Dec 2, 2015 9:49 AM John Levine wrote: > >> Different people are different and it is not helpful to pretend that > >> all end users are the same. Most people say they care about privacy, > >> but their actions show that they actually don't, e.g., they'll trade > >> their password and SSN for a candy bar. > > Show your data or please stop making generalizations like this. This is > really not helpful. > > > http://news.bbc.co.uk/2/hi/technology/3639679.stm That was a bit of stunt, polling people in the street outside a conference room, designed to shock and grab attention with little attention paid to demographics or study conditions. It is also 11 years old, and public perceptions have evolved a lot since then, especially after the Snowden revelations. For something a bit more scientific, balanced, and recent, I recommend the Pew Research Center study on "Public perceptions of privacy," November 2014. http://www.pewinternet.org/2014/11/12/public-privacy-perceptions/ The Pew Research study shows a fairly good awareness of privacy, a widespread concern about surveillance by government and businesses, but also a loss of confidence in the security of common communications channels. Most say they want to do more to protect their privacy, but many believe it is not possible to be anonymous online. And many of the responders were actually taking steps to protect their privacy, however ineffective those steps may be. -- Christian Huitema From nobody Thu Dec 3 16:36: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 2F23F1B2B7A for ; Thu, 3 Dec 2015 16:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 7Yjv59Kr1EO4 for ; Thu, 3 Dec 2015 16:36:17 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AED201B2B5B for ; Thu, 3 Dec 2015 16:36:17 -0800 (PST) Received: by ioir85 with SMTP id r85so99996527ioi.1 for ; Thu, 03 Dec 2015 16:36:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lcMAjVB7QQKSgKGdxfF0qcUdbUgwEKfAt4i7k8TvHR8=; b=lSspCp5TumIvOD0RPJPOEKw8rAmNK2a5wDz6MNUXKfICbxRK/PFgB3vQPDMUCAPAy3 ftTE+KLLD8Y8rTkSt4CkKSSvvAB4NywQWGEv2ZXm7y89O20ECilv3aqKffytu5mk8CN3 iOhWCXYFKTN5NNTGVyzP01UDiDec+uYnbB9o4PrxMlymakBdEmVXkFlhdzRgKGDCVum6 cOnfxvxPEOwKwsnI+MEDjiw0C2xZ0NQgZzbY09wqBiyrEnZJsrhoPK2qa+8vWFaCpnLy blilx0q1Hq9VsB3qgvLhfXSvoqY+4KOQfSyaz+2SiDdrdScXw5nZw/X8vNff891Cq496 sHyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=lcMAjVB7QQKSgKGdxfF0qcUdbUgwEKfAt4i7k8TvHR8=; b=WibYcEUNcNmZe8TsR4C2y6zl11XQf8CzpB95MZU/Hx+xfHu+xDABORNPEbKlRs18v5 YS3LQeY3Citw7Zttz3HZx0oXxxuFGIGTKgPEpzEhUeTxI9njVeAzF86fCfTDLgvUSN1v SBq8QolOHebwzCvm42qLIaLSlrOKyhVexaaT3cxPsQgOpBKSzwQZkKRlvv5hHOHkxM2o 8zW8THmWRV96xrBaHOEguBaokEpuux7fAo2pi1bhx0EIYD+ZuL6roNxtndFdB0nuhx1H PytI/1slQn+12z8gCA0q55n4miKltkLXuawSyMxd+gi8NZ0VMD6M35eGQH72rshFUyWI zlJg== X-Gm-Message-State: ALoCoQmgStNGTKs7fiYdWAmKbXtF/zzOghLiHytfM6uSNBU5FBteRdREyJHPYpT4OOloLmXmUtkv MIME-Version: 1.0 X-Received: by 10.107.16.18 with SMTP id y18mr11883618ioi.113.1449189376887; Thu, 03 Dec 2015 16:36:16 -0800 (PST) Received: by 10.64.62.14 with HTTP; Thu, 3 Dec 2015 16:36:16 -0800 (PST) Date: Thu, 3 Dec 2015 16:36:16 -0800 Message-ID: From: Brandon Long To: shutup@ietf.org, ietf-smtp Content-Type: multipart/alternative; boundary=001a113fe62e05f652052607b218 Archived-At: Subject: [Shutup] Levels of proposals 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: Fri, 04 Dec 2015 00:36:19 -0000 --001a113fe62e05f652052607b218 Content-Type: text/plain; charset=UTF-8 The WG proposal seems to imply taking all IPs out. The discussion has mostly been about submission. It seems to me that there are at least three different IPs used, and some of these are going to be visible regardless of intent. Ie, there is the submission IPs, there are "internal" IPs, and external ones. Submission IPs seem like the largest level of risk, and from my gross understanding of anti-spam, pretty minor. I'm not sure what the current source levels are, but submission IPs would be most useful in the case of hijacked account spam or abusive account spam. Presumably, if spam reports about such are forwarded to the MSP, then the MSP can easily store the information somewhere other than the easily forged headers and take the appropriate action. Only if the answer is "they don't take action" would you need more. Also, if the previous thread's list of large MSPs inclusion of submission IPs is correct, then >2 out of the top 3 have already removed them (ie, only a fraction of Gmail mail has them at this point). Internal IPs, this hardly seems controversial. If any mail system did that, not sure if anyone would bat an eye. External IPs, ie server to server... I guess one may learn "something" if you can tell which submission server they talked to, we certainly have servers across the world... but even with 20 odd locations, I doubt that would be that specific. So, I would recommend concentrating on submission IPs. I might also include a recommendation for submission servers to store the IPs for some length of time to allow for abuse handling, or even to include an encrypted version in the message. Brandon --001a113fe62e05f652052607b218 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The WG proposal seems to imply taking all IPs out.=C2=A0 T= he discussion has mostly been about submission.

It seems= to me that there are at least three different IPs used, and some of these = are going to be visible regardless of intent.

Ie, = there is the submission IPs, there are "internal" IPs, and extern= al ones.

Submission IPs seem like the largest leve= l of risk, and from my gross understanding of anti-spam, pretty minor.=C2= =A0 I'm not sure what the current source levels are, but submission IPs= would be most useful in the case of hijacked account spam or abusive accou= nt spam.=C2=A0 Presumably, if spam reports about such are forwarded to the = MSP, then the MSP can easily store the information somewhere other than the= easily forged headers and take the appropriate action.=C2=A0 Only if the a= nswer is "they don't take action" would you need more.
<= div>

Also, if the previous thread's list of large MS= Ps inclusion of submission IPs is correct, then >2 out of the top 3 have= already removed them (ie, only a fraction of Gmail mail has them at this p= oint).

Internal IPs, this hardly seems contr= oversial.=C2=A0 If any mail system did that, not sure if anyone would bat a= n eye.

External IPs, ie server to server... I gues= s one may learn "something" if you can tell which submission serv= er they talked to, we certainly have servers across the world... but even w= ith 20 odd locations, I doubt that would be that specific.

So, I would recommend concentrating on submission IPs.=C2=A0 I mig= ht also include a recommendation for submission servers to store the IPs fo= r some length of time to allow for abuse handling, or even to include an en= crypted version in the message.

Brandon
--001a113fe62e05f652052607b218-- From nobody Thu Dec 3 16:53:42 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 9273B1B2C48; Thu, 3 Dec 2015 16:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kVvineYcb-d; Thu, 3 Dec 2015 16:53:40 -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 D67211B2C44; Thu, 3 Dec 2015 16:53:38 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14491904146720.8595879825297743" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <5660A269.50405@mustelids.ca> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <57B818513A0069189BA3CF41@JcK-HP8200.jck.com> <1449014394167-7d2dec58-2c6a9ae8-33fc8e7a@fugue.com> <565E4CCF.3080901@mustelids.ca> <565E4FEC.2000607@cs.tcd.ie> <565FBDE6.8020001@mustelids.ca> <56605545.3010207@dcrocker.net> <5660A269.50405@mustelids.ca> Date: Fri, 04 Dec 2015 00:53:34 +0000 Message-Id: <1449190415463-5b354825-c1ffe6b9-2ea9da93@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: Fri, 04 Dec 2015 00:53:41 -0000 ------sinikael-?=_1-14491904146720.8595879825297743 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thursday, Dec 3, 2015 3:13 PM Chris Lewis wrote: > In fact, very few people have been killed by buses. The reason very few people are killed by buses, to the extent that this is = even true, is not =5Fjust=5F that people have learned to look out for cross= traffic, although they certainly have. It's that there is a whole system= of traffic laws that try to make sure that the bus and the person who = would be killed by it do not occupy the same space at the same time. = There are sometimes stringent, sometimes lax, but very real licensing = requirements to operate a bus, and if you are hired to operate a bus, and = turn out to be a dangerous driver, you will probably lose your job. In = addition, there are rigorous inspection requirements in most localities = (and where there aren't, bus fatalities are not coincidentally higher). I think your analogy is a good one, but I don't think the conclusion you = drew from it made any sense, because you only accounted for the behavior = that people engage in to avoid being hit by buses, and that behavior is = probably less than half of the protection that's in place to keep them from= getting hit. Nobody is perfectly attentive. You need a = belt-and-suspenders system of defense if you are going to avoid accidents. The same is true of email, and that's why we're having this conversation! -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14491904146720.8595879825297743 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWYOQPCRAMw8Nu0HeKywAAOKwH/j7B9LmUDjTIVo7yuBVB Ku7kKp4JIwIkqTPEE7LeXxTFM5wvqN69MHtWW1IL2x8XkY1sCo9cpjQJB57F 01UbIzBdfpeABPIE4MSJB3b5SMCNORazF6gHEyaWLe0gY/kxE72hszICvY/6 QmuA47X0Wyb1bPEAcuVlNp/VWgxI8i0YBDkOlL7e/gJbtmAApSYDVdtch0g6 AIoC5zkwCIjQHXgUuzKqjxecavODv4mx1cu5oPUUGWXOrNmF9ACdd1zJSANo M+noNuFzCO+xdgpmlEHzu6JXMEIwzWDs2EHuVA04wdH4QxPFVO0dHkouqz8G R4uyuYJCYIA8V90Tye10LZM= =A25X -----END PGP SIGNATURE----- ------sinikael-?=_1-14491904146720.8595879825297743-- From nobody Thu Dec 3 17:19: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 9A9551A8AAD; Thu, 3 Dec 2015 17:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTs7Qg5mATyS; Thu, 3 Dec 2015 17:19:55 -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 8ECD41A8A05; Thu, 3 Dec 2015 17:19:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2E013BE55; Fri, 4 Dec 2015 01:19:53 +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 oqX-yKsTRm_J; Fri, 4 Dec 2015 01:19:51 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.20.32]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id ED47CBE3F; Fri, 4 Dec 2015 01:19:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449191991; bh=5IVrjZX7LIlJ2lfbSEuplhYeo4YGsH6YXk7d2Hs2iVM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=s6JSsg3zOV0t7iVrHbKXvOfstxv6VqRxl2fomosBLO3zoV0+N3Hw1uCHYZjd1klEc bbmuLN9LqxqXCnE4uVy0TKyuA1zAXpVrkBwb6r1+q9eA1mjJeThqnQk2ERPuIfMgiQ FOLxoXHPVbMiauQPKrgmpfPSZ/gCynIjPxSr8/PA= To: Brandon Long , shutup@ietf.org, ietf-smtp References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5660EA36.9030905@cs.tcd.ie> Date: Fri, 4 Dec 2015 01:19:50 +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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Shutup] Levels of proposals 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: Fri, 04 Dec 2015 01:19:58 -0000 This seems like another sensible opinion that doesn't make overbroad claims about the goodness/badness of what's proposed to be examined. More of us limiting our posting like this would be good IMO. S. On 04/12/15 00:36, Brandon Long wrote: > The WG proposal seems to imply taking all IPs out. The discussion has > mostly been about submission. > > It seems to me that there are at least three different IPs used, and some > of these are going to be visible regardless of intent. > > Ie, there is the submission IPs, there are "internal" IPs, and external > ones. > > Submission IPs seem like the largest level of risk, and from my gross > understanding of anti-spam, pretty minor. I'm not sure what the current > source levels are, but submission IPs would be most useful in the case of > hijacked account spam or abusive account spam. Presumably, if spam reports > about such are forwarded to the MSP, then the MSP can easily store the > information somewhere other than the easily forged headers and take the > appropriate action. Only if the answer is "they don't take action" would > you need more. > > Also, if the previous thread's list of large MSPs inclusion of submission > IPs is correct, then >2 out of the top 3 have already removed them (ie, > only a fraction of Gmail mail has them at this point). > > Internal IPs, this hardly seems controversial. If any mail system did > that, not sure if anyone would bat an eye. > > External IPs, ie server to server... I guess one may learn "something" if > you can tell which submission server they talked to, we certainly have > servers across the world... but even with 20 odd locations, I doubt that > would be that specific. > > So, I would recommend concentrating on submission IPs. I might also > include a recommendation for submission servers to store the IPs for some > length of time to allow for abuse handling, or even to include an encrypted > version in the message. > > Brandon > > > > _______________________________________________ > Shutup mailing list > Shutup@ietf.org > https://www.ietf.org/mailman/listinfo/shutup > From nobody Thu Dec 3 18:00:09 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 51D1F1AD355; Thu, 3 Dec 2015 18:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.242 X-Spam-Level: ** X-Spam-Status: No, score=2.242 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haJXDE0Sl7Md; Thu, 3 Dec 2015 18:00:05 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE91D1AD350; Thu, 3 Dec 2015 18:00:04 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB4201RN009320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 3 Dec 2015 21:00:03 -0500 To: shutup@ietf.org, ietf-smtp References: From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <5660F3A1.7060807@mustelids.ca> Date: Thu, 3 Dec 2015 21:00:01 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Shutup] Levels of proposals 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: Fri, 04 Dec 2015 02:00:06 -0000 On 12/03/2015 07:36 PM, Brandon Long wrote: > The WG proposal seems to imply taking all IPs out. The discussion has > mostly been about submission. The draft has been mostly about submission, but there have been some conversations about internals. I've seen auditors bring up points about obscuring internals (corporate context, it's one of their checkoff 10 commandments), but, we managed to convince them that ease of diagnosing problems outweighed the downsides. Before getting too far into concrete proposals, we still need to decide whether it should be done, and what (if anything) should be done in mitigation. That said: > Submission IPs seem like the largest level of risk, and from my gross > understanding of anti-spam, pretty minor. Yes, and no... It depends on how you use/acquire them, this is a fairly complex/esoteric end of spam filtering, and just doing it justice would take up pages of text. I'll try to short cut - purely from a filtering but not-ML perspective: Using them: If you have a list of IPs known to be infected with AUTH-cracking spambots, it's of immediate/valuable use to both the MSAs themselves in detecting malicious injects, as well as the recipient's filtering, and header forgery is not an issue (certainly not to MSAs, and headers that forge collisions with the list you don't want anyway). The potential yields are huge - ISPs (using a list we create of 2.2M IPs demonstrably capable of AUTH-cracking) can see botnet suppression rates at the MSA of 80% (of all submissions) or even higher, depending on the spam/botnet de-jour. In just one case it's in the 1000+/second range. Some of these botnets are very very prolific per IP. Which boils down to the MSAs being able to stop it at source, or the receivers being able to stop it at destination. If a significant fraction of MSAs stopped it at source, then, maybe, the MSA Received line isn't important. But where they don't (the majority), losing the MSA Received line is potentially a big hit. Obtaining them: Obviously, someone trying to authenticate to you and is demonstrably infected isn't spoofable. That yields the vast majority of our list. On a case-by-case basis with specialized knowledge it is possible to derive trustworthy infected submission addresses from received lines. Yes, actually, it really is. Useful, but not terribly significant (or at least how far we've followed that rathole). By eliminating MSA received clauses, it means that only the MSA can do blocking based on this technique, the receivers can't. On one server, in a 40 minute interval, 774123 out of 1126763 connections were AUTH spoofing from just one particular botnet. That's 775,000 spams that ordinary receivers couldn't filter via IP if the from clauses disappeared. > Also, if the previous thread's list of large MSPs inclusion of > submission IPs is correct, then >2 out of the top 3 have already removed > them (ie, only a fraction of Gmail mail has them at this point). The top 3 aren't generally large scale botnet spam sources, and botnets generally don't use real mail servers (except via AUTH crackers), and the top 3 are amply well instrumented with rate limiters etc. So they really aren't relevant to this. From nobody Thu Dec 3 18:11: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 BF0251ADBFC; Thu, 3 Dec 2015 18:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5xfMNzlSYyu; Thu, 3 Dec 2015 18:11:54 -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 876131AD49F; Thu, 3 Dec 2015 18:11:53 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14491951077390.3884546449407935" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <5660F3A1.7060807@mustelids.ca> References: <5660F3A1.7060807@mustelids.ca> Date: Fri, 04 Dec 2015 02:11:47 +0000 Message-Id: <1449195108085-9ef6f394-96f931b3-20b99bd2@fugue.com> MIME-Version: 1.0 Archived-At: Cc: ietf-smtp@ietf.org Subject: Re: [Shutup] [ietf-smtp] Levels of proposals 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: Fri, 04 Dec 2015 02:11:55 -0000 ------sinikael-?=_1-14491951077390.3884546449407935 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thursday, Dec 3, 2015 9:00 PM Chris Lewis wrote: > If you have a list of IPs known to be infected with AUTH-cracking = spambots, it's of immediate/valuable use to both the MSAs themselves in = detecting malicious injects, as well as the recipient's filtering, and = header forgery is not an issue (certainly not to MSAs, and headers that = forge collisions with the list you don't want anyway). Can you unpack =22AUTH-cracking spambots=22 for the greenhorns=3F I have = no idea what this means, and google unfortunately was unable to help. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14491951077390.3884546449407935 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWYPZkCRAMw8Nu0HeKywAAGWQH/2nB7K8nLCkg9zpobEw1 LWkTh31vt8R7H0tOee2pZ8u4jPPa9Ec9EKxOUxuKVnJy9LcbtLoB+icQRXYy 4es6pWPfuIkbRJJ4vSHvfbJg037CWrnxXXmtoV3gfbqTZlfMgD76lohE/+Ny M0ojPnkIefr2s39EskOBFRNI+RyL1DnuaFO+GKXTNEIpjMFMSdlgOEjH/W1k xkMYZBQfcCt/Lo9fozLbsznk6K+Dh0uOOZdjV5knN/4Xjd9Wm/ge3egKWETb Os0cM4FFMteW34g33mgHxwWoSWHzmEyEYyqYfOPmkcxuWZh/CGB0xxgVp9yK +wEiwUxDQppmDKbASby5EEY= =9cRK -----END PGP SIGNATURE----- ------sinikael-?=_1-14491951077390.3884546449407935-- From nobody Thu Dec 3 18:39:41 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 CA33E1B2A32; Thu, 3 Dec 2015 18:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XE69xXVUsXrC; Thu, 3 Dec 2015 18:39:39 -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 30F711B2A2D; Thu, 3 Dec 2015 18:39:38 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14491967752630.3112983494065702" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <87k2ov7xly.fsf@hope.eyrie.org> References: <5660F3A1.7060807@mustelids.ca> <1449195108085-9ef6f394-96f931b3-20b99bd2@fugue.com> <87k2ov7xly.fsf@hope.eyrie.org> Date: Fri, 04 Dec 2015 02:39:35 +0000 Message-Id: <1449196775597-73137a19-d32873ba-cad85c2a@fugue.com> MIME-Version: 1.0 Archived-At: Cc: ietf-smtp@ietf.org Subject: Re: [Shutup] [ietf-smtp] Levels of proposals 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: Fri, 04 Dec 2015 02:39:41 -0000 ------sinikael-?=_1-14491967752630.3112983494065702 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thursday, Dec 3, 2015 9:31 PM Russ Allbery wrote: > Standard practice for attackers these days is to automate attacks on any > sort of password-protected system, whether that be web pages, > authentication providers, or anything else that takes a password. = Usually > this is done by taking some list of common passwords and some list of > account names and just brute-forcing combinations, although some = attackers > do more sophisticated things. >=20 > Obviously, that sort of brute force approach is easy to detect and > throttle, so the next step in the arms race was for attackers to use = large > networks of compromised machines, usually home machines behind DSL and > cable modem links, each of which tries a small number of passwords = against > a variety of targets to stay below the radar. Those machines were > generally compromised via malware of some kind and are part of a botnet, > without the knowledge of the user of the machine. Thanks for explaining! I am still a bit puzzled: how does increasing the number of attackers help = to bypass the throttling mechanism=3F Why isn't the throttle per = id/password pair, rather than per ip-address/password/id triple=3F Secondarily, if distributed processing makes throttling per id/password = pair difficult, why is it hard to do the botnet IP address matching at the = authentication point=3F This seems like it would avoid a =5Flot=5F of = extra processing. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14491967752630.3112983494065702 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWYPznCRAMw8Nu0HeKywAALdgIAL3vfMDZRtHizJC4BH7S HHxuLkkuoSjOgNi/WExyD2YeemPS/usgQKbzeMPbdqeUEmx12LtTWv/K53li EOzlLiEY55wEeLXPh2wXLfE5Yw75DOiNd6qvR+fNadXljr5vg3KRizZ8Ioor VifDFQ3lq8Q3ZylYgmlsi9f7hl8jQ/4J6Es++Ur0+r5eZDeYY65pushQZ5HU EI6BWo/QjhVmeHVTYwkkrURvVjv6x/+m0dWGWkZWUWFXuU69FaGKMMBnNQ6V oGxRHLBvCvRAXUyImL/OBC8/aw5E1yfaDSvUsyyIPZsnry0NQJafL1KV8Lxp MrgWQwHCquhlIwSK5yMxWfU= =uP/I -----END PGP SIGNATURE----- ------sinikael-?=_1-14491967752630.3112983494065702-- From nobody Thu Dec 3 18:48:52 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 86B001B2A5D; Thu, 3 Dec 2015 18:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7K3Xm7YKzIg; Thu, 3 Dec 2015 18:48:48 -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 1EB441B2A03; Thu, 3 Dec 2015 18:48:46 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14491973233290.9587844042107463" From: Ted Lemon To: shutup@ietf.org In-Reply-To: References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <57B818513A0069189BA3CF41@JcK-HP8200.jck.com> <1449014394167-7d2dec58-2c6a9ae8-33fc8e7a@fugue.com> <565E4CCF.3080901@mustelids.ca> <20151202032522.GB12713@gsp.org> <1449027304809-2b32a944-6d383650-49f2a64c@fugue.com> <20151202225124.GA18695@gsp.org> Date: Fri, 04 Dec 2015 02:48:43 +0000 Message-Id: <1449197323648-4e74dacc-8bacef9a-217d6196@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: Fri, 04 Dec 2015 02:48:49 -0000 ------sinikael-?=_1-14491973233290.9587844042107463 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thursday, Dec 3, 2015 9:39 PM Robert A. Rosenberg wrote: > If the message is HTML, then putting a 1x1 web-bug image in the HTML will= trigger the info UNLESS the user's MUA is set to NOT automatically = retrieve images. That retrieving images is the default behavior of most MUAs, and that it is= even possible to do without cryptographically validating the ID of the = sender in =5Fany=5F MUA, is an example of what I am talking about when I = say that UI design is vitally important to protecting users' privacy. Obviously if you have an MUA that behaves so stupidly, then your privacy is= forfeit. At present, that's most MUAs. This is something that I hope = MUA implementors will wise up to, and we ought to be advising them to if we= aren't already. There are some ways of fixing this without involving the MUA. E.g., if a = user gets email with links to images, rewrite all of the links to point to = a proxy that has a mapping between each rewritten link and the original; if= the MUA fetches against that link, proxy it. This protects the end = user's IP address without requiring that they install a new MUA, and should= be the default behavior of every mail system (but I suspect isn't the = default behavior of any, although I heard Google was contemplating doing = something like this). -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14491973233290.9587844042107463 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWYP8LCRAMw8Nu0HeKywAAWPEIAMpMUy91YQa6czyE0X5d egXk4FdjirPaRfE9PMvTrlm9RshG0v9mEa3yqu55QPMCLCCAJN0yggD2SjfC Pu8cwzu7r7wUEv/9L6DhA2gbNBF83E7knQeEA/STWo1JZcnEx9aJCLGdjdjq SegR99tOU23w95+Fp/Ivy9pylry6Zl5059TvEvHBa4jogoNGnkVjdgeUWuOZ yxDa6tdLQmXwoAp9LkvUznDX0ZJqUycS5aymbZgdXIXgtHnDzKAtRj1ACqtu WzAbVch6P9wAdd2jO+UaGrYypA1LoKGGz54ELNnS2RzTlygSbI0Ot+sJPywI ecelKEAmYQ6SEVao4XZfyFk= =Ow3y -----END PGP SIGNATURE----- ------sinikael-?=_1-14491973233290.9587844042107463-- From nobody Thu Dec 3 20:22:53 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 538B41B2D14; Thu, 3 Dec 2015 20:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KrmdEXssNrp; Thu, 3 Dec 2015 20:22: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 7A8341B2D13; Thu, 3 Dec 2015 20:22:49 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14492029664600.627680711215362" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <87a8pq98m3.fsf@hope.eyrie.org> References: <5660F3A1.7060807@mustelids.ca> <1449195108085-9ef6f394-96f931b3-20b99bd2@fugue.com> <87k2ov7xly.fsf@hope.eyrie.org> <1449196775597-73137a19-d32873ba-cad85c2a@fugue.com> <87a8pq98m3.fsf@hope.eyrie.org> Date: Fri, 04 Dec 2015 04:22:46 +0000 Message-Id: <1449202966785-573af732-876dd2d9-16d51672@fugue.com> MIME-Version: 1.0 Archived-At: Cc: ietf-smtp@ietf.org Subject: Re: [Shutup] [ietf-smtp] Levels of proposals 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: Fri, 04 Dec 2015 04:22:52 -0000 ------sinikael-?=_1-14492029664600.627680711215362 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thursday, Dec 3, 2015 10:48 PM Russ Allbery wrote: >> I am still a bit puzzled: how does increasing the number of attackers >> help to bypass the throttling mechanism=3F Why isn't the throttle per >> id/password pair, rather than per ip-address/password/id triple=3F >=20 > Why would you throttle per id/password pair=3F The attacker doesn't try = the > same pair more than once. That would be pointless. I think you missed the distinction I was making. You are describing = throttling per ip-address, irrespective of the password/id pair. I am = asking why you don't simply say =22if more than 10 attempts are made on = this username per hour, lock it out for a while.=22 This is a common = practice on some web sites. If you require the user to have a = non-dictionary password, then 10 attempts per hour is few enough to prevent= a botnet of any number of hosts from guessing that password. > The TLDR in case something about that message was confusing is that only > the authentication point can block the IP addresses at the = authentication > point, but you can analyze Received headers to do a bunch of other things= , > such as determine compromised botnet IP addresses that someone else > *didn't* block but that you *do* want to block for *your* service. It > improves the scale and flexibility of what you can do by basically = giving > you more threat intelligence. Yes, I have heard that before. It makes sense. However, it does make me = wonder why you don't just stop accepting mail from sites that are this = badly run until they shape up. You seem to be suggesting that it's = because you value the intelligence that you glean from their incompetence. = Did I misunderstand=3F -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14492029664600.627680711215362 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWYRUWCRAMw8Nu0HeKywAALpYIAKiUOQ1UGJBvhy2n0ayD MhmO7Xrw6JblCyYb2RDMAvP8Dnr+qQIPseFjD3GpI6t1/WFKuGc+MivmU5N8 e3ji6+RQxBPG1sjBB1YBDY/7ZReBXJo+PjjiSDl7i13nZc4s2hdbZJHOYzhI IEeTcuMZSUe4bpZqHB+Zhocr/Yb4v7uBNsV3CgrxoVXzMQCxfC8miosdRZmS /m2ka8z/KSDMFenOt7pFVgwvxXXQrGsPHYBZ04HIf0xXLOesys8UX2J7aHhj cinHu0EGJcqKO49KxCo1eZLLqlb2PlgjsyayjEu04HROFaLsAPYmNUEyE/Gf oeclhcNKBwZ00gZRdsqsds0= =zIis -----END PGP SIGNATURE----- ------sinikael-?=_1-14492029664600.627680711215362-- From nobody Fri Dec 4 00:11: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 F08271B29F7; Thu, 3 Dec 2015 18:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpwNblknnlDM; Thu, 3 Dec 2015 18:31:57 -0800 (PST) Received: from haven.eyrie.org (haven.eyrie.org [166.84.7.159]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 018021B29F6; Thu, 3 Dec 2015 18:31:56 -0800 (PST) Received: from lothlorien.eyrie.org (unknown [96.90.234.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by haven.eyrie.org (Postfix) with ESMTPS id 62FDD11821C; Thu, 3 Dec 2015 18:31:55 -0800 (PST) Received: by lothlorien.eyrie.org (Postfix, from userid 1000) id A8A16B40739; Thu, 3 Dec 2015 18:31:53 -0800 (PST) From: Russ Allbery To: Ted Lemon In-Reply-To: <1449195108085-9ef6f394-96f931b3-20b99bd2@fugue.com> (Ted Lemon's message of "Fri, 04 Dec 2015 02:11:47 +0000") Organization: The Eyrie References: <5660F3A1.7060807@mustelids.ca> <1449195108085-9ef6f394-96f931b3-20b99bd2@fugue.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) Date: Thu, 03 Dec 2015 18:31:53 -0800 Message-ID: <87k2ov7xly.fsf@hope.eyrie.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: X-Mailman-Approved-At: Fri, 04 Dec 2015 00:11:43 -0800 Cc: shutup@ietf.org, ietf-smtp@ietf.org Subject: Re: [Shutup] [ietf-smtp] Levels of proposals 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: Fri, 04 Dec 2015 02:31:59 -0000 Ted Lemon writes: > Thursday, Dec 3, 2015 9:00 PM Chris Lewis wrote: >> If you have a list of IPs known to be infected with AUTH-cracking >> spambots, it's of immediate/valuable use to both the MSAs themselves in >> detecting malicious injects, as well as the recipient's filtering, and >> header forgery is not an issue (certainly not to MSAs, and headers that >> forge collisions with the list you don't want anyway). > Can you unpack "AUTH-cracking spambots" for the greenhorns? I have no > idea what this means, and google unfortunately was unable to help. Standard practice for attackers these days is to automate attacks on any sort of password-protected system, whether that be web pages, authentication providers, or anything else that takes a password. Usually this is done by taking some list of common passwords and some list of account names and just brute-forcing combinations, although some attackers do more sophisticated things. Obviously, that sort of brute force approach is easy to detect and throttle, so the next step in the arms race was for attackers to use large networks of compromised machines, usually home machines behind DSL and cable modem links, each of which tries a small number of passwords against a variety of targets to stay below the radar. Those machines were generally compromised via malware of some kind and are part of a botnet, without the knowledge of the user of the machine. This is used against SMTP AUTH just like it is against anything else on the Internet that takes a password. The usual goal is to send out spam using other people's valid credentials to bypass spam filtering, or to send phishing or stock pump and dump schemes, or what have you. One useful tool in fighting this sort of attack is to be able to collect and share information about currently compromised client IP addresses so that you can detect them as being part of a bot net and use much more aggressive rate limiting on these sorts of attempts, or block any email that they successfully sent after cracking someone's SMTP AUTH password. -- Russ Allbery (eagle@eyrie.org) From nobody Fri Dec 4 00:11: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 8B3ED1B2C8B; Thu, 3 Dec 2015 19:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfHyh-5uZBX4; Thu, 3 Dec 2015 19:48:55 -0800 (PST) Received: from haven.eyrie.org (haven.eyrie.org [IPv6:2001:470:30:84:e276:63ff:fe62:3539]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25B61B2C89; Thu, 3 Dec 2015 19:48:55 -0800 (PST) Received: from lothlorien.eyrie.org (unknown [96.90.234.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by haven.eyrie.org (Postfix) with ESMTPS id DE9C81186F0; Thu, 3 Dec 2015 19:48:53 -0800 (PST) Received: by lothlorien.eyrie.org (Postfix, from userid 1000) id 598B7B40739; Thu, 3 Dec 2015 19:48:52 -0800 (PST) From: Russ Allbery To: Ted Lemon In-Reply-To: <1449196775597-73137a19-d32873ba-cad85c2a@fugue.com> (Ted Lemon's message of "Fri, 04 Dec 2015 02:39:35 +0000") Organization: The Eyrie References: <5660F3A1.7060807@mustelids.ca> <1449195108085-9ef6f394-96f931b3-20b99bd2@fugue.com> <87k2ov7xly.fsf@hope.eyrie.org> <1449196775597-73137a19-d32873ba-cad85c2a@fugue.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) Date: Thu, 03 Dec 2015 19:48:52 -0800 Message-ID: <87a8pq98m3.fsf@hope.eyrie.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: X-Mailman-Approved-At: Fri, 04 Dec 2015 00:11:43 -0800 Cc: shutup@ietf.org, ietf-smtp@ietf.org Subject: Re: [Shutup] [ietf-smtp] Levels of proposals 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: Fri, 04 Dec 2015 03:48:57 -0000 Ted Lemon writes: > I am still a bit puzzled: how does increasing the number of attackers > help to bypass the throttling mechanism? Why isn't the throttle per > id/password pair, rather than per ip-address/password/id triple? Why would you throttle per id/password pair? The attacker doesn't try the same pair more than once. That would be pointless. Let me try explaining this from a different direction. Suppose you are an attacker. You have a list of 10,000 common account names, and a list of 10,000 common passwords. You want to try each of those passwords with each of those account names and try to find a combination that works. If you connect from your compromised host and start plowing through the 100 million combinations, after the first few thousand that you try from that host any decent authentication system will go "hey, there are tons of failed authentications from this one IP address" and block all further attempts, successful or not, from that IP address. That's pretty easy to implement. So what the attacker does instead is use their botnet of a million compromised personal computers (that's sadly not really an exaggeration), and has each one of those hosts try 100 combinations and then disconnect. This is now below (or at least near) the threshold for an actual customer typoing their address or password or something, and rate limiting becomes fairly useless as a defense. > Secondarily, if distributed processing makes throttling per id/password > pair difficult, why is it hard to do the botnet IP address matching at > the authentication point? This seems like it would avoid a _lot_ of > extra processing. Chris addressed this quite well in his message. I don't really have much to add to what he already said. The TLDR in case something about that message was confusing is that only the authentication point can block the IP addresses at the authentication point, but you can analyze Received headers to do a bunch of other things, such as determine compromised botnet IP addresses that someone else *didn't* block but that you *do* want to block for *your* service. It improves the scale and flexibility of what you can do by basically giving you more threat intelligence. -- Russ Allbery (eagle@eyrie.org) From nobody Fri Dec 4 00:11:47 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 45D9B1B2CD4; Thu, 3 Dec 2015 20:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBhLO73GUIya; Thu, 3 Dec 2015 20:24:41 -0800 (PST) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9511E1B2C51; Thu, 3 Dec 2015 20:24:41 -0800 (PST) Received: from [192.168.1.241] (ool-4571974e.dyn.optonline.net [69.113.151.78]) by mailbackend.panix.com (Postfix) with ESMTPA id 66CE0174F4; Thu, 3 Dec 2015 23:24:40 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <565FBDE6.8020001@mustelids.ca> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <57B818513A0069189BA3CF41@JcK-HP8200.jck.com> <1449014394167-7d2dec58-2c6a9ae8-33fc8e7a@fugue.com> <565E4CCF.3080901@mustelids.ca> <565E4FEC.2000607@cs.tcd.ie> <565FBDE6.8020001@mustelids.ca> X-Mailer: Eudora for Mac OS X 6.2.4 (MacOS 10.5.8) Date: Thu, 3 Dec 2015 23:14:21 -0500 To: Chris Lewis From: "Robert A. Rosenberg" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Archived-At: X-Mailman-Approved-At: Fri, 04 Dec 2015 00:11:43 -0800 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: Fri, 04 Dec 2015 04:24:43 -0000 At 22:58 -0500 on 12/02/2015, Chris Lewis wrote about Re: [ietf-smtp] [Shutup] Proposed Charter for the "SMTP Hea: >Trying to "measure" the result of training is usually futile, >because correctly posing the questions, and getting useful answers >is equally complicated and fraught with definitional/terminology >problems. I groan whenever these surveys are published, because the >questions are badly crafted, the answers irrelevant, the >interpretation is completely out to lunch, and the media scrambles >it unrecognizeably Then there is the issue of "Push Polls" were the questions and/or responses to select from are deliberately designed to insure that you get the desired results you want since it is impossible to get any other result. From nobody Fri Dec 4 00:11:49 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 282A11B2DAE; Thu, 3 Dec 2015 20:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_KCiTZvYOeA; Thu, 3 Dec 2015 20:53:36 -0800 (PST) Received: from haven.eyrie.org (haven.eyrie.org [IPv6:2001:470:30:84:e276:63ff:fe62:3539]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F281B2DAD; Thu, 3 Dec 2015 20:53:36 -0800 (PST) Received: from lothlorien.eyrie.org (unknown [96.90.234.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by haven.eyrie.org (Postfix) with ESMTPS id 002A711874D; Thu, 3 Dec 2015 20:53:34 -0800 (PST) Received: by lothlorien.eyrie.org (Postfix, from userid 1000) id DEFFDB40739; Thu, 3 Dec 2015 20:53:32 -0800 (PST) From: Russ Allbery To: Ted Lemon In-Reply-To: <1449202966785-573af732-876dd2d9-16d51672@fugue.com> (Ted Lemon's message of "Fri, 04 Dec 2015 04:22:46 +0000") Organization: The Eyrie References: <5660F3A1.7060807@mustelids.ca> <1449195108085-9ef6f394-96f931b3-20b99bd2@fugue.com> <87k2ov7xly.fsf@hope.eyrie.org> <1449196775597-73137a19-d32873ba-cad85c2a@fugue.com> <87a8pq98m3.fsf@hope.eyrie.org> <1449202966785-573af732-876dd2d9-16d51672@fugue.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) Date: Thu, 03 Dec 2015 20:53:32 -0800 Message-ID: <874mfy95mb.fsf@hope.eyrie.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: X-Mailman-Approved-At: Fri, 04 Dec 2015 00:11:43 -0800 Cc: shutup@ietf.org, ietf-smtp@ietf.org Subject: Re: [Shutup] [ietf-smtp] Levels of proposals 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: Fri, 04 Dec 2015 04:53:39 -0000 Ted Lemon writes: > Thursday, Dec 3, 2015 10:48 PM Russ Allbery wrote: >> Why would you throttle per id/password pair? The attacker doesn't try >> the same pair more than once. That would be pointless. > I think you missed the distinction I was making. You are describing > throttling per ip-address, irrespective of the password/id pair. I am > asking why you don't simply say "if more than 10 attempts are made on > this username per hour, lock it out for a while." Oh, you didn't mean throttle by id/password pair. You meant throttle purely by user ID. There are two reasons (well, at least -- maybe more) why this doesn't help as much as it sounds like it would, particularly in the case of SMTP AUTH. One is that the attacker just changes the pattern of their brute force search to distribute it across more known accounts or across more time, so they just probe more accounts with fewer passwords. It's all the same to them; they're just doing a combinatoric search, and varying parameters that way doesn't have too negative of an impact on their ability to compromise accounts. Another reason is more specific to SMTP AUTH: dozens of incorrect login attempts for the same username is a common *legitimate* pattern for users who have a single misconfigured device (a typo in their password, for instance. (And thanks to cell phones, those failed logins often come from a huge variety of IP addresses.) SMTP UAs often retry authentication pretty aggressively and will happily look like an attacker. If you lock an account for that pattern, you can lock out that user's other legitimate devices. Web sites usually don't have to worry as much about automated incorrect legitimate login attempts. Now, you can do more complex things like checking whether the failures are all the same password or are different passwords; I'm not saying there aren't multiple approaches here. My point, rather, is that figuring out what IP addresses are probably part of botnets is really useful and not something to be casually discarded as additional information for your abuse prevention. This example is obviously simplified in an attempt to answer your original question, since you said you were wholly ignorant of this whole area of abuse handling. Real-world scenarios get more complicated and involve more complex parameters to rate limiting and ways of figuring out what's going on. The point is that threat intelligence about compromised IPs is really useful input into those systems, and that can be garnered from spam email Received headers in some fairly effective ways, as touched on by Chris in his original message. Note that this sort of thing (login abuse detection) is something for which many companies employ an entire team of full-time people devoted to nothing but this. Those people use all the relevant tools that they can get their hands on because this is an arms race against quite sophisticated attackers. I was (mostly successfully) staying out of this thread, but one other comment I'll make while I'm here: I suspect a lot of people who work on email abuse detection and mail filtering would make the argument that they care just as greatly about user privacy as you do, but consider phishing attacks a much more serious threat to the privacy of the average user than the information that leaks out in email headers. It's one thing to get a user's home address; it's quite another to get all of their bank information and access to their personal email. Obviously none of us want those two goals to be in conflict, but please remember that spam filtering is also *phishing* filtering, and therefore is *also* privacy defense for users, and quite important privacy defense at that. > Yes, I have heard that before. It makes sense. However, it does make > me wonder why you don't just stop accepting mail from sites that are > this badly run until they shape up. You seem to be suggesting that it's > because you value the intelligence that you glean from their > incompetence. Did I misunderstand? Yes, in a couple of ways. For one, just deciding to ban whole sending sites from your email system and saying tough luck if someone at that site wants to mail you is the sort of thing that you can do if you're running a hobbyist or personal mail service. When you have a large-scale email system for paying customers, it turns out that those customers are unimpressed by your decision to not let specific people talk to them because you don't like how they run their mail system. Or, similarly, if you're running a large-scale mail system for a company, deciding that your sales people don't get to hear from certain prospects, or that your business people simply don't get to talk to certain domains, based on your opinions about their email policy doesn't go over well. You have to be pretty damn sure that the sending site is 100% garbage before you can do things like that, as opposed to something more sophisticated. For another, I think you're missing that can garner useful information from the Received headers of messages that you *reject*. You can accept the whole message body first and then reject it or throw it away. If you're pretty sure for other reasons that this collection of a few million messages are all spam or phishing, analyzing the headers of those messages to pull out patterns like, say, a list of submission IP addresses and then using that IP addresses as an additional data point in analyzing more borderline messages, or as a set of IP addresses for which to do additional login throttling for your own authentication systems, can be very helpful. Chris had some concrete numbers in his original message. -- Russ Allbery (eagle@eyrie.org) From nobody Fri Dec 4 00:11:50 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 2274F1B2DCA; Thu, 3 Dec 2015 21:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30W0tMfaAcnW; Thu, 3 Dec 2015 21:03:50 -0800 (PST) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDFE01B2DC8; Thu, 3 Dec 2015 21:03:50 -0800 (PST) Received: from [192.168.1.241] (ool-4571974e.dyn.optonline.net [69.113.151.78]) by mailbackend.panix.com (Postfix) with ESMTPA id A17971720E; Fri, 4 Dec 2015 00:03:49 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <1449197323648-4e74dacc-8bacef9a-217d6196@fugue.com> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <57B818513A0069189BA3CF41@JcK-HP8200.jck.com> <1449014394167-7d2dec58-2c6a9ae8-33fc8e7a@fugue.com> <565E4CCF.3080901@mustelids.ca> <20151202032522.GB12713@gsp.org> <1449027304809-2b32a944-6d383650-49f2a64c@fugue.com> <20151202225124.GA18695@gsp.org> <1449197323648-4e74dacc-8bacef9a-217d6196@fugue.com> X-Mailer: Eudora for Mac OS X 6.2.4 (MacOS 10.5.8) Date: Thu, 3 Dec 2015 23:53:10 -0500 To: Ted Lemon From: "Robert A. Rosenberg" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Archived-At: X-Mailman-Approved-At: Fri, 04 Dec 2015 00:11:43 -0800 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: Fri, 04 Dec 2015 05:03:52 -0000 At 02:48 +0000 on 12/04/2015, Ted Lemon wrote about Re: [ietf-smtp] [Shutup] Proposed Charter for the "SMTP Hea: >Thursday, Dec 3, 2015 9:39 PM Robert A. Rosenberg wrote: >> If the message is HTML, then putting a 1x1 web-bug image in the >>HTML will trigger the info UNLESS the user's MUA is set to NOT >>automatically retrieve images. > >That retrieving images is the default behavior of most MUAs, and >that it is even possible to do without cryptographically validating >the ID of the sender in _any_ MUA, is an example of what I am >talking about when I say that UI design is vitally important to >protecting users' privacy. > >Obviously if you have an MUA that behaves so stupidly, then your >privacy is forfeit. At present, that's most MUAs. This is >something that I hope MUA implementors will wise up to, and we ought >to be advising them to if we aren't already. As you can see from my X-Mailer header (which BTW [since we are talking about leaking info] leaks the fact that I am using a Mac and what MacOS Version I am running) I use Eudora. One of its settings (which I have set) tells the MUA to NOT fetch images and to wait until I click on the image icon to replace the icon with the actual image. Thus I see the icon whenever I am sent a Web-Bug in lieu of the bug calling home. From nobody Fri Dec 4 05:11: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 564E01B3149; Fri, 4 Dec 2015 05:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.043 X-Spam-Level: *** X-Spam-Status: No, score=3.043 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIx97EAxfqPz; Fri, 4 Dec 2015 05:11:01 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BEC91B3147; Fri, 4 Dec 2015 05:11:01 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB4DAw7H020750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 4 Dec 2015 08:10:59 -0500 To: shutup@ietf.org References: <5660F3A1.7060807@mustelids.ca> <1449195108085-9ef6f394-96f931b3-20b99bd2@fugue.com> From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <566190E2.9090301@mustelids.ca> Date: Fri, 4 Dec 2015 08:10:58 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <1449195108085-9ef6f394-96f931b3-20b99bd2@fugue.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: ietf-smtp@ietf.org Subject: Re: [Shutup] [ietf-smtp] Levels of proposals 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: Fri, 04 Dec 2015 13:11:02 -0000 On 12/03/2015 09:11 PM, Ted Lemon wrote: > Can you unpack "AUTH-cracking spambots" for the greenhorns? I have no idea what this means, and google unfortunately was unable to help. Primarily botnets that connect to MSAs and use stolen (or potentially brute-forced) userid/password credentials in order to use the MSA/MTA combo as an open relay. There's at least one major windows executable botnet that does this in very high volumes. This is a particularly long-standing botnet that has many other nasty tricks at its disposal (DDOS, keystroke harvesting, account stealing etc). There are several web server compromises that do the same thing, potentially using the same sources for compromised userid/passwords, tho, these aren't nearly the volume as the aforementioned botnet. It's really quite surprising how successful that some spam campaigns are in doing this, and I can only imagine that at least part of it is the botnet dredging out an infected user's MSA/userid/password triple from their mail reader and propagating it to the rest of the botnet (along with harvesting address books), and hence have enormous numbers of compromised accounts to exploit. They may also be using more generic userid/password dumps from online site leaks. We've seen ISPs subject to massive attacks where hundreds or thousands (or more) of different IPs do authenticated MSA submissions of 10s or 100s of thousands of spams in fairly short (hours) intervals, resulting in traffic flows 100s of times above normal to the point of overloading the ISP's MSAs. This is even with quite aggressive per-user and per-IP rate limiting. AUTH-cracking to this extent is a relatively recent phenomena, and is clearly being used as an attempt to bypass normal direct-2-MX botnet blocking and hijack the reputation of the MTA instead of some random cracked PC. From nobody Fri Dec 4 05:27:03 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 290C61B317E; Fri, 4 Dec 2015 05:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.364 X-Spam-Level: * X-Spam-Status: No, score=1.364 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, MISSING_HEADERS=1.021, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBmFdDESbOg7; Fri, 4 Dec 2015 05:26:59 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1167E1B317D; Fri, 4 Dec 2015 05:26:58 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB4DQveQ023726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 4 Dec 2015 08:26:57 -0500 References: <5660F3A1.7060807@mustelids.ca> <1449195108085-9ef6f394-96f931b3-20b99bd2@fugue.com> <87k2ov7xly.fsf@hope.eyrie.org> <1449196775597-73137a19-d32873ba-cad85c2a@fugue.com> <87a8pq98m3.fsf@hope.eyrie.org> From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <566194A1.9010901@mustelids.ca> Date: Fri, 4 Dec 2015 08:26:57 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <87a8pq98m3.fsf@hope.eyrie.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: shutup@ietf.org, ietf-smtp@ietf.org Subject: Re: [Shutup] [ietf-smtp] Levels of proposals 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: Fri, 04 Dec 2015 13:27:00 -0000 On 12/03/2015 10:48 PM, Russ Allbery wrote: > Ted Lemon writes: > >> I am still a bit puzzled: how does increasing the number of attackers >> help to bypass the throttling mechanism? Why isn't the throttle per >> id/password pair, rather than per ip-address/password/id triple? > So what the attacker does instead is use their botnet of a million > compromised personal computers (that's sadly not really an exaggeration), > and has each one of those hosts try 100 combinations and then disconnect. > This is now below (or at least near) the threshold for an actual customer > typoing their address or password or something, and rate limiting becomes > fairly useless as a defense. Hi Russ, it's been a long time since we last were in the same place (physically or otherwise ;-) One of the most depressing indicators I've seen is watching thousands of different IPs only attempt one or two submissions, and not trying again EVEN THO both submissions succeeded and none failed. Secondly, we have full instrumentation, and the passwords they're trying are pretty obviously not "common password" dictionaries or brute-forcing attempts. Clearly they're not lacking in compromised accounts. So, the problem is much larger than "brute force or common password dictionaries" >> Secondarily, if distributed processing makes throttling per id/password >> pair difficult, why is it hard to do the botnet IP address matching at >> the authentication point? This seems like it would avoid a _lot_ of >> extra processing. > Chris addressed this quite well in his message. I don't really have much > to add to what he already said. Yeah, it's obvious that the authentication point is the best place to do it, but the reality is that most of them don't (we're working on that), so... > The TLDR in case something about that message was confusing is that only > the authentication point can block the IP addresses at the authentication > point, but you can analyze Received headers to do a bunch of other things, > such as determine compromised botnet IP addresses that someone else > *didn't* block but that you *do* want to block for *your* service. It > improves the scale and flexibility of what you can do by basically giving > you more threat intelligence. you have to do it for them so that _you_ can block what they should have and didn't. Furthermore, intelligent botnet operators will aim their cannons away from the sites successful at MSA-blocking to the ones who aren't. From nobody Fri Dec 4 05:46:57 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 61BEF1A700F; Fri, 4 Dec 2015 05:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.364 X-Spam-Level: * X-Spam-Status: No, score=1.364 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, MISSING_HEADERS=1.021, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9K4eNc3YQxd; Fri, 4 Dec 2015 05:46:53 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 062E61B319A; Fri, 4 Dec 2015 05:46:52 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB4DkpHK029695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 4 Dec 2015 08:46:51 -0500 References: <5660F3A1.7060807@mustelids.ca> <1449195108085-9ef6f394-96f931b3-20b99bd2@fugue.com> <87k2ov7xly.fsf@hope.eyrie.org> <1449196775597-73137a19-d32873ba-cad85c2a@fugue.com> <87a8pq98m3.fsf@hope.eyrie.org> <1449202966785-573af732-876dd2d9-16d51672@fugue.com> <874mfy95mb.fsf@hope.eyrie.org> From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <5661994B.8030706@mustelids.ca> Date: Fri, 4 Dec 2015 08:46:51 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <874mfy95mb.fsf@hope.eyrie.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: shutup@ietf.org, ietf-smtp@ietf.org Subject: Re: [Shutup] [ietf-smtp] Levels of proposals 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: Fri, 04 Dec 2015 13:46:54 -0000 On 12/03/2015 11:53 PM, Russ Allbery wrote: > Ted Lemon writes: >> Thursday, Dec 3, 2015 10:48 PM Russ Allbery wrote: > >>> Why would you throttle per id/password pair? The attacker doesn't try >>> the same pair more than once. That would be pointless. > >> I think you missed the distinction I was making. You are describing >> throttling per ip-address, irrespective of the password/id pair. I am >> asking why you don't simply say "if more than 10 attempts are made on >> this username per hour, lock it out for a while." > Oh, you didn't mean throttle by id/password pair. You meant throttle > purely by user ID. > > There are two reasons (well, at least -- maybe more) why this doesn't help > as much as it sounds like it would, particularly in the case of SMTP AUTH. Third and most telling reason: few people know how many valid id/password pairs they already have, and coupled with the large numbers of IPs they also have, and the fact that userid/password pairs often work under multiple services, you can spread the spam across so many IPs and userids that throttling is only useful in some marginal edge cases (even when the throttle levers are in the hands of a certified BOFH). Case in point: less than 10% of our list of auth-cracking IPs is derived from methods useable by MSAs, and those that are derived from MSAs utilize very specialized fingerprinting that has nothing to do with throttles. From nobody Fri Dec 4 07:34:47 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 8E3161A87D2; Fri, 4 Dec 2015 07:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.242 X-Spam-Level: ** X-Spam-Status: No, score=2.242 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDQ0bXI53UUt; Fri, 4 Dec 2015 07:34:44 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C821C1A8857; Fri, 4 Dec 2015 07:30:57 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB4FUtTk029233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 4 Dec 2015 10:30:56 -0500 To: shutup@ietf.org References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <01PTRE1WMUMQ01729W@mauve.mrochek.com> <1448995610381-36d96644-173d7bf5-b94de12d@fugue.com> <565DF2F0.6050207@mustelids.ca> <1449025790038-5861f0d7-9427eca4-6b12d71f@fugue.com> From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <5661B1AF.6060603@mustelids.ca> Date: Fri, 4 Dec 2015 10:30:55 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <1449025790038-5861f0d7-9427eca4-6b12d71f@fugue.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 04 Dec 2015 15:34:45 -0000 On 12/01/2015 10:09 PM, Ted Lemon wrote: > I am very curious to hear your numbers, as long as you explain how you got them. I don't mean explain your spam algorithm--I mean characterize your sample, and explain why you think it's a good sample, and explain your methodology: what you did to the sample for test A versus what you did for test B. Interesting things to do for the test sample to differentiate it from the control sample would be removing the last Received header field entirely (last in sequence, meaning first added), modifying the From clause for example as Stephen Farrell suggested, or simply deleting the From clause but keeping the rest of the last Received header field. The issue here is even describing the methodology of comparing the test sets and the discussion about how it's very difficult to catch the same spam in other ways, reveals altogether too much information for spammers to use. The numbers I've been able to give in these threads should be informative and are about as far as I can go. > BTW, turning off the Received header field testing for a week isn't a valid methodology, since there's no way to control for the rather substantial variation in amounts and types of spam from week to week. Actually, even though I'm not specifically measuring this over long periods of time (because the efficacious is already proven well enough to me and the systems who use the results which is what matters), I could readily provide time-series numbers that take into account that variation and demonstrate the usefulness of the technique. But I don't think it worth the days worth of digging through old log files, and the exposure risk to the measurement infrastructure itself it would take to prove to you that I actually do know what I'm talking about. >> In an ideal world, when everybody here was under NDA, I could give you some of the obvious, compelling and overwhelming evidence. > I don't think you could. You've said enough things that don't actually make sense at this point that I would really need you to show your work, not just give me assurances like the following: Your inability to make sense of what I've said is demonstrative of a lack of operational experience. I don't like "I know, and can't tell you how, trust me" arguments from authority any more than you do. Ironically, most people say I talk far too much. I like explaining things and do a lot of free training in the appropriately secured venues. But sometimes I have no choice. Sorry. If you can tell me what I said doesn't make sense, maybe I could fix those bits. From nobody Fri Dec 4 07:35: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 0365E1A8836; Fri, 4 Dec 2015 07:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ju5UroifkySy; Fri, 4 Dec 2015 07:35:16 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 29CF71A87BD; Fri, 4 Dec 2015 07:32:37 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PTVFEN4Y2O00WLY5@mauve.mrochek.com>; Fri, 4 Dec 2015 07:27:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1449242853; bh=Mcvj/kBPX3zphaCW2WJp6U0tLAYkuHOXwkMsdGSjmeI=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=OO0ZLg8KZnXblnLNzw6KOwnCXJQqNAfioTtd5C8SgdqmsA66+8OJmWJb1SUZct67s 5v29ixTMqQRAeeYgZh+L+3Mh7ho4XH2KkFEWoSH964eg1TPkRYRTRCfeYV/hLH5nMR Rye+9Jemj4XHmZs8JQIAtPw+jrZJTMonUG9udzfo= 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 <01PTUN3IDZ9C018EYG@mauve.mrochek.com>; Fri, 04 Dec 2015 07:27:30 -0800 (PST) Message-id: <01PTVFELDFAC018EYG@mauve.mrochek.com> Date: Fri, 04 Dec 2015 07:17:55 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 03 Dec 2015 20:53:32 -0800" <874mfy95mb.fsf@hope.eyrie.org> References: <5660F3A1.7060807@mustelids.ca> <1449195108085-9ef6f394-96f931b3-20b99bd2@fugue.com> <87k2ov7xly.fsf@hope.eyrie.org> <1449196775597-73137a19-d32873ba-cad85c2a@fugue.com> <87a8pq98m3.fsf@hope.eyrie.org> <1449202966785-573af732-876dd2d9-16d51672@fugue.com> <874mfy95mb.fsf@hope.eyrie.org> To: Russ Allbery Archived-At: Cc: shutup@ietf.org, Ted Lemon , ietf-smtp@ietf.org Subject: Re: [Shutup] [ietf-smtp] Levels of proposals 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: Fri, 04 Dec 2015 15:35:19 -0000 > Oh, you didn't mean throttle by id/password pair. You meant throttle > purely by user ID. An important reason not to have a pure user ID block is it provides an easy way to block someone's access to their email: Simply set up a system to constantly bang on their account with the wrong password, and they're effectively locked out. An alternative is a pure user ID slowdown (as opposed to a complete block), but there are limits to how effective this can be. Bad guys can afford to be patient whereas legitimate clients time out pretty quickly, turning a slowdown back into a block. > There are two reasons (well, at least -- maybe more) why this doesn't help > as much as it sounds like it would, particularly in the case of SMTP AUTH. > One is that the attacker just changes the pattern of their brute force > search to distribute it across more known accounts or across more time, so > they just probe more accounts with fewer passwords. It's all the same to > them; they're just doing a combinatoric search, and varying parameters > that way doesn't have too negative of an impact on their ability to > compromise accounts. > Another reason is more specific to SMTP AUTH: dozens of incorrect login > attempts for the same username is a common *legitimate* pattern for users > who have a single misconfigured device (a typo in their password, for > instance. (And thanks to cell phones, those failed logins often come from > a huge variety of IP addresses.) SMTP UAs often retry authentication > pretty aggressively and will happily look like an attacker. If you lock > an account for that pattern, you can lock out that user's other legitimate > devices. Web sites usually don't have to worry as much about automated > incorrect legitimate login attempts. I note that this also applies to IMAP and POP3. In fact the most common case is probably going to be legitimate IMAP clients banging on the door. Sometimes a single client even does it from multiple threads. Ned From nobody Fri Dec 4 08:00: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 16A951A88F3 for ; Fri, 4 Dec 2015 08:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.137 X-Spam-Level: X-Spam-Status: No, score=-101.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 CMIR9lIsini1 for ; Fri, 4 Dec 2015 08:00:11 -0800 (PST) Received: from groups.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D0CDB1A8913 for ; Fri, 4 Dec 2015 08:00:10 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1919; t=1449244804; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=lqCF8+s9oU7bYNzyi7lFCwuqRvU=; b=uf9eeu255jcN08w9b6cS5KQaJGuB6HXaJNMtsOheo2by6hnHZL8NbpzoB8Qq+y 2o4J6AWsLarvnCGBv3BZjhV3akPj2xaQhT9WTkG74GYErLFUVk77wzVmlJygC3D1 8qFdc9+ZWAfjKFYpFumMR0V6RurZDyh8P2QHOVQGlEjbs= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for shutup@ietf.org; Fri, 04 Dec 2015 11:00:04 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1132996886.3357.1700; Fri, 04 Dec 2015 11:00:02 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1919; t=1449244688; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=6uZdf4B qeQ+4wFsOCTW0cKxrCvSVALqhNydXq04DxBI=; b=oG2o9UlC/QxMJSpoDkk+M9Q 8n4Rvt0MnCXvD8qmB7SAQmoNy0MnbfqCFyA3fARRoZNCWd+cb8GO5KATbz+95d4A K7uX5/+6jevh6CplqdweCVh8FcHdsHus+jABgveK24+GhbePJTCjU9nwI/vfsJmd X0atE+TzxMuPeWmXUwNs= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for shutup@ietf.org; Fri, 04 Dec 2015 10:58:08 -0500 Received: from [192.168.1.2] ([99.121.4.202]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 71854243.9.95524; Fri, 04 Dec 2015 10:58:07 -0500 Message-ID: <5661B844.4050605@isdg.net> Date: Fri, 04 Dec 2015 10:59:00 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Chris Lewis , shutup@ietf.org References: <5660F3A1.7060807@mustelids.ca> <1449195108085-9ef6f394-96f931b3-20b99bd2@fugue.com> <566190E2.9090301@mustelids.ca> In-Reply-To: <566190E2.9090301@mustelids.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: ietf-smtp@ietf.org Subject: Re: [Shutup] [ietf-smtp] Levels of proposals 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: Fri, 04 Dec 2015 16:00:13 -0000 On 12/4/2015 8:10 AM, Chris Lewis wrote: > On 12/03/2015 09:11 PM, Ted Lemon wrote: > >> Can you unpack "AUTH-cracking spambots" for the greenhorns? I have >> no idea what this means, and google unfortunately was unable to help. > > Primarily botnets that connect to MSAs and use stolen (or potentially > brute-forced) userid/password credentials in order to use the MSA/MTA > combo as an open relay. > > ... > > AUTH-cracking to this extent is a relatively recent phenomena, and is > clearly being used as an attempt to bypass normal direct-2-MX botnet > blocking and hijack the reputation of the MTA instead of some random > cracked PC. Hi, I'm surprise to read you say this is "relatively recent." Are you mean in months, years or one to several decades? I have seen tons of "auth-cracking/brute force" auth attempts done at all the IP protocol servers. Generally, they do it all in one connection session where a "Maximum Failed Login Attempt" count may is used. I always knew it was possible, but I suppose there are now increased distributed "botnet" forms of this where the Failed Login Attempt Count would be reset at the connection. I have not seen the need to do much because I am not seeing damage. Everything (robust high scale servers) have been in place for many years, you know "Set it and forget it." Overall, having robust 24x7x365 load balancing/control IP tracking/blocking server(s) is par for the course, so this is more about relaxing the STD10/RFC2821/RFC5321.Received SMTP receiver protocol requirement to help avoid mitigate negative correlation methods with ESMTP AUTH, right? Incidentally, what I am seeing more of late, are single or "botnet" IP connections that do nothing, i.e. they sit there idle and they don't attempt to login. What is interesting is that if you (force) close/drop it, they immediately reconnect with the same IP. -- HLS From nobody Fri Dec 4 08:14:52 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 091921A8961; Fri, 4 Dec 2015 08:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.043 X-Spam-Level: *** X-Spam-Status: No, score=3.043 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSd-n0ubv2fG; Fri, 4 Dec 2015 08:14:50 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4A491A8965; Fri, 4 Dec 2015 08:14:41 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB4GEdjM009830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 4 Dec 2015 11:14:39 -0500 To: Ted Lemon , shutup@ietf.org References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <57B818513A0069189BA3CF41@JcK-HP8200.jck.com> <1449014394167-7d2dec58-2c6a9ae8-33fc8e7a@fugue.com> <565E4CCF.3080901@mustelids.ca> <1449024914920-c367c12b-5b2db232-b118a379@fugue.com> <565EB238.6060207@pscs.co.uk> <1449064251263-c451a28b-ba1e4af8-62e69b69@fugue.com> From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <5661BBEF.9020105@mustelids.ca> Date: Fri, 4 Dec 2015 11:14:39 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <1449064251263-c451a28b-ba1e4af8-62e69b69@fugue.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 04 Dec 2015 16:14:51 -0000 On 12/02/2015 08:50 AM, Ted Lemon wrote: ch. > So saying that because people don't care about privacy, we shouldn't try to protect their privacy, is wrong on two counts: Claiming that's the stance of anyone here is wrong on several counts, not least being that a very large part of what we do is specifically aimed at anti-phishing (that "default no strangers" does little for these days, eg: address book spamming), and that's a vastly bigger privacy issue than a Received from clause. The argument is that it's a relatively minor thing, the lack of which has worse privacy/operational and other implications, and there are more significant wins elsewhere. Several years ago, a major anti-abuse industry organization invited a speaker from one of the privacy groups intimately involved with the issue of Syrian expats in the west being online harrassed, stalked and potentially harmed by SEA. I had seen the reports earlier and did a little digging based upon what I could see (albeit rather indirectly, and without any contact with any of the true "point people" in the mess so it would be improper for me to act on my own). The first thing out of his mouth was "I came here prepared with a diatribe about how your entire industry were endangering lives, and to my surprise learned that you were just as concerned about privacy as we are, and we should be treating you as allies". After the end of the talk he was deluged with specific offers of assistance, which I think included taking down one of the sources of it (identified by headers such as the RFC wants to eliminate) I brought up in the Q&A: "Why is this still up?". From nobody Fri Dec 4 08:31:43 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 AC4631A8A4E; Fri, 4 Dec 2015 08:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.242 X-Spam-Level: ** X-Spam-Status: No, score=2.242 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhbtpEWtFJAB; Fri, 4 Dec 2015 08:31:38 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99901A8AAE; Fri, 4 Dec 2015 08:31:37 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB4GVaYE015438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 4 Dec 2015 11:31:36 -0500 To: shutup@ietf.org References: <5660F3A1.7060807@mustelids.ca> <1449195108085-9ef6f394-96f931b3-20b99bd2@fugue.com> <566190E2.9090301@mustelids.ca> <5661B844.4050605@isdg.net> From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <5661BFE8.2070706@mustelids.ca> Date: Fri, 4 Dec 2015 11:31:36 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <5661B844.4050605@isdg.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: ietf-smtp@ietf.org Subject: Re: [Shutup] [ietf-smtp] Levels of proposals 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: Fri, 04 Dec 2015 16:31:38 -0000 On 12/04/2015 10:59 AM, Hector Santos wrote: > On 12/4/2015 8:10 AM, Chris Lewis wrote: >> AUTH-cracking to this extent is a relatively recent phenomena, and is >> clearly being used as an attempt to bypass normal direct-2-MX botnet >> blocking and hijack the reputation of the MTA instead of some random >> cracked PC. > Hi, I'm surprise to read you say this is "relatively recent." Are you > mean in months, years or one to several decades? I should say that "back in the day", SMTP-auth from BOTs was sufficiently rare that it could safely be ignored. SMTP-auth from bot started in a noticable fashion about 2-3 years ago and continuing to rise to extreme levels in the past 6-12 months. To some MSAs, the impacts were obvious before that. To me, this is "relatively recent". Sorry, should have clarified. As a MUCH more recent development, remember "open relay"? That was obsolete 10 years ago, and except for a couple of low volume Chinese spammers, not seen at all. Well, guess what? One extremely prolific spambot started doing it in very high volumes less than a month ago. That's right, spambots attempting to open relay through MTAs. Shipping almost exclusively malware at that. Fun eh? From nobody Fri Dec 4 08:54:34 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 1F0981A8A10; Fri, 4 Dec 2015 08:54:32 -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 DVFCaKbtm_Df; Fri, 4 Dec 2015 08:54:31 -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 F362F1A8A0E; Fri, 4 Dec 2015 08:54:30 -0800 (PST) Received: from [10.45.248.234] ([156.39.10.45]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id tB4GsUDX016876 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 4 Dec 2015 08:54:30 -0800 References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <01PTRE1WMUMQ01729W@mauve.mrochek.com> <1448995610381-36d96644-173d7bf5-b94de12d@fugue.com> <565DF2F0.6050207@mustelids.ca> <1449025790038-5861f0d7-9427eca4-6b12d71f@fugue.com> <5661B1AF.6060603@mustelids.ca> To: shutup@ietf.org From: Dave Crocker X-Enigmail-Draft-Status: N1110 Organization: Brandenburg InternetWorking Message-ID: <5661C55E.8040704@dcrocker.net> Date: Fri, 4 Dec 2015 08:54:54 -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: <5661B1AF.6060603@mustelids.ca> 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]); Fri, 04 Dec 2015 08:54:30 -0800 (PST) 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 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: Fri, 04 Dec 2015 16:54:32 -0000 On 12/4/2015 7:30 AM, Chris Lewis wrote: > On 12/01/2015 10:09 PM, Ted Lemon wrote: > >> I am very curious to hear your numbers, as long as you explain how you >> got them. I don't mean explain your spam algorithm--I mean >> characterize your sample, and explain why you think it's a good >> sample, and explain your methodology: what you did to the sample for >> test A versus what you did for test B. Interesting things to do for >> the test sample to differentiate it from the control sample would be >> removing the last Received header field entirely (last in sequence, >> meaning first added), modifying the From clause for example as Stephen >> Farrell suggested, or simply deleting the From clause but keeping the >> rest of the last Received header field. > > The issue here is even describing the methodology of comparing the test > sets and the discussion about how it's very difficult to catch the same > spam in other ways, reveals altogether too much information for spammers > to use. There's a deeper problem with this line of query. I believe we have reasonable consensus about the facts and about the basic issues, from the various folk who spend fulltime working in this space and have posted to this thread. Hence, queries of the 'show your work' type move into the realm of etended tutorial to non-experts, rather than helping to the vetting of foundational issues for creating a working group. Extended tutorial material is well and good in the right context, but it is not typically considered appropriate for vetting a working group creation effort. Worse, I believe the tutorial exercise has been going on for quite a few days now, which makes it costly, as well as wasteful. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Dec 4 09:51:09 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 8CA211A9044; Fri, 4 Dec 2015 09:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.343 X-Spam-Level: X-Spam-Status: No, score=0.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NE8JwM0-rFtr; Fri, 4 Dec 2015 09:51:05 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DBE81A9032; Fri, 4 Dec 2015 09:51:05 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB4Hp36c007511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 4 Dec 2015 12:51:04 -0500 To: shutup@ietf.org References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <01PTRE1WMUMQ01729W@mauve.mrochek.com> <1448995610381-36d96644-173d7bf5-b94de12d@fugue.com> <565DF2F0.6050207@mustelids.ca> <1449025790038-5861f0d7-9427eca4-6b12d71f@fugue.com> <5661B1AF.6060603@mustelids.ca> <5661C55E.8040704@dcrocker.net> From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <5661D287.4030806@mustelids.ca> Date: Fri, 4 Dec 2015 12:51:03 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <5661C55E.8040704@dcrocker.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 04 Dec 2015 17:51:06 -0000 On 12/04/2015 11:54 AM, Dave Crocker wrote: > Extended tutorial material is well and good in the right context, but it > is not typically considered appropriate for vetting a working group > creation effort. Worse, I believe the tutorial exercise has been going > on for quite a few days now, which makes it costly, as well as wasteful. Yes, you're quite right. Backing up to the original mandate of this discussion: I think it's fairly evident that the draft (and some of the discussions here are venturing into areas outside of the normal scope of IETF work (eg: social policy) and has insufficient practical experience to be adequately informed on how to accomplish the result, let alone the potential consequences from an operational/security/privacy perspective. Work in this area can be immensely useful, but the candidate draft presumes too much and needs substantial re-work, probably to the point of starting over. For example: - Normative "MUST NOT" wording won't work in an IETF non-technical/non-interoperability policy-based supposedly optional choice. - The draft has no understanding that the Received lines and other headers may well have exactly the same information in other than a Received "from clause". IOW: the proposal doesn't come close to addressing the desired outcome. - The draft makes no notice of the privacy, operational or security issues that can be impaired by the lack of such information. IOW: the proposal may well do more harm than good even if only to privacy. Before deciding what the draft should say, let alone before re-work/starting over, we need to have a proper discussion of the pros/cons of doing anything in this space, and if we do decide to do something in this space, identify what protocol details need to be addressed. From nobody Fri Dec 4 10:21:18 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 27C771B2BE3 for ; Fri, 4 Dec 2015 10:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 Wx7niIzLnFQW for ; Fri, 4 Dec 2015 10:21:16 -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 EE5D71B2BCB for ; Fri, 4 Dec 2015 10:21:15 -0800 (PST) Received: (qmail 84564 invoked from network); 4 Dec 2015 18:21:14 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 4 Dec 2015 18:21:14 -0000 Date: 4 Dec 2015 18:20:52 -0000 Message-ID: <20151204182052.40409.qmail@ary.lan> From: "John Levine" To: ietf-smtp@ietf.org, shutup@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: blong@google.com Subject: Re: [Shutup] [ietf-smtp] Levels of proposals 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: Fri, 04 Dec 2015 18:21:17 -0000 >The WG proposal seems to imply taking all IPs out. The discussion has >mostly been about submission. > >It seems to me that there are at least three different IPs used, and some >of these are going to be visible regardless of intent. > >Ie, there is the submission IPs, there are "internal" IPs, and external >ones. > >Submission IPs seem like the largest level of risk, and from my gross >understanding of anti-spam, pretty minor. ... If every mail provider had infrastructure and instrumentation as sophisticated as Google's, that would be more or less true. But it's going to be a long time until we get there. Also, as other people have noted, you can learn a lot from cross correlating what you see, e.g., I see a fair amount of spam from AUTH attackers and it's useful to know where the bot is and see whether the same bots are attacking multiple sites or categories of sites. We certainly have stuff to talk about, but the tradeoffs are a vastly more difficult and subtle than the WG's proponents appear to understand. Chris Newman's counterproposal would be a good place to start. R's, John From nobody Fri Dec 4 11:31:01 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 9A80C1B32B8; Fri, 4 Dec 2015 11:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uh-4iQPx22_Y; Fri, 4 Dec 2015 11:30:59 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 537C81B32B7; Fri, 4 Dec 2015 11:30:59 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PTVNQ7HSS000C3B6@mauve.mrochek.com>; Fri, 4 Dec 2015 11:25:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1449257156; bh=hLP3qZCjs+6bi9MmcTOrt6HgB0xXSqwzEI1Vc78wZIw=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=FX5tTPMkaEvXky+bCDvcZVm+DVmjBLVFntHnBf/p/tu9CRde5H8n5WOUq69ouy7Lt QVWomTsXjKBvT+72u3vQmgP4xMX4gQN1v5IALKhU41oRZuzo5fxo4JJ06wdbRcl6xS bNHUGk3BaaRxDIASUMiYzRtIWSmOVMs0H0gpcFr8= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PTVFL0BHTS018EYG@mauve.mrochek.com>; Fri, 04 Dec 2015 11:25:53 -0800 (PST) Message-id: <01PTVNQ5DSQK018EYG@mauve.mrochek.com> Date: Fri, 04 Dec 2015 11:18:21 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Fri, 04 Dec 2015 11:31:36 -0500" <5661BFE8.2070706@mustelids.ca> References: <5660F3A1.7060807@mustelids.ca> <1449195108085-9ef6f394-96f931b3-20b99bd2@fugue.com> <566190E2.9090301@mustelids.ca> <5661B844.4050605@isdg.net> <5661BFE8.2070706@mustelids.ca> To: Chris Lewis Archived-At: Cc: shutup@ietf.org, ietf-smtp@ietf.org Subject: Re: [Shutup] [ietf-smtp] Levels of proposals 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: Fri, 04 Dec 2015 19:31:00 -0000 > On 12/04/2015 10:59 AM, Hector Santos wrote: > > On 12/4/2015 8:10 AM, Chris Lewis wrote: > >> AUTH-cracking to this extent is a relatively recent phenomena, and is > >> clearly being used as an attempt to bypass normal direct-2-MX botnet > >> blocking and hijack the reputation of the MTA instead of some random > >> cracked PC. > > Hi, I'm surprise to read you say this is "relatively recent." Are you > > mean in months, years or one to several decades? > I should say that "back in the day", SMTP-auth from BOTs was > sufficiently rare that it could safely be ignored. > SMTP-auth from bot started in a noticable fashion about 2-3 years ago > and continuing to rise to extreme levels in the past 6-12 months. To > some MSAs, the impacts were obvious before that. FWIW, our customers are seeing this as well. It used to be that AUTH-cracking on SUBMIT was a nonissue, now it's something you can't safely ignore. I even see it on my home system. It kinds of amazes me that my little box is seen as a target worth spending time banging on, but my logs show ~12,000 password guessing attempts in the last 12 hours. (It's all coming from Hong Kong, the IPs doing it are in the SBL, and it seems to be driven on a generic list of likely account names, not anything more targeted.) > To me, this is "relatively recent". Sorry, should have clarified. > As a MUCH more recent development, remember "open relay"? That was > obsolete 10 years ago, and except for a couple of low volume Chinese > spammers, not seen at all. Well, guess what? One extremely prolific > spambot started doing it in very high volumes less than a month ago. > That's right, spambots attempting to open relay through MTAs. Shipping > almost exclusively malware at that. We're also getting reports of activities that look like attempts to trick MTAs into relay through the use of oddball address formats, some legal, some not. Not sure if this is what you're seeing or not. Ned From nobody Fri Dec 4 11:37: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 3E81F1B32CF; Fri, 4 Dec 2015 11:37:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxnjSXEw8ykS; Fri, 4 Dec 2015 11:37:41 -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 DFCAF1B32CE; Fri, 4 Dec 2015 11:37:39 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14492578569520.5359358440618962" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <5661C55E.8040704@dcrocker.net> References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <01PTRE1WMUMQ01729W@mauve.mrochek.com> <1448995610381-36d96644-173d7bf5-b94de12d@fugue.com> <565DF2F0.6050207@mustelids.ca> <1449025790038-5861f0d7-9427eca4-6b12d71f@fugue.com> <5661B1AF.6060603@mustelids.ca> <5661C55E.8040704@dcrocker.net> Date: Fri, 04 Dec 2015 19:37:36 +0000 Message-Id: <1449257857273-059c8a27-1accf1f5-4d335b6b@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: Fri, 04 Dec 2015 19:37:42 -0000 ------sinikael-?=_1-14492578569520.5359358440618962 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Friday, Dec 4, 2015 11:54 AM Dave Crocker wrote: > Hence, queries of the 'show your work' type move into the realm of > etended tutorial to non-experts, rather than helping to the vetting of > foundational issues for creating a working group. I share your discomfort. However, my concern with the approach of simply = refusing to answer questions on the grounds you state is twofold: first, it= excludes any participation by stakeholders other than anti-spam developers= , and there are other stakeholders. Second, it preserves the status quo, = which is clearly broken. By which I do not mean that you all are not = doing good work: what I mean is that because you are so effective at = minimizing spam, there is no incentive to actually clean up many of the = messes you are working around at the moment. >From my perspective, quite a bit of useful information has already been = shared as a result of this discussion, and it would be nice if that = information were collected somewhere. I think that there's more work to = be done. It may be bothersome to folks who don't feel that these = questions need to be answered, but I don't think it's realistic to think = that if you just protest loudly enough, they will stop getting asked, or = that the practice of header redaction will not become more widespread. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14492578569520.5359358440618962 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWYeuBCRAMw8Nu0HeKywAAX+gH/3Gf9meJEumsHZzmTH5v OSeRtWRWxnIo+lJnM1nDbBWM4C4gUetcOIqmOiPc4FCwapKYHdx0/eU3Mn+q 8hw5LubG7GquyjaCTNADdjBVUiouRXzTqLpBHj6oAWnVZNQ4IAKjkdMAmDUj 2wbcrm87hObqzxys2Hs68R+0BWAPxtHbQzj1CbrsnLCpwy8FCGT1Vvaf5i28 6H2rIZP1iyPqDQAYf8nckbwf6iUdPwfXf12wN6sBXRNC/0lvnX5i5VRRr4wT 1tnRvxriUqtWlKTO2J7NQffjXps17dU/9LQxggG/+ecc4ow11Hlk2u3ABGnx 3g9FuisPKoFpRAxEoBBpo04= =AYTt -----END PGP SIGNATURE----- ------sinikael-?=_1-14492578569520.5359358440618962-- From nobody Fri Dec 4 13:10:22 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 3A8EA1A9028; Fri, 4 Dec 2015 13:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4s_m8EH_iITc; Fri, 4 Dec 2015 13:10: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 B2B6C1A9026; Fri, 4 Dec 2015 13:10:18 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14492634150080.4767314870841801" From: Ted Lemon To: shutup@ietf.org In-Reply-To: <20151204204229.GA7666@gsp.org> References: <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <57B818513A0069189BA3CF41@JcK-HP8200.jck.com> <1449014394167-7d2dec58-2c6a9ae8-33fc8e7a@fugue.com> <565E4CCF.3080901@mustelids.ca> <20151202032522.GB12713@gsp.org> <1449027304809-2b32a944-6d383650-49f2a64c@fugue.com> <20151202225124.GA18695@gsp.org> <1449197323648-4e74dacc-8bacef9a-217d6196@fugue.com> <20151204204229.GA7666@gsp.org> Date: Fri, 04 Dec 2015 21:10:15 +0000 Message-Id: <1449263415342-dfee86d0-8c0f66a7-860d568b@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: Fri, 04 Dec 2015 21:10:21 -0000 ------sinikael-?=_1-14492634150080.4767314870841801 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Friday, Dec 4, 2015 3:42 PM Rich Kulawiec wrote: > 1. Such links are often customized on a per-user per-message basis > with unique URLs. Thus *any* hit on that URL from anywhere must > have come from that user [1] and via that particular message. > It may not disclose their IP address but it *does* disclose that > they read the message and when. This is bad. Yup. You have to always fetch, when the mail arrives. Which could turn = into a DDoS attack if you do it for all messages, so not ideal without = additional heuristics. But I don't see any way around those heuristics = without simply deleting all URLs from all email messages. > 2. Proxying means proxy means proxy log means yet another place where > sensitive information accumulates. I.e., I don't think it's a good idea > to attempt to fix this issue by MITM'ing connections. You already have the whole email message if it's not encrypted, so I don't = see that any additional information is leaking here. But this is still a = good point. > 3. How do you rewrite a link over an encrypted connection=3F If you are running the IMAP server, it doesn't matter whether the = connection between the user and the server is encrypted. If you are not, = then it's not your problem. > I'm not arguing that there isn't a massive privacy problem here. > There is, and I think it's far more worrisome than IP addresses > in Received lines, because it discloses far more information *and it > does so in real time*. I just don't think solving it will be this easy. Agreed on both counts. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14492634150080.4767314870841801 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWYgE3CRAMw8Nu0HeKywAA1Q0IAJdenIYWIZWZRHSdVvLV K675bxuQTr0yQIJ3i2nMQJswdGp7XU5Vv+nDdglT9IGtAm02X+XZdrSwu6Y5 kVMSWI2bFHbUO02Q+4/yvqWSfur8dc5lmtgpzYnvHNr3r3kR9Y/47XK+Oeyh 9EAQXZGDOzpZm2Zw+YQPKsqv5euR2i04wfdiNvc4nWlSoFrVjA/gEC29leaR BfnQDFGpkvnzGg81jvDudNSo2bBykOB1GxODSEEB+Jky0iQiyM/M5C1cEga6 fNH4Ed70IxtxJgIww2Zo7fkPCrMLOuSldFJhaSLL2iBv9nRtPAOyMMKSqJuT /pJnWxmpI8TFAMbgNClF3lA= =kdVP -----END PGP SIGNATURE----- ------sinikael-?=_1-14492634150080.4767314870841801-- From nobody Fri Dec 4 14:19:13 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 B48CE1AC3DF; Fri, 4 Dec 2015 14:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.064 X-Spam-Level: **** X-Spam-Status: No, score=4.064 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, MISSING_HEADERS=1.021, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUzQ4YaIqeGd; Fri, 4 Dec 2015 14:19:11 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D24BB1AC3D8; Fri, 4 Dec 2015 14:19:10 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB4MJ7V6023680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 4 Dec 2015 17:19:08 -0500 References: <5660F3A1.7060807@mustelids.ca> <1449195108085-9ef6f394-96f931b3-20b99bd2@fugue.com> <566190E2.9090301@mustelids.ca> <5661B844.4050605@isdg.net> <5661BFE8.2070706@mustelids.ca> <01PTVNQ5DSQK018EYG@mauve.mrochek.com> From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <5662115B.5040200@mustelids.ca> Date: Fri, 4 Dec 2015 17:19:07 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <01PTVNQ5DSQK018EYG@mauve.mrochek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: shutup@ietf.org, ietf-smtp@ietf.org Subject: Re: [Shutup] [ietf-smtp] Levels of proposals 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: Fri, 04 Dec 2015 22:19:11 -0000 On 12/04/2015 02:18 PM, Ned Freed wrote: > We're also getting reports of activities that look like attempts to trick > MTAs into relay through the use of oddball address formats, some legal, > some not. Not sure if this is what you're seeing or not. What you're describing sounds like old-school open relay trickery. Indeed, what you could be seeing is decade or older open relay testers being used to scan for "buggy" open relay prevention. What I'm seeing isn't that at all. What I see is more like "for everybody I want to spam (address A), pick another address (address B), connect to address B's MX, forge the email to be From: address B, and attempt to get B's MX to relay to address A". However, it's possible that what I'm seeing would shift gears to more obvious trickery if the first attempt failed. It you see the same IP hitting more normal relay rejects before trying the oddball addresses, it could be. If you sent me a log record or received string[s] (off-forum please) I can probably tell for sure. From nobody Fri Dec 4 14:51:24 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 D03831ACD70 for ; Fri, 4 Dec 2015 14:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 2X-uEq9vw8xG for ; Fri, 4 Dec 2015 14:51:20 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADE091ACD78 for ; Fri, 4 Dec 2015 14:51:20 -0800 (PST) Received: by igcto18 with SMTP id to18so46677300igc.0 for ; Fri, 04 Dec 2015 14:51:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1OyIlIU3hJAyZdl6rajbK9EL9JGN0JJihI8Wl3XgX4I=; b=EUf8QR6IWedNshIe/AZqfjOYL8B/QUsBaEpmIOFWjOUltDAGdSEipTtZ90J0TC9Azk NUk3rPiaM5pAdMf2q8D5LyiXxRhpaxxj0OTldESCqAMDu5LAzob90M4Rl7ZTM+/eJROX faJT5IJPdjHaDB38Nceef1AJVWt8ol8uSXVdRylfe1WV7tEJFxv3KY1/ml9GXl1/cP9K Ne7w2OWcesAyq7aRp0Uw5xXotwWxbBrkwcXm/2NU36n0NZd+4mA2FsDHQdpzORR37R2B 7qbwJIdaS8mFYq3+KZQL3+/hniD48VgpRvcf2IPH+CzEHfdfJYyYIDnHiZvGA/2Y2fS/ td9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1OyIlIU3hJAyZdl6rajbK9EL9JGN0JJihI8Wl3XgX4I=; b=PgDWHfw2HD2cbh6pBEe1N/b4r5HibncDpQx225zh/D9f5PMSZmVXy5NmgRVgYOCkwa LL8xKOJJaGYyLa2q/Oum7A8b93I7Bzo2m6Cd4YPU2H8XckL57cuT2gSrZwNSQtGl1Je3 YhqzywblrMHnccB3FJDIXVI+LDFspHCk96N2p5qngmz4BkNsxyTqanIb60cpIKfsuHKd crpGb0sQ/ys/tDIsQn2fpIuEUopeeV8GSSGFpVm9iRQStUpocz5R07suIHtQAShS1B3y JBW/AGqSTrW9h8I+D7seoa/PvT/QAxQ5XJB0LtSpfQuhqvKE/U7/BNnrjwTzkU8uXnlY PWXQ== X-Gm-Message-State: ALoCoQkcR1EGapKZkhfM08g7f40RHrF+QnqIkvvPFMKA/fFPT0mBJznzz3hiThCazyizL8fXaUPD4aXO+zUudXOOA5XkW5PntGraCLc7FrpquBhGLSRoiSc= MIME-Version: 1.0 X-Received: by 10.50.122.100 with SMTP id lr4mr6664613igb.69.1449269479900; Fri, 04 Dec 2015 14:51:19 -0800 (PST) Received: by 10.64.62.14 with HTTP; Fri, 4 Dec 2015 14:51:19 -0800 (PST) In-Reply-To: <5660F3A1.7060807@mustelids.ca> References: <5660F3A1.7060807@mustelids.ca> Date: Fri, 4 Dec 2015 14:51:19 -0800 Message-ID: From: Brandon Long To: Chris Lewis Content-Type: multipart/alternative; boundary=001a11c1f7a489036005261a5847 Archived-At: Cc: shutup@ietf.org, ietf-smtp Subject: Re: [Shutup] [ietf-smtp] Levels of proposals 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: Fri, 04 Dec 2015 22:51:23 -0000 --001a11c1f7a489036005261a5847 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 3, 2015 at 6:00 PM, Chris Lewis wrote: > On 12/03/2015 07:36 PM, Brandon Long wrote: > >> The WG proposal seems to imply taking all IPs out. The discussion has >> mostly been about submission. >> > > The draft has been mostly about submission, but there have been some > conversations about internals. I've seen auditors bring up points about > obscuring internals (corporate context, it's one of their checkoff 10 > commandments), but, we managed to convince them that ease of diagnosing > problems outweighed the downsides. > > Before getting too far into concrete proposals, we still need to decide > whether it should be done, and what (if anything) should be done in > mitigation. > > That said: > > Submission IPs seem like the largest level of risk, and from my gross >> understanding of anti-spam, pretty minor. >> > > Yes, and no... It depends on how you use/acquire them, this is a fairly > complex/esoteric end of spam filtering, and just doing it justice would > take up pages of text. I'll try to short cut - purely from a filtering but > not-ML perspective: > > Using them: > > If you have a list of IPs known to be infected with AUTH-cracking > spambots, it's of immediate/valuable use to both the MSAs themselves in > detecting malicious injects, as well as the recipient's filtering, and > header forgery is not an issue (certainly not to MSAs, and headers that > forge collisions with the list you don't want anyway). > > The potential yields are huge - ISPs (using a list we create of 2.2M IPs > demonstrably capable of AUTH-cracking) can see botnet suppression rates at > the MSA of 80% (of all submissions) or even higher, depending on the > spam/botnet de-jour. In just one case it's in the 1000+/second range. Some > of these botnets are very very prolific per IP. > > Which boils down to the MSAs being able to stop it at source, or the > receivers being able to stop it at destination. If a significant fraction > of MSAs stopped it at source, then, maybe, the MSA Received line isn't > important. But where they don't (the majority), losing the MSA Received > line is potentially a big hit. > > Obtaining them: > > Obviously, someone trying to authenticate to you and is demonstrably > infected isn't spoofable. That yields the vast majority of our list. > > On a case-by-case basis with specialized knowledge it is possible to > derive trustworthy infected submission addresses from received lines. Yes, > actually, it really is. Useful, but not terribly significant (or at least > how far we've followed that rathole). > > By eliminating MSA received clauses, it means that only the MSA can do > blocking based on this technique, the receivers can't. > > On one server, in a 40 minute interval, 774123 out of 1126763 connections > were AUTH spoofing from just one particular botnet. That's 775,000 spams > that ordinary receivers couldn't filter via IP if the from clauses > disappeared. > > Also, if the previous thread's list of large MSPs inclusion of >> submission IPs is correct, then >2 out of the top 3 have already removed >> them (ie, only a fraction of Gmail mail has them at this point). >> > > The top 3 aren't generally large scale botnet spam sources, and botnets > generally don't use real mail servers (except via AUTH crackers), and the > top 3 are amply well instrumented with rate limiters etc. So they really > aren't relevant to this. > We've had to deal with hijacked account spam for years at this point, and have invested heavily against it, and why we are doing our best to sunset "programmatic" password based auth, ie: https://googleonlinesecurity.blogspot.com/2014/04/new-security-measures-will-affect-older.html https://support.google.com/accounts/answer/6010255 Of course, oauth isn't quite ready for widespread adoption, due to issues with discoverability of end-points and software registration. And a botnet may be able to lift the oauth tokens out of the local software, but it has some benefits. Brandon --001a11c1f7a489036005261a5847 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 3, 2015 at 6:00 PM, Chris Lewis <ietf@mustelids.ca>= wrote:
On 12/03/2015 07:36 PM,= Brandon Long wrote:
The WG proposal seems to imply taking all IPs out.=C2=A0 The discussion has=
mostly been about submission.

 The draft has been mostly about submission, but there have been some conver= sations about internals.=C2=A0 I've seen auditors bring up points about= obscuring internals (corporate context, it's one of their checkoff 10 = commandments), but, we managed to convince them that ease of diagnosing pro= blems outweighed the downsides.

Before getting too far into concrete proposals, we still need to decide whe= ther it should be done, and what (if anything) should be done in mitigation= .

That said:

Submission IPs seem like the largest level of risk, and from my gross
understanding of anti-spam, pretty minor.

 Yes, and no...=C2=A0 It depends on how you use/acquire them, this is a fair= ly complex/esoteric end of spam filtering, and just doing it justice would = take up pages of text.=C2=A0 I'll try to short cut - purely from a filt= ering but not-ML perspective:

Using them:

If you have a list of IPs known to be infected with AUTH-cracking spambots,= it's of immediate/valuable use to both the MSAs themselves in detectin= g malicious injects, as well as the recipient's filtering, and header f= orgery is not an issue (certainly not to MSAs, and headers that forge colli= sions with the list you don't want anyway).

The potential yields are huge - ISPs (using a list we create of 2.2M IPs de= monstrably capable of AUTH-cracking) can see botnet suppression rates at th= e MSA of 80% (of all submissions) or even higher, depending on the spam/bot= net de-jour.=C2=A0 In just one case it's in the 1000+/second range. Som= e of these botnets are very very prolific per IP.

Which boils down to the MSAs being able to stop it at source, or the receiv= ers being able to stop it at destination.=C2=A0 If a significant fraction o= f MSAs stopped it at source, then, maybe, the MSA Received line isn't i= mportant.=C2=A0 But where they don't (the majority), losing the MSA Rec= eived line is potentially a big hit.

Obtaining them:

Obviously, someone trying to authenticate to you and is demonstrably infect= ed isn't spoofable.=C2=A0 That yields the vast majority of our list.
On a case-by-case basis with specialized knowledge it is possible to derive= trustworthy infected submission addresses from received lines. Yes, actual= ly, it really is.=C2=A0 Useful, but not terribly significant (or at least h= ow far we've followed that rathole).

By eliminating MSA received clauses, it means that only the MSA can do bloc= king based on this technique, the receivers can't.

On one server, in a 40 minute interval, 774123 out of 1126763 connections w= ere AUTH spoofing from just one particular botnet.=C2=A0 That's 775,000= spams that ordinary receivers couldn't filter via IP if the from claus= es disappeared.

Also, if the previous thread's list of large MSPs inclusion of
submission IPs is correct, then >2 out of the top 3 have already removed=
them (ie, only a fraction of Gmail mail has them at this point).

 The top 3 aren't generally large scale botnet spam sources, and botnets= generally don't use real mail servers (except via AUTH crackers), and = the top 3 are amply well instrumented with rate limiters etc.=C2=A0 So they= really aren't relevant to this.

We= 've had to deal with hijacked account spam for years at this point, and= have invested heavily against it, and why we are doing our best to sunset = "programmatic" password based auth, ie:



O= f course, oauth isn't quite ready for widespread adoption, due to issue= s with discoverability of end-points and software registration.
A= nd a botnet may be able to lift the oauth tokens out of the local software,= but it has some benefits.

Brandon
--001a11c1f7a489036005261a5847-- From nobody Sat Dec 5 10:49:25 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 C0F721B2C4D for ; Sat, 5 Dec 2015 10:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.103 X-Spam-Level: X-Spam-Status: No, score=-100.103 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 tKiwjyKDJB9z for ; Sat, 5 Dec 2015 10:49:17 -0800 (PST) Received: from mail.santronics.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 461251B2C50 for ; Sat, 5 Dec 2015 10:49:16 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5828; t=1449341350; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=eE70q/oURwjnZMxQCLCpY5Xi6J8=; b=uzPwyFT1oFKW/mxWNxfgEV68g+SQD0349TmTw1BdnNeiSRRJjfm2vJX/ucbyrd mHuopV1J/3tw3TXlRANpCFIk1LwsW8ITOy5V163n+Gic78B7zoelBMZ5s6TRWyhc xz0gfiYYHr+mBNE/jeRJLwDVNS/fgCQC7BpyD1d6VR/ZM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for shutup@ietf.org; Sat, 05 Dec 2015 13:49:10 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1229543222.3311.2984; Sat, 05 Dec 2015 13:49:10 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5828; t=1449341236; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=WovVO/5 HTSFYac3bjLy2tgN5+6nppgdfJ+p6Kzq07SQ=; b=RPhfgWBEAOlzUcVhhdHRN/v X8uitmcJ7KUgvwd2YGmwhefmpEpXRe/P7cslHxaBJ0NAivoB3UjlIaXkQMinG0zK 6lJDkMtcqdtgrWPCDA8RPAJ+7jCmLCZ3lFiNAprOVLmPHq6t1t9TAunqNmxlm7r0 VT3D8K4A/iAvmzLcdgj0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for shutup@ietf.org; Sat, 05 Dec 2015 13:47:16 -0500 Received: from [192.168.1.2] ([99.121.4.202]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 168401868.9.95964; Sat, 05 Dec 2015 13:47:15 -0500 Message-ID: <5663316A.3060002@isdg.net> Date: Sat, 05 Dec 2015 13:48:10 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Ted Lemon , shutup@ietf.org References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <01PTRE1WMUMQ01729W@mauve.mrochek.com> <1448995610381-36d96644-173d7bf5-b94de12d@fugue.com> <565DF2F0.6050207@mustelids.ca> <1449025790038-5861f0d7-9427eca4-6b12d71f@fugue.com> <5661B1AF.6060603@mustelids.ca> <5661C55E.8040704@dcrocker.net> <1449257857273-059c8a27-1accf1f5-4d335b6b@fugue.com> In-Reply-To: <1449257857273-059c8a27-1accf1f5-4d335b6b@fugue.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: Sat, 05 Dec 2015 18:49:20 -0000 On 12/4/2015 2:37 PM, Ted Lemon wrote: > Friday, Dec 4, 2015 11:54 AM Dave Crocker wrote: >> Hence, queries of the 'show your work' type move into the realm of >> etended tutorial to non-experts, rather than helping to the vetting of >> foundational issues for creating a working group. > > I share your discomfort. However, my concern with the approach of simply refusing to answer questions on the grounds you state is twofold: first, it excludes any participation by stakeholders other than anti-spam developers, and there are other stakeholders. Second, it preserves the status quo, which is clearly broken. By which I do not mean that you all are not doing good work: what I mean is that because you are so effective at minimizing spam, there is no incentive to actually clean up many of the messes you are working around at the moment. > >>From my perspective, quite a bit of useful information has already been shared as a result of this discussion, and it would be nice if that information were collected somewhere. I think that there's more work to be done. It may be bothersome to folks who don't feel that these questions need to be answered, but I don't think it's realistic to think that if you just protest loudly enough, they will stop getting asked, or that the practice of header redaction will not become more widespread. > Ted, as you know, many packages are quite old and well established -- change is not easy. What is common is that we all need to interop in a consistent and persistent protocol required/expected manner. Without that, it doesn't work well. Sure, it will be nice to read reports on methods, ideas, issues but for the most part much of this has already been covered. So what else is possibly new after 30+ years of world-wide mail industry? If it has been shown that the STD10/RFC2821/RFC5321.Received can be "exploited" in some negative way, then it doesn't really matter what I think, the customer can be potentially harmed and therefore, I am ethically obligated to offer an option to disable, hide or mask the "harmful" information. So what are the ideas for this? In the end, it may come down to changing the standard to say "MAY|SHOULD" instead of "MUST" IFF there is NO evidence of interop issues. We do this all the time with product identification during any internet application protocol connections. For example, for PCI compliance, I have a very large customer whose PCI auditor pushed for the removal of all hosting product id/version identifying information. We made the option to disable available to the customer quickly and for others in the next update. No more support cost issues along those lines whether I thought it as stupid or not. I can say that PCI Auditors can push for (IETF protocol related) technical changes if the customers are hassled by them. We have already begun to see the browser enforcement with the HTTPS only push. We long had a "Single Click PCI Compliance" button to enforces HTTPS and Session Tracking/Time Management. However, most of the time, No one have have an answer for "Compromised User" issues. In that case, all bets are off. Like a "Active Shooter," learn to track it and basically shut the account or force a changing of a password. If the removal of the "Received:" trace line help mitigate a potential exploit, then I would like to see input from people who think it may be also a backward compatibility issue where "useful things" may break. Now that I am thinking about it, I need to see how it could alter our SMTP valid RFC header detector during reception. Technically, we can have Very Simple Mail Transfer Protocol (VSMTP) clients sending mail where the RFC 822/2821/5321 header block MAY NOT be part of the payload (DATA). IOW, you can do see this: C: EHLO mail.fugue.com S: 250 Welcome C: MAIL FROM S: 250 its all good C: RCPT TO: S: 250 continue C: DATA S: 353 What do you have to say? Hi there!. S: 250 Mail Accepted! C: QUIT S: 220 And that MAY be an acceptable transaction because the system will auto-fill or regenerate the required RFC fields or it may not, i.e. for a print or fax job, or if its a local message versus a relay: 5322.From: <--- 5321.MAIL FROM, Required 5322.Date: <--- Current Time Stamp (GMT), Required 5322.To: <--- 5321.RCPT TO, Not Required 5322.Subject: <--- not required At a minimum, most mail readers systems only needed the above fields for the simplest Mail Reader possible. I've written about 5-6 MUAs in my time. However, the regeneration MAY NOT take place if it detects a valid internet email header. So the question now becomes how tight is the SMTP requirements per site? If the site follow strict RFC822, then you require: 822.From: 822.Date: 822.TO or 822.CC If you relaxed it to RFC2822 (which is the same as RFC5322), then only the 5322.From: and 5322.Date: are required. The "To:" was relaxed, not required. Once upon a time there was a I-D Proposal to further relaxed the "5322.From" header from email. If that had happen, DKIM would probably never had been done even though today, many folks would probably not wanted the 5322.From: DKIM binding requirement. Notice how there is a conflict here as well with Received since it also part of the Binding recommendations (but not a requirement). In any case, in our SMTP RFC detector, we also use the the required "Received" line depending on what level of 822/2822/5322 support is enabled. I have to check. So overall, it is not cut and dry about removing a long time "standard" required feature in SMTP. It has to be studied before a recommendation can be made to effectively change a long time standard. -- HLS From nobody Sat Dec 5 21:31: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 AC3C41A8960 for ; Sat, 5 Dec 2015 21:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 4-c4eMhwLjwR for ; Sat, 5 Dec 2015 21:31:09 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F161A8945 for ; Sat, 5 Dec 2015 21:31:09 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id tB65V0Ac024298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 5 Dec 2015 21:31:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1449379867; x=1449466267; bh=iYjIt+ubOrqh5UodMozGfc7src7yk0azDm41K/9/9Dk=; h=Date:To:From:Subject; b=spqF6g9sV1mNQN4XA3sR7kblKCf2H+SQBm2Mq/wcggDw2vUUBkieZg2U9Okqv5bF4 aITv7/+SPqoK+rbu4kF7LoUbWW9+Ap5u7YkEQtyczG73BJ8Sr7cMV5o2XMfH6xh1my n0xwfIxmVlG8zxWtmRHDDNj7k3I1/mDdFUpqUltE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1449379867; x=1449466267; i=@resistor.net; bh=iYjIt+ubOrqh5UodMozGfc7src7yk0azDm41K/9/9Dk=; h=Date:To:From:Subject; b=2Q5Has9evAv3lLskFvIFCHJ0Zjbb58kET6gn1lzeqblU/h4cwovIb758UHL4aEZyz BMxhQSjxmjLdbmD7tJ/nv4InRvmoG+L9lsn70xsKp94xJCxdIP/bDwQvkg1ov0Nf2N biB7TgzAenjOh+oEqBk2qCIxyw3cm/ii7BYbKnIQ= Message-Id: <6.2.5.6.2.20151205205343.0c75fed0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 05 Dec 2015 21:24:50 -0800 To: shutup@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: 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: Sun, 06 Dec 2015 05:31:10 -0000 Hello, I took a look at the proposed charter [1]. The proposed work looks like a Received header field shutup. Is that based on RFC 7624? The discussion in that RFC, specifically Section 3.3.4, focuses on IP addresses. The proposed charter mentions leaking address and timing information. Is that IP addresses? "Header fields in Email messages can reveal private information to an observer that might be used for attacking an organization or an" An attack on organization is a security issue; it isn't a privacy issue. The privacy issue is about mail-related metadata which can be collected by state surveillance agencies. Will the proposed working group attempt to fix that? Regards, -sm 1. http://www.ietf.org/mail-archive/web/shutup/current/msg00001.html From nobody Sat Dec 5 22:34: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 6105B1B3265 for ; Sat, 5 Dec 2015 22:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.043 X-Spam-Level: *** X-Spam-Status: No, score=3.043 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKzFhIMPvIMY for ; Sat, 5 Dec 2015 22:34:56 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD331B3263 for ; Sat, 5 Dec 2015 22:34:56 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB66YrGD005602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 6 Dec 2015 01:34:54 -0500 To: shutup@ietf.org References: <6.2.5.6.2.20151205205343.0c75fed0@elandnews.com> From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <5663D70D.30707@mustelids.ca> Date: Sun, 6 Dec 2015 01:34:53 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <6.2.5.6.2.20151205205343.0c75fed0@elandnews.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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: Sun, 06 Dec 2015 06:34:57 -0000 On 12/06/2015 12:24 AM, SM wrote: > An attack on organization is a security issue; it isn't a privacy > issue. The privacy issue is about mail-related metadata which can be > collected by state surveillance agencies. Will the proposed working > group attempt to fix that? Privacy is only about state surveillance? That seems to be a, um, remarkably narrow definition, and completely ignores the privacy issues that people usually get harmed by. Furthermore, state surveillance doesn't need to scrape headers, they just get the providers to reveal the contents of their logs, which no amount of header obfuscation can hide. The NSA didn't get their 5 years worth of universal phone penlogs from tapping wires, they did it with taps right into the provider's equipment. No amount of on-the-wire fussing would have done a thing. This harks back to a big investigation I was involved with in the late 1970's/early 80's[*], prompted by a huge public uproar over (supposed) LE access to medical information from Canada's (Ontario's) health insurance programme (and later spread to Workman's Compensation). Our investigation showed that there were indeed a few (on the order of a dozen or two) LE-related incidents, and as far as I remember, not one of them involved medical information (they were current address searches in order to serve warrants). The real problem was 3rd party private insurers accessing full medical information of thousands of people (we proved out more than 5000 incidents with one insurer alone) that could result in severe financial or in some cases medical harm. At least one suicide resulted, probably more. Oh, and yes, some of the access claims were entirely bogus (eg: claims of accessing information that didn't and couldn't exist) - made up by people who were happy to lie to the journalists and get their own tiny bits of fame and a few beers. The biggest fault with the charter that there is no mandate whatsoever to explore/mention/define the risks (of either revealing the information or omitting it). I can see a BCP on privacy protection arising out of this effort, but without any serious attempt to give the reader guidance on pro/con, it'll do more harm than good. [*] The Royal Commission of Enquiry into the Confidentiality of Health Records in Ontario. I was the computer security consultant/advisor ro the commission. The first "Krevor Commission". Most Canadians will associate Justice Krevor (Ontario Supreme Court Judge) with the tainted blood Commission years later. We plugged quite a few policy/procedural holes, the Ministry of Health got bruised and battered by it, but survived. A lot of really good things happened from that Commission and carried over to other jurisdictions and even other countries, I'm quite proud of my minor contributions. From nobody Sat Dec 5 22:40:25 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 E45391A0053 for ; Sat, 5 Dec 2015 22:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.043 X-Spam-Level: *** X-Spam-Status: No, score=3.043 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0P3rEuam67k for ; Sat, 5 Dec 2015 22:40:24 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A9721A0033 for ; Sat, 5 Dec 2015 22:40:24 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB66eMWM008275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 6 Dec 2015 01:40:23 -0500 To: shutup@ietf.org References: <6.2.5.6.2.20151205205343.0c75fed0@elandnews.com> From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <5663D856.5050202@mustelids.ca> Date: Sun, 6 Dec 2015 01:40:22 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <6.2.5.6.2.20151205205343.0c75fed0@elandnews.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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: Sun, 06 Dec 2015 06:40:25 -0000 Repeating a point that may have gotten lost in my previous posting. As I see it, the fatal fault in the proposed charter is NO mention whatsoever of exploring/documenting the risks of eliding/not-eliding such information. Whatever document that comes out of this effort has to give the reader reasonable guidance of what the risks are, both from providing the "privacy-dangerous" information, and not providing it. Without it, a provider would not be able to make a reasonable judgment whether they should implement some/all of the recommendations or not. From nobody Sat Dec 5 23:05:34 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 158B11A039D for ; Sat, 5 Dec 2015 23:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1cethyyiDpu for ; Sat, 5 Dec 2015 23:05:28 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id EF45D1A03A6 for ; Sat, 5 Dec 2015 23:05:27 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PTXQAKJTAO0187DS@mauve.mrochek.com> for shutup@ietf.org; Sat, 5 Dec 2015 23:00:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1449385225; bh=yRB+fYkS+98l8dXb46lcGb6m8/CDYFrUBKzmQnQtowI=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=eJhEel0g0PtdCvik9sjB3ha95gpDNLk2vPf3tXUdUl4WuYR5/6jyeDLQPJFZKWg98 keuqYEJYFjFF+eD+JwBUj8fFt4NWPuJw9Ys78/GsH8ZozeB+xJiKyuBkfAoKgPQ278 vLY05Na0Q/9jbgcpqQtQaOu/TlvlUYSNolgftDf0= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PTXOWWZ1GG00HE89@mauve.mrochek.com>; Sat, 05 Dec 2015 23:00:23 -0800 (PST) Message-id: <01PTXQAJ1Y2400HE89@mauve.mrochek.com> Date: Sat, 05 Dec 2015 22:52:17 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sat, 05 Dec 2015 21:24:50 -0800" <6.2.5.6.2.20151205205343.0c75fed0@elandnews.com> References: <6.2.5.6.2.20151205205343.0c75fed0@elandnews.com> To: SM 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: Sun, 06 Dec 2015 07:05:32 -0000 SM writes: > An attack on organization is a security issue; it isn't a privacy > issue. The privacy issue is about mail-related metadata which can be > collected by state surveillance agencies. Will the proposed working > group attempt to fix that? As I pointed out on the perpass list when the Received: field draft was first posted, there are definitely privacy issues associated with Received: fields, but metadata collection by state actors really isn't one of them. Why bother with Received: fields when you can simply collect transaction logs from ISPs/MSPs. And unless I'm missing something, the generation and collection of transaction logs is far beyond the purview of the IETF. Ned From nobody Sat Dec 5 23:49:17 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 27CCA1A1B2B for ; Sat, 5 Dec 2015 23:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] 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 93I-4Z0RdR5f for ; Sat, 5 Dec 2015 23:49:15 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 211CA1A1B29 for ; Sat, 5 Dec 2015 23:49:15 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id tB67n8KW016487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Dec 2015 23:49:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1449388154; x=1449474554; bh=dkoo/jtnU+5oF23YhoK7k3G/1Of4UlMJLX4r1CsU798=; h=Date:To:From:Subject:In-Reply-To:References; b=wpyv3oBfNk7mUqM2QXRg7RZ4FB+83l6wgnnG9XbkEOlneYmABC61WdycEWFXMXIqo VcDnyZ4LwJIRgnL4FTaRYp7ySOc2cwFYKb4pnYXGjAATVm6xrMv5reL7vP9vDjklIv LQwgX8Z9pNldjepLkR+dQKdnOhPSH7iTvi0hdh4c= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1449388154; x=1449474554; i=@resistor.net; bh=dkoo/jtnU+5oF23YhoK7k3G/1Of4UlMJLX4r1CsU798=; h=Date:To:From:Subject:In-Reply-To:References; b=PQ193Sw7SMZuDjGOSBpVYnVqlNYt/cwzwlKzGvEThxFhHhpFECdc2g2YR3J6zOGr+ Z7pXs4dYPGt+SDdX492yJuIIYW5G1W7+ezchhoDLg6OUJ39z9XBWSqyzObzMymtU1o y0w698hzhefbBJYWH8d/cq6EYjEib3zkC7mTWwEU= Message-Id: <6.2.5.6.2.20151205230057.06a26038@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 05 Dec 2015 23:48:52 -0800 To: Chris Lewis , shutup@ietf.org From: SM In-Reply-To: <5663D70D.30707@mustelids.ca> References: <6.2.5.6.2.20151205205343.0c75fed0@elandnews.com> <5663D70D.30707@mustelids.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: 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: Sun, 06 Dec 2015 07:49:16 -0000 Hello, At 22:34 05-12-2015, Chris Lewis wrote: >Privacy is only about state surveillance? That seems to be a, um, >remarkably narrow definition, and completely ignores the privacy >issues that people usually get harmed by. Furthermore, state >surveillance doesn't need to scrape headers, they just get the >providers to reveal the contents of their logs, which no amount of >header obfuscation can hide. It is indeed a narrow definition. I am limiting my discussion of the proposed charter to what has previously been discussed on the perpass mailing list [1] and on this mailing list. It is up to the participant working for provider which was asked to reveal the contents of its logs to argue for including that aspect in the proposed charter if the participant wishes to do so. >The NSA didn't get their 5 years worth of universal phone penlogs >from tapping wires, they did it with taps right into the provider's >equipment. No amount of on-the-wire fussing would have done a thing. That is not mentioned in RFC 7258. >The biggest fault with the charter that there is no mandate >whatsoever to explore/mention/define the risks (of either revealing >the information or omitting it). > >I can see a BCP on privacy protection arising out of this effort, >but without any serious attempt to give the reader guidance on >pro/con, it'll do more harm than good. I am still trying to understand the problem(s) which the proposed working group might work on. I am unable to say anything useful about the above at the moment. Regards, -sm 1. https://www.ietf.org/mail-archive/web/perpass/current/maillist.html From nobody Sun Dec 6 00:26:53 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 06A0D1A9037 for ; Sun, 6 Dec 2015 00:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.043 X-Spam-Level: *** X-Spam-Status: No, score=3.043 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZC3UcnSueQ6 for ; Sun, 6 Dec 2015 00:26:51 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFA371A902A for ; Sun, 6 Dec 2015 00:26:50 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB68Qnjr010295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 6 Dec 2015 03:26:49 -0500 To: shutup@ietf.org References: <6.2.5.6.2.20151205205343.0c75fed0@elandnews.com> <5663D70D.30707@mustelids.ca> <6.2.5.6.2.20151205230057.06a26038@resistor.net> From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <5663F149.7060207@mustelids.ca> Date: Sun, 6 Dec 2015 03:26:49 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <6.2.5.6.2.20151205230057.06a26038@resistor.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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: Sun, 06 Dec 2015 08:26:52 -0000 On 12/06/2015 02:48 AM, SM wrote: > Hello, > At 22:34 05-12-2015, Chris Lewis wrote: >> Privacy is only about state surveillance? That seems to be a, um, >> remarkably narrow definition, and completely ignores the privacy >> issues that people usually get harmed by. Furthermore, state >> surveillance doesn't need to scrape headers, they just get the >> providers to reveal the contents of their logs, which no amount of >> header obfuscation can hide. > > It is indeed a narrow definition. I am limiting my discussion of the > proposed charter to what has previously been discussed on the perpass > mailing list [1] and on this mailing list. It is up to the participant > working for provider which was asked to reveal the contents of its logs > to argue for including that aspect in the proposed charter if the > participant wishes to do so. > >> The NSA didn't get their 5 years worth of universal phone penlogs from >> tapping wires, they did it with taps right into the provider's >> equipment. No amount of on-the-wire fussing would have done a thing. > > That is not mentioned in RFC 7258. I don't see how that matters. Also, as others have remarked, legal/regulatory log access is out-of-scope for the IETF (a legal/regulatory issue not a technical one), so how could RFC7258 mention it? Out of scope is out of scope, whether the provider wants to include it or not. I'll also note that the second page of RFC7258 specifically states: "The motivation for PM can range from non-targeted nation-state surveillance, to legal but privacy-unfriendly purposes by commercial enterprises, to illegal actions by criminals." IOW: if this is about pervasive monitoring (perpass), you can't leave out 2/3rds of the actors (and far more than 2/3rds of the demonstrated risk) and expect to have any useful validity. By limiting us to the actors who don't care about headers, knowing you can't include log access in whether you want to or not, this WG is completely without a purpose. Or was that your point? ;-) From nobody Sun Dec 6 09:36: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 97B611A82E2 for ; Sun, 6 Dec 2015 09:36:37 -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 3_C57wcnOznf for ; Sun, 6 Dec 2015 09:36:35 -0800 (PST) Received: from xsmtp11.mail2web.com (xsmtp11.mail2web.com [168.144.250.181]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6E8D1A854D for ; Sun, 6 Dec 2015 09:36:35 -0800 (PST) Received: from [10.5.2.11] (helo=xmail01.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1a5dEc-00039B-DJ for shutup@ietf.org; Sun, 06 Dec 2015 12:36:34 -0500 Received: (qmail 7974 invoked from network); 6 Dec 2015 17:36:29 -0000 Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail01.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 6 Dec 2015 17:36:29 -0000 From: "Christian Huitema" To: "'Ned Freed'" , "'SM'" References: <6.2.5.6.2.20151205205343.0c75fed0@elandnews.com> <01PTXQAJ1Y2400HE89@mauve.mrochek.com> In-Reply-To: <01PTXQAJ1Y2400HE89@mauve.mrochek.com> Date: Sun, 6 Dec 2015 09:37:14 -0800 Message-ID: <05b301d1304c$bf6f3880$3e4da980$@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: AQKN73fyxiYngre5rqmJ3KfWLrx3QgKRxoaNnTAlxOA= Content-Language: en-us 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: Sun, 06 Dec 2015 17:36:37 -0000 On Saturday, December 5, 2015 10:52 PM, Ned Freed wrote: > SM writes: > > > An attack on organization is a security issue; it isn't a privacy > > issue. The privacy issue is about mail-related metadata which can be > > collected by state surveillance agencies. Will the proposed working > > group attempt to fix that? > > As I pointed out on the perpass list when the Received: field draft was first > posted, there are definitely privacy issues associated with Received: fields, > but metadata collection by state actors really isn't one of them. Why bother > with Received: fields when you can simply collect transaction logs from > ISPs/MSPs. Ned, you are basically saying, "why bother plugging one leak when the same data can leak somewhere else." Well, I think it is actually important to plug all the privacy leaks, much like in security it is important to plug all the holes. You are making the argument that authorities can commandeer data by imposing on mail providers. They can, but in countries with decent rule of laws there are limits, such as requesting probable cause and not going through fishing expeditions. We have seen rogue agencies attempt to bypass these limits by just taking the data whichever way they can, and we want to stop that. We also worry that what these agencies can do today, organized gangs can do tomorrow, and petty criminals after that. The email traces are particular because they are carried to multiple places, not just the submission site but also every relay and every mail recipient. That multiplies the chances of compromise. My email provider has some reason to try maintain my trust, but relays and recipients may not. For me, it makes a great deal of difference whether the information can be obtained from just one place or from many. As I wrote in a previous message, we have a specific problem with the correlation between IP address and user identity. Once that correlation is established, it becomes possible to attribute 5-tuple traces to specific individuals. You may think that the relation between someone's home IP address and their identity is static, but in many case it is not. Some ISP can provide you with addresses that deliberately vary over time. You can use VPN. You can use Wi-Fi hot spots. That's exactly what privacy conscious users do. And that's why I find the listing of submission IP in traces problematic. I understand that there are good use of the information, and that managing email systems is hard. I also understand that the problem is complex. For example, precise timestamp information can be used for debugging and validation. But it can also be used to retrieve the IP address of a message sender, by looking in the 5 tuple traces what addresses were sending packets to the email provider at that time. We need to surface these issues, to understand both the cost of the value of the information, and to propose solutions. -- Christian Huitema > And unless I'm missing something, the generation and collection of > transaction logs is far beyond the purview of the IETF. > > Ned > > _______________________________________________ > Shutup mailing list > Shutup@ietf.org > https://www.ietf.org/mailman/listinfo/shutup From nobody Sun Dec 6 10:45:33 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 7109D1B2A57 for ; Sun, 6 Dec 2015 10:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] 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 kYBc3kl73HBc for ; Sun, 6 Dec 2015 10:45:31 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 569B71B2A55 for ; Sun, 6 Dec 2015 10:45:31 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id tB6IjMai026933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Dec 2015 10:45:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1449427529; x=1449513929; bh=d5aSxel434l+NKw6H0F31+IRZ6PZz4zTpapUcbX91+4=; h=Date:To:From:Subject:In-Reply-To:References; b=hkbH8iEDz+ablEXm7ov97RyQOvouF6IuOIONsXSkiW/RUvUUDiwC1vQXWl+ZFegYn 3MwPqmIUwRv0xK4qMCVOmrk0dsFtovy2jnUlTX/i/wQwq+04D2N6/15PC7wA3AtmgZ qDlLsuL/vF1Su1Dhp6QgupN1DQbRo2MyjgYIDjB8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1449427529; x=1449513929; i=@resistor.net; bh=d5aSxel434l+NKw6H0F31+IRZ6PZz4zTpapUcbX91+4=; h=Date:To:From:Subject:In-Reply-To:References; b=qzutzPZyKa3U4RVe+IIrfxmwKulcN01jmDSsfCB3UYywBBK/SivAjxQUePvsvUADF YOeiyRZVouAJd7tQ1PV5mF+ibqiybdX9WDYI5kHjHNcTaKDdavwZyLNHZzbt7SuNQy rfpA+1Kxx0adcYgj79jslFDLJSzJT/m+Kapfdvck= Message-Id: <6.2.5.6.2.20151206041035.0cc116a8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 06 Dec 2015 05:23:48 -0800 To: Chris Lewis , shutup@ietf.org From: SM In-Reply-To: <5663F149.7060207@mustelids.ca> References: <6.2.5.6.2.20151205205343.0c75fed0@elandnews.com> <5663D70D.30707@mustelids.ca> <6.2.5.6.2.20151205230057.06a26038@resistor.net> <5663F149.7060207@mustelids.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: 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: Sun, 06 Dec 2015 18:45:32 -0000 Hello, At 00:26 06-12-2015, Chris Lewis wrote: >I don't see how that matters. > >Also, as others have remarked, legal/regulatory log access is >out-of-scope for the IETF (a legal/regulatory issue not a technical >one), so how could RFC7258 mention it? Out of scope is out of >scope, whether the provider wants to include it or not. The topic of pervasive surveillance did not gather much interest prior to a few months before RFC 7258 was published. >I'll also note that the second page of RFC7258 specifically states: > >"The motivation for PM can range from non-targeted nation-state >surveillance, to legal but privacy-unfriendly purposes by commercial >enterprises, to illegal actions by criminals." Ok. >IOW: if this is about pervasive monitoring (perpass), you can't >leave out 2/3rds of the actors (and far more than 2/3rds of the >demonstrated risk) and expect to have any useful validity. > >By limiting us to the actors who don't care about headers, knowing >you can't include log access in whether you want to or not, this WG >is completely without a purpose. Or was that your point? ;-) The proposed charter does not mention mail logs. I mentioned pervasive monitoring as there were news articles about email metadata being captured. Looking at this in terms of the text in the proposed charter, it is about what is in the mail headers being transmitted during a SMTP session. The comment [1] which I sent was about that. I am was not limiting that to one or more entities who might be able to collect that information on an international scale or an entity which could collect that on a national scale. I was not trying to make a point about the proposed working group being completely without purpose if log access was out of scope. There were three questions in my initial email to this mailing list. Ned provided some input about the Received header field question [2]. I read his comments about the draft which is mentioned in the proposed charter; the comments were informative. Regards, -sm 1. http://www.ietf.org/mail-archive/web/shutup/current/msg00146.html 2. http://www.ietf.org/mail-archive/web/shutup/current/msg00149.html From nobody Sun Dec 6 11:59: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 5CB0B1A899E for ; Sun, 6 Dec 2015 11:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.043 X-Spam-Level: *** X-Spam-Status: No, score=3.043 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sy0y44hIMLeW for ; Sun, 6 Dec 2015 11:59:57 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C70ED1A899C for ; Sun, 6 Dec 2015 11:59:56 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB6JxsnS007992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 6 Dec 2015 14:59:55 -0500 References: <6.2.5.6.2.20151205205343.0c75fed0@elandnews.com> <01PTXQAJ1Y2400HE89@mauve.mrochek.com> <05b301d1304c$bf6f3880$3e4da980$@huitema.net> From: Chris Lewis X-Enigmail-Draft-Status: N1110 To: shutup@ietf.org Message-ID: <566493BA.8050707@mustelids.ca> Date: Sun, 6 Dec 2015 14:59:54 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <05b301d1304c$bf6f3880$3e4da980$@huitema.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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: Sun, 06 Dec 2015 19:59:58 -0000 On 12/06/2015 12:37 PM, Christian Huitema wrote: > On Saturday, December 5, 2015 10:52 PM, Ned Freed wrote: >> SM writes: >> >>> An attack on organization is a security issue; it isn't a privacy >>> issue. The privacy issue is about mail-related metadata which can be >>> collected by state surveillance agencies. Will the proposed working >>> group attempt to fix that? >> >> As I pointed out on the perpass list when the Received: field draft was > first >> posted, there are definitely privacy issues associated with Received: > fields, >> but metadata collection by state actors really isn't one of them. Why > bother >> with Received: fields when you can simply collect transaction logs from >> ISPs/MSPs. > > Ned, you are basically saying, "why bother plugging one leak when the same > data can leak somewhere else." Well, I think it is actually important to > plug all the privacy leaks, much like in security it is important to plug > all the holes. This came out of a thread started on the supposition that this effort was only aimed at pervasive monitoring by state actors and that all other aspects were out of scope as per RFC7358, including whether it was a good idea or not. 1) You can't fight state actors with protocol tweaks. If a state is interested in these headers, they simply have to order providers to ignore anything we do. They already have. 2) State actors have a much easier time of doing this at the network level than email headers. The great firewall of china and the big red "disconnect" switch makes such measures as proposed irrelevant. 3) At best this effort becomes a game of whack a mole, where the mole gets to scurry around unmolested while "we" take 5 years or more to swing the bat each time. 4) I agree that making general improvements to privacy is generally a good thing. But it cannot be if we artificially limit the discussion to areas where anything we could do hardly matters in the first place. Secondly, the results can be catastrophic failures if we refuse to acknowledge the drawbacks in other areas (operational problems, suicide prevention, handling of threats of violence, harrassment, or anti-fraud, anti-privacy violation efforts). This work cannot be done in isolation. > You are making the argument that authorities can commandeer data by imposing > on mail providers. They can, but in countries with decent rule of laws there > are limits, such as requesting probable cause and not going through fishing > expeditions. We have seen rogue agencies attempt to bypass these limits by > just taking the data whichever way they can, and we want to stop that. Yet, the best/most famous example we have to date is that of a country with decent rules of law, it was explicitly made legal, and that suppression of the source "address" equivalent (eg: callerid) wouldn't have made the slightest bit of difference. Nor would it with the great firewall. I contend that relying on, say, a handful of illicit wire connects, sporadic access to relay logs, and/or "informer" recipients, is by its very definition not "pervasive monitoring", and is thus also out-of-scope by the article that began this thread. For our effort to be useful, the scoping has to be wider, as does the considerations of the downsides to doing it. I shall relate a highly relevant real-world experience: As part of the privacy investigation I mentioned in another posting, we were tasked at trying to track down a rather prolific sexual harrassment caller who seemed to have a surprisingly high level of intimate and accurate health/medical detail about the victims. Over the span of the investigation, we verified more than 1500 (yes, 1500!) of these calls by one guy, to as many separate individuals (well, subtract one, one woman was savvy enough to trick the guy into phoning again and taped the conversation). 1500 calls - one guy. The consequences of some of these calls were pretty damaging to the women and their families - some were quite traumatised. [The calls usually started out with the perp identifing themselves as a doctor asked to follow up on some sort of gynecological "issue" revealed by a recent test/procedure, scaring the women into believing that something was seriously wrong, and then getting their jollies by asking intimate questions about sexual practises and progressing to worse things. Very very nasty.] This was before callerid. I was in the interview where we solidly identified who it was doing it (after brainstorming between me, other members of the commission, and the LE tasked with running/supervising the effort) and asking a small group of female workers in the "common factor" office to see if they could identify the voice on tape. [I was and am still impressed by the sensitivity shown by the senior Detective Sergeant of the OPP who led that interview. The officer asked me to be there to act as a technical bridge between him and the office staff, and otherwise shut up and be a sympathetic listener.] It turned out to be a rogue insurance company employee inside a secured processing area harvesting the "to be shredded and incinerated" bins. Nailed the SOB and the calls ended. Callerid would have made it so much easier. I was never so glad as to see something as the wide-scale deployment of callerid a few years later. The same (occasionally strident and emotional) privacy arguments we hear now about MSA submission addresses were made then. Accommodations were made (facilities at threat, per-use suppression etc), and how many privacy advocates are tilting at callerid these days? Approximately zero. We already have the equivalent accommodations (tor, anon remailers, etc. etc. etc) that callerid developed! Harrassment calls almost completely vanished country-wide despite the fact that you could opt-out of callerid. Unfortunately, I fully expect them to have been on the rise again with the wide-spread spoofing of callerid that VOIP et. al. makes possible. Certainly phone spammers are doing it already. Be careful what you ask for, you might get it. From nobody Sun Dec 6 13:10:43 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 1D2DA1B2C4A for ; Sun, 6 Dec 2015 13:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.82 X-Spam-Level: X-Spam-Status: No, score=0.82 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, 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 8xcgyclVdRDZ for ; Sun, 6 Dec 2015 13:10:40 -0800 (PST) Received: from mail.lapsedordinary.net (thinksmall.vps.bitfolk.com [85.119.83.85]) by ietfa.amsl.com (Postfix) with ESMTP id BAC7A1B2C48 for ; Sun, 6 Dec 2015 13:10:40 -0800 (PST) Received: by mail.lapsedordinary.net (Postfix, from userid 1000) id C81FD343FE; Sun, 6 Dec 2015 21:10:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lapsedordinary.net; s=mail; t=1449436239; bh=vqoSD5HPQsRcxjo+P8/gNrmh4QTU5TY0vPrfCKg+JZc=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=f1btriF6Dlfd5+G+q7z2+/YKMaTJhteJbbSC6m64e8Lf5abnF0ijkkbvnOucx9srb 2XvWxpr0SH1r1wvH2RZ+u6b6hEfUA+4gAUHc5tos8Ol6SjdYL8RbegWV0ZPrb4HUjj U3RIumeiQ31WTTm0SglT3mkxQQIwwb6d9YdyRuH8= Date: Sun, 6 Dec 2015 21:10:39 +0000 From: Martijn Grooten To: shutup@ietf.org Message-ID: <20151206211039.GA9984@lapsedordinary.net> References: <6.2.5.6.2.20151205205343.0c75fed0@elandnews.com> <01PTXQAJ1Y2400HE89@mauve.mrochek.com> <05b301d1304c$bf6f3880$3e4da980$@huitema.net> <566493BA.8050707@mustelids.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: <566493BA.8050707@mustelids.ca> User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: 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: Sun, 06 Dec 2015 21:10:42 -0000 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Dec 06, 2015 at 02:59:54PM -0500, Chris Lewis wrote: > I was never so glad as to see something as the wide-scale deployment > of callerid a few years later. But for Caller ID to work in cases like the one you describe, you wouldn't need to know the phone number (which often includes the location) of the caller; a "cryptographic blob" identifying their phone line would suffice. I am not a lawyer, but I believe IP addresses are considered personal data in some countries; the European Court of Justice is currently looking into the issue. I don't think it's impossible for a court to decide that because of this, providers should strip (submission) IP addresses from emails. Or perhaps one of the many tracking companies is already using this to correlate emails sent to website visits. This could lead to outrage among privacy activists and a call for providers to strip submission IP addresses. Hence I believe it is worth seeing if we can come up with guidelines on what information can be removed/redacted/cryptographically blobbed in email headers, so that senders' privacy is improved, yet the ability to block and fight abuse isn't significantly harmed. I do think the proposed charter is a bit too strong on the need to remove headers which, given comments here, probably isn't very helpful. I would be in favour of a more open-minded charter, but I do think there is a need for a WG like this one. Martijn. --envbJBWh7q8WU6mo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWZKRPAAoJEI5dMs9dIv8ZPvsIAIgDmxjwHbxc/5bxmVNxDwWt d/uwlyNFy+VrnGYtNbRaapPjIcc+nxGqb7TPhWszBvJO/QlgC5HK6PhViG5GJeGm Hu5HYxRKGlU1v30Oz8t6fbamu5G3+oEzdo1NqMIb4HnLxdGbz032z+aVF2BjefUF XzBLw+2pv8YwJypRd1cGh9mXSrtTecnDdZCD+RQ0YLIXDBLMXqoHr8lGoITnA08X KvX6CGBOjGGO+jkDswD2/4hr6O1Leyuca6dD57bf1ibYg2SfTuUz9KKDjgEI7cTs TMQaMkLtaCBhYgDDSOYCGGnGC+NX3CQ/IwtCKX9pPsm5RoklR9ytLQ+rR7gwBY0= =6w1L -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- From nobody Sun Dec 6 16:15:47 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 940BE1A8A76 for ; Sun, 6 Dec 2015 16:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.043 X-Spam-Level: *** X-Spam-Status: No, score=3.043 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gV1rA0em_n2D for ; Sun, 6 Dec 2015 16:15:33 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A9691A8A74 for ; Sun, 6 Dec 2015 16:15:31 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB70FThA027366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 6 Dec 2015 19:15:30 -0500 To: shutup@ietf.org References: <6.2.5.6.2.20151205205343.0c75fed0@elandnews.com> <01PTXQAJ1Y2400HE89@mauve.mrochek.com> <05b301d1304c$bf6f3880$3e4da980$@huitema.net> <566493BA.8050707@mustelids.ca> <20151206211039.GA9984@lapsedordinary.net> From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <5664CFA1.6090408@mustelids.ca> Date: Sun, 6 Dec 2015 19:15:29 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <20151206211039.GA9984@lapsedordinary.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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: Mon, 07 Dec 2015 00:15:34 -0000 On 12/06/2015 04:10 PM, Martijn Grooten wrote: > On Sun, Dec 06, 2015 at 02:59:54PM -0500, Chris Lewis wrote: >> I was never so glad as to see something as the wide-scale deployment >> of callerid a few years later. > > But for Caller ID to work in cases like the one you describe, you > wouldn't need to know the phone number (which often includes the > location) of the caller; a "cryptographic blob" identifying their phone > line would suffice. The proper analog is "Call Trace". You dial a * code, and the calling number gets recorded by the telco, but it can only be retrieved via a LE process (I do not believe it requires a full search warrant, but, joe-blow citizen certainly can't get it). It cannot be disabled (but presumably spoofable) by the caller. > I am not a lawyer, but I believe IP addresses are considered personal > data in some countries; the European Court of Justice is currently > looking into the issue. I don't think it's impossible for a court to > decide that because of this, providers should strip (submission) IP > addresses from emails. Anything's possible. What's also possible that when presented in its entirety, a court may still agree that the operational/other benefits of providing them in this case outweighs the potential risk. Nothing is an absolute. There are always edge cases where informed judgment is required, and you rely on courts and judges to provide guidance through precedent. What I also know is that when asked, regulators over here in PIPEDA land are most emphatic in saying that IP addresses are not PII. And this _includes_ the Privacy Commissioner. > Or perhaps one of the many tracking companies is already using this to > correlate emails sent to website visits. This could lead to outrage > among privacy activists and a call for providers to strip submission IP > addresses. That's in part why we have governments - to prevent public panics of the uninformed driving public policy. We had one when callerid happened. Callerid got "fixed" not killed. We had one when the newspaper stories about the leaks (that ultimately led to the Commission I was a member of). They were (mostly) bogus. But we fixed the problems that were really there and weren't in the newspaper stories. We have a panic _now_. How would you feel about security/privacy policy being driven by Trump and his followers? If that doesn't scare you, it should. What would really be fascinating is to get one or more people highly respected in their knowledge of the law, public policy and privacy to take on the question of passing through SUBMIT addresses. Bring out all the pros and cons. Put it on trial as it were. > I do think the proposed charter is a bit too strong on the need to > remove headers which, given comments here, probably isn't very helpful. > I would be in favour of a more open-minded charter, but I do think there > is a need for a WG like this one. I agree, but the WG charter is too strong on the mechanics of "how" and has nothing at all on the mechanics of "will it do anything?" and the real downsides. The charter needs to be expanded, and the WG work begun. Perhaps one of the most important things in the WG is to decide whether the output is a document, and whether the document is an informational, a BCP or standard or STD. My current thinking is that we're going to hit BCP at best. An alternate approach occured to me - rather than trying to defacto impose it everywhere (which is sorta what the existing documentation is pushing towards), what about some sort of informational/BCP or even full RFC defining a "privacy enhanced interface" and outline what it needs to do w.r.t. email, and other service privacy? Existing environments could make it an option, makes an opportunity for niche providers, and describes in concrete terms what it needs to do? From nobody Sun Dec 6 18:34:55 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 A97D41ACCE3 for ; Sun, 6 Dec 2015 18:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 LcS2MaLCPCdS for ; Sun, 6 Dec 2015 18:34:50 -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 723831ACCDC for ; Sun, 6 Dec 2015 18:34:50 -0800 (PST) Received: (qmail 29616 invoked from network); 7 Dec 2015 02:34:48 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 7 Dec 2015 02:34:48 -0000 Date: 7 Dec 2015 02:34:26 -0000 Message-ID: <20151207023426.54934.qmail@ary.lan> From: "John Levine" To: ietf-smtp@ietf.org, shutup@ietf.org In-Reply-To: <5664CFA1.6090408@mustelids.ca> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: ietf@mustelids.ca Subject: Re: [Shutup] Proposed Charter for something 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, 07 Dec 2015 02:34:51 -0000 >Perhaps one of the most important things in the WG is to decide whether >the output is a document, and whether the document is an informational, >a BCP or standard or STD. My current thinking is that we're going to >hit BCP at best. This is increasingly looking like a RG, not a WG. There's a lot of speculation about what aspects of mail messages and SMTP sessions have what privacy implications, with an extremely premature focus on IP address logging. I'd much rather back up a step or two and see if we can catalog the aspects of mail messages with estimates of the privacy benefits and risks of each, keeping in mind the context. For example, how much new information is there in the date stamp in a Received header in the usual case that it's a few seconds after the timestamp in the Date: header? On the other hand, most Received headers have a unique ID that's really handy to identify the message and the path it took (That's how you tell who's sending spam reports from AOL and Yahoo, even though they redact all the addresses.) That would be a useful catalog, and we can think about models that look at the net personal information, and diagnostic and anti-abuse information provided by various combinations of features or the lack thereof. That would be interesting on its own, and would give us a much better foundation from which to consider changes that could produce an actual overall privacy improvement. R's, John From nobody Sun Dec 6 19:00:47 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 5A6101ACD8F for ; Sun, 6 Dec 2015 19:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWqmyPE9W57a for ; Sun, 6 Dec 2015 19:00:44 -0800 (PST) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A46411ACD93 for ; Sun, 6 Dec 2015 19:00:44 -0800 (PST) Received: from [192.168.1.241] (ool-4571974e.dyn.optonline.net [69.113.151.78]) by mailbackend.panix.com (Postfix) with ESMTPA id 8B6B3178C2; Sun, 6 Dec 2015 22:00:43 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <5664CFA1.6090408@mustelids.ca> References: <6.2.5.6.2.20151205205343.0c75fed0@elandnews.com> <01PTXQAJ1Y2400HE89@mauve.mrochek.com> <05b301d1304c$bf6f3880$3e4da980$@huitema.net> <566493BA.8050707@mustelids.ca> <20151206211039.GA9984@lapsedordinary.net> <5664CFA1.6090408@mustelids.ca> X-Mailer: Eudora for Mac OS X 6.2.4 (MacOS 10.5.8) Date: Sun, 6 Dec 2015 21:54:06 -0500 To: Chris Lewis From: "Robert A. Rosenberg" Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: Mon, 07 Dec 2015 03:00:46 -0000 At 19:15 -0500 on 12/06/2015, Chris Lewis wrote about Re: [Shutup] Proposed Charter for the "SMTP Headers Unhealt: >On 12/06/2015 04:10 PM, Martijn Grooten wrote: >>On Sun, Dec 06, 2015 at 02:59:54PM -0500, Chris Lewis wrote: >>>I was never so glad as to see something as the wide-scale deployment >>>of callerid a few years later. >> >>But for Caller ID to work in cases like the one you describe, you >>wouldn't need to know the phone number (which often includes the >>location) of the caller; a "cryptographic blob" identifying their phone >>line would suffice. > >The proper analog is "Call Trace". You dial a * code, and the >calling number gets recorded by the telco, but it can only be >retrieved via a LE process (I do not believe it requires a full >search warrant, but, joe-blow citizen certainly can't get it). It >cannot be disabled (but presumably spoofable) by the caller. The *-code you are referencing is *57 (1157 from a dial phone) and records the ANI (Call Setup and Routing) information not the spoof-capable CALLERID information. I think about am not sure that the information is accurate and can not be spoofed/faked. Note that the called party must use the code before another call comes in and the TelCo charges you when you use it. Here is a Wikipedia article on the code/feature. https://en.wikipedia.org/wiki/Malicious_caller_identification From nobody Sun Dec 6 19:44: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 59DE71B2D37; Sun, 6 Dec 2015 19:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0e7IbeybX4W; Sun, 6 Dec 2015 19:44:10 -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 9D0441B2D36; Sun, 6 Dec 2015 19:44:08 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14494598449520.06005436880514026" From: Ted Lemon To: ietf-smtp@ietf.org In-Reply-To: <20151207023426.54934.qmail@ary.lan> References: <20151207023426.54934.qmail@ary.lan> Date: Mon, 07 Dec 2015 03:44:04 +0000 Message-Id: <1449459845284-0f35b2c2-4c269683-2083d091@fugue.com> MIME-Version: 1.0 Archived-At: Cc: shutup@ietf.org Subject: Re: [Shutup] Proposed Charter for something 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, 07 Dec 2015 03:44:11 -0000 ------sinikael-?=_1-14494598449520.06005436880514026 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Sunday, Dec 6, 2015 9:34 PM John Levine wrote: > For example, how much new information is there in the date stamp in a > Received header in the usual case that it's a few seconds after the > timestamp in the Date: header=3F On the other hand, most Received > headers have a unique ID that's really handy to identify the message > and the path it took (That's how you tell who's sending spam reports > from AOL and Yahoo, even though they redact all the addresses.) Bear in mind that the date header field isn't modified in transit, so it = can in principle be in the encrypted blob, and not in the postcard headers.= > That would be a useful catalog, and we can think about models that > look at the net personal information, and diagnostic and anti-abuse > information provided by various combinations of features or the lack > thereof. That would be interesting on its own, and would give us a > much better foundation from which to consider changes that could > produce an actual overall privacy improvement. Agreed, but I don't see why you think this is an RG and not a WG. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14494598449520.06005436880514026 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWZQCFCRAMw8Nu0HeKywAAknQIAKw3sg9nX2lSR9K0XfVT 9+mQfnYb27N+xq7004iTqSCl5nb/uUm9ZbEtqrt0yU40KIgD9imf98H1bi2V LMbT46KapSIb2pnkAQ2LYO/HIdBks+L27a1d9M9DXUi1zr1Xqy1yFnY5G04Q VtCz3XAQ+kcM+7e/eutZo+njrWlHsMeu8gjwJPNMUIxASnuBpcTy18/pHYUR sL9q85qmptwakzT9YWCChirDn/PH2QcJVPuzQLwEpsw6TxaAVRxcDhvdmGFI 8MsNF9oq/hWfu+SRBpCUAvZmdwJfzcPfOW4j9eDZPUHTr0MNOZbu0ke2y5NL eJQwDa8RfXfqr7YSe12dT+E= =2Kkv -----END PGP SIGNATURE----- ------sinikael-?=_1-14494598449520.06005436880514026-- From nobody Sun Dec 6 20:34:53 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 94FA61B2DCC; Sun, 6 Dec 2015 20:34:50 -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 5048Ymr-Vj4r; Sun, 6 Dec 2015 20:34:49 -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 754521B2DCB; Sun, 6 Dec 2015 20:34:49 -0800 (PST) Received: from [192.168.1.99] (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 tB74Yl3n024580 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sun, 6 Dec 2015 20:34:48 -0800 References: <20151207023426.54934.qmail@ary.lan> <1449459845284-0f35b2c2-4c269683-2083d091@fugue.com> To: Ted Lemon From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <56650C80.2000307@dcrocker.net> Date: Sun, 6 Dec 2015 20:35:13 -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: <1449459845284-0f35b2c2-4c269683-2083d091@fugue.com> 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, 06 Dec 2015 20:34:48 -0800 (PST) Archived-At: Cc: shutup@ietf.org, ietf-smtp@ietf.org Subject: Re: [Shutup] Proposed Charter for something 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: Mon, 07 Dec 2015 04:34:50 -0000 On 12/6/2015 7:44 PM, Ted Lemon wrote: > Agreed, but I don't see why you think this is an RG and not a WG. Please re-read his note and one or another of my earlier notes. They explain why. At the moment, proposals for taking specific actions represent a random walk down a large and complex set of possibilities, with no serious analysis of benefits, risks, likelihoods or anything other than intuition. Before modifying infrastructure operations of a critical Internet resource, perhaps we should develop some credible basis for taking any specific action? Individuals are free to take whatever random path strikes their whimsy. Standards groups should have rather more basis for moving the whole ship in a particular direction. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Dec 6 23:44:19 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 AE8551B30C5; Sun, 6 Dec 2015 23:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.079 X-Spam-Level: X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, 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 mhTr0DVtixq7; Sun, 6 Dec 2015 23:44:15 -0800 (PST) Received: from mail.lapsedordinary.net (thinksmall.vps.bitfolk.com [85.119.83.85]) by ietfa.amsl.com (Postfix) with ESMTP id 756881B30C4; Sun, 6 Dec 2015 23:44:15 -0800 (PST) Received: by mail.lapsedordinary.net (Postfix, from userid 1000) id E6649343FE; Mon, 7 Dec 2015 07:44:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lapsedordinary.net; s=mail; t=1449474254; bh=I50cpjMHhCNJHZwf8Q4pib2vQI0cF+f1Gta0huFprKI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=OoH+8ACgB2ak7ibIMFbNVJn9waWXdFPzuBxAx14RxmVb76IA8v0PNDEKiYPm0Qu1J bdH2w8J4t3z3P7XIMoeVJmZCHUfVkaDpYndyxnUJyP5KLx10uq0QimFVLX3T9QW4Zy 4A5IyUfui08yrHsBb/rz9TzrH+5o71kct0+AkYrY= Date: Mon, 7 Dec 2015 07:44:14 +0000 From: Martijn Grooten To: shutup@ietf.org Message-ID: <20151207074414.GA14212@lapsedordinary.net> References: <5664CFA1.6090408@mustelids.ca> <20151207023426.54934.qmail@ary.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: <20151207023426.54934.qmail@ary.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Cc: ietf-smtp@ietf.org Subject: Re: [Shutup] Proposed Charter for something 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, 07 Dec 2015 07:44:16 -0000 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 07, 2015 at 02:34:26AM -0000, John Levine wrote: > This is increasingly looking like a RG, not a WG. There's a lot of > speculation about what aspects of mail messages and SMTP sessions have > what privacy implications, with an extremely premature focus on IP > address logging. I'd much rather back up a step or two and see if we > can catalog the aspects of mail messages with estimates of the privacy > benefits and risks of each, keeping in mind the context. =20 I would be in favour of such a RG. Martijn. --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWZTjOAAoJEI5dMs9dIv8Z/NoIAJ4RtglCE7pQTH1EsrTM5rwV eG/DjCEg8j3g8wE8ipn2p3SgF56bbSZwBLQPAzN1PWsS1q7FiMTvnyaOF1lNh9oI f/IP3DyVBzx/eRVdyWRrw4TXy6ogNPLL256m2wxMsHMyAcNWqVyammFEH1LbqK0R jUC8NDZ25mzjyyK/9rCkdG66+TrTEsahmd0ttDBI4ZPB+1P4zs/oCNgNDTRjIXZe 6KhFsG3hYJTZLghh66Z8ph2ApZ5ym6RezfrhrAK3Bd+Crs79KRUIfq7ftWxJ6utu Rjqg92C39umIX+lk1PK5S6d8ISg2BI/7QW4zNksYkDaSN0q70UNdQN9YAGGgxBo= =qQTq -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- From nobody Mon Dec 7 00:31:18 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 A9B8B1A1A72; Sun, 6 Dec 2015 23:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAvuY5R4A3Lh; Sun, 6 Dec 2015 23:31:35 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9095F1A02BE; Sun, 6 Dec 2015 23:31:35 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1a5qGj-0002mJ-SR; Mon, 07 Dec 2015 02:31:33 -0500 Date: Mon, 07 Dec 2015 02:31:28 -0500 From: John C Klensin To: John Levine , ietf-smtp@ietf.org, shutup@ietf.org Message-ID: In-Reply-To: <20151207023426.54934.qmail@ary.lan> References: <20151207023426.54934.qmail@ary.lan> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: X-Mailman-Approved-At: Mon, 07 Dec 2015 00:31:17 -0800 Cc: ietf@mustelids.ca Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for something 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, 07 Dec 2015 07:31:37 -0000 --On Monday, December 07, 2015 02:34 +0000 John Levine wrote: >... > This is increasingly looking like a RG, not a WG. There's a > lot of speculation about what aspects of mail messages and > SMTP sessions have what privacy implications, with an > extremely premature focus on IP address logging. I'd much > rather back up a step or two and see if we can catalog the > aspects of mail messages with estimates of the privacy > benefits and risks of each, keeping in mind the context. > > For example, how much new information is there in the date > stamp in a Received header in the usual case that it's a few > seconds after the timestamp in the Date: header? On the other > hand, most Received headers have a unique ID that's really > handy to identify the message and the path it took (That's how > you tell who's sending spam reports from AOL and Yahoo, even > though they redact all the addresses.) > > That would be a useful catalog, and we can think about models > that look at the net personal information, and diagnostic and > anti-abuse information provided by various combinations of > features or the lack thereof. That would be interesting on > its own, and would give us a much better foundation from which > to consider changes that could produce an actual overall > privacy improvement. This strikes me as a really good idea. This is probably what John has in mind but, to be explicit, if it could also catalog (not just allow "thinking about"), for each item, the substantive uses to which any relevant aspect or datum is being legitimately put today, differentiating things that are specifically anti-spam from anti-phishing and mitigation of malware and other types of attacks, that would be even better. As many people have suggested in the previous threads, "more privacy", whether about location or other information, is not free but involves tradeoffs with other priorities and it is important to consider the tradeoffs and balance. For me at least, Dave Crocker's subsequent comments reinforce that view. john From nobody Mon Dec 7 02:50:50 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 8FF691A1BCB; Mon, 7 Dec 2015 02:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KNYwDLxU5ku; Mon, 7 Dec 2015 02:50:46 -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 D54F41A1B7B; Mon, 7 Dec 2015 02:50:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3C9F4BE33; Mon, 7 Dec 2015 10:50:44 +0000 (GMT) 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 jEX96P-LVoXG; Mon, 7 Dec 2015 10:50:44 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6FD81BDCF; Mon, 7 Dec 2015 10:50:43 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449485444; bh=8efiUTxUa+PTBFJKP9Sdh4oKV5Ke0QrdsYwLR0obM68=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=eoEBNabTZJ1SxccE5kRYbHx51caChPcWd9UvxCVVvLHhw8tR4PB67z416GkgAHGp1 VxDn004ROf8AYXAzrsmkv99xj85oGb3QvGZs4JRKhgkdb4Giv1pjMhESGAKcpvd9hi kdNTSA7Zx6A+71ubMg8b8wyOOdhZ2ljGo+86g+o8= To: John Levine , ietf-smtp@ietf.org, shutup@ietf.org References: <20151207023426.54934.qmail@ary.lan> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56656482.7090900@cs.tcd.ie> Date: Mon, 7 Dec 2015 10:50:42 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151207023426.54934.qmail@ary.lan> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: ietf@mustelids.ca Subject: Re: [Shutup] Proposed Charter for something 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, 07 Dec 2015 10:50:47 -0000 On 07/12/15 02:34, John Levine wrote: > This is increasingly looking like a RG, not a WG. Hmm, not sure. A good RG is one that'd attract an active research community and be relatively long lived whereas this seems like a bit of work where we need to do a relatively small and discrete amount of research on one topic. (Which is roughly "What'd happen if you mucked with received headers the MSA passes on to the rest of the mail infrastructure?") The way I think of it is a good RG would produce a stream of academic publications and then some stuff that'd be of use to the IETF. This sounds more like one paper's worth of research then stuff would be done in the IETF or not, depending on the findings. So I don't think an RG would be a good plan and a WG can be chartered to investigate things before proposing things. But if folks think an RG is better, the first step would be to talk to Lars about it. S. From nobody Mon Dec 7 08:20: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 6C92C1B384E for ; Mon, 7 Dec 2015 08:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.936 X-Spam-Level: X-Spam-Status: No, score=0.936 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Muk8m2IeGmVA for ; Mon, 7 Dec 2015 08:20:44 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id A17B71B384D for ; Mon, 7 Dec 2015 08:20:44 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PTZNYBYCK000AW25@mauve.mrochek.com> for shutup@ietf.org; Mon, 7 Dec 2015 08:15:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1449504939; bh=+pUqDZwGq9bHKHyuE/wEExsNmRX/EYmRkwGu1EOLSc8=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=TxoSNZCIohhqUyxzkYk3dkIyLRTiHaIxWOWWpsURb5XYfQg+ve7RMXvLN4cSeKV1q rMz7/9qpBKrRVKZS0ttw+JMSE2Zvz5cVZWvyKvfpANtcA5MnseXkAgArL6YLBdVg7i hz2hm+fkpBdIf8Fp7qlfDmDCNSN0V3ncY17eExh0= 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 <01PTVFL0BHTS018EYG@mauve.mrochek.com>; Mon, 07 Dec 2015 08:15:37 -0800 (PST) Message-id: <01PTZNYA1SXY018EYG@mauve.mrochek.com> Date: Sun, 06 Dec 2015 11:31:44 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sun, 06 Dec 2015 09:37:14 -0800" <05b301d1304c$bf6f3880$3e4da980$@huitema.net> References: <6.2.5.6.2.20151205205343.0c75fed0@elandnews.com> <01PTXQAJ1Y2400HE89@mauve.mrochek.com> <05b301d1304c$bf6f3880$3e4da980$@huitema.net> To: Christian Huitema Archived-At: Cc: 'SM' , 'Ned Freed' , 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: Mon, 07 Dec 2015 16:20:46 -0000 > On Saturday, December 5, 2015 10:52 PM, Ned Freed wrote: > > SM writes: > > > > > An attack on organization is a security issue; it isn't a privacy > > > issue. The privacy issue is about mail-related metadata which can be > > > collected by state surveillance agencies. Will the proposed working > > > group attempt to fix that? > > > > As I pointed out on the perpass list when the Received: field draft was > first > > posted, there are definitely privacy issues associated with Received: > fields, > > but metadata collection by state actors really isn't one of them. Why > bother > > with Received: fields when you can simply collect transaction logs from > > ISPs/MSPs. > Ned, you are basically saying, "why bother plugging one leak when the same > data can leak somewhere else." Stop. Right. There. In the text you quoted, I said, "there are definitely privacy issues associated with Received: fields". That in no way, shape, or form equates to my saying that Received: fields are not worth worrying about. In fact in this message: http://mailarchive.ietf.org/arch/msg/perpass/olIpnc_N1Vu46k0X_Rc74XMlYZE I said: ... there is a real privacy gain in not including [IP addresses] in messages. State actors with subpeona powers may have easy access to ISP/MSP logs, but other players, including legitimate message recipients, do not. And my location at the time I send a piece of mail really isn't the concern of any of the message's recipients unless I choose to reveal it. That's almost the exact opposite of the position you claim I held. You really need to start reading what people are actually saying. > Well, I think it is actually important to > plug all the privacy leaks, much like in security it is important to plug > all the holes. And if that was the only factor in play it would be a no-brainer to simply remove the IP addresses. But it isn't the only factor. > You are making the argument that authorities can commandeer data by imposing > on mail providers. That's a statement of fact, not an argument. > They can, but in countries with decent rule of laws there > are limits, such as requesting probable cause and not going through fishing > expeditions. We have seen rogue agencies attempt to bypass these limits by > just taking the data whichever way they can, and we want to stop that. We > also worry that what these agencies can do today, organized gangs can do > tomorrow, and petty criminals after that. The claim has been made - and still is made in the draft under consideration - that IP addresses in Received: field are of significant value to state actors and should be removed for that reason alone. But that claims fails because state actors have the ability to get a better version of that information from transaction logs. Unless you can demonstrate that state actors have an easier time going after message content - and that's demonstratably false in the United States and probably most of other jurisdictions - the specifics of what restrictions apply to state actors overall are entirely irrelevant. And once again, this does *not* constitute an argument that there aren't *other* privacy implications for IP addresses in Received: fields that are worth considering. It's an argument against a specific claim that has been and continues to be made. > The email traces are particular because they are carried to multiple places, > not just the submission site but also every relay and every mail recipient. > That multiplies the chances of compromise. My email provider has some reason > to try maintain my trust, but relays and recipients may not. For me, it > makes a great deal of difference whether the information can be obtained > from just one place or from many. Yes, I believe I have some small awareness of how email works. > As I wrote in a previous message, we have a specific problem with the > correlation between IP address and user identity. Once that correlation is > established, it becomes possible to attribute 5-tuple traces to specific > individuals. You may think that the relation between someone's home IP > address and their identity is static, but in many case it is not. Some ISP > can provide you with addresses that deliberately vary over time. You can use > VPN. You can use Wi-Fi hot spots. That's exactly what privacy conscious > users do. And that's why I find the listing of submission IP in traces > problematic. And I also believe I have some small awareness of how modern networking works. > I understand that there are good use of the information, and that managing > email systems is hard. Except that you apparently refuse to acknowledge it, preferring instead to put words in other people's mouths, not to mention assuming they don't understand the most basic operational characteristics of modern email. Even more important, you also apparently refuse to acknowledge some of those uses have significant privacy implications of their own. A lot of people here are saying that the inclusion of IP addresses in Received: fields is of use in shutting down phishing attacks. And phishing is tremedounsly damaging to user privacy. So what we have here is a tradeoff. On the one hand, if we include client IP addresses in Received: fields, we leak information about message senders which may be exploited by message recipients, service providers etc. (but not state actors). But on the other hand, if we don't include client IP information, we make it harder to prevent spam and phishining attacks from reaching mail recipients, which when those attacks are successful - as some percentage always are - utterly compromises user privacy. And this is going to be a very difficult tradeoff to weigh for a bunch of reasons. For one thing, it's something of an applies to oranges comparison - a small loss of privacy for a large group in aggregate is difficult to compare to a major loss of privacy to a much smaller group. And that's assuming we can find the means of assessing the sizes and characteristics of the groups. And in the case of phishing attacks, if the past is any indication, the efficacy of using a particular piece of information like client IP is going to change over time as attackers change their strategy. But none of this is helped by your failure to actually read what other people are saying, and your frankly insulting assumptions that I don't understand the most basic principles of how email and networks work. Ned From nobody Mon Dec 7 09:04:50 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 94AF51A9113 for ; Mon, 7 Dec 2015 09:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3P49pY3mPGZ for ; Mon, 7 Dec 2015 09:04:43 -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 C73871A9084 for ; Mon, 7 Dec 2015 09:04:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DFA8EBE39; Mon, 7 Dec 2015 17:04:40 +0000 (GMT) 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 8gfxhyMkZagS; Mon, 7 Dec 2015 17:04:40 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1EE56BE38; Mon, 7 Dec 2015 17:04:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449507880; bh=lEBlFZeU0mj4qkOX+Oe2pE1foxdWFoR1JJk4a2vEwps=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=XLvuTbF9374c7fiaHMsp2T65j0vUE8qTWzXjLddyA+55Bwjyl0vkp3tbc+ew8WYSn ZAYQYgNO3NP62kjw1QfF6oc6yD19aj0ynv/dLtfjmEP1Z7atcyiMWrRN/mKWnTd9e/ g32/nI0elKQTO6ndnjX5+mqX9CB7nR5/7FeXf+tE= To: Ned Freed , Christian Huitema References: <6.2.5.6.2.20151205205343.0c75fed0@elandnews.com> <01PTXQAJ1Y2400HE89@mauve.mrochek.com> <05b301d1304c$bf6f3880$3e4da980$@huitema.net> <01PTZNYA1SXY018EYG@mauve.mrochek.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Enigmail-Draft-Status: N1110 Message-ID: <5665BC27.3090402@cs.tcd.ie> Date: Mon, 7 Dec 2015 17:04:39 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <01PTZNYA1SXY018EYG@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: 'SM' , 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: Mon, 07 Dec 2015 17:04:48 -0000 Hiya, On 06/12/15 19:31, Ned Freed wrote: > The claim has been made - and still is made in the draft under consideration - > that IP addresses in Received: field are of significant value to state actors > and should be removed for that reason alone. But that claims fails because > state actors have the ability to get a better version of that information from > transaction logs. I don't think I've seen substantiation of "significant value" to state actors for the specific case of message author's IP addresses in Received: fields. OTOH, access to transaction logs should depend on the jurisdiction in which those are located though whereas if SMTP is not (or badly) protected via STARTTLS then those fields will be visible to monitoring devices. And it also seems likely that that data will be stored if it can be stored [1] as one real pattern seems to be that those doing PM will attempt to get data via every possible avenue, even when they have a way to convince or force service providers to co-operate. [1] http://leaksource.info/2015/02/25/pony-express-cse-spying-on-canadians-emails-to-government/ So while I've not seen specific information that these fields have been used after e.g. having been recorded via tempora or similar, it seems credible to assume that that can be done (and hence is being done). > Unless you can demonstrate that state actors have an easier time going after > message content - and that's demonstratably false in the United States and > probably most of other jurisdictions - the specifics of what restrictions apply > to state actors overall are entirely irrelevant. > > And once again, this does *not* constitute an argument that there aren't > *other* privacy implications for IP addresses in Received: fields that are > worth considering. It's an argument against a specific claim that has been and > continues to be made. Right. There's also the case of leaked data, e.g. in the hacking team leak case, ([2] search down the page for "homing pigeon"), those fields in that tranche of stolen/leaked data did expose specific information that might otherwise not have been extractable. I'm not sure if I'd call that additional information significant or not, given all the rest of the things the folks who did [2] could deduce from the data. [2] http://labs.rs/en/metadata/ (Note that I'm assuming that when [2] says "email headers reveal the IP address of the sender" they mean from Received: fields, and not something else.) And to be clear, none of the above is meant to contradict the arguments folks have made about using this information for reasonable purposes. I figure this is just a part of the analysis of the trade offs that a WG would have to do. (Or that someone could just go and do now before there's a WG.) Cheers, S. From nobody Mon Dec 7 10:29: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 B99401B391D for ; Mon, 7 Dec 2015 10:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 S6U4rbDT1IGB for ; Mon, 7 Dec 2015 10:29:43 -0800 (PST) Received: from xsmtp01.mail2web.com (xsmtp01.mail2web.com [168.144.250.230]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7861B32B0 for ; Mon, 7 Dec 2015 10:29:43 -0800 (PST) Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1a60Xb-00072t-FU for shutup@ietf.org; Mon, 07 Dec 2015 13:29:41 -0500 Received: (qmail 30207 invoked from network); 7 Dec 2015 18:29:38 -0000 Received: from unknown (HELO huitema2) (Authenticated-user:_huitema@huitema.net@[131.107.147.15]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 7 Dec 2015 18:29:38 -0000 From: "Christian Huitema" To: "'Ned Freed'" References: <6.2.5.6.2.20151205205343.0c75fed0@elandnews.com> <01PTXQAJ1Y2400HE89@mauve.mrochek.com> <05b301d1304c$bf6f3880$3e4da980$@huitema.net> <01PTZNYA1SXY018EYG@mauve.mrochek.com> In-Reply-To: <01PTZNYA1SXY018EYG@mauve.mrochek.com> Date: Mon, 7 Dec 2015 10:29:49 -0800 Message-ID: <041801d1311d$4295ef30$c7c1cd90$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKN73fyxiYngre5rqmJ3KfWLrx3QgKRxoaNAoO5+RMBwZTMBJ0PoeAw Content-Language: en-us Archived-At: Cc: 'SM' , 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: Mon, 07 Dec 2015 18:29:44 -0000 On Sunday, December 6, 2015 11:32 AM, Ned Freed wrote: > ... > But none of this is helped by your failure to actually read what other people > are saying, and your frankly insulting assumptions that I don't understand > the most basic principles of how email and networks work. Ned, I am sorry if my message felt insulting. That was definitely not my goal. We may disagree on the relative priority of plugging this or that hole to thwart pervasive monitoring, but I never meant questioning your technical competency. If you felt insulted, please accept my apologies. -- Christian Huitema From nobody Mon Dec 7 11:41:18 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 70E9A1A6FE9; Mon, 7 Dec 2015 11:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.043 X-Spam-Level: *** X-Spam-Status: No, score=3.043 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9z0MJPjINfd0; Mon, 7 Dec 2015 11:41:16 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 176201A6FE5; Mon, 7 Dec 2015 11:41:15 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB7JfDh1022221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 7 Dec 2015 14:41:14 -0500 To: ietf-smtp@ietf.org, shutup@ietf.org References: <20151207023426.54934.qmail@ary.lan> <56656482.7090900@cs.tcd.ie> From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <5665E0D9.1050102@mustelids.ca> Date: Mon, 7 Dec 2015 14:41:13 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <56656482.7090900@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for something 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, 07 Dec 2015 19:41:17 -0000 On 12/07/2015 05:50 AM, Stephen Farrell wrote: > > > On 07/12/15 02:34, John Levine wrote: >> This is increasingly looking like a RG, not a WG. > > Hmm, not sure. A good RG is one that'd attract an active > research community and be relatively long lived whereas > this seems like a bit of work where we need to do a relatively > small and discrete amount of research on one topic. (Which > is roughly "What'd happen if you mucked with received headers > the MSA passes on to the rest of the mail infrastructure?") > > The way I think of it is a good RG would produce a stream > of academic publications and then some stuff that'd be of > use to the IETF. This sounds more like one paper's worth > of research then stuff would be done in the IETF or not, > depending on the findings. One could envision a RG constituted to long-term specifically work on privacy implications of IETF RFCs in general, with a view towards improving privacy via future RFCs. There is at least some precedent given the requirements about security area oversight of new RFCs, and the required SECURITY sections of RFCs now. Which would be a "good thing", but huge, unwieldy, and perhaps unsustainable long-term (given that most people may only have narrow topic-area interests). You could, instead, have it focus on specific areas for periods of time. Like, "today SMTP, 6 months from now web" etc. May still be unwieldy/ineffective for the same reasons. Or finally, make it narrow - "RG on email privacy leakage" - a WG with a stronger research/analysis mandate. OTOH, if we stayed with the WG approach, the mandate still has to be adjusted to do the research for guiding output documents w.r.t. privacy vs other tradeoffs. I'm tending more towards RG on email privacy leakage. Even just a document outlining where the potential leaks are, and outlining the threat landscape tradeoffs (both privacy and other) of eliding/not-eliding the info. So put me up as a strongish vote for a narrow RG. From nobody Mon Dec 7 11:59: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 84D901A854C for ; Mon, 7 Dec 2015 11:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable 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 bs2UUIZ_Km8r for ; Mon, 7 Dec 2015 11:59:55 -0800 (PST) Received: from listserv.winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id BC57D1A6FF6 for ; Mon, 7 Dec 2015 11:59:54 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2091; t=1449518391; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=zEQx6yiZsVgfZL/g6pOM2m4Ym/s=; b=gNajH2mrtjBcHIXxKG3HSG/Z+HahCHM5Dz5yE2PN4PqcxTMgWOCW6xfJE8xKDV x6j8OJtRekgKxYb3elh9B3n3K3hwGFl2xS0V7b1Mt0I5rlodAiRWQXc16+R3BSmD KDLFvyzYTDGb3FNnoe8/9sg1rrs1ABdQ5ObuMVxySKkSY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4b1) for shutup@ietf.org; Mon, 07 Dec 2015 14:59:51 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4b1) with ESMTP id 1406580816.3.4008; Mon, 07 Dec 2015 14:59:50 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2091; t=1449518272; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=EYZoS8m zfHauNRN0zQO3+DDy46/RPRKlrmGxAH8lOj0=; b=0ezUN1bpOmtCxiDt9aFQQfE RPGEI0RXQtNHmbQJMI5jp/jJWoAYsMp8T+6QggyX5ft8Yrii1Z5iG9A4ZDbG+7dC vSfwLlzhGRFRJSOyuGxzOShNAd3cL6R9ZMyGC1Cm0sJfc6gzDslbrnmdaWKNHxpO uwYLj7+t8NSdsWndMfag= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for shutup@ietf.org; Mon, 07 Dec 2015 14:57:52 -0500 Received: from [192.168.1.2] ([99.121.4.202]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 345437805.9.99524; Mon, 07 Dec 2015 14:57:51 -0500 Message-ID: <5665E52E.6060604@isdg.net> Date: Mon, 07 Dec 2015 14:59:42 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Stephen Farrell , ietf-smtp@ietf.org, shutup@ietf.org References: <20151207023426.54934.qmail@ary.lan> <56656482.7090900@cs.tcd.ie> In-Reply-To: <56656482.7090900@cs.tcd.ie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: ietf@mustelids.ca Subject: Re: [Shutup] Proposed Charter for something 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, 07 Dec 2015 19:59:57 -0000 On 12/7/2015 5:50 AM, Stephen Farrell wrote: > > > On 07/12/15 02:34, John Levine wrote: >> This is increasingly looking like a RG, not a WG. > > Hmm, not sure. A good RG is one that'd attract an active > research community and be relatively long lived whereas > this seems like a bit of work where we need to do a relatively > small and discrete amount of research on one topic. (Which > is roughly "What'd happen if you mucked with received headers > the MSA passes on to the rest of the mail infrastructure?") > > The way I think of it is a good RG would produce a stream > of academic publications and then some stuff that'd be of > use to the IETF. This sounds more like one paper's worth > of research then stuff would be done in the IETF or not, > depending on the findings. > > So I don't think an RG would be a good plan and a WG > can be chartered to investigate things before proposing > things. +1. I think a working group is sufficient with faster high quality results than a longer term research effort. We have enough ietf-industry-man-years, especially in the mail industry, to determine what is necessary. The charter started out with ambitious goals that included "well-engineered improvements to the SMTP protocol." But then it limited itself to specific work items, including DMARC related items which is not enough. I believe this effort requires liaison with the IETF-SMTP and DNS communities, as well as the DMARC and SPF communities. How about: o RFC5321BIS, RFC5322BIS Working Groups o "Email Bible" BCP for Hosting Mail Services Working Group The latter would produce an Modern Integrated ESMTP guide like RFC1123 was the "hosting bible" for many internet application hosting implementers. But then again, I can see how the charter may want to keep it simple too with the specific work items: o New I-D to relax the STD10/RFC5321.Received MUST requirement, o New I-D for "Cryptographic Protection of E-mail Headers" (memoryhole) o Soliciting new ideas (any I-Ds?) for Loop Detections. -- HLS From nobody Tue Dec 8 12:42:57 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 8B6061A6FAD for ; Tue, 8 Dec 2015 12:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 k7d-49tqh-vt for ; Tue, 8 Dec 2015 12:42:50 -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 3442D1A6FA7 for ; Tue, 8 Dec 2015 12:42:50 -0800 (PST) Received: (qmail 62433 invoked from network); 8 Dec 2015 20:42:48 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 8 Dec 2015 20:42:48 -0000 Date: 8 Dec 2015 20:42:27 -0000 Message-ID: <20151208204227.62714.qmail@ary.lan> From: "John Levine" To: ietf-smtp@ietf.org, shutup@ietf.org In-Reply-To: <20151208194658.GA7146@gsp.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: rsk@gsp.org Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for something 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: Tue, 08 Dec 2015 20:42:54 -0000 >I'm going to have some time starting in January to devote to this. >And I'm willing to put together a laundry list of issues-to-consider, >which will no doubt be incomplete, wrong, and poorly written. But it >would at least be a revision 0.1 try at enumerating the things we >could/should discuss. I recently noticed RFC 5111 which describes an Exploratory Group, sort of half way between a WG and a RG. This seems like a good fit. R's, JOhn From nobody Wed Dec 9 12:34:03 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 204BB1A1EFC; Wed, 9 Dec 2015 12:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.079 X-Spam-Level: X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, 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 eL4vvp_Zpbzl; Wed, 9 Dec 2015 12:33:59 -0800 (PST) Received: from mail.lapsedordinary.net (thinksmall.vps.bitfolk.com [85.119.83.85]) by ietfa.amsl.com (Postfix) with ESMTP id 8615C1A1B7D; Wed, 9 Dec 2015 12:33:59 -0800 (PST) Received: by mail.lapsedordinary.net (Postfix, from userid 1000) id 7953E343FE; Wed, 9 Dec 2015 20:33:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lapsedordinary.net; s=mail; t=1449693238; bh=DhxygWw9XObbOTe0rQpgAdBEMdYmMcJ/B6R3n5gNdz8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=pJfwFxvu9AJEkOLf1p0ZzALzLqn01iowVVg3MRXq0NFq02bdihkUhVQ1Nc+obsj4L gPXFaK9W0AZpl4vR2NBXfFHc4YJiNTJB3lPa3askhMLEvlwbOWteq9kR6dpiE2OQOU pQuZDwf9tqA3MHYG4ftVnzjck4ddQA1hCKWeg8S0= Date: Wed, 9 Dec 2015 20:33:58 +0000 From: Martijn Grooten To: ietf-smtp@ietf.org Message-ID: <20151209203358.GA24326@lapsedordinary.net> References: <20151208194658.GA7146@gsp.org> <20151208204227.62714.qmail@ary.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: <20151208204227.62714.qmail@ary.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Cc: shutup@ietf.org Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for something 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: Wed, 09 Dec 2015 20:34:01 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Dec 08, 2015 at 08:42:27PM -0000, John Levine wrote: > I recently noticed RFC 5111 which describes an Exploratory Group, sort > of half way between a WG and a RG. This seems like a good fit. I wasn't familiar with that concept, but I agree, it seems like a good fit. Martijn. --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWaJA2AAoJEI5dMs9dIv8ZAkAH/1XMrH32BnqBfg9YcckcdvkO wFbfCOTg7VHfK8EQAhKkpLevuEba88ZoL6uBU75Yxpm7YBii0q9IlLPHnmr3iw0w 3FZKbkRdvVAHVHy2hfkfKWHijnruRzNjE8JYAURCo3Pj8nSYGkNsHAeFYTJQrQFf WzQNuXpaLlxDQCnICJif+Khl3eMUApNbi3xpZjyAmj01JC83N00XREsyP0PLI0g1 d3eW/MEEhs6kzjhoaILBjbVVKqUB+OazIu60TnXL2X/gSaWZuTvOCXbR5S9CatZN pxna6SxYLk7btItXpK+YyXTDvmFVKDgWIs3hG7v2m4Rm2stPsS5d63dLG8IhzrI= =N3wr -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- From nobody Wed Dec 9 13:17:52 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 2BCB41B2DDE; Wed, 9 Dec 2015 13:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 WurustWA5qA4; Wed, 9 Dec 2015 13:17:49 -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 775AD1B2DF5; Wed, 9 Dec 2015 13:17:28 -0800 (PST) Received: from [192.168.1.99] (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 tB9LHQxl025997 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 9 Dec 2015 13:17:28 -0800 References: <20151208204227.62714.qmail@ary.lan> To: ietf-smtp@ietf.org, shutup@ietf.org From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <56689A81.7030401@dcrocker.net> Date: Wed, 9 Dec 2015 13:17:53 -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: <20151208204227.62714.qmail@ary.lan> 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]); Wed, 09 Dec 2015 13:17:28 -0800 (PST) Archived-At: Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for something 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: Wed, 09 Dec 2015 21:17:51 -0000 > I recently noticed RFC 5111 which describes an Exploratory Group, sort > of half way between a WG and a RG. This seems like a good fit. Here's why it isn't: The distance between the current state of the community and the ability to start a productive working group is not merely the matter of clarifying a few issues. The community has no overall sense of privacy protection, nor efficacy of choices, nor... well, many things. Absent a basic, systems-approach to guide community effort, for doing anything but the most blindingly obvious steps for protection, the community will be executing a random walk through a very complex face. This will essentially guarantee spending quite a lot of time and money on an effort that will have little benefit. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Dec 10 06:28:40 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 3D1011B2CFA; Thu, 10 Dec 2015 05:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xszv729J_zPZ; Thu, 10 Dec 2015 05:29:15 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03FBB1B2D1F; Thu, 10 Dec 2015 05:29:06 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1a71HL-000BK3-QT; Thu, 10 Dec 2015 08:29:03 -0500 Date: Thu, 10 Dec 2015 08:28:58 -0500 From: John C Klensin To: dcrocker@bbiw.net, ietf-smtp@ietf.org, shutup@ietf.org Message-ID: <738DEB65ECBB08C69B04DC0B@JcK-HP8200.jck.com> In-Reply-To: <56689A81.7030401@dcrocker.net> References: <20151208204227.62714.qmail@ary.lan> <56689A81.7030401@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: X-Mailman-Approved-At: Thu, 10 Dec 2015 06:28:39 -0800 Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for something 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, 10 Dec 2015 13:29:17 -0000 --On Wednesday, December 09, 2015 13:17 -0800 Dave Crocker wrote: > >> I recently noticed RFC 5111 which describes an Exploratory >> Group, sort of half way between a WG and a RG. This seems >> like a good fit. > > Here's why it isn't: > > The distance between the current state of the community > and the ability to start a productive working group is not > merely the matter of clarifying a few issues. > > The community has no overall sense of privacy protection, > nor efficacy of choices, nor... well, many things. > > Absent a basic, systems-approach to guide community > effort, for doing anything but the most blindingly obvious > steps for protection, the community will be executing a random > walk through a very complex face. > > This will essentially guarantee spending quite a lot of > time and money on an effort that will have little benefit. And, if we have learned anything from either more traditional security designs or protocol design for complex systems more generally, it also predicts to ending up with a "solution" that is replaces whatever attack vectors we are trying to eliminate with others -- perhaps new and perhaps latent there already but not discovered by the process that is used. john From nobody Thu Dec 10 07:16: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 0384D1B2BE5 for ; Thu, 10 Dec 2015 07:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 rUzTYbrgsZAS for ; Thu, 10 Dec 2015 07:16:05 -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 152571B32AB for ; Thu, 10 Dec 2015 07:16:04 -0800 (PST) Received: (qmail 76048 invoked from network); 10 Dec 2015 15:16:02 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Dec 2015 15:16:02 -0000 Date: 10 Dec 2015 15:15:41 -0000 Message-ID: <20151210151541.68326.qmail@ary.lan> From: "John Levine" To: shutup@ietf.org In-Reply-To: <20151210144814.GA16386@lapsedordinary.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: martijn@lapsedordinary.net Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for something 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, 10 Dec 2015 15:16:06 -0000 >The real question is: would spam filters still be >able to do a good enough job if we removed these things? No, it's not. The question is whether there would be an overall gain in users' privacy since providers would likely be less able to combat phishing and other privacy attacks. Spam filtering is just part of it, and in this case not where the most important effects would be. R's, John From nobody Thu Dec 10 08:40:50 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 8DD5B1A0235; Thu, 10 Dec 2015 08:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.079 X-Spam-Level: X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, 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 JUVbJmKr97bC; Thu, 10 Dec 2015 08:40:42 -0800 (PST) Received: from mail.lapsedordinary.net (thinksmall.vps.bitfolk.com [85.119.83.85]) by ietfa.amsl.com (Postfix) with ESMTP id 4821D1A88E4; Thu, 10 Dec 2015 08:40:42 -0800 (PST) Received: by mail.lapsedordinary.net (Postfix, from userid 1000) id 7CB8F343FE; Thu, 10 Dec 2015 16:40:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lapsedordinary.net; s=mail; t=1449765641; bh=RpKTCttA7aDNG23VX1taXRLUa5+qJmKZUmYqGrIFf+w=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=rsOkrf6xbUwldWYMETtnDDaDjfBbLl8AaqR1q+1l1cidLaIpkkwmaRYnMq8xkzTs9 AFOuvmdyQ5rP236Sbk6q/KJbROFJV2gfS7oJtl9vS2lH9mAzbJVTcbBI1BNw8xUPHm MaKywBh20Y5K/wapk8ao192CJZPvHSM1c4LKBjkw= Date: Thu, 10 Dec 2015 16:40:41 +0000 From: Martijn Grooten To: shutup@ietf.org Message-ID: <20151210164041.GA27258@lapsedordinary.net> References: <20151210144814.GA16386@lapsedordinary.net> <20151210151541.68326.qmail@ary.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline In-Reply-To: <20151210151541.68326.qmail@ary.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Cc: ietf-smtp@ietf.org Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for something 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, 10 Dec 2015 16:40:47 -0000 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 10, 2015 at 03:15:41PM -0000, John Levine wrote: > >The real question is: would spam filters still be > >able to do a good enough job if we removed these things? >=20 > No, it's not. The question is whether there would be an overall > gain in users' privacy since providers would likely be less able > to combat phishing and other privacy attacks. >=20 > Spam filtering is just part of it, and in this case not where the > most important effects would be. I meant "spam filters" in the broad sense, including all human and non-human activity against spam, though should have made that clear. Are there other parts of the email headers that are important to combat phishing and other "privacy attacks", apart from the submission IP address? And how much does the actual IP address matter, as opposed to a "cryptographic blob" of said address, that can be "decrypted" by the ISP and is constant for some time for a given (user,IP) combination. Martijn. --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWaasJAAoJEI5dMs9dIv8ZGKoH/iVsXVETzE1VPP/+LUQu+Zk2 H1vSqwJZ41rGD4pfvsbtp5DRuWW1w4LYxjyhDMxUlpmoNBP+lmGpEXxeO4HDHlGr aNNm4udOYGOH8yKEVWXfEksbO7QsY6xjPjIZEOz2m7P9I6nJhXbJAQj48RYAThDk YeRiO9WMJriduLgzD9/hmg78mMGCtL1MaKtJKJYqZo1It+9/rj9LM+bS2aUciNtP yGOeqoJ9ZVeU62epi3fCac9SSaDU403HbhQ5zgJAhFJPGbbHvmnWge8NSI4p2/Cf X/oVymQTm0cs4ngDk9/Qg9wo8LP+1CzcmFa1kWA869d4fb0TRqW+LfrI38r+SN4= =cIwC -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- From nobody Thu Dec 10 08:57:39 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 5DE481A8A1E; Thu, 10 Dec 2015 08:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.353 X-Spam-Level: * X-Spam-Status: No, score=1.353 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553] 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 nFajoCo63L8m; Thu, 10 Dec 2015 08:57:36 -0800 (PST) Received: from mail.highwayman.com (happyday.demon.co.uk [80.177.121.10]) (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 7D5851A88D7; Thu, 10 Dec 2015 08:57:36 -0800 (PST) Received: from localhost ([127.0.0.1]:27775 helo=happyday.al.cl.cam.ac.uk) by mail.highwayman.com with esmtp (Exim 4.86) (envelope-from ) id 1a74X7-000598-8a; Thu, 10 Dec 2015 16:57:33 +0000 Message-ID: Date: Thu, 10 Dec 2015 16:56:29 +0000 To: Martijn Grooten From: Richard Clayton References: <20151210144814.GA16386@lapsedordinary.net> <20151210151541.68326.qmail@ary.lan> <20151210164041.GA27258@lapsedordinary.net> In-Reply-To: <20151210164041.GA27258@lapsedordinary.net> MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.03 M Archived-At: Cc: shutup@ietf.org, ietf-smtp@ietf.org Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for something 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, 10 Dec 2015 16:57:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <20151210164041.GA27258@lapsedordinary.net>, Martijn Grooten writes >And how much does the actual IP address matter, as opposed >to a "cryptographic blob" of said address, that can be "decrypted" by >the ISP and is constant for some time for a given (user,IP) combination. an IP address generally indicates the ISP and country of origin (but there's a number of edge cases) for many individuals there is only a short-term linkage between themselves and the IP address (think dialup, DHCP systems for broadband and carrier grade NAT solutions for mobile) so you can seldom use it for long-term tracking of activity ("what else has this person done") - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBVmmuveINNVchEYfiEQLzMQCg2avnEk/oFef11N2xvRBxVkuxroMAoLwo p68c2AD7yGULpaRhnGEfWVn4 =stsH -----END PGP SIGNATURE----- From nobody Thu Dec 10 09:11: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 BDF911A8A05; Thu, 10 Dec 2015 09:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.621 X-Spam-Level: * X-Spam-Status: No, score=1.621 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_NET=0.611, HOST_MISMATCH_COM=0.311, 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 I49eZkZe6YeC; Thu, 10 Dec 2015 09:11:23 -0800 (PST) Received: from mail.lapsedordinary.net (thinksmall.vps.bitfolk.com [85.119.83.85]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1E81A89F5; Thu, 10 Dec 2015 09:11:23 -0800 (PST) Received: by mail.lapsedordinary.net (Postfix, from userid 1000) id 7AEF2343FE; Thu, 10 Dec 2015 17:11:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lapsedordinary.net; s=mail; t=1449767482; bh=a8kTS4t/aY9uBM4uxrLq7Kc+52ku5UI2bdc6vtsxN1Y=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=s55KXt/FNHTniMrh2pJb/qMUSRIoqmNWskd0gDg6RvNZK6j6/oEwY3BKE1FYTg5Z0 r+aN5blCh00FFsknr1Do7KuFxBCk9kYcffiD6E5nIB3NjFFf251wUN3UniXvjwsRii D7TXEw0yA8Zu0TEmxQIcYxKsYWMQq+wsCcb8Lg1o= Date: Thu, 10 Dec 2015 17:11:22 +0000 From: Martijn Grooten To: ietf-smtp@ietf.org Message-ID: <20151210171122.GB27258@lapsedordinary.net> References: <20151208204227.62714.qmail@ary.lan> <56689A81.7030401@dcrocker.net> <20151210144814.GA16386@lapsedordinary.net> <55103b70-ca39-4694-92dc-07a17344d485@gulbrandsen.priv.no> <5669A568.6000907@mustelids.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uZ3hkaAS1mZxFaxD" Content-Disposition: inline In-Reply-To: <5669A568.6000907@mustelids.ca> User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Cc: shutup@ietf.org Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for something 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, 10 Dec 2015 17:11:25 -0000 --uZ3hkaAS1mZxFaxD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Dec 10, 2015 at 11:16:40AM -0500, Chris Lewis wrote: > There really are no technical differences whatsoever between a > blackhat and a whitehat trying to protect their identity. The ONLY > saving grace is that (in the spam space) the blackhat is forced to > resort to methods that scale high enough for an adequate ROI, while > the whitehat usually doesn't care that much. Most spam filtering - again used in the broad sense - only cares about the identity of the sending organisation (ISP, company, etc.). And sometimes not even that. If an email body matches some (fuzzy) signature, it gets blocked, often regardless of who sent it from where. It's only when said organisation doesn't do a good enough job of checking the identity (or the hat colour) of the sender, that being able to find the actual sender matters to everyone else. > Tor, for example, being a case in point. Tor would be ideal for > spam. And it was for a bit. Slow, but worked. I don't know whether > the fact that the tor network became so slow as to be unuseable, or > that the screams from the "spammed" turned the day, but so few tor > exit nodes support outbound port 25 nowadays that it isn't a big > problem. If they hadn't all blocked that port (it's the default, I believe) then every DNSBL would add the exit nodes; Tor, by design, doesn't hide the nodes' IP addresses and it's easy to check if a certain IP address is or was a Tor exit node at a given time. Tor in an email context should be used to connect to an ISP's or corporate mail server. It's up to them to decide whether they have enough reason to believe youare a whitehat. Many believe they are able to do so, though they often require a one-time phone verification. If being able to hide (the geolocation of) your submission IP address is of vital importance, then this is the way to use email. For most people, this isn't necessary, but it is my belief that at the very least we should help organisations that wish to protect personal data for all of its users to do so in a way that doesn't seriously harm the existing email infrastructure. Martijn. --uZ3hkaAS1mZxFaxD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWabI6AAoJEI5dMs9dIv8ZQ5kIAJ12Br2PHRdYccWBT5FuMFgb UE99TnDoak4yL0afWrrOjzfo/6iumpf6fsrmXvH8AE6HwL0A4l24lW9MTIQxtNll ZHDqvGZZ+Xe8eHoO+iERvD5cUyBaJvGcngQsU3nJOk2uqvaEqgaZ13Tx209GgKoe /3iC1JhvU6AI1jGhCO9oRAyoJwWXxHYpzKTLow+YTRWA7mFP/n/2z+PMpq2kL/94 fNqRjaw8cnn10qG4Pv3DkN35TwQhC54RRGSNjVG+Iod33RtuJPJrOjBpllD7W3V5 Iwmofb8L8qldjLSgcAHoWpkS2YcdrJ4pbLuEhzcOd8IurwogjcIe1tPAathwJzY= =a6po -----END PGP SIGNATURE----- --uZ3hkaAS1mZxFaxD-- From nobody Thu Dec 10 09:23:40 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 DD9BF1A9008; Thu, 10 Dec 2015 09:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.621 X-Spam-Level: * X-Spam-Status: No, score=1.621 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_NET=0.611, HOST_MISMATCH_COM=0.311, 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 JqgQdQRN3mGn; Thu, 10 Dec 2015 09:23:36 -0800 (PST) Received: from mail.lapsedordinary.net (thinksmall.vps.bitfolk.com [85.119.83.85]) by ietfa.amsl.com (Postfix) with ESMTP id A2FB71A9005; Thu, 10 Dec 2015 09:23:36 -0800 (PST) Received: by mail.lapsedordinary.net (Postfix, from userid 1000) id 1E487343FE; Thu, 10 Dec 2015 17:23:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lapsedordinary.net; s=mail; t=1449768216; bh=wcg61mLlQwLcTw8MhjVE2tltYzKZxalJycGuUvwDskk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=K7Tuy5iZyeRwjsPf9x8AEMdkpdVJAcjhDfu7KsKpOObwhZZRI+v3mU4f2XrBgFFNs Y+1mMhadX+uTmAuxn7pOJ31jjkVtdFSW57orTpc0JBlllVna3lC+NscigShsg1h6IQ eutsy4wIYKs70bB3byblJEuQrvVwNgfYDAyQJrZQ= Date: Thu, 10 Dec 2015 17:23:36 +0000 From: Martijn Grooten To: ietf-smtp@ietf.org Message-ID: <20151210172336.GC27258@lapsedordinary.net> References: <20151210144814.GA16386@lapsedordinary.net> <20151210151541.68326.qmail@ary.lan> <20151210164041.GA27258@lapsedordinary.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GZVR6ND4mMseVXL/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Cc: shutup@ietf.org Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for something 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, 10 Dec 2015 17:23:38 -0000 --GZVR6ND4mMseVXL/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 10, 2015 at 04:56:29PM +0000, Richard Clayton wrote: > an IP address generally indicates the ISP and country of origin (but > there's a number of edge cases) The email address does at least indicate the former. Personally, I don't think country of origin is significant personal information (though here too there are edge cases). > for many individuals there is only a short-term linkage between > themselves and the IP address (think dialup, DHCP systems for broadband > and carrier grade NAT solutions for mobile) so you can seldom use it for > long-term tracking of activity ("what else has this person done") I have been told that in the case of a home ISP, the linkage lasts long enough that if you send me a job application email from 1.2.3.4 that a visit to our website three days ago from 1.2.3.4 was quite likely made =66rom the same house. I believe this is in part why some legislations consider an IP address personal data. A "crypgraphic blob" would still be linked to the customer, but not to any other activity. Martijn. --GZVR6ND4mMseVXL/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWabUYAAoJEI5dMs9dIv8ZUx4H/2a89i5qlHokwAPBIgPBs1bF 3RE1C39Vg3rmfTFMUm+24BMFuW0V+ULTZlg/+zTkE7QyP4mdP1Cw2ZKrBX/4WML/ wyqvbP18zljKRjc33Z6ZUGz8MwO4J+xwtl1b4O+S1uBVxVhHPrX1khqW+gWabeko K3tKJejc6B8iLjpqhR+FxII2c/PT0wYvtRruHEvDDnqzU8oUa4PntP+Jfvx7rs7e OmZKksWICNLoStfa184QNGgnmweuUE+JqhAGCnVUw03ACIAWIoH1rURK1JYvoR21 kIIoWctlhFpqFN59hrp4eta+xggkhOIaU4rF3ib95hDC6Lplk4hEENW//mvwzMA= =Js6E -----END PGP SIGNATURE----- --GZVR6ND4mMseVXL/-- From nobody Thu Dec 10 09:36: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 43E521A905A; Thu, 10 Dec 2015 09:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Di8O_DlO1I05; Thu, 10 Dec 2015 09:36:43 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 675101A88D3; Thu, 10 Dec 2015 09:36:43 -0800 (PST) Received: from satsuke.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 17D268011A; Thu, 10 Dec 2015 09:36:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1449769003; bh=efxJZMDyDuD8kYaAr3hV/R85uYGOnNnDUkBA6spSLBM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Dl6ZqucUTfm5tVxXE7CrsWScuYvp2qkq/rR+zggy05MBq3p5ryJLxkjLhoGhocTzC urh+n+PSFqt9lHp2hj24pAn7YEn+PMSNH7Daj6lIHny1Y0jaf1VceMU9BgVjbeMOL4 4kYdOWdHPOTCCgZv4DT6JkDsa9gSNwwDgcMTss5Q= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Steve Atkins In-Reply-To: <20151210172336.GC27258@lapsedordinary.net> Date: Thu, 10 Dec 2015 09:36:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151210144814.GA16386@lapsedordinary.net> <20151210151541.68326.qmail@ary.lan> <20151210164041.GA27258@lapsedordinary.net> <20151210172336.GC27258@lapsedordinary.net> To: ietf-smtp@ietf.org X-Mailer: Apple Mail (2.3112) Archived-At: Cc: shutup@ietf.org Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for something 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, 10 Dec 2015 17:36:44 -0000 > On Dec 10, 2015, at 9:23 AM, Martijn Grooten = wrote: >=20 > On Thu, Dec 10, 2015 at 04:56:29PM +0000, Richard Clayton wrote: >> an IP address generally indicates the ISP and country of origin (but >> there's a number of edge cases) >=20 > The email address does at least indicate the former. Only in the cases where the email address is provided by the access ISP of the user. That's not as common as it was (and the case where all the = email addresses in the domain are used solely by users of the same access ISP is = vanishingly rare). Cheers, Steve From nobody Thu Dec 10 09:43: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 B42CA1A909F; Thu, 10 Dec 2015 09:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.353 X-Spam-Level: * X-Spam-Status: No, score=1.353 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553] 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 hT52y3X99ADv; Thu, 10 Dec 2015 09:43:49 -0800 (PST) Received: from mail.highwayman.com (happyday.demon.co.uk [80.177.121.10]) (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 519841A908B; Thu, 10 Dec 2015 09:43:40 -0800 (PST) Received: from localhost ([127.0.0.1]:33155 helo=happyday.al.cl.cam.ac.uk) by mail.highwayman.com with esmtp (Exim 4.86) (envelope-from ) id 1a75Fi-0005mu-9S; Thu, 10 Dec 2015 17:43:38 +0000 Message-ID: <2dguxzCGmbaWFA0x@highwayman.com> Date: Thu, 10 Dec 2015 17:42:30 +0000 To: Martijn Grooten From: Richard Clayton References: <20151210144814.GA16386@lapsedordinary.net> <20151210151541.68326.qmail@ary.lan> <20151210164041.GA27258@lapsedordinary.net> <20151210172336.GC27258@lapsedordinary.net> In-Reply-To: <20151210172336.GC27258@lapsedordinary.net> MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.03 M Archived-At: Cc: shutup@ietf.org, ietf-smtp@ietf.org Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for something 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, 10 Dec 2015 17:43:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <20151210172336.GC27258@lapsedordinary.net>, Martijn Grooten writes >> for many individuals there is only a short-term linkage between >> themselves and the IP address (think dialup, DHCP systems for broadband >> and carrier grade NAT solutions for mobile) so you can seldom use it for >> long-term tracking of activity ("what else has this person done") > >I have been told that in the case of a home ISP, the linkage lasts long >enough that if you send me a job application email from 1.2.3.4 that a >visit to our website three days ago from 1.2.3.4 was quite likely made >from the same house. My home cable connection has had the same IP for 15 months... but I would expect to get a different IP if I powered the cable modem down for more than a few minutes. There are no general rules here and almost every possible case is common >I believe this is in part why some legislations consider an IP address >personal data. It's not to do with lifetimes per se because there may exist organisations that can link the IP to a person.... the test is any information relating to an identified or identifiable natural person and you should read for a detailed analysis of each of those four elements. And then you can amuse yourself for seeing how the UK failed to transcribe this especially well (so the test is different here) and then note that the EU is almost certainly going to go forward with a Regulation next week (so that the UK can't "cheat" in future) >A "crypgraphic blob" would still be linked to the customer, but not to >any other activity. all recipients of the email (and the blob) will of course become processors of personal data (but we all knew that already, didn't we) - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBVmm5huINNVchEYfiEQLA+ACg1u6NX+1xHYeoNf2tXa8aQyImRJQAmgO0 l7b42AE+91j5SAuHAtBO4ulc =pqqN -----END PGP SIGNATURE----- From nobody Thu Dec 10 09:50: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 D7C971A90AC; Thu, 10 Dec 2015 09:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.043 X-Spam-Level: *** X-Spam-Status: No, score=3.043 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xC7rEC6qEdV; Thu, 10 Dec 2015 09:50:50 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38D331A90C5; Thu, 10 Dec 2015 09:50:49 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tBAHolsN005267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 10 Dec 2015 12:50:47 -0500 To: ietf-smtp@ietf.org References: <20151208204227.62714.qmail@ary.lan> <56689A81.7030401@dcrocker.net> <20151210144814.GA16386@lapsedordinary.net> <55103b70-ca39-4694-92dc-07a17344d485@gulbrandsen.priv.no> <5669A568.6000907@mustelids.ca> <20151210171122.GB27258@lapsedordinary.net> From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <5669BB77.2030000@mustelids.ca> Date: Thu, 10 Dec 2015 12:50:47 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <20151210171122.GB27258@lapsedordinary.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: shutup@ietf.org Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for something 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, 10 Dec 2015 17:50:56 -0000 On 12/10/2015 12:11 PM, Martijn Grooten wrote: > On Thu, Dec 10, 2015 at 11:16:40AM -0500, Chris Lewis wrote: >> There really are no technical differences whatsoever between a >> blackhat and a whitehat trying to protect their identity. The ONLY >> saving grace is that (in the spam space) the blackhat is forced to >> resort to methods that scale high enough for an adequate ROI, while >> the whitehat usually doesn't care that much. > > Most spam filtering - again used in the broad sense - only cares about > the identity of the sending organisation (ISP, company, etc.). And > sometimes not even that. If an email body matches some (fuzzy) > signature, it gets blocked, often regardless of who sent it from where. I would contend that very little spam filtering cares what the identity is at all. The identifier tokens just being more grist for the filtering engine that may help or may not. For example, Bayes doesn't care what the words it scans mean, it looks for statistical similarity with stuff it knows is bad and stuff it knows is good. > It's only when said organisation doesn't do a good enough job of > checking the identity (or the hat colour) of the sender, that being able > to find the actual sender matters to everyone else. Or, sometimes, when you're trying to figure out where it's going to pop up next and/or warn providers of the toxic customer. >> Tor, for example, being a case in point. Tor would be ideal for >> spam. And it was for a bit. Slow, but worked. I don't know whether >> the fact that the tor network became so slow as to be unuseable, or >> that the screams from the "spammed" turned the day, but so few tor >> exit nodes support outbound port 25 nowadays that it isn't a big >> problem. > > If they hadn't all blocked that port (it's the default, I believe) Newbie ;-) It wasn't always that way. How do you think that came to be that way? > then every DNSBL would add the exit nodes; Precisely. > Tor, by design, doesn't hide the > nodes' IP addresses and it's easy to check if a certain IP address is > or was a Tor exit node at a given time. The aforementioned boilerplate describes that in copious detail so as to make it easier for the DNSBL operator to use their exit node list to whitelist them unconditionally no matter what comes out of them. Er, no. We're very polite. We have boilerplate for that too. They also get told that at least we don't treat tor nodes any differently than any other, and a reminder to not co-locate a tor node with their own servers/network and thus share the reputation of the exit node. > If being able to hide (the geolocation of) your submission IP address is > of vital importance, then this is the way to use email. For most people, > this isn't necessary, but it is my belief that at the very least we > should help organisations that wish to protect personal data for all of > its users to do so in a way that doesn't seriously harm the existing > email infrastructure. The tor "group" had to make a similar decision, when it came to the serious harm to the viability of their own infrastructure by what, at the time, was unfettered spam. I2P is going through a similar revolution now - going from a theology of the "bits must be free and more importantly private" to a realization that their future relevance relies on not becoming an infamous source of harm. They have to come up with innovative ways to preserve what they want it to be, in the face of those wishing to pervert it to being a safe haven conduit for their abuse. From nobody Thu Dec 10 10:06:34 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 AB56D1ABD3A for ; Thu, 10 Dec 2015 10:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.138 X-Spam-Level: X-Spam-Status: No, score=-101.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 ZWNAdWnkTTrE for ; Thu, 10 Dec 2015 10:06:24 -0800 (PST) Received: from mail.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id F379D1A92AD for ; Thu, 10 Dec 2015 10:06:16 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2005; t=1449770767; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=D5nVuMHkGEvZWDSYSsHTtDs9UzM=; b=leJ6r6oVxilj0/ijp9UEeLPDaaNGAk79UzrISpyooy3jW9JtaQpj3pHFdO7+sF qwLwHxfn5CFjaDd5aNmTuO5PVOCTRkrf8hboFC/1K1ZBh15aMjhC4q4nI+ZuQLhK OaUfJR74DoAx6Ef1IsYOCpF8hx2uIUft5GtrEbgU5T2v0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4b1) for shutup@ietf.org; Thu, 10 Dec 2015 13:06:07 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4b1) with ESMTP id 1658954335.3.3996; Thu, 10 Dec 2015 13:06:06 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2005; t=1449770643; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=VGK47aT VXFZiEuDmxhuohz8OxnkB3ODJV8g5LbFWUkY=; b=OyfZZ2KSHWOWLtu+3lld/jy PXOuMpCs803k9UcTb22tc1znJROoeIp1HC/SQMkwxYoqg3cQFFgnH+JV0OCSOZWd pQFunYodvlSnInQEGENoc+MGcsEedK6KTZy2ddsAMfdGiMOBa4yPWY5kxDh3Gg+v rEHTewJ7J4pv5bIP81lY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for shutup@ietf.org; Thu, 10 Dec 2015 13:04:03 -0500 Received: from [192.168.1.2] ([99.121.4.202]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 597809055.9.102176; Thu, 10 Dec 2015 13:04:02 -0500 Message-ID: <5669BF07.3000600@isdg.net> Date: Thu, 10 Dec 2015 13:05:59 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Richard Clayton , Martijn Grooten References: <20151210144814.GA16386@lapsedordinary.net> <20151210151541.68326.qmail@ary.lan> <20151210164041.GA27258@lapsedordinary.net> <20151210172336.GC27258@lapsedordinary.net> <2dguxzCGmbaWFA0x@highwayman.com> In-Reply-To: <2dguxzCGmbaWFA0x@highwayman.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: shutup@ietf.org, ietf-smtp@ietf.org Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for something 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, 10 Dec 2015 18:06:26 -0000 On 12/10/2015 12:42 PM, Richard Clayton wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > In message <20151210172336.GC27258@lapsedordinary.net>, Martijn Grooten > writes > >>> for many individuals there is only a short-term linkage between >>> themselves and the IP address (think dialup, DHCP systems for broadband >>> and carrier grade NAT solutions for mobile) so you can seldom use it for >>> long-term tracking of activity ("what else has this person done") >> >> I have been told that in the case of a home ISP, the linkage lasts long >> enough that if you send me a job application email from 1.2.3.4 that a >> visit to our website three days ago from 1.2.3.4 was quite likely made >>from the same house. > > My home cable connection has had the same IP for 15 months... but I > would expect to get a different IP if I powered the cable modem down for > more than a few minutes. I will be surprise if it did. For my home system, my "dynamic" IP has not changed unless the box itself was replaced by my ISP (AT&T). That has happened twice (box replaced) over the last 8-10 years and only then did the IP change. Over those years, there has been times where the boxes were powered off for lengthy periods and to my surprise, and unlike the earlier days, there was never a new IP assigned. > There are no general rules here and almost every possible case is common I personally think the ISP has a contract and business deals with the advertising market to make sure to keep dynamic IP boxes "static" for as long as possible. I'm sure they have deals with the "Facebooks" and "Yahoos" of the world. In any case, I am going to pencil in an new SMTP option in our SMTP server product: [X] Add Receiver Trace Line (o) Show Client IP (_) Mask Client IP I think it is important enough because of the improved (and society acceptable) BI (business intelligence) software in the market today. Thanks -- HLS From nobody Thu Dec 10 10:48: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 2650A1ACD30 for ; Thu, 10 Dec 2015 10:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 GTtg5kAC8Mu6 for ; Thu, 10 Dec 2015 10:48:41 -0800 (PST) Received: from xsmtp04.mail2web.com (xsmtp04.mail2web.com [168.144.250.231]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BADD1ACD04 for ; Thu, 10 Dec 2015 10:48:41 -0800 (PST) Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1a76GV-0000fv-TO for shutup@ietf.org; Thu, 10 Dec 2015 13:48:40 -0500 Received: (qmail 31084 invoked from network); 10 Dec 2015 18:48:30 -0000 Received: from unknown (HELO huitema2) (Authenticated-user:_huitema@huitema.net@[131.107.147.15]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 10 Dec 2015 18:48:30 -0000 From: "Christian Huitema" To: "'John Levine'" , References: <20151210144814.GA16386@lapsedordinary.net> <20151210151541.68326.qmail@ary.lan> In-Reply-To: <20151210151541.68326.qmail@ary.lan> Date: Thu, 10 Dec 2015 10:48:41 -0800 Message-ID: <09ee01d1337b$64881950$2d984bf0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLGihlIx8XgxnwAvMMRHGeScaCZr5zZ4Axw Content-Language: en-us Archived-At: Cc: martijn@lapsedordinary.net Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for something 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, 10 Dec 2015 18:48:43 -0000 On Thursday, December 10, 2015 7:16 AM, John Levine wrote: > ... > >The real question is: would spam filters still be able to do a good > >enough job if we removed these things? > > No, it's not. The question is whether there would be an overall gain in users' > privacy since providers would likely be less able to combat phishing and > other privacy attacks. > > Spam filtering is just part of it, and in this case not where the most important > effects would be. I am not sure I understand correctly, but it seems the reference to phishing is in the context of "impersonated users." Bob receives a mail that appears to come from "Alice@example.com." Everything matches, SPF, DKIM, DMARC. So Bob actually believes the mail comes from Alice, and opens the attachment. But the mail actually comes from the evil Eve, who somehow managed to acquire Alice's password, and submitted the phishing message by authenticating as Alice to Alice's MSA. In that context, if Bob's UA notices that the submission IP comes from Upper Nowheristan instead of the usual Mirrorland, Bob's UA could pop up a warning, or block the message. Is that a correct summary of the concern? -- Christian Huitema From nobody Thu Dec 10 11:36:27 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 92E671AD366 for ; Thu, 10 Dec 2015 11:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.043 X-Spam-Level: *** X-Spam-Status: No, score=3.043 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNEn0PaNMq43 for ; Thu, 10 Dec 2015 11:36:24 -0800 (PST) Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8615F1AD289 for ; Thu, 10 Dec 2015 11:36:24 -0800 (PST) Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tBAJaFNd013774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 10 Dec 2015 14:36:16 -0500 To: Christian Huitema , "'John Levine'" , shutup@ietf.org References: <20151210144814.GA16386@lapsedordinary.net> <20151210151541.68326.qmail@ary.lan> <09ee01d1337b$64881950$2d984bf0$@huitema.net> From: Chris Lewis X-Enigmail-Draft-Status: N1110 Message-ID: <5669D42F.5050502@mustelids.ca> Date: Thu, 10 Dec 2015 14:36:15 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <09ee01d1337b$64881950$2d984bf0$@huitema.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: martijn@lapsedordinary.net Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for something 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, 10 Dec 2015 19:36:25 -0000 On 12/10/2015 01:48 PM, Christian Huitema wrote: > I am not sure I understand correctly, but it seems the reference to phishing > is in the context of "impersonated users." Bob receives a mail that appears > to come from "Alice@example.com." Everything matches, SPF, DKIM, DMARC. So > Bob actually believes the mail comes from Alice, and opens the attachment. > But the mail actually comes from the evil Eve, who somehow managed to > acquire Alice's password, and submitted the phishing message by > authenticating as Alice to Alice's MSA. In that context, if Bob's UA notices > that the submission IP comes from Upper Nowheristan instead of the usual > Mirrorland, Bob's UA could pop up a warning, or block the message. Is that a > correct summary of the concern? If all of these in place world wide (ha!), it would still only apply to a small percentage (generally <10%) of the phishing that tries to impersonate the email address completely. Most phishes don't impersonate email addresses, just the "friendly" part of the From: line if that. How does SPF/DKIM/DMARC help you with? Subject: Alert! Your American Express card has been compromised! From: "AmericanExpress Accounts" [Especially if razzum.bar's DMARC lines up] Right now the highest volume spam of all is blind-recipient spoofing on behalf of various (for the most part non-finance) companies, and the headers are all brand-specific and consistent - except for the DKIM-useful header bits which are just plain random. And infects you (with Dyre/Dridex) if you fall for it - just like phishing, but infection not identity/account being the payload. The lack of a unique id of some kind (relatively static in terms of spam burst durations), forces the ML (or less sophisticated filter) to treat all of the output of a given domain (or MTA) as equal, and it cannot use originator distinction to "help" the content filtering. Which, as we well know, is extraordinarily difficult in the case of 419 and essentially impossible in the case of CEO phishing. From nobody Thu Dec 10 13:19:35 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 C14EC1B2B98 for ; Thu, 10 Dec 2015 13:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 YfJmAf1z_4px for ; Thu, 10 Dec 2015 13:19:33 -0800 (PST) Received: from xsmtp02.mail2web.com (xsmtp02.mail2web.com [168.144.250.215]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B42781B2B7A for ; Thu, 10 Dec 2015 13:19:27 -0800 (PST) Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1a78cY-0002un-28 for shutup@ietf.org; Thu, 10 Dec 2015 16:19:26 -0500 Received: (qmail 1547 invoked from network); 10 Dec 2015 21:19:25 -0000 Received: from unknown (HELO huitema2) (Authenticated-user:_huitema@huitema.net@[131.107.147.15]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 10 Dec 2015 21:19:25 -0000 From: "Christian Huitema" To: "'Chris Lewis'" , "'John Levine'" , References: <20151210144814.GA16386@lapsedordinary.net> <20151210151541.68326.qmail@ary.lan> <09ee01d1337b$64881950$2d984bf0$@huitema.net> <5669D42F.5050502@mustelids.ca> In-Reply-To: <5669D42F.5050502@mustelids.ca> Date: Thu, 10 Dec 2015 13:19:36 -0800 Message-ID: <0a5f01d13390$79625650$6c2702f0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQD3chmnWPwuTgzkQ4BeVDxKF4q5EALGihlIAhgQPdECT1tQbqA+yZaQ Content-Language: en-us Archived-At: Cc: martijn@lapsedordinary.net Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for something 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, 10 Dec 2015 21:19:34 -0000 On Thursday, December 10, 2015 11:36 AM, Chris Lewis wrote: > On 12/10/2015 01:48 PM, Christian Huitema wrote: > > > I am not sure I understand correctly, but it seems the reference to > > phishing is in the context of "impersonated users." Bob receives a > > mail that appears to come from "Alice@example.com." Everything > > matches, SPF, DKIM, DMARC. So Bob actually believes the mail comes from > Alice, and opens the attachment. > > But the mail actually comes from the evil Eve, who somehow managed to > > acquire Alice's password, and submitted the phishing message by > > authenticating as Alice to Alice's MSA. In that context, if Bob's UA > > notices that the submission IP comes from Upper Nowheristan instead of > > the usual Mirrorland, Bob's UA could pop up a warning, or block the > > message. Is that a correct summary of the concern? > > If all of these in place world wide (ha!), it would still only apply to a small > percentage (generally <10%) of the phishing that tries to impersonate the > email address completely. Most phishes don't impersonate email addresses, > just the "friendly" part of the From: line if that. Yes of course. There are many types of attacks, the "mass market" scammers use crude techniques, and they probably account for the biggest volumes. But these are not the only ones that we care about. The more sophisticated "spear phishing" attacks commonly include detailed reconnaissance of the target and their relations, precisely of the type "hacking Alice to get to Bob." I think that's what you refer to when you mention "CEO phishing." We could argue that checking the origin IP is only one of the many possible ways to harden mail systems against phishing, and that alternatives could be just as efficient. Maybe. But first, I would like to be sure that we understand the scenarios in which the origin IP address is used to prevent phishing. -- Christian Huitema From nobody Sat Dec 12 18:19:01 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 189031A6F20 for ; Sat, 12 Dec 2015 18:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 KCScG-_hkbPc for ; Sat, 12 Dec 2015 18:18:59 -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 F21D51A6F1E for ; Sat, 12 Dec 2015 18:18:58 -0800 (PST) Received: (qmail 4787 invoked from network); 13 Dec 2015 02:18:56 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 13 Dec 2015 02:18:56 -0000 Date: 13 Dec 2015 02:18:34 -0000 Message-ID: <20151213021834.1676.qmail@ary.lan> From: "John Levine" To: ietf-smtp@ietf.org, shutup@ietf.org In-Reply-To: <566CC58E.8000703@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: dcrocker@bbiw.net Subject: Re: [Shutup] [ietf-smtp] persistent identifiers, was Proposed Charter 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, 13 Dec 2015 02:19:00 -0000 >1. Phone number: in theoretical terms it works as an identifier. >However there have been attempts to get it used as an alternative to an >email address and there's been no traction. >And BTW, phone number only sometimes -- maybe >even often, but not always -- maps to a specific individual... How many apps do you use on a phone or tablet? Lots and lots of them use your mobile phone number as the identifier, since everyone knows his own number, and mobile phones are quite personal. Of course, bad programmers are everywhere, and since my tablet has no phone number, well, um. I'm certainly not saying it's a great idea, but it's got plenty of traction. R's, John From nobody Sun Dec 13 07:11: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 CD3FC1AD0B1; Sun, 13 Dec 2015 07:11:12 -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 z_6zWmaICx8s; Sun, 13 Dec 2015 07:11:11 -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 C72B41AD0AF; Sun, 13 Dec 2015 07:11:11 -0800 (PST) Received: from [192.168.1.99] (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 tBDFBAnQ004109 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sun, 13 Dec 2015 07:11:10 -0800 References: <20151213021834.1676.qmail@ary.lan> To: John Levine From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <566D8AAB.1090209@dcrocker.net> Date: Sun, 13 Dec 2015 07:11:39 -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: <20151213021834.1676.qmail@ary.lan> 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, 13 Dec 2015 07:11:11 -0800 (PST) Archived-At: Cc: shutup@ietf.org, ietf-smtp@ietf.org Subject: Re: [Shutup] [ietf-smtp] persistent identifiers, was Proposed Charter 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, 13 Dec 2015 15:11:13 -0000 On 12/12/2015 6:18 PM, John Levine wrote: > How many apps do you use on a phone or tablet? Lots and lots of them > use your mobile phone number as the identifier, since everyone knows > his own number, The problem is that everyone does not know /every else's/. That's the usability issue. Acquisition and recall by /others/. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net