From nobody Mon May 7 10:15:01 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C6E1275AB for ; Mon, 7 May 2018 10:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 5zI1Sqm2IsMN for ; Mon, 7 May 2018 10:14:57 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70D371273E2 for ; Mon, 7 May 2018 10:14:56 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id DE0DD1C9E7B for ; Mon, 7 May 2018 10:14:54 -0700 (PDT) Received: from mail-it0-f47.google.com (mail-it0-f47.google.com [209.85.214.47]) by c8a.amsl.com (Postfix) with ESMTPSA id BC0161C9A5C for ; Mon, 7 May 2018 10:14:54 -0700 (PDT) Received: by mail-it0-f47.google.com with SMTP id q72-v6so2708097itc.0 for ; Mon, 07 May 2018 10:14:56 -0700 (PDT) X-Gm-Message-State: ALQs6tAhtO5rGwfq8PqC65vBMQXAmetb9penxNuirPHWuNPQhSsYEfTK 71YarMoBlv0WpJyLiJfuIOiwcyEtU7RYBKXXB3w= X-Google-Smtp-Source: AB8JxZpPF/MJO+feTiUTcAVJdMwTE3rwH1Dvev5UfBnJHRW2fhfVIBh3zCR2HRa/oJsKvJ4Ii8WYORpuaUH9m6WAjbo= X-Received: by 2002:a24:d82:: with SMTP id 124-v6mr2156299itx.90.1525713295591; Mon, 07 May 2018 10:14:55 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:1c49:0:0:0:0:0 with HTTP; Mon, 7 May 2018 10:14:35 -0700 (PDT) From: Glen Date: Mon, 7 May 2018 10:14:35 -0700 X-Gmail-Original-Message-ID: Message-ID: To: tools-development@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TOOLS-DEVELOPMENT] OpenSuse 42.3 - IETF X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 17:14:59 -0000 Dear Tools Development Team - The current version of OpenSuse used by the ISOC ELIST servers, 42.2, has now reached end of life, and been replaced by a new version, 42.3. I would like to start the discussion about upgrading the IETF servers to this version. In a normal world, this upgrade is essentially a larger version of the normal system maintenance we perform routinely. The servers themselves are generally up and online during the upgrade process - a process which takes approximately 3 hours to download and install. Minor interruptions during the process will occur as services restart - a minute or two here or there. As things restart, our engineers check to make sure that all services are running and working, and that all else is in order. We end the process with the usual reboot and final post-reboot check. I've upgraded 14 servers in various configurations from 42.2 to 42.3 so far, and there have been zero problems in all of those cases. But.... given the large number of moving parts and customized software packages in operation on the IETF's servers.... we definitely want to take extra care with this process here. As you know we have a primary production server and two hot backup servers, and so our plan would of course be to upgrade the hot backup servers first, and check those for any anomalies, before upgrading the production machine in place. And of course, despite all efforts, some things may still be impacted, so we would want to do this at a time when all of our engineers are online and Robert and Henrik can also be online, so that we can all work together on resolving any last-minute items that may come up. Can we please start the discussion about this process? This is not a fire, but something I do think we should undertake soon, since it does seem to be less disruptive than updates generally are. OpenSuse 42.2 was retired from support a few months ago. OpenSuse 42.3 is expected to be maintained until January 2019. Thank you, Glen -- Glen Barney IT Director AMS (IETF Secretariat) From nobody Tue May 8 07:04:50 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC9112E890 for ; Tue, 8 May 2018 07:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=JY5dgcwl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mYvNzH/v 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 L6SzoH7sxC-d for ; Tue, 8 May 2018 07:04:42 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9093B12E88E for ; Tue, 8 May 2018 07:04:42 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 0014B227DE for ; Tue, 8 May 2018 10:04:41 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Tue, 08 May 2018 10:04:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=sNDNTg2v2+7PlY9rYwgAJeddU6vLt GTTc09Q7IA+NEQ=; b=JY5dgcwlOFT4lG8MHEWiWRt9cLJQ8yTZWZapYfApMjnhT fAlG13rlDX0gMnveR/aDfJKDmNQOFS0bB1+/enVLmGORMUrx4mNGGpRpoBUGW/zG +DHE8NeTM1QIGos4oDRzRjE/awIovRsurwCtnatGZQFu7jFW7Pt2NQY/IxgOAvbW nHNfdBz2mK1rxRF7DvPAwKX8lrFCzadBZF3Q0Eurgn0CKPwDnQYOHl1MO+S/GIfC a6DZbHeZglisgBkCpHyEQ8nLxQrYnc+07qgrJWLPZCSN34lYg+uauqae5lbxKupw wlNAWfxLX4qH8RKOm2tqn5IhI9z6AuDWy/sS2ZrqA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=sNDNTg 2v2+7PlY9rYwgAJeddU6vLtGTTc09Q7IA+NEQ=; b=mYvNzH/vOuvDjTo3kOmbou vxEnlOv4CVsmaOz/hvex7r7Myd6+Ts0kfc46HEWDZzN57a2jL6O0jr6Ccblsk3nM AwgMNxWTjD2k0YziwaRTbYNY7Qq04n7M/qkGkjFEwmLWPCnB9IuDhh4QGz420bcK OHjGvasHDmcVasI0BTevfQxwO6efv/F7RI48j2S+9LPF7UgJg2+/59YmUqz0dCai doeyEC2buCcEoOUFbX6LRUYJMDZTVSV7FYkU7IwcFewAWk2MM9yTW4P5QjTphfdr d05o3aFiauJa1miNTM5KNJsXY+GT1ajLDwv5hVLMWJCKNJdgAtH9w2oMXjU22zqg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D389F9E0E7; Tue, 8 May 2018 10:04:41 -0400 (EDT) Message-Id: <1525788281.3600721.1364842648.031F6C57@webmail.messagingengine.com> From: Alexey Melnikov To: tools-development@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-62b61488 References: Date: Tue, 08 May 2018 15:04:41 +0100 In-Reply-To: Archived-At: Subject: [TOOLS-DEVELOPMENT] DMARC status (was Re: Tools Call Agenda -- 8 May 2018 at 1:00 Eastern) X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 14:04:49 -0000 Hi all, On Thu, Apr 26, 2018, at 9:48 PM, Russ Housley wrote: > 4. Server Infrastructure > - IESG discussions of DMARC -- Henrik and Alexey > -- Deployed for volunteer WGs. Is it ready for all mail lists? My summary of the current DMARC workaround state is as follows: 1) DMARC workaround code works, in particular: a) messages from p=reject domains are rewritten, so that they have @dmarc.ietf.org From email addresses. b) replying to such mapped email addresses works c) I haven't seen any DMARC related bounces in response to email sent from mapped @dmarc.ietf.org addresses. d) The message duplicate problem was solved, as well as the temporary message loss that was experienced a week ago. e) It is hard to assess how much "addressbook pollution"(*) we get from @dmarc.ietf.org addresses. I wish I knew answer to this question, but this is rather Mail User Agent specific. 2) It is possible to send an email to an algorithmically constructed @dmarc.ietf.org address even if the email address from which it was constructed doesn't come from p=reject DMARC domain. In fact, the original email doesn't even have to be a subscriber of an IETF mailing list (Henrik, is this correct?). This is effectively an obscure form of an open relay, so we need to fix that. Henrik has a proposal how to fix that. Preventing the open relay problem was not clearly specified in requirements for Henrik's work, we only realized that this is a problem very recently. A fix proposed by Henrik will change the mapping, so it will invalidate all already instantiated mapped addresses @dmarc.ietf.org. Henrik will correct me, but I think this means that replies to them will bounce. I suggest if we want to change the format, we change it now before deploying DMARC workaround to more mailing lists. This will minimize the number of complains that people will have about bounces. 3) I've sent a separate email saying that in order to be able to move to ARC (which is a better fix), we should keep ability to control which IETF mailing lists are subject to DMARC workaround. This is trivial, we just need not to forget to preserve this. Best Regards, Alexey (*) - i.e. emails from "mapped(A)" (where "A" is an email address from a p=reject DMARC domain) might appear in recipients addressbooks together or instead of email address "A". From nobody Tue May 8 08:48:00 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED7512E8FA for ; Tue, 8 May 2018 08:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 QHj212cFuIwg for ; Tue, 8 May 2018 08:47:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44FA8127078 for ; Tue, 8 May 2018 08:47:57 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:59357 helo=[192.168.1.120]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1fG4pz-0005bl-9Q; Tue, 08 May 2018 08:47:51 -0700 To: Alexey Melnikov , tools-development@ietf.org References: <1525788281.3600721.1364842648.031F6C57@webmail.messagingengine.com> From: Henrik Levkowetz Message-ID: Date: Tue, 8 May 2018 17:47:25 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1525788281.3600721.1364842648.031F6C57@webmail.messagingengine.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NMcunBNe5BHa5aO7ue6n4NVtbPPCMACxB" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: tools-development@ietf.org, aamelnikov@fastmail.fm X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] DMARC status (was Re: Tools Call Agenda -- 8 May 2018 at 1:00 Eastern) X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 15:48:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NMcunBNe5BHa5aO7ue6n4NVtbPPCMACxB Content-Type: multipart/mixed; boundary="2f0eTPtslpAOiVL1F8tndU6vXsqe0gBs3"; protected-headers="v1" From: Henrik Levkowetz To: Alexey Melnikov , tools-development@ietf.org Message-ID: Subject: Re: [TOOLS-DEVELOPMENT] DMARC status (was Re: Tools Call Agenda -- 8 May 2018 at 1:00 Eastern) References: <1525788281.3600721.1364842648.031F6C57@webmail.messagingengine.com> In-Reply-To: <1525788281.3600721.1364842648.031F6C57@webmail.messagingengine.com> --2f0eTPtslpAOiVL1F8tndU6vXsqe0gBs3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Supplementary info inline: On 2018-05-08 16:04, Alexey Melnikov wrote: > Hi all, >=20 > On Thu, Apr 26, 2018, at 9:48 PM, Russ Housley wrote: >=20 >> 4. Server Infrastructure >> - IESG discussions of DMARC -- Henrik and Alexey >> -- Deployed for volunteer WGs. Is it ready for all mail lists? >=20 > My summary of the current DMARC workaround state is as follows: >=20 > 1) DMARC workaround code works, in particular: >=20 > a) messages from p=3Dreject domains are rewritten, so that they have @d= marc.ietf.org From email addresses. > b) replying to such mapped email addresses works > c) I haven't seen any DMARC related bounces in response to email sent f= rom mapped @dmarc.ietf.org addresses. > d) The message duplicate problem was solved, as well as the temporary m= essage loss that was experienced a week ago. > e) It is hard to assess how much "addressbook pollution"(*) we get from= @dmarc.ietf.org addresses. I wish I knew answer to this question, but th= is is rather Mail User Agent specific. >=20 > 2) It is possible to send an email to an algorithmically constructed > @dmarc.ietf.org address even if the email address from which it was > constructed doesn't come from p=3Dreject DMARC domain. In fact, the > original email doesn't even have to be a subscriber of an IETF > mailing list (Henrik, is this correct?). Yes, that's right. > This is effectively an > obscure form of an open relay, so we need to fix that. Henrik has a > proposal how to fix that. >=20 > Preventing the open relay problem was not clearly specified in > requirements for Henrik's work, we only realized that this is a > problem very recently. A fix proposed by Henrik will change the > mapping, so it will invalidate all already instantiated mapped > addresses @dmarc.ietf.org. Henrik will correct me, but I think this > means that replies to them will bounce. Yes. > I suggest if we want to > change the format, we change it now before deploying DMARC workaround > to more mailing lists. This will minimize the number of complains > that people will have about bounces. >=20 > 3) I've sent a separate email saying that in order to be able to move > to ARC (which is a better fix), we should keep ability to control > which IETF mailing lists are subject to DMARC workaround. This is > trivial, we just need not to forget to preserve this. Ack. This is a config setting for the dmarc rewrite workaround. Best regards, Henrik --2f0eTPtslpAOiVL1F8tndU6vXsqe0gBs3-- --NMcunBNe5BHa5aO7ue6n4NVtbPPCMACxB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlrxxo0ACgkQTptXS4+7 FxrF5RAAom4mSDrfuG+j8briatjVNOTyL4KXZFU0JxDKB/cCRLbRKbkZXZlXYKX5 +WsfS7JB0CnNYIKkNeviQ6Vj4H9fD0BguETD27c3KXPL0zIbaIZ6m5vkWEdXl+6Q QC4VwosVcrU0rFcEWqd+gp3pVDoUJL2nz/QxfT0e5dC0QKCNGaIWqJy2lbl4krEH Gw1r7elLHVriN8IBucZTIwETErcgdQ8mZJSsUTYDIg8CiYJb6AIlExaEqkPiqTeI pn/NUNx5SeLYRQBtu4i5LMHAHXmCh56YqXx40weB7nQ2ZVHKWGeI/gsEQahG7CW9 gRMEs+fM/EEVrNj7VxXP4c4YdYAwYMnv5DAHcpLYirtTlV0qB+zOAWLuKCaqprDi A4ft0bDtzTVpcZmIhqMfMIjFkjw4U4bpVLxla7SK078epPHVO/hFnnO6es+EcEWe R2ndotTT+gq/Vr19TXJxCbZ0gSnd11zFrhDX99Q4omFiZQ7xg5ZWJmV/aYtgf9PK tRYDmUOWynNpPbhvGbuHU3Whq8Px5FMBZSg17jcLjPFA770JQu7/4nPSC70hb6Iw m4oaUHrT8fIQo5wThKjQUBWcGyTy2QAhfGnPPbfLWouEKx0dmJqPoStZXir3D2Iz 6iRRu13WdM2w2Imp986eQynHjnQrkYb625Qj7ozJqsIwzoLonCY= =tcjd -----END PGP SIGNATURE----- --NMcunBNe5BHa5aO7ue6n4NVtbPPCMACxB-- From nobody Tue May 8 09:27:19 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377E012E9DD for ; Tue, 8 May 2018 09:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 15CE2R5A4EV2 for ; Tue, 8 May 2018 09:27:15 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5803B12E9D9 for ; Tue, 8 May 2018 09:27:15 -0700 (PDT) Received: from [10.59.35.156] (mobile-166-137-216-106.mycingular.net [166.137.216.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w48GR9uB018726 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 8 May 2018 11:27:11 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-137-216-106.mycingular.net [166.137.216.106] claimed to be [10.59.35.156] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Robert Sparks X-Mailer: iPhone Mail (15C202) In-Reply-To: Date: Tue, 8 May 2018 11:27:04 -0500 Cc: Alexey Melnikov , tools-development@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <23E0901F-CC7C-4770-A2F6-45C98FE7EA78@nostrum.com> References: <1525788281.3600721.1364842648.031F6C57@webmail.messagingengine.com> To: Henrik Levkowetz Archived-At: Subject: [TOOLS-DEVELOPMENT] Late regrets (was Re: DMARC status (was Re: Tools Call Agenda -- 8 May 2018 at 1:00 Eastern)) X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 16:27:17 -0000 Things have worked out such that I wont be able to join today=E2=80=99s call= (i=E2=80=99m fine, its travel related). Apologies for the last minute notic= e.=20 Sent from my iPhone > On May 8, 2018, at 10:47 AM, Henrik Levkowetz wrote= : >=20 > Supplementary info inline: >=20 >> On 2018-05-08 16:04, Alexey Melnikov wrote: >> Hi all, >>=20 >>> On Thu, Apr 26, 2018, at 9:48 PM, Russ Housley wrote: >>>=20 >>> 4. Server Infrastructure >>> - IESG discussions of DMARC -- Henrik and Alexey >>> -- Deployed for volunteer WGs. Is it ready for all mail lists? >>=20 >> My summary of the current DMARC workaround state is as follows: >>=20 >> 1) DMARC workaround code works, in particular: >>=20 >> a) messages from p=3Dreject domains are rewritten, so that they have @dma= rc.ietf.org =46rom email addresses. >> b) replying to such mapped email addresses works >> c) I haven't seen any DMARC related bounces in response to email sent fro= m mapped @dmarc.ietf.org addresses. >> d) The message duplicate problem was solved, as well as the temporary mes= sage loss that was experienced a week ago. >> e) It is hard to assess how much "addressbook pollution"(*) we get from @= dmarc.ietf.org addresses. I wish I knew answer to this question, but this is= rather Mail User Agent specific. >>=20 >> 2) It is possible to send an email to an algorithmically constructed >> @dmarc.ietf.org address even if the email address from which it was >> constructed doesn't come from p=3Dreject DMARC domain. In fact, the >> original email doesn't even have to be a subscriber of an IETF >> mailing list (Henrik, is this correct?). >=20 > Yes, that's right. >=20 >> This is effectively an >> obscure form of an open relay, so we need to fix that. Henrik has a >> proposal how to fix that. >>=20 >> Preventing the open relay problem was not clearly specified in >> requirements for Henrik's work, we only realized that this is a >> problem very recently. A fix proposed by Henrik will change the >> mapping, so it will invalidate all already instantiated mapped >> addresses @dmarc.ietf.org. Henrik will correct me, but I think this >> means that replies to them will bounce. >=20 > Yes. >=20 >> I suggest if we want to >> change the format, we change it now before deploying DMARC workaround >> to more mailing lists. This will minimize the number of complains >> that people will have about bounces. >>=20 >> 3) I've sent a separate email saying that in order to be able to move >> to ARC (which is a better fix), we should keep ability to control >> which IETF mailing lists are subject to DMARC workaround. This is >> trivial, we just need not to forget to preserve this. >=20 > Ack. This is a config setting for the dmarc rewrite workaround. >=20 > Best regards, >=20 > Henrik >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development From nobody Tue May 8 09:49:51 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA14612EA74 for ; Tue, 8 May 2018 09:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 T9t7FrzS9biX for ; Tue, 8 May 2018 09:49:48 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD5B12EA58 for ; Tue, 8 May 2018 09:49:48 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:59592 helo=[192.168.1.120]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1fG5o9-0007ai-FM; Tue, 08 May 2018 09:49:46 -0700 To: Russ Housley , IETF Tools Development References: From: Henrik Levkowetz Message-ID: <69687df1-6790-6e71-d7e4-c8806f18564d@levkowetz.com> Date: Tue, 8 May 2018 18:49:35 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Tq1Ee8QP5URJFJIcQhMD3vbM85uhpKJKv" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: tools-development@ietf.org, housley@vigilsec.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 8 May 2018 at 1:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 16:49:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Tq1Ee8QP5URJFJIcQhMD3vbM85uhpKJKv Content-Type: multipart/mixed; boundary="SsP8nv2fnm6iQjrf4qR9ngTcP6qLLhtiG"; protected-headers="v1" From: Henrik Levkowetz To: Russ Housley , IETF Tools Development Message-ID: <69687df1-6790-6e71-d7e4-c8806f18564d@levkowetz.com> Subject: Re: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 8 May 2018 at 1:00 Eastern References: In-Reply-To: --SsP8nv2fnm6iQjrf4qR9ngTcP6qLLhtiG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Some late notes: On 2018-04-26 22:48, Russ Housley wrote: > Tools Call Agenda -- 8 May 2018 at 1:00 Eastern >=20 >=20 > JOIN WEBEX MEETING > https://ietf.webex.com/ietf/j.php?MTID=3Dm440dd848726339c03e605b9956e38= bac > Meeting number (access code): 640 103 570 > Meeting password: tools >=20 > JOIN BY PHONE > 1-877-668-4493 Call-in toll free number (US/Canada)=20 > 1-650-479-3208 Call-in toll number (US/Canada) > Meeting number (access code): 640 103 570 > Meeting password: tools >=20 >=20 > 1. Datatracker Projects > - Expected Datatracker Releases -- Robert and Henrik > -- http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan This has been adjusted to match the expected GDPR work. > - GDPR Compliance -- Robert and Henrik 5 of 8 work items are done; this covers most of the datatracker model and= infrastructure changes. What remains is mostly GUI-related. Should be done within about a week; release before the GDPR May 25th deadline shoul= d be easy. > 2. Community & Other Projects > - Discontinue MonArch email archives -- Robert > -- Community clearly still likes MonArch speed Ryan has made good progress on static mailarchive.ietf.org pages with CDN support. Gives a definitely snappy feel. Ryan can say more. > 3. RFC Services Projects > - RFC Format Contracts -- Heather and Robert > -- IDnits > -- Publication Formatter > -- Text Submission > -- RFClint > -- SVGcheck > -- XMLdiff >=20 > 4. Server Infrastructure > - IESG discussions of DMARC -- Henrik and Alexey > -- Deployed for volunteer WGs. Is it ready for all mail lists? Alexey sent a separate note about the current status. Henrik > 5. Parking Lot > - Prepare the RFC Production Center code for publication >=20 > 6. AOB >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development >=20 --SsP8nv2fnm6iQjrf4qR9ngTcP6qLLhtiG-- --Tq1Ee8QP5URJFJIcQhMD3vbM85uhpKJKv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlrx1R8ACgkQTptXS4+7 FxqqGA//VTTfK9rlMXqNdvAWSCRYf6lZqScnnCT1a5KkVQndn85qMxfepAzgFl2D kYvOidfvduqg+3pfpWxREb1DBRitCLU7lDnTODHskRqw1lus90KOdiqhX01UPM4O /XFT8/2y4Gt9N4E+Xzw5NHd6VdxPOyvcWkRIVCTGewd8V0zzW3Ujp0lKbA580JjK qcj7mRk0KaOQzGtSpi4987XEu0bVrtswmjqKNE6GpwD4S2NhKIOsTme9UbHYmCA/ icAr4y48+FAqwtbWiKVZWprWmoZ+Na2H8+asZYKz6hC2hGUaG8CRpp33dghuSmNF DTxWxsHLuEgU2C7Df3SESP+Dtytl6yoOX1zMm8G6Imgz6mx0ipnQVDnchAgMnG72 knSz3YOnbJtPTvoYFXj0iyxgzVqOKRCeoMOt140PNI+8buaHFv6YJH/ER4uoGPJQ C3YoQl2vNwLN21QVzMd9lqV3x6zeHGU2eAU7rAuy0Kji5pQNRL1/HjW4CThMChAo ldol8wUBe94JT1b/ogLRDkfKrTT+IO88T6M5+hA71HNWujdLeADwDaon3R1s5iM6 mw7d7ZR35TbcdClFSEfzYO3CgE6c700C50UsJI0s9N8gJhasMFN7FOqWZ1XmxcGv UcCmyl/IXxdxQwhGWft5tf8/pSAx2Zq1+37R0mfTEf0QPWzIVQg= =Pve7 -----END PGP SIGNATURE----- --Tq1Ee8QP5URJFJIcQhMD3vbM85uhpKJKv-- From nobody Tue May 8 09:50:37 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD92212EA64 for ; Tue, 8 May 2018 09:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 4JH0RTiBUhgK for ; Tue, 8 May 2018 09:50:34 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C353512EA58 for ; Tue, 8 May 2018 09:50:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A2646300A07 for ; Tue, 8 May 2018 12:50:31 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TvCCRHaXd1Mk for ; Tue, 8 May 2018 12:50:30 -0400 (EDT) Received: from [192.168.100.30] (unknown [209.65.107.211]) by mail.smeinc.net (Postfix) with ESMTPSA id D9FCD3009FB; Tue, 8 May 2018 12:50:29 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <1525788281.3600721.1364842648.031F6C57@webmail.messagingengine.com> Date: Tue, 8 May 2018 12:50:33 -0400 Cc: IETF Tools Development Content-Transfer-Encoding: quoted-printable Message-Id: References: <1525788281.3600721.1364842648.031F6C57@webmail.messagingengine.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] DMARC status (was Re: Tools Call Agenda -- 8 May 2018 at 1:00 Eastern) X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 16:50:36 -0000 Alexey: I do not think we need to wait for the open relay fix before deploying = to all mail lists. Do you agree? Russ > On May 8, 2018, at 10:04 AM, Alexey Melnikov = wrote: >=20 > Hi all, >=20 > On Thu, Apr 26, 2018, at 9:48 PM, Russ Housley wrote: >=20 >> 4. Server Infrastructure >> - IESG discussions of DMARC -- Henrik and Alexey >> -- Deployed for volunteer WGs. Is it ready for all mail lists? >=20 > My summary of the current DMARC workaround state is as follows: >=20 > 1) DMARC workaround code works, in particular: >=20 > a) messages from p=3Dreject domains are rewritten, so that they have = @dmarc.ietf.org =46rom email addresses. > b) replying to such mapped email addresses works > c) I haven't seen any DMARC related bounces in response to email sent = from mapped @dmarc.ietf.org addresses. > d) The message duplicate problem was solved, as well as the temporary = message loss that was experienced a week ago. > e) It is hard to assess how much "addressbook pollution"(*) we get = from @dmarc.ietf.org addresses. I wish I knew answer to this question, = but this is rather Mail User Agent specific. >=20 > 2) It is possible to send an email to an algorithmically constructed = @dmarc.ietf.org address even if the email address from which it was = constructed doesn't come from p=3Dreject DMARC domain. In fact, the = original email doesn't even have to be a subscriber of an IETF mailing = list (Henrik, is this correct?). This is effectively an obscure form of = an open relay, so we need to fix that. Henrik has a proposal how to fix = that. >=20 > Preventing the open relay problem was not clearly specified in = requirements for Henrik's work, we only realized that this is a problem = very recently. A fix proposed by Henrik will change the mapping, so it = will invalidate all already instantiated mapped addresses = @dmarc.ietf.org. Henrik will correct me, but I think this means that = replies to them will bounce. I suggest if we want to change the format, = we change it now before deploying DMARC workaround to more mailing = lists. This will minimize the number of complains that people will have = about bounces. >=20 > 3) I've sent a separate email saying that in order to be able to move = to ARC (which is a better fix), we should keep ability to control which = IETF mailing lists are subject to DMARC workaround. This is trivial, we = just need not to forget to preserve this. >=20 > Best Regards, > Alexey >=20 > (*) - i.e. emails from "mapped(A)" (where "A" is an email address from = a p=3Dreject DMARC domain) might appear in recipients addressbooks = together or instead of email address "A". From nobody Tue May 8 09:54:40 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8197B12EA56 for ; Tue, 8 May 2018 09:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=nWAlW2+j; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KG6BbY30 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 DS3evAkvgw9U for ; Tue, 8 May 2018 09:54:37 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F0B12EA64 for ; Tue, 8 May 2018 09:54:36 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1D6882254C; Tue, 8 May 2018 12:54:36 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Tue, 08 May 2018 12:54:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=9lx77iHHHTF/8kgDN5g5GHh7t79gf wh0rw+0rrOFz+I=; b=nWAlW2+jcCu/FraYzpvBuvtrqCUBBegYBbNLaT/nYyUU6 0P6T3usPmMOazbEG70nRXyRwviAzC8f4jvb9bd00xLlsCDbqKthPMheBbmh3p9FA 0NSt2/pmOM2AKIlK6Jb5YCnxlaBQv6ahSydV/rFZJl3OWl+YXuOI/3NjFuUqfyX/ sBxz65iul2/F0gY8P3U0GIlA/XHjn7B3ws/h97LkI+APhOynrIhtfcypuL5ZG4fW aJndGNlfckSFXVnmxxdu2QV/k/wWN/c18SFdkQ2Efx/lE7kdhvHoboNxEVfQNqB5 7WjdpmuDH4uMiPf34gr91CSFG8Zb1QCwZXq1U+isQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=9lx77i HHHTF/8kgDN5g5GHh7t79gfwh0rw+0rrOFz+I=; b=KG6BbY30wcNO0uHethSwif Q5swAkfMyK4cluIwreTYKdU6xs5iD0/V2Qo9vM1ZHjir1mF1Z1rVRKw6VwWfcHly AbZdmuQCmMJH8hvYAvhuXNWSdY906H28JUpweZZE/xYfE7vaRQ5+zK44juSoA7bo 7ffLuOaOzWsyXOPYDgmVhSS29x4/QmbVBI0tsIY9kmG4moN59FfiPZer2syySWhx QdwpoJ1HihogzOTqbboonb5SCuAQCrLOr07NPr9lWxEgyy9acP5/JMmaS8Tn0w29 LlH9FzQ3v/e9hnBpwCje+UquvKWiXtG9T0vFqAtXI8HwphTyrrRxuzfFm0pTBQtQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id F05039E0DB; Tue, 8 May 2018 12:54:35 -0400 (EDT) Message-Id: <1525798475.162289.1365067976.6EF8C0D4@webmail.messagingengine.com> From: Alexey Melnikov To: Russ Housley Cc: IETF Tools Development MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-62b61488 Date: Tue, 08 May 2018 17:54:35 +0100 In-Reply-To: References: <1525788281.3600721.1364842648.031F6C57@webmail.messagingengine.com> Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] DMARC status (was Re: Tools Call Agenda -- 8 May 2018 at 1:00 Eastern) X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 16:54:38 -0000 Russ, On Tue, May 8, 2018, at 5:50 PM, Russ Housley wrote: > Alexey: > > I do not think we need to wait for the open relay fix before deploying > to all mail lists. Do you agree? I don't agree. I am Ok with having open relay as long as it is fixed quickly. So we can deploy without the fix, as long as the mapping format is changed before we deploy to all mail lists. However, once the format is changed, I think Henrik will be nearly done with the fix anyway. > > On May 8, 2018, at 10:04 AM, Alexey Melnikov wrote: > > > > Hi all, > > > > On Thu, Apr 26, 2018, at 9:48 PM, Russ Housley wrote: > > > >> 4. Server Infrastructure > >> - IESG discussions of DMARC -- Henrik and Alexey > >> -- Deployed for volunteer WGs. Is it ready for all mail lists? > > > > My summary of the current DMARC workaround state is as follows: > > > > 1) DMARC workaround code works, in particular: > > > > a) messages from p=reject domains are rewritten, so that they have @dmarc.ietf.org From email addresses. > > b) replying to such mapped email addresses works > > c) I haven't seen any DMARC related bounces in response to email sent from mapped @dmarc.ietf.org addresses. > > d) The message duplicate problem was solved, as well as the temporary message loss that was experienced a week ago. > > e) It is hard to assess how much "addressbook pollution"(*) we get from @dmarc.ietf.org addresses. I wish I knew answer to this question, but this is rather Mail User Agent specific. > > > > 2) It is possible to send an email to an algorithmically constructed @dmarc.ietf.org address even if the email address from which it was constructed doesn't come from p=reject DMARC domain. In fact, the original email doesn't even have to be a subscriber of an IETF mailing list (Henrik, is this correct?). This is effectively an obscure form of an open relay, so we need to fix that. Henrik has a proposal how to fix that. > > > > Preventing the open relay problem was not clearly specified in requirements for Henrik's work, we only realized that this is a problem very recently. A fix proposed by Henrik will change the mapping, so it will invalidate all already instantiated mapped addresses @dmarc.ietf.org. Henrik will correct me, but I think this means that replies to them will bounce. I suggest if we want to change the format, we change it now before deploying DMARC workaround to more mailing lists. This will minimize the number of complains that people will have about bounces. > > > > 3) I've sent a separate email saying that in order to be able to move to ARC (which is a better fix), we should keep ability to control which IETF mailing lists are subject to DMARC workaround. This is trivial, we just need not to forget to preserve this. > > > > Best Regards, > > Alexey > > > > (*) - i.e. emails from "mapped(A)" (where "A" is an email address from a p=reject DMARC domain) might appear in recipients addressbooks together or instead of email address "A". > From nobody Tue May 8 10:01:17 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADB2126E64 for ; Tue, 8 May 2018 10:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 axAIY9rGaBUB for ; Tue, 8 May 2018 10:01:15 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11A41124207 for ; Tue, 8 May 2018 10:01:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E90DC300A07 for ; Tue, 8 May 2018 13:01:12 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zkm9BBNWNd9y for ; Tue, 8 May 2018 13:01:11 -0400 (EDT) Received: from [192.168.100.30] (unknown [209.65.107.211]) by mail.smeinc.net (Postfix) with ESMTPSA id 85A433004D6; Tue, 8 May 2018 13:01:11 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <1525798475.162289.1365067976.6EF8C0D4@webmail.messagingengine.com> Date: Tue, 8 May 2018 13:01:11 -0400 Cc: IETF Tools Development Content-Transfer-Encoding: quoted-printable Message-Id: <22DED90E-66D8-485E-B039-2BDB8DB94BBC@vigilsec.com> References: <1525788281.3600721.1364842648.031F6C57@webmail.messagingengine.com> <1525798475.162289.1365067976.6EF8C0D4@webmail.messagingengine.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] DMARC status (was Re: Tools Call Agenda -- 8 May 2018 at 1:00 Eastern) X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 17:01:16 -0000 > On May 8, 2018, at 12:54 PM, Alexey Melnikov = wrote: >=20 > Russ, >=20 > On Tue, May 8, 2018, at 5:50 PM, Russ Housley wrote: >> Alexey: >>=20 >> I do not think we need to wait for the open relay fix before = deploying=20 >> to all mail lists. Do you agree? >=20 > I don't agree. >=20 > I am Ok with having open relay as long as it is fixed quickly. So we = can deploy without the fix, as long as the mapping format is changed = before we deploy to all mail lists. However, once the format is changed, = I think Henrik will be nearly done with the fix anyway. So, you do agree about the open relay part, right? Russ From nobody Tue May 8 10:34:14 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5452112EA8E for ; Tue, 8 May 2018 10:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 6O1Kyojs2_Ha for ; Tue, 8 May 2018 10:34:08 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F2A12EA8C for ; Tue, 8 May 2018 10:34:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1C044300A07 for ; Tue, 8 May 2018 13:34:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id be4B9V7gUrF7 for ; Tue, 8 May 2018 13:34:04 -0400 (EDT) Received: from [192.168.100.30] (unknown [209.65.107.211]) by mail.smeinc.net (Postfix) with ESMTPSA id 748F5300435; Tue, 8 May 2018 13:34:04 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Tue, 8 May 2018 13:34:04 -0400 Cc: IETF Tools Development Content-Transfer-Encoding: quoted-printable Message-Id: <672E67D0-479F-46E6-A552-2C6AEF839874@vigilsec.com> References: <1525788281.3600721.1364842648.031F6C57@webmail.messagingengine.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] DMARC status (was Re: Tools Call Agenda -- 8 May 2018 at 1:00 Eastern) X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 17:34:12 -0000 Based on the discussion during the Tools Call today, no format change is = needed. A check for IETF mail list membership will be added, and then = we will deploy on Thursday. Alexey will announce to the community. Russ > On May 8, 2018, at 12:50 PM, Russ Housley = wrote: >=20 > Alexey: >=20 > I do not think we need to wait for the open relay fix before deploying = to all mail lists. Do you agree? >=20 > Russ >=20 >=20 >> On May 8, 2018, at 10:04 AM, Alexey Melnikov = wrote: >>=20 >> Hi all, >>=20 >> On Thu, Apr 26, 2018, at 9:48 PM, Russ Housley wrote: >>=20 >>> 4. Server Infrastructure >>> - IESG discussions of DMARC -- Henrik and Alexey >>> -- Deployed for volunteer WGs. Is it ready for all mail lists? >>=20 >> My summary of the current DMARC workaround state is as follows: >>=20 >> 1) DMARC workaround code works, in particular: >>=20 >> a) messages from p=3Dreject domains are rewritten, so that they have = @dmarc.ietf.org =46rom email addresses. >> b) replying to such mapped email addresses works >> c) I haven't seen any DMARC related bounces in response to email sent = from mapped @dmarc.ietf.org addresses. >> d) The message duplicate problem was solved, as well as the temporary = message loss that was experienced a week ago. >> e) It is hard to assess how much "addressbook pollution"(*) we get = from @dmarc.ietf.org addresses. I wish I knew answer to this question, = but this is rather Mail User Agent specific. >>=20 >> 2) It is possible to send an email to an algorithmically constructed = @dmarc.ietf.org address even if the email address from which it was = constructed doesn't come from p=3Dreject DMARC domain. In fact, the = original email doesn't even have to be a subscriber of an IETF mailing = list (Henrik, is this correct?). This is effectively an obscure form of = an open relay, so we need to fix that. Henrik has a proposal how to fix = that. >>=20 >> Preventing the open relay problem was not clearly specified in = requirements for Henrik's work, we only realized that this is a problem = very recently. A fix proposed by Henrik will change the mapping, so it = will invalidate all already instantiated mapped addresses = @dmarc.ietf.org. Henrik will correct me, but I think this means that = replies to them will bounce. I suggest if we want to change the format, = we change it now before deploying DMARC workaround to more mailing = lists. This will minimize the number of complains that people will have = about bounces. >>=20 >> 3) I've sent a separate email saying that in order to be able to move = to ARC (which is a better fix), we should keep ability to control which = IETF mailing lists are subject to DMARC workaround. This is trivial, we = just need not to forget to preserve this. >>=20 >> Best Regards, >> Alexey >>=20 >> (*) - i.e. emails from "mapped(A)" (where "A" is an email address = from a p=3Dreject DMARC domain) might appear in recipients addressbooks = together or instead of email address "A". >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development From nobody Tue May 8 15:20:42 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DEB12EAF7 for ; Tue, 8 May 2018 15:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 ylcH_T0nSAKP for ; Tue, 8 May 2018 15:20:38 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 2738F12EAE3 for ; Tue, 8 May 2018 15:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1525818038; x=1557354038; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=hsueK9phHzPTq/jOIDK6ARWmJeer+1PZpUcqMJHf6Mo=; b=ioVHs9EzUGZR8gtBEG2Z+sWJ06WGbGCeXmmutHef45m3fjKuNVFky5+V wCACzeoj/yzhRhAwzrzZ24fJkkfNK/LzgDQUlz2C0z2YQI4IpHbXaUzni xwvWpqrjmb1L8+2THIv7xXisQ9i4vGZ5iL9jY+irKARK8lCnKJUs35wLt cQTF0NXESxJhelWJ/vPbyuyJOzH0ALVtULh/fbpjBHNeCZBDEwUVGFQ3U pr/EHOB8CgpsP3bKD5cx2/CkTHLhgw1IqPwHFNMwj3s2fI7I6EJFp30+a biYSaDXfevnXUNGWjT96DzcaH+ycXCowqw1WNzTPe3jKLHlqq/kl0D8CI A==; X-IronPort-AV: E=Sophos;i="5.49,379,1520852400"; d="scan'208";a="10069405" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 121.98.244.177 - Outgoing - Outgoing-SSL Received: from dynamic-cpe-pool.orcon.net.nz (HELO [192.168.20.4]) ([121.98.244.177]) by mx4-int.auckland.ac.nz with ESMTP; 09 May 2018 10:20:35 +1200 To: tools-development@ietf.org From: Nevil Brownlee Message-ID: Date: Wed, 9 May 2018 10:20:34 +1200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [TOOLS-DEVELOPMENT] SVG RFC _ should we allow Markers in SVG diagrams X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 22:20:41 -0000 Hi Tools-dev folk: Jim Schaad has raised the question "should the marker element be allowed in SVG RFC?" I've raised this as an issue for RFC SVG, the URL for that discussion is https://github.com/rfc-format/draft-iab-svg-rfc-bis/issues/5 The short version of that is: FOR: Many SVG drawing/editing programs use markers for arrowheads etc, and people will probably want to use those. AGAINST: The marker element is not allowed in SVG Tiny (SVG for small-screen devices). If we allow it in SVG RFC, how likely is it that small-screen devices won;t be able to display images using markers? If we decide to allow markers, I can certainly rework the iab-rfc-bis draft to do that - but that's a change that needs wider discussion. What do you all thinnk about this, please? Cheers, Nevil From nobody Wed May 9 09:40:50 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC68126C22; Wed, 9 May 2018 09:40:46 -0700 (PDT) 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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=n8ql7/MO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MCFnPw5q 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 t8MffGhkj5aW; Wed, 9 May 2018 09:40:43 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5581F12D892; Wed, 9 May 2018 09:40:43 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2C4B1224F7; Wed, 9 May 2018 12:40:42 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Wed, 09 May 2018 12:40:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=k2abBOlB57NvVQrdDxS+A540vO29xSLYKaFAiv7HVsw=; b=n8ql7/MO QETCGzyC0lJN3GxZ97ngkIlHqXXMn+7WP86iY5fY9xjb5ht+FPIHohOsd7jPDjU0 vfZ/4LLns0ceXrGxpgQui/UOioY/9LH/q1iIIm3Z0ZR1r5bmyBywDAQg9uy5VIXH 5fUqLAV4P4id5bRZ8YGJac3trOpLNXRQIoYAQWLOmhZJGc1dszz/m2gQ/FfQFxYu c6ZXK4BSPvmsbPDysDTZdiTOiFuTz2p/vGQ1IcE/d6a22WkaVHHBbuaZPUX3NMMD RZDh+h/o7X5FTZS8XQ5jeIpKE2zw2bH2WaUlrJAR9N7mnvIHufEqI3pmppWm584K N5GCjQq/unIshw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=k2abBOlB57NvVQrdDxS+A540vO29x SLYKaFAiv7HVsw=; b=MCFnPw5qjWNU8FYEIAmfLqWVfyC6B5KHIVGDS9C0SfdIG CNDP286BJy167d2T+3TdZhGjfdnQrMaZZkkHEWgu8ufq3yCivmFSrOpWsqze72LO N/CHAllTvAi4359pZYhpByZKNuignGoICsWlbnAu74QQ5QBmiBQ7FcfuuND5ewbu SpuSNdHUvtSjvx6K8b/9hf0TFOGike+md9zAL8Y92xHb/sdzJ6oRHfFqjL9CdxYp FETc4q+KAukjuGn1cn/XkVbwIHDrdHRW0R4kOhI17PdxV1ILKcYHzDlUetDflUuA cyKkh/veNlWPfFGfdTsBE/vJl/hX9PHrSd/2qzWPQ== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0C7219E0E3; Wed, 9 May 2018 12:40:42 -0400 (EDT) Message-Id: <1525884041.722362.1366394000.51566605@webmail.messagingengine.com> From: Alexey Melnikov To: tools-development@ietf.org, iesg@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29fe4c42 Date: Wed, 09 May 2018 17:40:41 +0100 Archived-At: Subject: [TOOLS-DEVELOPMENT] DRAFT: Message to IETF community about enabling DMARC workaround for all IETF/IRTF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 16:40:46 -0000 Suggestions for improvements are welcome. Is it too much or too little of technical details? --------------------- Hi, Many of you have seen several long discussions thread about DMARC and how it affects use of mailing lists. After testing DMARC workaround code written by Henrik Levkowetz on several high volume IETF mailing lists, tools team and IESG decided that Henrik's code should be deployed for all IETF and IRTF mailing lists. In particular the workaround allows people from DMARC p=reject domains to participate in IETF mailing lists and avoids mailing list unsubscriptions from recipients that enforce DMARC. These 2 issues were the main reasons for developing the DMARC workaround code. The workaround will be deployed tomorrow, May 10th. Below are technical details on how the email address rewriting workaround is going to work: Emails from domains that don't have p=reject DMARC setting are not going to be affected in any way. For emails from p=reject domains: - From header field of such emails will be rewritten to be under @dmarc.ietf.org domain (which will have p=none policy). For example, "alexey@example.com" email address would become "alexey%40example.com@dmarc.ietf.org". The original From header field will be preserved in the X-Original-From header field, which can be used for automatic message processing by Sieve and Mail User Agents. Note that the mapping is reversible, so it is possible to send replies or new messages to an original sender by sending them to the corresponding mapped @dmarc.ietf.org email address. Best Regards, Alexey From nobody Wed May 9 10:15:25 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2075412D955 for ; Wed, 9 May 2018 10:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 AADDmVH-VPi4 for ; Wed, 9 May 2018 10:15:21 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9651D1200B9 for ; Wed, 9 May 2018 10:15:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 79C44300A03 for ; Wed, 9 May 2018 13:15:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aGLB1xhrzk6d for ; Wed, 9 May 2018 13:15:18 -0400 (EDT) Received: from [5.5.33.72] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 9AD9830025C; Wed, 9 May 2018 13:15:17 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <1525884041.722362.1366394000.51566605@webmail.messagingengine.com> Date: Wed, 9 May 2018 13:15:16 -0400 Cc: IETF Tools Development , IESG Content-Transfer-Encoding: quoted-printable Message-Id: <7BF6BE1C-B6BA-4153-AB3B-56589CC52B95@vigilsec.com> References: <1525884041.722362.1366394000.51566605@webmail.messagingengine.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] DRAFT: Message to IETF community about enabling DMARC workaround for all IETF/IRTF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 17:15:23 -0000 Just trying to make it a bit more simple ... See below. Russ > On May 9, 2018, at 12:40 PM, Alexey Melnikov = wrote: >=20 > Suggestions for improvements are welcome. Is it too much or too little = of technical details? >=20 > --------------------- > Hi, > Many of you have seen several long discussions thread about DMARC and = how it affects use of mailing lists. ... IETF mail lists. >=20 > After testing DMARC workaround code written by Henrik Levkowetz on = several high volume IETF mailing lists, tools team and IESG decided that = Henrik's code should be deployed for all IETF and IRTF mailing lists. In = particular the workaround allows people from DMARC p=3Dreject domains to = participate in IETF mailing lists and avoids mailing list = unsubscriptions from recipients that enforce DMARC. These 2 issues were = the main reasons for developing the DMARC workaround code. ... from DMARC p=3Dreject domains to participate normally in IETF and = IRTF mail lists. The workaround avoids removal of subscriptions for = recipients from DMARC p=3Dreject domains. >=20 > The workaround will be deployed tomorrow, May 10th. >=20 >=20 > Below are technical details on how the email address rewriting = workaround is going to work: >=20 > Emails from domains that don't have p=3Dreject DMARC setting are not = going to be affected in any way. >=20 > For emails from p=3Dreject domains: >=20 > - =46rom header field of such emails will be rewritten to be under = @dmarc.ietf.org domain (which will have p=3Dnone policy). For example, = "alexey@example.com" email address would become = "alexey%40example.com@dmarc.ietf.org". The original =46rom header field = will be preserved in the X-Original-=46rom header field, which can be = used for automatic message processing by Sieve and Mail User Agents. >=20 > Note that the mapping is reversible, so it is possible to send replies = or new messages to an original sender by sending them to the = corresponding mapped @dmarc.ietf.org email address. >=20 > Best Regards, > Alexey From nobody Wed May 9 11:38:44 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0978A12DA42; Wed, 9 May 2018 11:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 s9xodGFcpm3Q; Wed, 9 May 2018 11:38:26 -0700 (PDT) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (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 06AD312DA49; Wed, 9 May 2018 11:38:26 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id w14-v6so12675779ybm.5; Wed, 09 May 2018 11:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fQw7j2ckokpUECfXozkHzRbwUcF55NYnmZi5DDkAGpk=; b=ngxp+7F2f4b5vRuaoV4Zs6/Nsx2TZicMVHiWqEgzYP/51NFuLWEqN2TOfjCIaADSPR HyhHw8VplafFGI8kl5karDgrMC8lGCBMrdARcUJI356sCOfOrO7oAG93hLCFyuXvnZTH mnueYF59OLh81spUyQs5vQX4ipooGv6/NgQA4iQfYZTzAHIrkFASu2gU8+wEW70sado1 9CEq4cos2BM9Q2Hb64OPwVBxppb0vXgb1lDwtN1MLK0b+mgGwYzU7UCaio2O5NQmRGqC 4iyGJwmM2c1pfivI7pjFS12AkdVjj++rEOuhcWa3Q/5c5IRXH0kJVXqTT0F8ncifijPk Lctg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fQw7j2ckokpUECfXozkHzRbwUcF55NYnmZi5DDkAGpk=; b=q6urA64ebk0II/aNUCm43h44VkeONs9kQJ0ucTjG9CbfqWX4WUruEJ01Z4fJ8XAo6S hI097MRc1X7KgfeMqeTumrq/8McffejNWoSOOtCthWFu+UwcwrGT0cyHNRCRL9SyErNt sXOzpimaMpE63U5K9IpeL5bbtOlEQfsGlw3LXV4DcwuHTZiXB8GJDLv6svy83DIYzgB3 /W2LE6EFIF2lqTdbdeO7VN+6JnhCRdix0vrsthYFBmfwkrM6UyrRadR3QBnSb2+T3/Qt Pfa7O6rpeU3OB/FI/ioOzEovmJPvqBn7aEjkh77LzKgM9SRoNYqaZiTdhMUKt1GOp6UZ SHxw== X-Gm-Message-State: ALKqPweZx3WBTEGQEAVUsOjF/JWudiVUB02Zfrx/3YblpoK7PKN8ciL4 Q37Ufm13goD1O0V9f9Vpu5dz3jEXsPORxnreD1E= X-Google-Smtp-Source: AB8JxZoveIrf0b9MrrOT8GnC9zPUDOMkAZn0eegb2fg5yyCdB5DFFLLDwxqdnTgThrUngn+rWBrGzatSgHo2sko1u3g= X-Received: by 2002:a25:4d57:: with SMTP id a84-v6mr4297751ybb.286.1525891104890; Wed, 09 May 2018 11:38:24 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:d014:0:0:0:0:0 with HTTP; Wed, 9 May 2018 11:38:24 -0700 (PDT) In-Reply-To: <1525884041.722362.1366394000.51566605@webmail.messagingengine.com> References: <1525884041.722362.1366394000.51566605@webmail.messagingengine.com> From: Spencer Dawkins at IETF Date: Wed, 9 May 2018 13:38:24 -0500 Message-ID: To: Alexey Melnikov Cc: IETF Tools Development , IESG Content-Type: multipart/alternative; boundary="00000000000045e785056bca353a" Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] DRAFT: Message to IETF community about enabling DMARC workaround for all IETF/IRTF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 18:38:31 -0000 --00000000000045e785056bca353a Content-Type: text/plain; charset="UTF-8" Hi, Alexey, On Wed, May 9, 2018 at 11:40 AM, Alexey Melnikov wrote: > Suggestions for improvements are welcome. Is it too much or too little of > technical details? > Any sendable note to the community will probably have both too many technical details, and too few ... ;-) A couple of comments below. > > --------------------- > Hi, > Many of you have seen several long discussions thread about DMARC and how > it affects use of mailing lists. > > After testing DMARC workaround code written by Henrik Levkowetz on several > high volume IETF mailing lists, tools team and IESG decided that Henrik's > code should be deployed for all IETF and IRTF mailing lists. In particular > the workaround allows people from DMARC p=reject domains to participate in > IETF mailing lists and avoids mailing list unsubscriptions from recipients > that enforce DMARC. These 2 issues were the main reasons for developing the > DMARC workaround code. > If it was reasonable to name the mailing lists that were used in testing, that might be useful ("well, if it worked for THAT mailing list, it will probably work for mine"). > The workaround will be deployed tomorrow, May 10th. > A quick scan of my mailboxes pops up about 150 threads that include "New datatracker release" since I joined the IESG, so I'm sort of numb to changes to the datatracker, but I don't know that the community is aware of most changes to the datatracker. It might be useful to give the community more heads-up when there's a change coming that will affect a large chunk of the community. To be clear, I don't object to rolling this new version with one day's notice. That's just a suggestion for the future. Spencer > Below are technical details on how the email address rewriting workaround > is going to work: > > Emails from domains that don't have p=reject DMARC setting are not going > to be affected in any way. > > For emails from p=reject domains: > > - From header field of such emails will be rewritten to be under @ > dmarc.ietf.org domain (which will have p=none policy). For example, " > alexey@example.com" email address would become " > alexey%40example.com@dmarc.ietf.org". The original From header field will > be preserved in the X-Original-From header field, which can be used for > automatic message processing by Sieve and Mail User Agents. > > Note that the mapping is reversible, so it is possible to send replies or > new messages to an original sender by sending them to the corresponding > mapped @dmarc.ietf.org email address. > > Best Regards, > Alexey > > --00000000000045e785056bca353a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Alexey,

On Wed, May 9, 2018 at 11:40 AM, Alexey Melnikov <aamelnik= ov@fastmail.fm> wrote:
Suggestions for improvements are welcome. Is it too much or = too little of technical details?

Any se= ndable note to the community will probably have both too many technical det= ails, and too few ... ;-)

A couple of comments bel= ow.
=C2=A0

---------------------
Hi,
Many of you have seen several long discussions thread about DMARC and how i= t affects use of mailing lists.

After testing DMARC workaround code written by Henrik Levkowetz on several = high volume IETF mailing lists, tools team and IESG decided that Henrik'= ;s code should be deployed for all IETF and IRTF mailing lists. In particul= ar the workaround allows people from DMARC p=3Dreject domains to participat= e in IETF mailing lists and avoids mailing list unsubscriptions from recipi= ents that enforce DMARC. These 2 issues were the main reasons for developin= g the DMARC workaround code.

If it was = reasonable to name the mailing lists that were used in testing, that might = be useful ("well, if it worked for THAT mailing list, it will probably= work for mine").
=C2=A0
The workaround will be deployed tomorrow, May 10th.
=

A quick scan of my mailboxes pops up about= 150 threads that include "New datatracker release" since I joine= d the IESG, so I'm sort of numb to changes to the datatracker, but I do= n't know that the community is aware of most changes to the datatracker= . It might be useful to give the community more heads-up when there's a= change coming that will affect a large chunk of the community.=C2=A0
=

To be clear, I don't object to rolling this new ver= sion with one day's notice. That's just a suggestion for the future= .

Spencer
=C2=A0
Below are technical details on how the ema= il address rewriting workaround is going to work:

Emails from domains that don't have p=3Dreject DMARC setting are not go= ing to be affected in any way.

For emails from p=3Dreject domains:

=C2=A0- From header field of such emails will be rewritten to be under @dmarc.i= etf.org domain (which will have p=3Dnone policy). For example, "alexey@example.com" email address would become "alexey%40example.com@dmarc.ie= tf.org". The original From header field will be preserved in the X= -Original-From header field, which can be used for automatic message proces= sing by Sieve and Mail User Agents.

Note that the mapping is reversible, so it is possible to send replies or n= ew messages to an original sender by sending them to the corresponding mapp= ed @= dmarc.ietf.org email address.

Best Regards,
Alexey


--00000000000045e785056bca353a-- From nobody Wed May 9 11:42:51 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1599212DA42; Wed, 9 May 2018 11:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Q2M6b5LqC6Cl; Wed, 9 May 2018 11:42:45 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 81F4612DA3F; Wed, 9 May 2018 11:42:44 -0700 (PDT) X-AuditID: 12074423-e9dff700000027ce-87-5af341214d38 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 39.BE.10190.22143FA5; Wed, 9 May 2018 14:42:42 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w49IgegE031341; Wed, 9 May 2018 14:42:40 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w49Igarq009807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 May 2018 14:42:38 -0400 Date: Wed, 9 May 2018 13:42:36 -0500 From: Benjamin Kaduk To: Spencer Dawkins at IETF Cc: Alexey Melnikov , IETF Tools Development , IESG Message-ID: <20180509184236.GQ84491@kduck.kaduk.org> References: <1525884041.722362.1366394000.51566605@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42IR4hTV1lVy/Bxl0PnbzGL/+0NMFjP+TGS2 WDZlD7PF9GtLWRxYPHaeOsDmsXPWXXaPJUt+MgUwR3HZpKTmZJalFunbJXBl/O/ewlJwn7Xi yYKtbA2Mx1i6GDk5JARMJLo2XGTvYuTiEBJYzCTx5NkcNghnA6PE4imdjBDOFSaJO5f+MIG0 sAioSEzdcZ4RxGYDshu6LzOD2CIC1hJb+jrBupkFOhkluqfdZgVJCAvkSyyY3AbWzAu0b/u/ aUwQU6cxSlxfe44FIiEocXLmEzCbWUBL4sa/l0BFHEC2tMTyfxwgYU6BQImTk9eCzRQVUJbY 23eIfQKjwCwk3bOQdM9C6F7AyLyKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10wvN7NELzWldBMj KJDZXZR3ML7s8z7EKMDBqMTD+4Hnc5QQa2JZcWXuIUZJDiYlUd6ZVz5FCfEl5adUZiQWZ8QX leakFh9ilOBgVhLh/f8AKMebklhZlVqUD5OS5mBREucV3PwhSkggPbEkNTs1tSC1CCYrw8Gh JMHL7AC0R7AoNT21Ii0zpwQhzcTBCTKcB2j4XXugGt7igsTc4sx0iPwpRl2OU029fcxCLHn5 ealS4rz3QYoEQIoySvPg5oASkET2/ppXjOJAbwnzOoGs4wEmL7hJr4CWMAEtEXzwHmRJSSJC SqqBsefw42fMkjmv2tiPzWLN4+7eWcF232Hb+TPOViJZuuvn/hG7fDwooqgmYvdijte7kv++ qa/bkvS62qDjq9eEo3lHlnfpC0Yl71VZ+zqtYpWTf+kVnrp81vi+d+caYy2Kn1jXSd8yf6f2 4+t079PX03bvCmA9o+b2y5pLWPKOv+NJrweCPeIdSizFGYmGWsxFxYkAJ3rvgxsDAAA= Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] DRAFT: Message to IETF community about enabling DMARC workaround for all IETF/IRTF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 18:42:46 -0000 On Wed, May 09, 2018 at 01:38:24PM -0500, Spencer Dawkins at IETF wrote: > Hi, Alexey, > > On Wed, May 9, 2018 at 11:40 AM, Alexey Melnikov > wrote: > > > A quick scan of my mailboxes pops up about 150 threads that include "New > datatracker release" since I joined the IESG, so I'm sort of numb to > changes to the datatracker, but I don't know that the community is aware of > most changes to the datatracker. It might be useful to give the community > more heads-up when there's a change coming that will affect a large chunk > of the community. FWIW, Datatracker release announcements now go to wgchairs as well as iesg. Still doesn't qualify for "the community", though. -Benjamin From nobody Wed May 9 12:51:16 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08D7127AD4 for ; Wed, 9 May 2018 12:51:14 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 2p7lNIxzCq5e for ; Wed, 9 May 2018 12:51:02 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D073F127909 for ; Wed, 9 May 2018 12:51:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 43C831C3F74; Wed, 9 May 2018 12:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mpae27jrvVPT; Wed, 9 May 2018 12:50:58 -0700 (PDT) Received: from [192.168.129.199] (96-66-253-121-static.hfc.comcastbusiness.net [96.66.253.121]) by c8a.amsl.com (Postfix) with ESMTPSA id EFFFE1C3A49; Wed, 9 May 2018 12:50:57 -0700 (PDT) From: Ryan Cross Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_64D78D46-529E-4823-9A3E-73C61CA1E1EC" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 9 May 2018 12:51:01 -0700 In-Reply-To: Cc: IETF Tools Development To: Russ Housley References: X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 8 May 2018 at 1:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 19:51:15 -0000 --Apple-Mail=_64D78D46-529E-4823-9A3E-73C61CA1E1EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, The latest version of the mail archive is available here: http://mailarchivetest.ietf.org/arch/ = The contents are not current, but a snapshot from April. There is a new = Settings menu on the top of the page. Here you can turn Legacy mode on = or off. When legacy mode is on the user will be directed to MHonArc = like pages when browsing a list by date or by thread. These pages are = cached by CloudFlare. The URL scheme is date based, one month of = messages per page. For example: http://mailarchivetest.ietf.org/arch/browse/static/ietf/2018-04/ = For lists with less volume, less than 750 messages a year, index pages = are consolidated by year. For example: http://mailarchivetest.ietf.org/arch/browse/static/nemo/2009/ = The user can edit the URL to jump to a particular date. Client side = redirects are used when needed to map between year / month pages, based = on the rules above. Please take a look and reply with any comments or feedback. Thank You, Ryan > On Apr 26, 2018, at 1:48 PM, Russ Housley = wrote: >=20 > Tools Call Agenda -- 8 May 2018 at 1:00 Eastern >=20 >=20 > JOIN WEBEX MEETING > = https://ietf.webex.com/ietf/j.php?MTID=3Dm440dd848726339c03e605b9956e38bac= > Meeting number (access code): 640 103 570 > Meeting password: tools >=20 > JOIN BY PHONE > 1-877-668-4493 Call-in toll free number (US/Canada)=20 > 1-650-479-3208 Call-in toll number (US/Canada) > Meeting number (access code): 640 103 570 > Meeting password: tools >=20 >=20 > 1. Datatracker Projects > - Expected Datatracker Releases -- Robert and Henrik > -- http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan > - GDPR Compliance -- Robert and Henrik >=20 > 2. Community & Other Projects > - Discontinue MonArch email archives -- Robert > -- Community clearly still likes MonArch speed >=20 > 3. RFC Services Projects > - RFC Format Contracts -- Heather and Robert > -- IDnits > -- Publication Formatter > -- Text Submission > -- RFClint > -- SVGcheck > -- XMLdiff >=20 > 4. Server Infrastructure > - IESG discussions of DMARC -- Henrik and Alexey > -- Deployed for volunteer WGs. Is it ready for all mail lists? >=20 > 5. Parking Lot > - Prepare the RFC Production Center code for publication >=20 > 6. AOB >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development --Apple-Mail=_64D78D46-529E-4823-9A3E-73C61CA1E1EC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
All,

The latest version of the mail archive = is available here:
http://mailarchivetest.ietf.org/arch/

The contents are not = current, but a snapshot from April.  There is a new Settings menu = on the top of the page.  Here you can turn Legacy mode on or off. =  When legacy mode is on the user will be directed to MHonArc like = pages when browsing a list by date or by thread.  These pages are = cached by CloudFlare.  The URL scheme is date based, one month of = messages per page.  For example:
http://mailarchivetest.ietf.org/arch/browse/static/ietf/2018-04= /

For = lists with less volume, less than 750 messages a year, index pages are = consolidated by year.  For example:
http://mailarchivetest.ietf.org/arch/browse/static/nemo/2009/

The user = can edit the URL to jump to a particular date.  Client side = redirects are used when needed to map between year / month pages, based = on the rules above.

Please take a look and reply with any comments or = feedback.

Thank = You,
Ryan


On Apr 26, 2018, at 1:48 PM, Russ Housley <housley@vigilsec.com> wrote:

Tools = Call Agenda -- 8 May 2018 at 1:00 Eastern

JOIN WEBEX MEETING
https://ietf.webex.com/ietf/j.php?MTID=3Dm440dd848726339c03e605= b9956e38bac
Meeting number (access code): 640 103 = 570
Meeting password: tools

JOIN BY PHONE
1-877-668-4493 Call-in toll free = number (US/Canada)
1-650-479-3208 Call-in toll number = (US/Canada)
Meeting number (access code): 640 103 570
Meeting password: tools


1. Datatracker Projects
  - Expected = Datatracker Releases -- Robert and Henrik
=     -- = http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan
=   - GDPR Compliance -- Robert and Henrik

2. Community & Other Projects
=   - Discontinue MonArch email archives -- Robert
=     -- Community clearly still likes MonArch = speed

3. RFC Services Projects
=   - RFC Format Contracts -- Heather and Robert
=     -- IDnits
=     -- Publication Formatter
=     -- Text Submission
=     -- RFClint
=     -- SVGcheck
=     -- XMLdiff

4. = Server Infrastructure
  - IESG discussions of = DMARC -- Henrik and Alexey
    -- = Deployed for volunteer WGs.  Is it ready for all mail lists?

5. Parking Lot
  - = Prepare the RFC Production Center code for publication

6. AOB

_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVELOPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-development

= --Apple-Mail=_64D78D46-529E-4823-9A3E-73C61CA1E1EC-- From nobody Wed May 9 14:29:08 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB048129C6B for ; Wed, 9 May 2018 14:29:06 -0700 (PDT) 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] autolearn=ham autolearn_force=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 Pmj1DQhZfHFX for ; Wed, 9 May 2018 14:29:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1174D129C51 for ; Wed, 9 May 2018 14:29:05 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:64763 helo=[192.168.1.120]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1fGWdz-0004FZ-6n; Wed, 09 May 2018 14:29:04 -0700 To: Russ Housley , Alexey Melnikov References: <1525788281.3600721.1364842648.031F6C57@webmail.messagingengine.com> <672E67D0-479F-46E6-A552-2C6AEF839874@vigilsec.com> Cc: IETF Tools Development From: Henrik Levkowetz Message-ID: <5eabb8a4-f5eb-e95c-1928-9dac3de2343b@levkowetz.com> Date: Wed, 9 May 2018 23:28:55 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <672E67D0-479F-46E6-A552-2C6AEF839874@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7MfNO553ToXhDTGmPKwKVsAR9FiTa8bHC" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: tools-development@ietf.org, aamelnikov@fastmail.fm, housley@vigilsec.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] DMARC status (was Re: Tools Call Agenda -- 8 May 2018 at 1:00 Eastern) X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 21:29:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7MfNO553ToXhDTGmPKwKVsAR9FiTa8bHC Content-Type: multipart/mixed; boundary="oJPOorcePuTX2TjQLghSFCvbnxtuciDgm"; protected-headers="v1" From: Henrik Levkowetz To: Russ Housley , Alexey Melnikov Cc: IETF Tools Development Message-ID: <5eabb8a4-f5eb-e95c-1928-9dac3de2343b@levkowetz.com> Subject: Re: [TOOLS-DEVELOPMENT] DMARC status (was Re: Tools Call Agenda -- 8 May 2018 at 1:00 Eastern) References: <1525788281.3600721.1364842648.031F6C57@webmail.messagingengine.com> <672E67D0-479F-46E6-A552-2C6AEF839874@vigilsec.com> In-Reply-To: <672E67D0-479F-46E6-A552-2C6AEF839874@vigilsec.com> --oJPOorcePuTX2TjQLghSFCvbnxtuciDgm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Alexey, I've released postconfirm 0.42.0 with the added check on sender for the dmarc reverse path, and installed the new version on mail.ietf.org. Best regards, Henrik On 2018-05-08 19:34, Russ Housley wrote: > Based on the discussion during the Tools Call today, no format change > is needed. A check for IETF mail list membership will be added, and > then we will deploy on Thursday. Alexey will announce to the > community. >=20 > Russ >=20 >> On May 8, 2018, at 12:50 PM, Russ Housley wrote= : >>=20 >> Alexey: >>=20 >> I do not think we need to wait for the open relay fix before deploying= to all mail lists. Do you agree? >>=20 >> Russ >>=20 >>=20 >>> On May 8, 2018, at 10:04 AM, Alexey Melnikov = wrote: >>>=20 >>> Hi all, >>>=20 >>> On Thu, Apr 26, 2018, at 9:48 PM, Russ Housley wrote: >>>=20 >>>> 4. Server Infrastructure >>>> - IESG discussions of DMARC -- Henrik and Alexey >>>> -- Deployed for volunteer WGs. Is it ready for all mail lists? >>>=20 >>> My summary of the current DMARC workaround state is as follows: >>>=20 >>> 1) DMARC workaround code works, in particular: >>>=20 >>> a) messages from p=3Dreject domains are rewritten, so that they have = @dmarc.ietf.org From email addresses. >>> b) replying to such mapped email addresses works >>> c) I haven't seen any DMARC related bounces in response to email sent= from mapped @dmarc.ietf.org addresses. >>> d) The message duplicate problem was solved, as well as the temporary= message loss that was experienced a week ago. >>> e) It is hard to assess how much "addressbook pollution"(*) we get fr= om @dmarc.ietf.org addresses. I wish I knew answer to this question, but = this is rather Mail User Agent specific. >>>=20 >>> 2) It is possible to send an email to an algorithmically constructed = @dmarc.ietf.org address even if the email address from which it was const= ructed doesn't come from p=3Dreject DMARC domain. In fact, the original e= mail doesn't even have to be a subscriber of an IETF mailing list (Henrik= , is this correct?). This is effectively an obscure form of an open relay= , so we need to fix that. Henrik has a proposal how to fix that. >>>=20 >>> Preventing the open relay problem was not clearly specified in requir= ements for Henrik's work, we only realized that this is a problem very re= cently. A fix proposed by Henrik will change the mapping, so it will inva= lidate all already instantiated mapped addresses @dmarc.ietf.org. Henrik = will correct me, but I think this means that replies to them will bounce.= I suggest if we want to change the format, we change it now before deplo= ying DMARC workaround to more mailing lists. This will minimize the numbe= r of complains that people will have about bounces. >>>=20 >>> 3) I've sent a separate email saying that in order to be able to move= to ARC (which is a better fix), we should keep ability to control which = IETF mailing lists are subject to DMARC workaround. This is trivial, we j= ust need not to forget to preserve this. >>>=20 >>> Best Regards, >>> Alexey >>>=20 >>> (*) - i.e. emails from "mapped(A)" (where "A" is an email address fro= m a p=3Dreject DMARC domain) might appear in recipients addressbooks tog= ether or instead of email address "A". >>=20 >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development >=20 --oJPOorcePuTX2TjQLghSFCvbnxtuciDgm-- --7MfNO553ToXhDTGmPKwKVsAR9FiTa8bHC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlrzaBcACgkQTptXS4+7 Fxo9FQ//c3XIH4DwiTi5/3MZciGI/0Xmvetf+yOyDXPnv+JYiPqoGnFeSEj/Ebco weX3wDKnI4gEaUKmDE+bq6FjuE4aoMJEJ+7thArEKEOnKlfKj5caEMUjkaEwneTf Sz8AcW0zLznxW8ZO38LFgT0STxq3H21nDA404sYRRJweQqHfIDF/vouIECkxVIsW r49tT7rpKRT/F1OH+fjzreJO4q5bND0ipM/NEX3NGlZVGoOPUw8a3Rbqm0WyDLU3 8d8ZS2mFNs4rOAknTpmuFtG9M6zZRGtefAv3twfr+65tiJ/J6CoPF+Tj8ngX7Av8 ypJHa0XVl6Fl4RCq37Np1yHZNeHLPWLrPLM07kcobFiCl5+4SRWGokN4SDjsHu4I 8ctAzOxRVI7ttnYpFjm5SWHFOmWP85nRNy1zKTTCou6oJC2DDBUQV0DEJI1QYjXR Z9oFSCHs795j5lnfwb67a2uFF92xXRh1TVcdnJGIpE+i0MRMzdJ6lL8nsn4e2MeZ tTIHuZXUFlP4VJMH5XpakWbyBdw7vbdiHF9gQHul0vYNOseP/jjxAu5y/6Xk0jUu AXA7xp8blQohcKOIrEN5QLSWwPV1s53tJsHT1fdkIgmM01NN4oqMhrOalLU86kmL ehMeOnTQOCeM6RPkX/U6J+Z9lrTL8O765i+udHTL+rtocC9N6Oo= =KCMG -----END PGP SIGNATURE----- --7MfNO553ToXhDTGmPKwKVsAR9FiTa8bHC-- From nobody Thu May 10 03:01:51 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70E412EAA6; Thu, 10 May 2018 03:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=SvSWmBJu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=F2MybqS+ 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 3Dsbke3bcqhy; Thu, 10 May 2018 03:01:44 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BF6B127286; Thu, 10 May 2018 03:01:44 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 804CA22700; Thu, 10 May 2018 06:01:43 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 10 May 2018 06:01:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=i1QCOlhNkAllcM5NoI3l1w1nfr7YC nu3lY+mG3h8rRA=; b=SvSWmBJuly0WUEoz4tCMa9TFL9xrULHtpCaN6OmN8NblM fuPrWa8UdhKLNoWZMzsJOoufRtUB/46ruaukvf22qmZ6NDaW/I9i2JWrFw2tThRv wFGlVURy2z0ERtuSFjcpxupnlEp2MxLD0hmFHAtPOxcoC717vpvXY6gECDeWcZUx /OXSrC9NfXMERlNk2/xo9Bn5z7CS1NhZdYp19tHtpvzztbtau6V9qYU4XY5M/oR5 4khI8bFbRIPHQnO3lC+0Imep8gCpICg33KrKaVI6/BnNbqj8SxODpQKRVskdsljK oEWoJsuGzLOAhIozLLEqj+++WMUQSEzqLaNimdoBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=i1QCOl hNkAllcM5NoI3l1w1nfr7YCnu3lY+mG3h8rRA=; b=F2MybqS+7PjlpdOdaZXSTc ecaLrfZYLDANVEShJIWV4O3/rdRxd0cL6GYmRitcYYBTUf/WanXUhFFy32DXrMLH 201DhCCIM+RZBVMEu19/gFT0r/ERvUIt9/aGipwsTtO1mMzXcGDxTFHvCw5ceppi 1okr7R3TVpMTBx7ilGj8x6ZwMOK0+NcLe2fL4eWqlNEMD9To1cRXhcr4PcAvTevY oxkd1YVc57GP+Tk3h1xo6E7oE5ZBvZyJeYFX/aHLlaYlCkdq0GY21P0YL6tLeLAI SDLZhx2ZiQlbo0/4movk7+Bon7hgnKuLH7TRGTlwwEMDn7TPVREwAj65JlHoI3+A == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 5FB569E094; Thu, 10 May 2018 06:01:43 -0400 (EDT) Message-Id: <1525946503.1096503.1367250352.6D4BE75E@webmail.messagingengine.com> From: Alexey Melnikov To: Russ Housley Cc: IETF Tools Development , IESG MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29fe4c42 References: <1525884041.722362.1366394000.51566605@webmail.messagingengine.com> <7BF6BE1C-B6BA-4153-AB3B-56589CC52B95@vigilsec.com> Date: Thu, 10 May 2018 11:01:43 +0100 In-Reply-To: <7BF6BE1C-B6BA-4153-AB3B-56589CC52B95@vigilsec.com> Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] DRAFT: Message to IETF community about enabling DMARC workaround for all IETF/IRTF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 10:01:46 -0000 Hi Russ, On Wed, May 9, 2018, at 6:15 PM, Russ Housley wrote: > Just trying to make it a bit more simple ... See below. > > Russ > > > > On May 9, 2018, at 12:40 PM, Alexey Melnikov wrote: > > > > Suggestions for improvements are welcome. Is it too much or too little of technical details? > > > > --------------------- > > Hi, > > Many of you have seen several long discussions thread about DMARC and how it affects use of mailing lists. > > ... IETF mail lists. Ok. > > > > After testing DMARC workaround code written by Henrik Levkowetz on several high volume IETF mailing lists, tools team and IESG decided that Henrik's code should be deployed for all IETF and IRTF mailing lists. In particular the workaround allows people from DMARC p=reject domains to participate in IETF mailing lists and avoids mailing list unsubscriptions from recipients that enforce DMARC. These 2 issues were the main reasons for developing the DMARC workaround code. > > ... from DMARC p=reject domains to participate normally in IETF and IRTF > mail lists. The workaround avoids removal of subscriptions for > recipients from DMARC p=reject domains. Actually this is not the right change: there are 2 issues. One that email messages from p=reject might not get delivered (and thus might not be seen) by some recipients. The other one is that recipients (they don't have to be from DMARC p=reject domains, their email server just have to bounce messages that don't conform to sender's DMARC p=reject policy) can be unsubscribed from mailing lists, because such bounces get delivered to Mailman and Mailman doesn't know that they are caused by DMARC and not something else. > > The workaround will be deployed tomorrow, May 10th. > > > > > > Below are technical details on how the email address rewriting workaround is going to work: > > > > Emails from domains that don't have p=reject DMARC setting are not going to be affected in any way. > > > > For emails from p=reject domains: > > > > - From header field of such emails will be rewritten to be under @dmarc.ietf.org domain (which will have p=none policy). For example, "alexey@example.com" email address would become "alexey%40example.com@dmarc.ietf.org". The original From header field will be preserved in the X-Original-From header field, which can be used for automatic message processing by Sieve and Mail User Agents. > > > > Note that the mapping is reversible, so it is possible to send replies or new messages to an original sender by sending them to the corresponding mapped @dmarc.ietf.org email address. > > > > Best Regards, > > Alexey > From nobody Thu May 10 03:03:15 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0141D12EAAD; Thu, 10 May 2018 03:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=gZDe+wOH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=diFwik2q 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 GCd6qTaesjC4; Thu, 10 May 2018 03:03:12 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4654127286; Thu, 10 May 2018 03:03:11 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 55A83227AD; Thu, 10 May 2018 06:03:11 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 10 May 2018 06:03:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=tavmuSd6j1pdb2H8CmtbHRmxXNxSP KKLq69JlKekOZw=; b=gZDe+wOHDFhKHnAPol5Vmutn+4e1UwftdFkwQHs7zLBZD sqdJLTUX9Iq/Xb0k0s+soXCcxDzQQF+q5yvR4RhdXTjkMV3y3SPKYeXbJG28ilxy C6s6qu0qu3dUim1JTU/8VSUzeHNJzPh0/BVF0+GKRidM9NpSW3/oP+FrYguZEKM3 9tyxt7VWmgjxeL0am0SrTrZVaBb32p7bZIM8NKhZEMF2zUcr88wZaqPG2QXQmkoy Pfl5Njsq6U9yyRdgg0rGRrY65qQ82XfQK+j2fu8a1oo9OiAiyJfhQMTwEujcTEr+ PrY8rPAHXWmi18sAlcTsOnSxJBKNaTlXQtL/wYDbg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=tavmuS d6j1pdb2H8CmtbHRmxXNxSPKKLq69JlKekOZw=; b=diFwik2qOMivkK4HTIbpof p5aX3npgE47VK++F72vxxAt3++MptyzMAn0QK3pIfzG/AtX+XdQtDFM6FsPNOpwF rQ92eWWWXWoE9NKcyYLWibF8HZ92cXsAA4hJexBoLJtLObLk8Cx6HSvdv06OaYck XXzG0HI4Iz51xcBuFnsXrA3KxnMfzHB8b9qAYZzRO6lwm3vkRaXdr+yC8GJIsbn1 kJJkoeVUP/IQnAfVZpSJVdSIANMNWrl+YjdNryYUgaV0yOEQC8lvkxZ/7HO2gv24 7POHSuo2QoS4QdZBR8LJkVT5x4h5o6a46wIs2IUAxFo88Ax3GJMauhq/tg1CYFCQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 341949E094; Thu, 10 May 2018 06:03:11 -0400 (EDT) Message-Id: <1525946591.1097159.1367254344.0D17B01E@webmail.messagingengine.com> From: Alexey Melnikov To: Spencer Dawkins at IETF Cc: IETF Tools Development , IESG MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152594659110971594" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29fe4c42 References: <1525884041.722362.1366394000.51566605@webmail.messagingengine.com> Date: Thu, 10 May 2018 11:03:11 +0100 In-Reply-To: Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] DRAFT: Message to IETF community about enabling DMARC workaround for all IETF/IRTF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 10:03:14 -0000 This is a multi-part message in MIME format. --_----------=_152594659110971594 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, May 9, 2018, at 7:38 PM, Spencer Dawkins at IETF wrote: > Hi, Alexey, > > On Wed, May 9, 2018 at 11:40 AM, Alexey Melnikov > wrote: >> Suggestions for improvements are welcome. Is it too much or too >> little of technical details?> > Any sendable note to the community will probably have both too many > technical details, and too few ... ;-)> > A couple of comments below. > >> >> --------------------- >> Hi, >> Many of you have seen several long discussions thread about DMARC >> and how it affects use of mailing lists.>> >> After testing DMARC workaround code written by Henrik Levkowetz on >> several high volume IETF mailing lists, tools team and IESG decided >> that Henrik's code should be deployed for all IETF and IRTF mailing >> lists. In particular the workaround allows people from DMARC >> p=reject domains to participate in IETF mailing lists and avoids >> mailing list unsubscriptions from recipients that enforce DMARC. >> These 2 issues were the main reasons for developing the DMARC >> workaround code.> > If it was reasonable to name the mailing lists that were used in > testing, that might be useful ("well, if it worked for THAT mailing > list, it will probably work for mine").Yes, sure. Good idea. > >> The workaround will be deployed tomorrow, May 10th. > > A quick scan of my mailboxes pops up about 150 threads that include > "New datatracker release" since I joined the IESG, so I'm sort of numb > to changes to the datatracker, but I don't know that the community is > aware of most changes to the datatracker. It might be useful to give > the community more heads-up when there's a change coming that will > affect a large chunk of the community.Yeah, 1 day might be a bit short for anybody who is not on IESG or not a WG Chair. > > To be clear, I don't object to rolling this new version with one day's > notice. That's just a suggestion for the future.> > Spencer > >> Below are technical details on how the email address rewriting >> workaround is going to work:>> >> Emails from domains that don't have p=reject DMARC setting are not >> going to be affected in any way.>> >> For emails from p=reject domains: >> >> - From header field of such emails will be rewritten to be under >> @dmarc.ietf.org domain (which will have p=none policy). For >> example, "alexey@example.com" email address would become >> "alexey%40example.com@dmarc.ietf.org[1]". The original From >> header field will be preserved in the X-Original-From header >> field, which can be used for automatic message processing by >> Sieve and Mail User Agents.>> >> Note that the mapping is reversible, so it is possible to send >> replies or new messages to an original sender by sending them to the >> corresponding mapped @dmarc.ietf.org email address.>> >> Best Regards, >> Alexey >> Links: 1. mailto:alexey%2540example.com@dmarc.ietf.org --_----------=_152594659110971594 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, May 9, 2018, at 7:38 PM, Spencer Dawkins at IETF wrote:
Hi, Alexey,

On Wed, May 9, 2018 at 11:40 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
Suggestions for improvements are welcome. Is it too much or too little of technical details?

Any sendable note to the community will probably have both too many technical details, and too few ... ;-)

A couple of comments below.
 

---------------------
Hi,
Many of you have seen several long discussions thread about DMARC and how it affects use of mailing lists.

After testing DMARC workaround code written by Henrik Levkowetz on several high volume IETF mailing lists, tools team and IESG decided that Henrik's code should be deployed for all IETF and IRTF mailing lists. In particular the workaround allows people from DMARC p=reject domains to participate in IETF mailing lists and avoids mailing list unsubscriptions from recipients that enforce DMARC. These 2 issues were the main reasons for developing the DMARC workaround code.

If it was reasonable to name the mailing lists that were used in testing, that might be useful ("well, if it worked for THAT mailing list, it will probably work for mine").
Yes, sure. Good idea.

 
The workaround will be deployed tomorrow, May 10th.

A quick scan of my mailboxes pops up about 150 threads that include "New datatracker release" since I joined the IESG, so I'm sort of numb to changes to the datatracker, but I don't know that the community is aware of most changes to the datatracker. It might be useful to give the community more heads-up when there's a change coming that will affect a large chunk of the community. 
Yeah, 1 day might be a bit short for anybody who is not on IESG or not a WG Chair.


To be clear, I don't object to rolling this new version with one day's notice. That's just a suggestion for the future.

Spencer
 
Below are technical details on how the email address rewriting workaround is going to work:

Emails from domains that don't have p=reject DMARC setting are not going to be affected in any way.

For emails from p=reject domains:

 - From header field of such emails will be rewritten to be under @dmarc.ietf.org domain (which will have p=none policy). For example, "alexey@example.com" email address would become "alexey%40example.com@dmarc.ietf.org". The original From header field will be preserved in the X-Original-From header field, which can be used for automatic message processing by Sieve and Mail User Agents.

Note that the mapping is reversible, so it is possible to send replies or new messages to an original sender by sending them to the corresponding mapped @dmarc.ietf.org email address.

Best Regards,
Alexey


--_----------=_152594659110971594-- From nobody Thu May 10 09:30:25 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCB3128961 for ; Thu, 10 May 2018 09:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 DMLD9xYnSXqB for ; Thu, 10 May 2018 09:30:18 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D06D3120454 for ; Thu, 10 May 2018 09:30:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B4079300A01 for ; Thu, 10 May 2018 12:30:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RXKbh3SQQNEf for ; Thu, 10 May 2018 12:30:14 -0400 (EDT) Received: from [5.5.33.83] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id E2565300435; Thu, 10 May 2018 12:30:13 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <1525946503.1096503.1367250352.6D4BE75E@webmail.messagingengine.com> Date: Thu, 10 May 2018 12:30:13 -0400 Cc: IETF Tools Development , IESG Content-Transfer-Encoding: quoted-printable Message-Id: <0A710D8B-7987-41AA-A461-4017A1834F79@vigilsec.com> References: <1525884041.722362.1366394000.51566605@webmail.messagingengine.com> <7BF6BE1C-B6BA-4153-AB3B-56589CC52B95@vigilsec.com> <1525946503.1096503.1367250352.6D4BE75E@webmail.messagingengine.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] DRAFT: Message to IETF community about enabling DMARC workaround for all IETF/IRTF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 16:30:20 -0000 > On May 10, 2018, at 6:01 AM, Alexey Melnikov = wrote: >=20 > Hi Russ, >=20 > On Wed, May 9, 2018, at 6:15 PM, Russ Housley wrote: >> Just trying to make it a bit more simple ... See below. >>=20 >> Russ >>=20 >>=20 >>> On May 9, 2018, at 12:40 PM, Alexey Melnikov = wrote: >>>=20 >>> Suggestions for improvements are welcome. Is it too much or too = little of technical details? >>>=20 >>> --------------------- >>> Hi, >>> Many of you have seen several long discussions thread about DMARC = and how it affects use of mailing lists. >>=20 >> ... IETF mail lists. >=20 > Ok. >=20 >>>=20 >>> After testing DMARC workaround code written by Henrik Levkowetz on = several high volume IETF mailing lists, tools team and IESG decided that = Henrik's code should be deployed for all IETF and IRTF mailing lists. In = particular the workaround allows people from DMARC p=3Dreject domains to = participate in IETF mailing lists and avoids mailing list = unsubscriptions from recipients that enforce DMARC. These 2 issues were = the main reasons for developing the DMARC workaround code. >>=20 >> ... from DMARC p=3Dreject domains to participate normally in IETF and = IRTF=20 >> mail lists. The workaround avoids removal of subscriptions for=20 >> recipients from DMARC p=3Dreject domains. >=20 > Actually this is not the right change: there are 2 issues. One that = email messages from p=3Dreject might not get delivered (and thus might = not be seen) by some recipients. The other one is that recipients (they = don't have to be from DMARC p=3Dreject domains, their email server just = have to bounce messages that don't conform to sender's DMARC p=3Dreject = policy) can be unsubscribed from mailing lists, because such bounces get = delivered to Mailman and Mailman doesn't know that they are caused by = DMARC and not something else. Right. I think the message should be clear about both issues. >=20 >>> The workaround will be deployed tomorrow, May 10th. >>>=20 >>>=20 >>> Below are technical details on how the email address rewriting = workaround is going to work: >>>=20 >>> Emails from domains that don't have p=3Dreject DMARC setting are not = going to be affected in any way. >>>=20 >>> For emails from p=3Dreject domains: >>>=20 >>> - =46rom header field of such emails will be rewritten to be under = @dmarc.ietf.org domain (which will have p=3Dnone policy). For example, = "alexey@example.com" email address would become = "alexey%40example.com@dmarc.ietf.org". The original =46rom header field = will be preserved in the X-Original-=46rom header field, which can be = used for automatic message processing by Sieve and Mail User Agents. >>>=20 >>> Note that the mapping is reversible, so it is possible to send = replies or new messages to an original sender by sending them to the = corresponding mapped @dmarc.ietf.org email address. >>>=20 >>> Best Regards, >>> Alexey >>=20 From nobody Thu May 10 14:37:05 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E134912EB8E; Thu, 10 May 2018 14:36:59 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 oLEPBHl-FwMh; Thu, 10 May 2018 14:36:58 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 2C43E12D94D; Thu, 10 May 2018 14:36:57 -0700 (PDT) X-AuditID: 12074423-741ff70000003eaa-22-5af4bb777ff4 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 60.70.16042.77BB4FA5; Thu, 10 May 2018 17:36:56 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w4ALarPZ006351; Thu, 10 May 2018 17:36:54 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w4ALan8E010573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 May 2018 17:36:52 -0400 Date: Thu, 10 May 2018 16:36:49 -0500 From: Benjamin Kaduk To: Alexey Melnikov Cc: tools-development@ietf.org, iesg@ietf.org Message-ID: <20180510213649.GB84491@kduck.kaduk.org> References: <1525884041.722362.1366394000.51566605@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1525884041.722362.1366394000.51566605@webmail.messagingengine.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixCmqrVux+0uUwYPv/Bb73x9ispjxZyKz xfRrS1kcmD12njrA5rFkyU+mAKYoLpuU1JzMstQifbsErozG940sBYsEKl7v+87WwPiVp4uR g0NCwETi8zL5LkYuDiGBxUwSr/u3MEM4Gxklus/uYOxi5ARyrjJJ/JioCmKzCKhK/J93kRnE ZhNQkWjovgxmiwjoSBw7/JIJxGYW0JW4dnM5WFxYIF9iweQ2sDgv0LLWNQfZIGb6S3z7/IMV Ii4ocXLmExaIXi2JG/9A5nAA2dISy/9xgIQ5BQIkGg4vACsXFVCW2Nt3iH0Co8AsJN2zkHTP QuhewMi8ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdMLzezRC81pXQTIyhY2V2UdzC+7PM+xCjA wajEw1sQ9yVKiDWxrLgy9xCjJAeTkijvzCufooT4kvJTKjMSizPii0pzUosPMUpwMCuJ8O5b AVTOm5JYWZValA+TkuZgURLnFdz8IUpIID2xJDU7NbUgtQgmK8PBoSTBa7cLqFGwKDU9tSIt M6cEIc3EwQkynAdoODNIDW9xQWJucWY6RP4Uoy7HqabePmYhlrz8vFQpcV5tkCIBkKKM0jy4 OaAkI5G9v+YVozjQW8K8jiBVPMAEBTfpFdASJqAlB69+BllSkoiQkmpgZFieYCj7RuXH43+P eUIttOLWTcouON7wa4osf2nOASGp2BW7lLUyv7hmpj3Z+WKz9vlwx3un1p95kvViY6WkeASr x6X0f0s5FDxv+HyrW3jm65/ZZ8Jyzxx+vX+BN+vp8DcxrBEKvE9K/4Ru5WLQlf/IwCq32cbf yaW1aJ9QckVW7kVXvaRPSizFGYmGWsxFxYkAoY0RiQ0DAAA= Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] DRAFT: Message to IETF community about enabling DMARC workaround for all IETF/IRTF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 21:37:00 -0000 On Wed, May 09, 2018 at 05:40:41PM +0100, Alexey Melnikov wrote: > Suggestions for improvements are welcome. Is it too much or too little of technical details? I'm happy with the way the "technical details" discussion is unfolding, but will sprinkle some definite articles through the text: > --------------------- > Hi, > Many of you have seen several long discussions thread about DMARC and how it affects use of mailing lists. > > After testing DMARC workaround code written by Henrik Levkowetz on > several high volume IETF mailing lists, tools team and IESG "the tools team"; "the IESG" > decided that Henrik's code should be deployed for all IETF and > IRTF mailing lists. In particular the workaround allows people > from DMARC p=reject domains to participate in IETF mailing lists > and avoids mailing list unsubscriptions from recipients that > enforce DMARC. These 2 issues were the main reasons for developing > the DMARC workaround code. > > The workaround will be deployed tomorrow, May 10th. > > > Below are technical details on how the email address rewriting "some technical details", maybe? > workaround is going to work: > > Emails from domains that don't have p=reject DMARC setting are not "a p=reject" > going to be affected in any way. > > For emails from p=reject domains: > > - From header field of such emails will be rewritten to be under "The From header" > @dmarc.ietf.org domain (which will have p=none policy). For "a p=none"? > example, "alexey@example.com" email address would become the "alexey@example.com" -Benjamin > "alexey%40example.com@dmarc.ietf.org". The original From header > field will be preserved in the X-Original-From header field, > which can be used for automatic message processing by Sieve and > Mail User Agents. > > Note that the mapping is reversible, so it is possible to send > replies or new messages to an original sender by sending them to > the corresponding mapped @dmarc.ietf.org email address. > > Best Regards, Alexey > From nobody Thu May 10 14:58:14 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594EA12DB70; Thu, 10 May 2018 14:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 2VntVyqyrINU; Thu, 10 May 2018 14:58:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF609129C51; Thu, 10 May 2018 14:58:06 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:65304 helo=[192.168.1.103]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fGtZa-0007f4-QG; Thu, 10 May 2018 14:58:03 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Henrik Levkowetz X-Mailer: iPad Mail (15E216) In-Reply-To: <20180510213649.GB84491@kduck.kaduk.org> Date: Thu, 10 May 2018 23:57:54 +0200 Cc: Alexey Melnikov , tools-development@ietf.org, iesg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <36DB6AF0-84E6-47A3-AAA1-4A9ACBD77972@levkowetz.com> References: <1525884041.722362.1366394000.51566605@webmail.messagingengine.com> <20180510213649.GB84491@kduck.kaduk.org> To: Benjamin Kaduk X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: kaduk@mit.edu, tools-development@ietf.org, aamelnikov@fastmail.fm, iesg@ietf.org, henrik@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] DRAFT: Message to IETF community about enabling DMARC workaround for all IETF/IRTF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 21:58:08 -0000 One correction: > On 10 May 2018, at 23:36, Benjamin Kaduk wrote: >=20 >> On Wed, May 09, 2018 at 05:40:41PM +0100, Alexey Melnikov wrote: >> Suggestions for improvements are welcome. Is it too much or too little of= technical details? >=20 > I'm happy with the way the "technical details" discussion is > unfolding, but will sprinkle some definite articles through the > text: >=20 >> --------------------- >> Hi, >> Many of you have seen several long discussions thread about DMARC and how= it affects use of mailing lists. >>=20 >> After testing DMARC workaround code written by Henrik Levkowetz on >> several high volume IETF mailing lists, tools team and IESG >=20 > "the tools team"; "the IESG" >=20 >> decided that Henrik's code should be deployed for all IETF and >> IRTF mailing lists. In particular the workaround allows people >> from DMARC p=3Dreject domains to participate in IETF mailing lists >> and avoids mailing list unsubscriptions from recipients that >> enforce DMARC. These 2 issues were the main reasons for developing >> the DMARC workaround code. >>=20 >> The workaround will be deployed tomorrow, May 10th. >>=20 >>=20 >> Below are technical details on how the email address rewriting >=20 > "some technical details", maybe? >=20 >> workaround is going to work: >>=20 >> Emails from domains that don't have p=3Dreject DMARC setting are not >=20 > "a p=3Dreject" >=20 >> going to be affected in any way. >>=20 >> For emails from p=3Dreject domains: >>=20 >> - =46rom header field of such emails will be rewritten to be under >=20 > "The =46rom header" >=20 >> @dmarc.ietf.org domain (which will have p=3Dnone policy). For >=20 > "a p=3Dnone"? >=20 >> example, "alexey@example.com" email address would become >=20 > the "alexey@example.com" >=20 > -Benjamin >=20 >> "alexey%40example.com@dmarc.ietf.org". That should be "alexey=3D40example.com@dmarc.ietf.org". Henrik >> The original =46rom header >> field will be preserved in the X-Original-=46rom header field, >> which can be used for automatic message processing by Sieve and >> Mail User Agents. >>=20 >> Note that the mapping is reversible, so it is possible to send >> replies or new messages to an original sender by sending them to >> the corresponding mapped @dmarc.ietf.org email address. >>=20 >> Best Regards, Alexey >>=20 >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development >=20 From nobody Fri May 11 04:49:53 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5025912E88D; Fri, 11 May 2018 04:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=VZLTvGzH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gTA5xJ9J 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 614X4Q04Hgml; Fri, 11 May 2018 04:49:50 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F13F12E88F; Fri, 11 May 2018 04:49:49 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B2032261B2; Fri, 11 May 2018 07:49:48 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Fri, 11 May 2018 07:49:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=D3qc3kxOtbdaiiwIeeZOo6sAnWfl1 ABXvTrAfZ97RJU=; b=VZLTvGzHBBVGpnurkpLN3VeAAScJHJWFT7YPFvaWOHutN mfQPJkxF/pbBUlSXxa+oPadvTal2AU6JAjiMrW98Zg+S6EfgaVoRuOvtnMpGpI9d 9BHF6pSmxp5CVYW7/XPJ5n4zEmGHvq1bCai19rA3ghq3Jd2mwN+DAvDy0r2DDDnZ wI2BihqorWru0gtOGlyV4z4HHXiVqeVSbo8wTx/0nkMIRUJkgCAH/7o+/4fIUCvz fDCjsYAFinxmUSTQZwfFHuu4p7OlWs/vt73MKf860y7iOJaAjA+HhmF5mc4ID01S e9Y1uLghEqtNSuJnhBLJ8R5OdOFq9tBHPWiL6RjoA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=D3qc3k xOtbdaiiwIeeZOo6sAnWfl1ABXvTrAfZ97RJU=; b=gTA5xJ9Jmf+e6oEpbV0pcv 6uhDezYOFnHcPADHb2pFhQbLCtpIgC/3w1tpFt6NcM9zgty5z4l/ulEGeqPJ8l4b VSKHd2KUJCuini3g1RzjYFrq0kaAYH//3SYmTUMka1RJEmWEBe5wBSsIK9mtFExy bokmllzgaygwBsUtxCJhxqjEym6jNZDrWbAYdCTNwc0fCcTSPaa7yTLMm4YcMr4h LbvLo3qcdMOPU9Okqun2jsOw0ZoXWgSN2nh4Nw3odmFTS0Eh+cNvS7UfW3EXfZ1G qoA8VzDdwC/rlZgsh44Rl7U0dIX63a6WpeqU+rg9bV1BVYprI7crhfiTs2FMB2zA == X-ME-Sender: Received: from [10.4.215.228] (unknown [148.252.128.165]) by mail.messagingengine.com (Postfix) with ESMTPA id 53158102C1; Fri, 11 May 2018 07:49:48 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (15D60) In-Reply-To: <36DB6AF0-84E6-47A3-AAA1-4A9ACBD77972@levkowetz.com> Date: Fri, 11 May 2018 12:49:47 +0100 Cc: Benjamin Kaduk , tools-development@ietf.org, iesg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <90BC2540-4FA3-4FAE-9C19-D397302909FA@fastmail.fm> References: <1525884041.722362.1366394000.51566605@webmail.messagingengine.com> <20180510213649.GB84491@kduck.kaduk.org> <36DB6AF0-84E6-47A3-AAA1-4A9ACBD77972@levkowetz.com> To: Henrik Levkowetz Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] DRAFT: Message to IETF community about enabling DMARC workaround for all IETF/IRTF mailing lists X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 11:49:52 -0000 > On 10 May 2018, at 22:57, Henrik Levkowetz wrote: >=20 > One correction: >=20 >>> On 10 May 2018, at 23:36, Benjamin Kaduk wrote: >>>=20 >>> On Wed, May 09, 2018 at 05:40:41PM +0100, Alexey Melnikov wrote: >>> Suggestions for improvements are welcome. Is it too much or too little o= f technical details? >>=20 >> I'm happy with the way the "technical details" discussion is >> unfolding, but will sprinkle some definite articles through the >> text: >>=20 >>> --------------------- >>> Hi, >>> Many of you have seen several long discussions thread about DMARC and ho= w it affects use of mailing lists. >>>=20 >>> After testing DMARC workaround code written by Henrik Levkowetz on >>> several high volume IETF mailing lists, tools team and IESG >>=20 >> "the tools team"; "the IESG" >>=20 >>> decided that Henrik's code should be deployed for all IETF and >>> IRTF mailing lists. In particular the workaround allows people >>> from DMARC p=3Dreject domains to participate in IETF mailing lists >>> and avoids mailing list unsubscriptions from recipients that >>> enforce DMARC. These 2 issues were the main reasons for developing >>> the DMARC workaround code. >>>=20 >>> The workaround will be deployed tomorrow, May 10th. >>>=20 >>>=20 >>> Below are technical details on how the email address rewriting >>=20 >> "some technical details", maybe? >>=20 >>> workaround is going to work: >>>=20 >>> Emails from domains that don't have p=3Dreject DMARC setting are not >>=20 >> "a p=3Dreject" >>=20 >>> going to be affected in any way. >>>=20 >>> For emails from p=3Dreject domains: >>>=20 >>> - =46rom header field of such emails will be rewritten to be under >>=20 >> "The =46rom header" >>=20 >>> @dmarc.ietf.org domain (which will have p=3Dnone policy). For >>=20 >> "a p=3Dnone"? >>=20 >>> example, "alexey@example.com" email address would become >>=20 >> the "alexey@example.com" >>=20 >> -Benjamin >>=20 >>> "alexey%40example.com@dmarc.ietf.org". >=20 > That should be "alexey=3D40example.com@dmarc.ietf.org". Well spotted. I=E2=80=99ve corrected that in the email I=E2=80=99ve just sen= t to ietf@ietf.org >=20 > Henrik >=20 >>> The original =46rom header >>> field will be preserved in the X-Original-=46rom header field, >>> which can be used for automatic message processing by Sieve and >>> Mail User Agents. >>>=20 >>> Note that the mapping is reversible, so it is possible to send >>> replies or new messages to an original sender by sending them to >>> the corresponding mapped @dmarc.ietf.org email address. >>>=20 >>> Best Regards, Alexey >>>=20 >>=20 >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >>=20 >=20 From nobody Wed May 16 11:57:18 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5583912D88B for ; Wed, 16 May 2018 11:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 LvaED0r3GdNv for ; Wed, 16 May 2018 11:57:14 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79237126C0F for ; Wed, 16 May 2018 11:57:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 8A4AB1C00B9 for ; Wed, 16 May 2018 11:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7uMg4RuNzBZ for ; Wed, 16 May 2018 11:57:08 -0700 (PDT) Received: from Heathers-MacBook-Pro.local (c-73-181-135-61.hsd1.wa.comcast.net [73.181.135.61]) by c8a.amsl.com (Postfix) with ESMTPSA id 532A61C00B8 for ; Wed, 16 May 2018 11:57:08 -0700 (PDT) To: tools-development@ietf.org References: From: "Heather Flanagan (RFC Series Editor)" Message-ID: Date: Wed, 16 May 2018 11:57:13 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] SVG RFC _ should we allow Markers in SVG diagrams X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 18:57:17 -0000 Hi all, I'd like to pop this up the stack in your email queue. Any thoughts/opinions here? Thanks! Heather On 5/8/18 3:20 PM, Nevil Brownlee wrote: > > Hi Tools-dev folk: > > Jim Schaad has raised the question "should the marker element be > allowed in > SVG RFC?" > > I've raised this as an issue for RFC SVG, the URL for that discussion is >   https://github.com/rfc-format/draft-iab-svg-rfc-bis/issues/5 > > The short version of that is: > > FOR: Many SVG drawing/editing programs use markers for arrowheads etc, > and >        people will probably want to use those. > > AGAINST: The marker element is not allowed in SVG Tiny (SVG for > small-screen >        devices).  If we allow it in SVG RFC, how likely is it that >        small-screen devices won;t be able to display images using > markers? > > If we decide to allow markers, I can certainly rework the iab-rfc-bis > draft > to do that - but that's a change that needs wider discussion. > > What do you all thinnk about this, please? > > Cheers, Nevil > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development > From nobody Wed May 16 13:05:35 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6CB12D957 for ; Wed, 16 May 2018 13:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 luLp8ZWUsVqv for ; Wed, 16 May 2018 13:05:32 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 B347112741D for ; Wed, 16 May 2018 13:05:32 -0700 (PDT) Received: from unescapeable.local ([47.186.17.148]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4GK5UTj045716 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 16 May 2018 15:05:31 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.17.148] claimed to be unescapeable.local To: "Heather Flanagan (RFC Series Editor)" , tools-development@ietf.org References: From: Robert Sparks Message-ID: Date: Wed, 16 May 2018 15:05:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] SVG RFC _ should we allow Markers in SVG diagrams X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 20:05:34 -0000 I worry it won't be as simple as "markers are allowed" -  the marker spec includes animation elements for example. Will our profile, as currently written disallow those, or would we have to add marker-specific profiling text? (I'm looking at ). I would also like to find out why they were not included in tinysvg. RjS On 5/16/18 1:57 PM, Heather Flanagan (RFC Series Editor) wrote: > Hi all, > > I'd like to pop this up the stack in your email queue. Any > thoughts/opinions here? > > Thanks! > Heather > > On 5/8/18 3:20 PM, Nevil Brownlee wrote: >> >> Hi Tools-dev folk: >> >> Jim Schaad has raised the question "should the marker element be >> allowed in >> SVG RFC?" >> >> I've raised this as an issue for RFC SVG, the URL for that discussion is >>   https://github.com/rfc-format/draft-iab-svg-rfc-bis/issues/5 >> >> The short version of that is: >> >> FOR: Many SVG drawing/editing programs use markers for arrowheads >> etc, and >>        people will probably want to use those. >> >> AGAINST: The marker element is not allowed in SVG Tiny (SVG for >> small-screen >>        devices).  If we allow it in SVG RFC, how likely is it that >>        small-screen devices won;t be able to display images using >> markers? >> >> If we decide to allow markers, I can certainly rework the iab-rfc-bis >> draft >> to do that - but that's a change that needs wider discussion. >> >> What do you all thinnk about this, please? >> >> Cheers, Nevil >> >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >> > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development From nobody Wed May 16 13:07:01 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3987B127522 for ; Wed, 16 May 2018 13:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 UbWgJW_Nixc8 for ; Wed, 16 May 2018 13:06:57 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C3413127419 for ; Wed, 16 May 2018 13:06:57 -0700 (PDT) Received: from unescapeable.local ([47.186.17.148]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4GK6v78045951 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 16 May 2018 15:06:57 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.17.148] claimed to be unescapeable.local From: Robert Sparks To: "Heather Flanagan (RFC Series Editor)" , tools-development@ietf.org References: Message-ID: Date: Wed, 16 May 2018 15:06:56 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] SVG RFC _ should we allow Markers in SVG diagrams X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 20:06:59 -0000 is the editor's copy and it has better working links. On 5/16/18 3:05 PM, Robert Sparks wrote: > I worry it won't be as simple as "markers are allowed" -  the marker > spec includes animation elements for example. Will our profile, as > currently written disallow those, or would we have to add > marker-specific profiling text? > > (I'm looking at ). > > I would also like to find out why they were not included in tinysvg. > > RjS > > > On 5/16/18 1:57 PM, Heather Flanagan (RFC Series Editor) wrote: >> Hi all, >> >> I'd like to pop this up the stack in your email queue. Any >> thoughts/opinions here? >> >> Thanks! >> Heather >> >> On 5/8/18 3:20 PM, Nevil Brownlee wrote: >>> >>> Hi Tools-dev folk: >>> >>> Jim Schaad has raised the question "should the marker element be >>> allowed in >>> SVG RFC?" >>> >>> I've raised this as an issue for RFC SVG, the URL for that >>> discussion is >>>   https://github.com/rfc-format/draft-iab-svg-rfc-bis/issues/5 >>> >>> The short version of that is: >>> >>> FOR: Many SVG drawing/editing programs use markers for arrowheads >>> etc, and >>>        people will probably want to use those. >>> >>> AGAINST: The marker element is not allowed in SVG Tiny (SVG for >>> small-screen >>>        devices).  If we allow it in SVG RFC, how likely is it that >>>        small-screen devices won;t be able to display images using >>> markers? >>> >>> If we decide to allow markers, I can certainly rework the >>> iab-rfc-bis draft >>> to do that - but that's a change that needs wider discussion. >>> >>> What do you all thinnk about this, please? >>> >>> Cheers, Nevil >>> >>> _______________________________________________ >>> TOOLS-DEVELOPMENT mailing list >>> TOOLS-DEVELOPMENT@ietf.org >>> https://www.ietf.org/mailman/listinfo/tools-development >>> >> >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development > From nobody Fri May 18 06:29:15 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4969C12D949 for ; Fri, 18 May 2018 06:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=FErk/cfP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iN7+Jkji 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 dOwfXaC9l1D8 for ; Fri, 18 May 2018 06:29:12 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC3112D946 for ; Fri, 18 May 2018 06:29:12 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 0470C221AE; Fri, 18 May 2018 09:29:12 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Fri, 18 May 2018 09:29:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=sHoFcsC74IdQAGMiBni599EMm9YJ8qYzHV/OKfQAgRQ=; b=FErk/cfP S7ybw1fou0PA1B4Q7KVdQimFdyw4RbFi/9GX5CGLHuRM0/JzgMlJd3uhH7gzZGOv YXDE2Mua4nM5yjXwuNy+vv9SSQZBH+fnvJgaSMfDF2+I3Xl7LouG0yAVi/7000fL srvZhTp92ah5cXvxwhsGrZ/6sHWA3azNfFoDolQtuq2YVSoSV2zCL+4U4bDspFwl lNZRGLXok6ez35LS7F0HUZ88nCqGKU+CPmfmyY2nJlzGGZJb/b1a293ExJ/TTAF+ yqgeYVcLoyUBs46b6S9dI5adpKrOTqTZLM107syqbc9MKLuifkZotixcmzThq614 tRCEFP1nq9+K7A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=sHoFcsC74IdQAGMiBni599EMm9YJ8 qYzHV/OKfQAgRQ=; b=iN7+JkjizNv+zecU+TVRJa8OUsUptSueAi42CIk8cLEfe vKVufgPMvxku2k7XP3ahgCbDMu4PrJ5jPGWujr3NpoTjSfqKDZl8Sg060tEYS5R9 nO4PW6GHJJPFMFdCXRjWcBgA5TEJkveuPIAxv98vUCmf6IWsTnPQV7OwPrrU6aed BwgD4eCtSU0Lcd5kbUYBn9YzeRILh9C/5zU4dckG832R0IM7Uhk4tCzfzA8tosOu veACKKdUmYHv0kpDpEZ909+VyxIT1oLi0gfHgEUGxR7vrpA/G2jo3eaKR2Y4ZPyp urdDaHtIWikTXOJGUMxTZSX/K193uFjAAEjeuBmhA== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D30E29E0CD; Fri, 18 May 2018 09:29:11 -0400 (EDT) Message-Id: <1526650151.1246027.1376784864.6A295F47@webmail.messagingengine.com> From: Alexey Melnikov To: tools-development@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-a224ff37 Date: Fri, 18 May 2018 14:29:11 +0100 Archived-At: Subject: [TOOLS-DEVELOPMENT] Small feature request from IESG: notify secretariat when an IESG ballot is issued X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 13:29:14 -0000 Dear Tools Team, IESG would like to experiment with IETF Secretariat performing management of IESG agendas. IESG agreed that Secretariat would assign documents to IESG agendas based on document "ballot issuance". In order to make this simpler for Secretariat, Secretariat asked for an email with distinguishable subject prefix is sent directly to Secretariat. My understanding is that currently any issued ballot generates an email to iesg@ietf.org, but Secretariat commented that there are lots of emails sent to iesg@ietf.org, so Secretariat would like to see easily distinguishable messages addressed to them. Thank you, Alexey From nobody Fri May 18 08:17:16 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D1512DA3F for ; Fri, 18 May 2018 08:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 uTkOyk2eycdl for ; Fri, 18 May 2018 08:17:13 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B12712D87F for ; Fri, 18 May 2018 08:17:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 0E5581C00B6; Fri, 18 May 2018 08:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALEa1IO3wheZ; Fri, 18 May 2018 08:17:04 -0700 (PDT) Received: from [IPv6:2601:647:4200:a088:6918:6652:6349:b866] (unknown [IPv6:2601:647:4200:a088:6918:6652:6349:b866]) by c8a.amsl.com (Postfix) with ESMTPSA id D48031C00B5; Fri, 18 May 2018 08:17:04 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Alexa Morris In-Reply-To: <1526650151.1246027.1376784864.6A295F47@webmail.messagingengine.com> Date: Fri, 18 May 2018 08:17:12 -0700 Cc: tools-development@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1526650151.1246027.1376784864.6A295F47@webmail.messagingengine.com> To: "aamelnikov@fastmail.fm" X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Small feature request from IESG: notify secretariat when an IESG ballot is issued X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 15:17:15 -0000 Hi, > On May 18, 2018, at 6:29 AM, Alexey Melnikov = wrote: >=20 > Dear Tools Team, >=20 > IESG would like to experiment with IETF Secretariat performing = management of IESG agendas. IESG agreed that Secretariat would assign = documents to IESG agendas based on document "ballot issuance". In order = to make this simpler for Secretariat, Secretariat asked for an email = with distinguishable subject prefix is sent directly to Secretariat. My = understanding is that currently any issued ballot generates an email to = iesg@ietf.org, but Secretariat commented that there are lots of emails = sent to iesg@ietf.org, so Secretariat would like to see easily = distinguishable messages addressed to them. Specifically, the email should be directed to iesg-secretary@ietf.org, = so that it generates a ticket. Thanks, Alexa >=20 > Thank you, > Alexey >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development >=20 From nobody Fri May 18 11:50:52 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF54A12DA22 for ; Fri, 18 May 2018 11:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 2OLpwQ4LsTPv for ; Fri, 18 May 2018 11:50:47 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A04C212D80E for ; Fri, 18 May 2018 11:50:47 -0700 (PDT) Received: from unescapeable.local ([47.186.17.148]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4IIoVnt039021 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 18 May 2018 13:50:31 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.17.148] claimed to be unescapeable.local To: Alexa Morris , "aamelnikov@fastmail.fm" Cc: tools-development@ietf.org References: <1526650151.1246027.1376784864.6A295F47@webmail.messagingengine.com> From: Robert Sparks Message-ID: <4847a075-9e9e-8cf2-f71c-2293c01fd1ab@nostrum.com> Date: Fri, 18 May 2018 13:50:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Small feature request from IESG: notify secretariat when an IESG ballot is issued X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 18:50:51 -0000 After a quick chat with Cindy, the easiest thing to do seems acceptable, and that's to add iesg-secretary@ietf.org to the CC of the message that goes to the iesg. (And that's a mailtrigger change - data, not code - so it's really easy.) RjS On 5/18/18 10:17 AM, Alexa Morris wrote: > Hi, > >> On May 18, 2018, at 6:29 AM, Alexey Melnikov wrote: >> >> Dear Tools Team, >> >> IESG would like to experiment with IETF Secretariat performing management of IESG agendas. IESG agreed that Secretariat would assign documents to IESG agendas based on document "ballot issuance". In order to make this simpler for Secretariat, Secretariat asked for an email with distinguishable subject prefix is sent directly to Secretariat. My understanding is that currently any issued ballot generates an email to iesg@ietf.org, but Secretariat commented that there are lots of emails sent to iesg@ietf.org, so Secretariat would like to see easily distinguishable messages addressed to them. > Specifically, the email should be directed to iesg-secretary@ietf.org, so that it generates a ticket. > > Thanks, > Alexa >> Thank you, >> Alexey >> >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >> > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development From nobody Fri May 18 11:56:53 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F7912DA6D for ; Fri, 18 May 2018 11:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 zVFZdUPo6rAB for ; Fri, 18 May 2018 11:56:50 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 0225A12DA68 for ; Fri, 18 May 2018 11:56:49 -0700 (PDT) Received: from unescapeable.local ([47.186.17.148]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4IIuagC040089 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 18 May 2018 13:56:36 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.17.148] claimed to be unescapeable.local From: Robert Sparks To: Alexa Morris , "aamelnikov@fastmail.fm" Cc: tools-development@ietf.org References: <1526650151.1246027.1376784864.6A295F47@webmail.messagingengine.com> <4847a075-9e9e-8cf2-f71c-2293c01fd1ab@nostrum.com> Message-ID: Date: Fri, 18 May 2018 13:56:36 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <4847a075-9e9e-8cf2-f71c-2293c01fd1ab@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Small feature request from IESG: notify secretariat when an IESG ballot is issued X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 18:56:51 -0000 And that's done. On 5/18/18 1:50 PM, Robert Sparks wrote: > After a quick chat with Cindy, the easiest thing to do seems > acceptable, and that's to add iesg-secretary@ietf.org to the CC of the > message that goes to the iesg. > > (And that's a mailtrigger change - data, not code - so it's really easy.) > > RjS > > > On 5/18/18 10:17 AM, Alexa Morris wrote: >> Hi, >> >>> On May 18, 2018, at 6:29 AM, Alexey Melnikov >>> wrote: >>> >>> Dear Tools Team, >>> >>> IESG would like to experiment with IETF Secretariat performing >>> management of IESG agendas. IESG agreed that Secretariat would >>> assign documents to IESG agendas based on document "ballot >>> issuance". In order to make this simpler for Secretariat, >>> Secretariat asked for an email with distinguishable subject prefix >>> is sent directly to Secretariat. My understanding is that currently >>> any issued ballot generates an email to iesg@ietf.org, but >>> Secretariat commented that there are lots of emails sent to >>> iesg@ietf.org, so Secretariat would like to see easily >>> distinguishable messages addressed to them. >> Specifically, the email should be directed to >> iesg-secretary@ietf.org, so that it generates a ticket. >> >> Thanks, >> Alexa >>> Thank you, >>> Alexey >>> >>> _______________________________________________ >>> TOOLS-DEVELOPMENT mailing list >>> TOOLS-DEVELOPMENT@ietf.org >>> https://www.ietf.org/mailman/listinfo/tools-development >>> >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development From nobody Fri May 25 11:44:43 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A28E12DFE0 for ; Fri, 25 May 2018 11:44:41 -0700 (PDT) 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=ham autolearn_force=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 8ebVLZ6Rne8t for ; Fri, 25 May 2018 11:44:39 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04FC5127286 for ; Fri, 25 May 2018 11:44:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D7DD83009FB for ; Fri, 25 May 2018 14:44:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7hZERixwNSsm for ; Fri, 25 May 2018 14:44:36 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id EDF62300558 for ; Fri, 25 May 2018 14:44:35 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <2A62A328-53BF-450C-907B-3335374A35E3@vigilsec.com> Date: Fri, 25 May 2018 14:44:36 -0400 To: IETF Tools Development X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [TOOLS-DEVELOPMENT] Search across the web site, mail archive, and datatracker X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 18:44:42 -0000 We have been asked to look into a search feature that is homed at = www.ietf.org that will search across the web site, mail archive, and = datatracker. The way I use the IETF website, I know when I am searching for = meeting-related material, I-D-related material, or mail-archive-related = material. I rarely want to mix these things, so I am not the right = person to make suggestions about the way forward. That said, others, especially folks that are new to the IETF, come to = www.ietf.org looking for information about IETF work or a particular = standard, and the current search does not help them enough. They = probably don=E2=80=99t even know about datatracker. For example, they = would expect to get results about a current work item, say TLS 1.3, that = includes information that we know is in the datatracker, especially the = most recent Internet-Draft. My first thought was to see if we could leverage Google search. The SoW = for the recent website revamp says that core functions must not require = javascript. According to the documentation from Google = (https://developers.google.com/custom-search/docs/overview) custom = search does require javascript. Since search ought to be a core = function, the Google custom search is not a way forward. Does anyone have thoughts about how to approach this search feature? Russ From nobody Fri May 25 12:12:56 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D47C12E855 for ; Fri, 25 May 2018 12:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 E-nZG3GvNm0A for ; Fri, 25 May 2018 12:12:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A936E12E866 for ; Fri, 25 May 2018 12:12:43 -0700 (PDT) Received: from unescapeable.local ([47.186.17.148]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4PJCfBh018511 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 25 May 2018 14:12:41 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.17.148] claimed to be unescapeable.local To: tools-development@ietf.org References: <2A62A328-53BF-450C-907B-3335374A35E3@vigilsec.com> From: Robert Sparks Message-ID: Date: Fri, 25 May 2018 14:12:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <2A62A328-53BF-450C-907B-3335374A35E3@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Search across the web site, mail archive, and datatracker X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 19:12:54 -0000 My first thought (which assumes that the search function already on www.ietf.org is sufficient for searching the website - is that a correct assumption?) is to provide an api from the datatracker and the mailarchive that would take the search term and return what's needed (json objects, I think) to allow the www website to nicely show the results grouped by type. We could make a view there that doesn't use js (waits for results before displaying everything, then displays _everything), but could provide a better experience for folks that are willing to let js run (starts showing results as they come in, might provide a way to collapse the results, in a tree perhaps). RjS On 5/25/18 1:44 PM, Russ Housley wrote: > We have been asked to look into a search feature that is homed at www.ietf.org that will search across the web site, mail archive, and datatracker. > > The way I use the IETF website, I know when I am searching for meeting-related material, I-D-related material, or mail-archive-related material. I rarely want to mix these things, so I am not the right person to make suggestions about the way forward. > > That said, others, especially folks that are new to the IETF, come to www.ietf.org looking for information about IETF work or a particular standard, and the current search does not help them enough. They probably don’t even know about datatracker. For example, they would expect to get results about a current work item, say TLS 1.3, that includes information that we know is in the datatracker, especially the most recent Internet-Draft. > > My first thought was to see if we could leverage Google search. The SoW for the recent website revamp says that core functions must not require javascript. According to the documentation from Google (https://developers.google.com/custom-search/docs/overview) custom search does require javascript. Since search ought to be a core function, the Google custom search is not a way forward. > > Does anyone have thoughts about how to approach this search feature? > > Russ > > > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development From nobody Fri May 25 13:42:06 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D74129502 for ; Fri, 25 May 2018 13:42:04 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Nbx7wx52XXqY for ; Fri, 25 May 2018 13:42:02 -0700 (PDT) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 5A1C31275F4 for ; Fri, 25 May 2018 13:42:02 -0700 (PDT) Received: by mail-pg0-x243.google.com with SMTP id d14-v6so2749717pgv.8 for ; Fri, 25 May 2018 13:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=eVOARaXtzOrDkCVf4M9bsC336/Y8c3oCSJ+Zii5t0iE=; b=Vj8/xnUaw99+94d6OvQ53hfKt/CcCQRfRm26c8LXjHIvw5aMUdnCT1TUBG+LEJ2A+B vmnVuVajkwlZArsN7AMXRXOxxuMD6g6kWkE+nNWMZLzNq1FnqsV6r7wAHwcFU3RnYHIy Qj1XrOpT50E+aPwQGk4+Gvve4aMkL5vHyIeMqR4/Cx2xbzFVgUFUGDzOHkYVNydAPLzt cuyDjBFHF7iVYw4By9hZKUUBe0aatoKcbHRUx0vP8vWiMIwqCSDMYPWoOwp4AdsCQ2UT BAaX414SofyCqsDlTLG73Ba4V+zMCJUGjEyIQ+EMG77yrLpPvCsMKAw5evCZI8FXY8q5 3P2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=eVOARaXtzOrDkCVf4M9bsC336/Y8c3oCSJ+Zii5t0iE=; b=mwCC7o118TLJjHyZhXKbbb/7a6qxNQkgqoL0ZLBa+mD8NQMVnxqPSN87eEXI6Pxqhx FP/6AauwMLAzg24a+cxMC+w4b69WhRDlcDhjJi7XahoxQQS9qE0QX9j5WdiYxKRbYaSM jUxq3RJzHn7ZN/hJuDLaeZNjRDKasQPYc8hQVRg+5iivpM6CfIRZzFdqLWR+BKOJL+5H 8PIzLNr+aH3TO/2uQelOuqCQQFVpi927e7c1BlhW3sAGFjAjUzphma3Z6VGHGJTc4cwY O57A1cQQWDQLRpB5TsZRQerjoAtKQZhQbbho1ftFhi/XkHmUHidIzNogU5+IkzCwsG0P ERYA== X-Gm-Message-State: ALKqPwdxs1AyjGWZgAfKzbeffUb+6C30WGwPJephbu1C+eJpLsjjPv66 kanDYJMYKN3zuXkF+Una6So= X-Google-Smtp-Source: AB8JxZpQrx1PMzkdvliTevGGRx4PwYg+p5IvYZUrMRo4apRImymURrFATi9+OqvfJHjo3qmYfHilVA== X-Received: by 2002:a63:7905:: with SMTP id u5-v6mr3115750pgc.411.1527280921677; Fri, 25 May 2018 13:42:01 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id s1-v6sm35613101pgr.66.2018.05.25.13.42.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 May 2018 13:42:00 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9988317B-178E-4F53-9362-8CAFB6BA59DA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 25 May 2018 13:41:59 -0700 In-Reply-To: <2A62A328-53BF-450C-907B-3335374A35E3@vigilsec.com> Cc: Bob Hinden , IETF Tools Development To: Russ Housley References: <2A62A328-53BF-450C-907B-3335374A35E3@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Search across the web site, mail archive, and datatracker X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 20:42:05 -0000 --Apple-Mail=_9988317B-178E-4F53-9362-8CAFB6BA59DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Russ, > On May 25, 2018, at 11:44 AM, Russ Housley = wrote: >=20 > We have been asked to look into a search feature that is homed at = www.ietf.org that will search across the web site, mail archive, and = datatracker. >=20 > The way I use the IETF website, I know when I am searching for = meeting-related material, I-D-related material, or mail-archive-related = material. I rarely want to mix these things, so I am not the right = person to make suggestions about the way forward. > That said, others, especially folks that are new to the IETF, come to = www.ietf.org looking for information about IETF work or a particular = standard, and the current search does not help them enough. They = probably don=E2=80=99t even know about datatracker. For example, they = would expect to get results about a current work item, say TLS 1.3, that = includes information that we know is in the datatracker, especially the = most recent Internet-Draft. I am not convinced that an IETF wide search function like you describe = will be very useful I worry it will either come up with too many hits, = or the wrong ones. For example, I think a search for =E2=80=9CIPv6 = neighbor discovery=E2=80=9D will return thousands of emails, hundreds of = drafts, and tens of RFCs, and a lot of IPv6 and 6man w.g. agendas. = Somewhere in the vast amount of returns one might figure out that 6man = is doing an update to IPv6 Node Requirements that includes Neighbor = Discovery items. Is this useful? In the case you describe, we would have to formally define what an = =E2=80=9Cwork item=E2=80=9D means, and have a formal list. Otherwise = the search tool is know to have to know what the user is intending to = search for, that seems difficult to me. Bob >=20 > My first thought was to see if we could leverage Google search. The = SoW for the recent website revamp says that core functions must not = require javascript. According to the documentation from Google = (https://developers.google.com/custom-search/docs/overview) custom = search does require javascript. Since search ought to be a core = function, the Google custom search is not a way forward. >=20 > Does anyone have thoughts about how to approach this search feature? >=20 > Russ >=20 >=20 >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development --Apple-Mail=_9988317B-178E-4F53-9362-8CAFB6BA59DA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAlsIdRcACgkQrut0EXfn u6gnhQf/aqV+2L0ElbEhdHLCBLOesHk3fMCDRQw2ZX4ZF01CuLCCl7tpOcCUEq5C soaOSLwPnfHGNZ0RuO3paccac6+BkTdnon6aJO2iW1LirgVed/W0xVNbCzYf/VP9 g9MvR0c/qg8aZDPkuJbY7ce3csAYyEuBvktQFNGztxiniOURbO3MvivYnZh3t0VD GI2G7ys24Iu/einQ9J4RvjGxW3zfOls3+4bVgmnxDyapumINrz+lLaiGv+egGTzJ wATI6AzOpBZ4HJ1mTCuf6Grl2TB8ugGdM3UbYDxzjSTQySUwn1QLCZ1E+SFPlDqT T4MN9Fh1V2tSQp+HGmgT8a4fek4h2A== =Joka -----END PGP SIGNATURE----- --Apple-Mail=_9988317B-178E-4F53-9362-8CAFB6BA59DA-- From nobody Fri May 25 14:49:32 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588B3129C6E for ; Fri, 25 May 2018 14:49:30 -0700 (PDT) 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=ham autolearn_force=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 WLuXVaOTVzAB for ; Fri, 25 May 2018 14:49:28 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C46128959 for ; Fri, 25 May 2018 14:49:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 55744300A2C for ; Fri, 25 May 2018 17:49:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id S_zYnPbt0pct for ; Fri, 25 May 2018 17:49:25 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 121AC30063A; Fri, 25 May 2018 17:49:25 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Fri, 25 May 2018 17:49:24 -0400 Cc: IETF Tools Development Content-Transfer-Encoding: quoted-printable Message-Id: <5DFB46D8-0719-4A7D-8F96-C1C98660907C@vigilsec.com> References: <2A62A328-53BF-450C-907B-3335374A35E3@vigilsec.com> To: Bob Hinden X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Search across the web site, mail archive, and datatracker X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 21:49:31 -0000 Bob: >=20 >> We have been asked to look into a search feature that is homed at = www.ietf.org that will search across the web site, mail archive, and = datatracker. >>=20 >> The way I use the IETF website, I know when I am searching for = meeting-related material, I-D-related material, or mail-archive-related = material. I rarely want to mix these things, so I am not the right = person to make suggestions about the way forward. >=20 >> That said, others, especially folks that are new to the IETF, come to = www.ietf.org looking for information about IETF work or a particular = standard, and the current search does not help them enough. They = probably don=E2=80=99t even know about datatracker. For example, they = would expect to get results about a current work item, say TLS 1.3, that = includes information that we know is in the datatracker, especially the = most recent Internet-Draft. >=20 > I am not convinced that an IETF wide search function like you describe = will be very useful I worry it will either come up with too many hits, = or the wrong ones. For example, I think a search for =E2=80=9CIPv6 = neighbor discovery=E2=80=9D will return thousands of emails, hundreds of = drafts, and tens of RFCs, and a lot of IPv6 and 6man w.g. agendas. = Somewhere in the vast amount of returns one might figure out that 6man = is doing an update to IPv6 Node Requirements that includes Neighbor = Discovery items. Is this useful? I made a similar comment, and the ranking of the search hits will = certainly be vital to the tools being useful. > In the case you describe, we would have to formally define what an = =E2=80=9Cwork item=E2=80=9D means, and have a formal list. Otherwise = the search tool is know to have to know what the user is intending to = search for, that seems difficult to me. Interesting thought. I wonder if it would be hard to process the = charter text or charter milestones to help create a set of active work = items. Russ From nobody Fri May 25 15:04:18 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1DC12DA3F for ; Fri, 25 May 2018 15:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 IeSer3o7esvR for ; Fri, 25 May 2018 15:04:15 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28CE3127978 for ; Fri, 25 May 2018 15:04:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 259E71C00FF; Fri, 25 May 2018 15:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZX1ghWT1tFE; Fri, 25 May 2018 15:03:56 -0700 (PDT) Received: from [IPv6:2601:602:9c02:e2b0:49af:7e3a:8b0:949c] (unknown [IPv6:2601:602:9c02:e2b0:49af:7e3a:8b0:949c]) by c8a.amsl.com (Postfix) with ESMTPSA id D908C1C00B8; Fri, 25 May 2018 15:03:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Ryan Cross In-Reply-To: Date: Fri, 25 May 2018 15:04:14 -0700 Cc: tools-development@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <38D934A5-F026-441A-9027-76537D9CAA1E@amsl.com> References: <2A62A328-53BF-450C-907B-3335374A35E3@vigilsec.com> To: Robert Sparks X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Search across the web site, mail archive, and datatracker X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 22:04:18 -0000 I imagine it would be possible to create an Elasticsearch index for each = type of =E2=80=9Cdocument=E2=80=9D, draft, email, webpage, etc. You = could filter by type and indicate the type in search results, using an = icon for example. Ryan > On May 25, 2018, at 12:12 PM, Robert Sparks = wrote: >=20 > My first thought (which assumes that the search function already on = www.ietf.org is sufficient for searching the website - is that a correct = assumption?) is to provide an api from the datatracker and the = mailarchive that would take the search term and return what's needed = (json objects, I think) to allow the www website to nicely show the = results grouped by type. We could make a view there that doesn't use js = (waits for results before displaying everything, then displays = _everything), but could provide a better experience for folks that are = willing to let js run (starts showing results as they come in, might = provide a way to collapse the results, in a tree perhaps). >=20 > RjS >=20 > On 5/25/18 1:44 PM, Russ Housley wrote: >> We have been asked to look into a search feature that is homed at = www.ietf.org that will search across the web site, mail archive, and = datatracker. >>=20 >> The way I use the IETF website, I know when I am searching for = meeting-related material, I-D-related material, or mail-archive-related = material. I rarely want to mix these things, so I am not the right = person to make suggestions about the way forward. >>=20 >> That said, others, especially folks that are new to the IETF, come to = www.ietf.org looking for information about IETF work or a particular = standard, and the current search does not help them enough. They = probably don=E2=80=99t even know about datatracker. For example, they = would expect to get results about a current work item, say TLS 1.3, that = includes information that we know is in the datatracker, especially the = most recent Internet-Draft. >>=20 >> My first thought was to see if we could leverage Google search. The = SoW for the recent website revamp says that core functions must not = require javascript. According to the documentation from Google = (https://developers.google.com/custom-search/docs/overview) custom = search does require javascript. Since search ought to be a core = function, the Google custom search is not a way forward. >>=20 >> Does anyone have thoughts about how to approach this search feature? >>=20 >> Russ >>=20 >>=20 >>=20 >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development