From nobody Tue Dec 2 05:43:20 2014 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1B71A1BAD; Tue, 2 Dec 2014 05:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtiQLHu8Ep2e; Tue, 2 Dec 2014 05:43:14 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 451FB1A0155; Tue, 2 Dec 2014 05:43:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AFB2FBED3; Tue, 2 Dec 2014 13:43:13 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zviLixNxADZi; Tue, 2 Dec 2014 13:43:12 +0000 (GMT) Received: from [10.128.160.222] (unknown [212.76.224.120]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B658FBECA; Tue, 2 Dec 2014 13:43:10 +0000 (GMT) Message-ID: <547DC1EE.7080406@cs.tcd.ie> Date: Tue, 02 Dec 2014 13:43:10 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Daniel Burnett , Hannes Tschofenig References: <547D82E3.4030306@gmx.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tools-discuss/PaWJzZsU6gRaPypNeaY95fE4L50 Cc: wgchairs@ietf.org, "tools-discuss@ietf.org Discussion" Subject: Re: [Tools-discuss] Connectivity Problems with IETF Tools Page X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 13:43:16 -0000 Adding tools-discuss where answers may be found... S On 02/12/14 12:16, Daniel Burnett wrote: > Yes, I was having the same problem yesterday, with anything hosted at > tools.ietf.org. Haven't had time to try to debug yet . . . > > -- dan > > On Tue, Dec 2, 2014 at 4:14 AM, Hannes Tschofenig > wrote: > >> Over the last few days I had noticed problems connecting to the IETF >> tools page (such as https://tools.ietf.org/wg/dice/trac/report/1). >> >> Sometimes it worked, sometimes it didn't. It was always slow. >> >> Did someone notice something similar or is it just my side? >> >> Ciao >> Hannes >> >> > From nobody Tue Dec 2 06:18:46 2014 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9B71A1BAD for ; Tue, 2 Dec 2014 06:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7duuYehwv9yb for ; Tue, 2 Dec 2014 06:18:38 -0800 (PST) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7781A1B93 for ; Tue, 2 Dec 2014 06:18:31 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id y19so16996293wgg.21 for ; Tue, 02 Dec 2014 06:18:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=reSLWXLcLsYNwZlSOt3eAgZ7aC6WAEehcEVchNQm8LQ=; b=KGXtSP7S0NBgvGfv6bwkcBv7pwyFIvYK3DPSNEof/uMzLqz2phTYamR4oQfks1/wUV uOoDFETCeMQifvk6XI7KjSzmc9K0C65CqKAgj90oFrD+1x2FH9+0C8jzbTlCkl+14PN3 tTDZPoj2LnUFwNQ39zQ/RKg0s2YxILuhfWp4p2wce3V7gHrUDhCBYvhHuHK9erppedHq sUSqcHxRZAuJlS7x6tcvRQr96PqOHZpvqBgg1OgtoGLyNBKkTxXTvUPFmOs+hPUkx2NP EAk9ilEM91CSs7zvaTyvCw6cOtsD2PVDIxCeORDSypTQkQkRBQiCqZWvXoUDduuTJTgz 910Q== X-Gm-Message-State: ALoCoQngH28UJ5L+4x8urNZhW2lUY56FhufuQ2pIAy/gvdOoeAws5ItxZEvvYk8arc/5Ri1N2dd4 MIME-Version: 1.0 X-Received: by 10.194.63.229 with SMTP id j5mr104036730wjs.23.1417529908974; Tue, 02 Dec 2014 06:18:28 -0800 (PST) Received: by 10.194.64.37 with HTTP; Tue, 2 Dec 2014 06:18:28 -0800 (PST) In-Reply-To: <547DC1EE.7080406@cs.tcd.ie> References: <547D82E3.4030306@gmx.net> <547DC1EE.7080406@cs.tcd.ie> Date: Tue, 2 Dec 2014 09:18:28 -0500 Message-ID: From: Warren Kumari To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tools-discuss/K7D55JSkitSQtE8FqNLqBLNcopk Cc: Hannes Tschofenig , WG Chairs , Daniel Burnett , "tools-discuss@ietf.org Discussion" Subject: Re: [Tools-discuss] Connectivity Problems with IETF Tools Page X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 14:18:41 -0000 On Tue, Dec 2, 2014 at 8:43 AM, Stephen Farrell wrote: > > Adding tools-discuss where answers may be found... > > S > > On 02/12/14 12:16, Daniel Burnett wrote: >> Yes, I was having the same problem yesterday, with anything hosted at >> tools.ietf.org. Haven't had time to try to debug yet . . . I also didn't debug (kvetching is easier, and more fun!), but yesterday at ~1:00AM UTC (8PM EST) tools.ietf.org was unreachable for me, and for http://www.downforeveryoneorjustme.com/tools.ietf.org: "It's not just you! http://tools.ietf.org looks down from here." Seeing as I didn't debug anything, this is simply noise / Me Too! W >> >> -- dan >> >> On Tue, Dec 2, 2014 at 4:14 AM, Hannes Tschofenig >> wrote: >> >>> Over the last few days I had noticed problems connecting to the IETF >>> tools page (such as https://tools.ietf.org/wg/dice/trac/report/1). >>> >>> Sometimes it worked, sometimes it didn't. It was always slow. >>> >>> Did someone notice something similar or is it just my side? >>> >>> Ciao >>> Hannes >>> >>> >> > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Dec 2 06:35:54 2014 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A541ACE0F for ; Tue, 2 Dec 2014 06:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxHpypnoxp4a for ; Tue, 2 Dec 2014 06:35:44 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E830C1A1BAF for ; Tue, 2 Dec 2014 06:35:40 -0800 (PST) Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sB2EZU5s004861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 2 Dec 2014 08:35:40 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local Message-ID: <547DCE2D.6040506@nostrum.com> Date: Tue, 02 Dec 2014 08:35:25 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: tools-discuss@ietf.org References: <547D82E3.4030306@gmx.net> <547DC1EE.7080406@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tools-discuss/Vmclb2wiDPf--YS3UhSCKpbhbug Subject: Re: [Tools-discuss] Connectivity Problems with IETF Tools Page X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 14:35:49 -0000 There was an issue - it looks most likely just to have been a bot overzealously crawling that machine. Things should be better now. RjS On 12/2/14 8:18 AM, Warren Kumari wrote: > On Tue, Dec 2, 2014 at 8:43 AM, Stephen Farrell > wrote: >> Adding tools-discuss where answers may be found... >> >> S >> >> On 02/12/14 12:16, Daniel Burnett wrote: >>> Yes, I was having the same problem yesterday, with anything hosted at >>> tools.ietf.org. Haven't had time to try to debug yet . . . > I also didn't debug (kvetching is easier, and more fun!), but > yesterday at ~1:00AM UTC (8PM EST) tools.ietf.org was unreachable for > me, and for http://www.downforeveryoneorjustme.com/tools.ietf.org: > "It's not just you! http://tools.ietf.org looks down from here." > > Seeing as I didn't debug anything, this is simply noise / Me Too! > > W > >>> -- dan >>> >>> On Tue, Dec 2, 2014 at 4:14 AM, Hannes Tschofenig >>> wrote: >>>> Over the last few days I had noticed problems connecting to the IETF >>>> tools page (such as https://tools.ietf.org/wg/dice/trac/report/1). >>>> >>>> Sometimes it worked, sometimes it didn't. It was always slow. >>>> >>>> Did someone notice something similar or is it just my side? >>>> >>>> Ciao >>>> Hannes >>>> >>>> > > From nobody Sun Dec 21 12:17:06 2014 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FAA1A8768 for ; Sun, 21 Dec 2014 12:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hR8hP-y2fZze for ; Sun, 21 Dec 2014 12:17:01 -0800 (PST) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B101A8745 for ; Sun, 21 Dec 2014 12:17:01 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id v10so4517586pde.40 for ; Sun, 21 Dec 2014 12:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=UlBU+iC4vfxqIWXKMo9Clav+2zDzw/nv/qRF627+9qo=; b=ef7JULJhKulaPLkrX/GOC63EpM6jBtGnr+pglEwpLmgOn2xTagXnCOkiuFzBZ2RVAi iOpoeJhAs5phB+S3gr7xPGqS9ZZHHPe8xqk0FDFHBMlYeKLXfeUB510APVAuoKfAVcgf 9uuwINDdbQUYe2uUntwd0bT1JgQ1kDMDuxtFzUU7/VfUPXST19qrxSpLn33W7B6y8ko9 1cZLFESy/Roymtl/K762lOKPDzP8LBk0eXvdSLOhnpqQFCLEhdtlq3atk0h/VPOuduCf Frui5q819nxCBNIflBDOmQnicM+rRCAV4m5t7ef8BUNlrZpgDMwNx3jqQWVK3eJjHiQi xpGA== X-Received: by 10.70.52.33 with SMTP id q1mr26161293pdo.64.1419193020960; Sun, 21 Dec 2014 12:17:00 -0800 (PST) Received: from [10.0.0.38] (c-71-202-19-53.hsd1.ca.comcast.net. [71.202.19.53]) by mx.google.com with ESMTPSA id k4sm15228109pbq.74.2014.12.21.12.16.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Dec 2014 12:16:59 -0800 (PST) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_55DE2CD3-8B31-416C-8367-332C915D0FC0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Sun, 21 Dec 2014 12:16:49 -0800 Message-Id: <82E25C9F-37B3-4BD1-B864-9B988538635E@gmail.com> To: "tools-discuss@ietf.org Discussion" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/tools-discuss/azhBBW9rGsITBeHnYOmvMaKuHHc Subject: [Tools-discuss] Datatracker Email addresses X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2014 20:17:03 -0000 --Apple-Mail=_55DE2CD3-8B31-416C-8367-332C915D0FC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I discovered that the data tracker had four email addresses for me, of = which only one was active, and a few had been disabled more than ten = years ago. I discovered this because someone forwarded me a bounce for = an auth-48 email. Not good since I wasn't seeing email I should have. = Since I discovered this, I went into the datatracker manage accounts and = disabled the old non-working emails. If it happen to me, it is probably happening to others. I don't = understand why all of these old email addresses were all marked active = since there must have been countless bounces. =20 Could someone explain how this is supposed to work and what we an do to = avoid this problem in the future? Thanks, Bob p.s At least it didn't have all of the addresses listed in RFCs and IDs = I have written over the years :-) --Apple-Mail=_55DE2CD3-8B31-416C-8367-332C915D0FC0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUlyqxAAoJEK7rdBF357uo81AH/i9/bNcyO5CASkgZliSHrEqZ QAH38acsER10PJP8Ga5GidJlVQto0Vv+QED1GLpyrFyRTKkhNk5qxeVPrwR6RD/e e83uzfxyUhqDo3DmE4cmNPtU2sTVPoLyKFdG2JrpDaJBKJcCavDxvNYydx+gaSMD atSpBB6W2GvAIdyDJL4ThzKc3mjOOgt5xmS71qf/yF+ZjJaysEavkmGfCyMrWHx7 bINaI0DFXDqY9U4VV6+L0v8fqv/KsJ9uFYjiibmimUHT/nlKoQvAuN8A2m2nodEX /WoyAOj+3o5TxGjPWpb7HC8cDZ65okN4gPpR6hC8LziP/25zq5Er9lxSvOt1/BQ= =U6zu -----END PGP SIGNATURE----- --Apple-Mail=_55DE2CD3-8B31-416C-8367-332C915D0FC0-- From nobody Sun Dec 21 13:51:39 2014 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28A01A887D for ; Sun, 21 Dec 2014 13:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzKUS8ErB4eV for ; Sun, 21 Dec 2014 13:51:34 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 ADE7A1A8869 for ; Sun, 21 Dec 2014 13:51:34 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBLLpNl1035402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 21 Dec 2014 15:51:34 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <549740D6.5070107@nostrum.com> Date: Sun, 21 Dec 2014 15:51:18 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: tools-discuss@ietf.org References: <82E25C9F-37B3-4BD1-B864-9B988538635E@gmail.com> In-Reply-To: <82E25C9F-37B3-4BD1-B864-9B988538635E@gmail.com> Content-Type: multipart/alternative; boundary="------------080909000700070901010508" Archived-At: http://mailarchive.ietf.org/arch/msg/tools-discuss/tZEowNAjjd1cWLY3z1qmRERuebY Subject: Re: [Tools-discuss] Datatracker Email addresses X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2014 21:51:36 -0000 This is a multi-part message in MIME format. --------------080909000700070901010508 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 12/21/14 2:16 PM, Bob Hinden wrote: > Hi, > > I discovered that the data tracker had four email addresses for me, of which only one was active, and a few had been disabled more than ten years ago. I discovered this because someone forwarded me a bounce for an auth-48 email. Not good since I wasn't seeing email I should have. Since I discovered this, I went into the datatracker manage accounts and disabled the old non-working emails. > > If it happen to me, it is probably happening to others. I don't understand why all of these old email addresses were all marked active since there must have been countless bounces. > > Could someone explain how this is supposed to work and what we an do to avoid this problem in the future? I'm not sure what you're asking with "how this is supposed to work", but I'll provide some context you might find useful. As for avoiding the problem, anyone can (and should) look at what addresses the tracker knows for them by using the "Manage account link" after logging in. It's also a good way to check what address you have associated with your various roles. The addresses in the tracker come from several places. For most people, the primary source is their datatracker login (and this is the only address the tracker knows for them). For active draft authors, at least in recent years, new addresses are learned from drafts. New addresses can also come in via the nomcom process. Now, for people who have been around for more than a few years, some addresses came from legacy systems (this was most likely the source for the addresses in question for you). When those were imported, there was no notion of active or not, and at the time we had to assume they were active. Your particular case of an auth48 bouncing is odd - it should have been using the addresses for the authors of the draft. I didn't think the RFC Editor was using the datatracker addresses for that yet - if so, pleasant surprise. Would you be willing to forward the bounce to me and let me track down how the older address got selected? (If you were in that loop due to a role other than author, let me know, the answer there could be different). As for taking action on bounces: Until very recently (February 2014) the tracker had no visibility into bounces. Last February, we added a notification to the secretariat when an address generated an error on submission, and they work with the affected person to change their account configuration as necessary. Auth48 email isn't sent by the tracker, though, so it won't know about bounces in that workflow. Hope this helps, RjS > > Thanks, > Bob > > p.s At least it didn't have all of the addresses listed in RFCs and IDs I have written over the years :-) > > > > > > > > --------------080909000700070901010508 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 12/21/14 2:16 PM, Bob Hinden wrote:
Hi,

I discovered that the data tracker had four email addresses for me, of which only one was active, and a few had been disabled more than ten years ago.  I discovered this because someone forwarded me a bounce for an auth-48 email.  Not good since I wasn't seeing email I should have.   Since I discovered this, I went into the datatracker manage accounts and disabled the old non-working emails.

If it happen to me, it is probably happening to others.  I don't understand why all of these old email addresses were all marked active since there must have been countless bounces.  

Could someone explain how this is supposed to work and what we an do to avoid this problem in the future?

I'm not sure what you're asking with "how this is supposed to work", but I'll provide some context you might find useful.

As for avoiding the problem, anyone can (and should) look at what addresses the tracker knows for them by using the "Manage account link" after logging in.
It's also a good way to check what address you have associated with your various roles.

The addresses in the tracker come from several places.

For most people, the primary source is their datatracker login (and this is the only address the tracker knows for them).

For active draft authors, at least in recent years, new addresses are learned from drafts.
New addresses can also come in via the nomcom process.

Now, for people who have been around for more than a few years, some addresses came from legacy systems
(this was most likely the source for the addresses in question for you).
When those were imported, there was no notion of active or not, and at the time we had to assume they were active.

Your particular case of an auth48 bouncing is odd - it should have been using the addresses for the authors of the draft.
I didn't think the RFC Editor was using the datatracker addresses for that yet - if so, pleasant surprise.
Would you be willing to forward the bounce to me and let me track down how the older address got selected?
(If you were in that loop due to a role other than author, let me know, the answer there could be different).

As for taking action on bounces: Until very recently (February 2014) the tracker had no visibility into bounces.
Last February, we added a notification to the secretariat when an address generated an error on submission,
and they work with the affected person to change their account configuration as necessary.
Auth48 email isn't sent by the tracker, though, so it won't know about bounces in that workflow.

Hope this helps,

RjS

Thanks,
Bob

p.s At least it didn't have all of the addresses listed in RFCs and IDs I have written over the years :-)



--------------080909000700070901010508-- From nobody Sun Dec 21 15:08:38 2014 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D641A89C7 for ; Sun, 21 Dec 2014 15:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Clf8yjY0ZDG for ; Sun, 21 Dec 2014 15:08:26 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A689C1A89C5 for ; Sun, 21 Dec 2014 15:08:21 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fb1so4737554pad.13 for ; Sun, 21 Dec 2014 15:08:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=VJ2mlLB3TeVFyGrpqFI2O0BLmhv5PFw+nzq5GhGRRlA=; b=qCOcbR2lYMWJWIVUqm/XJLhY+uEExG6f6xZ0SIdbW/DYaHJEvNCe9+p4Cuzke/GTcd VI6N6eDmQ3RyFsPQMCZNEWclBn2qUav8MWEgPrTTpAya0e1HVD0ZRgF1Aa22igaVvRuq AOey455yha8F/xgjvUKwD01VyV25WXf0qFTIwMyu2vrFHJwpTo8lCm4+Iy9+L130usBB O3E2b33e7K0P9JsbeTVvcOfnIfXqMeQiwMe8S2FwgyD+GY/NT0AMToQYiFjr5fW3jnwD 9g+LXwHKlgnFTaaGA2yn6OBsd3XFu/sWhLD36mbYVXs6RYbwoB63fpmHqGt4z+RKTY89 q8dQ== X-Received: by 10.70.140.229 with SMTP id rj5mr30434073pdb.60.1419203300739; Sun, 21 Dec 2014 15:08:20 -0800 (PST) Received: from ?IPv6:2601:9:400:ac2:8dc7:deea:5e7a:4259? ([2601:9:400:ac2:8dc7:deea:5e7a:4259]) by mx.google.com with ESMTPSA id i5sm15541889pat.6.2014.12.21.15.08.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Dec 2014 15:08:19 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_4BF06147-900B-44C7-B234-38F255B87782"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Bob Hinden In-Reply-To: <549740D6.5070107@nostrum.com> Date: Sun, 21 Dec 2014 15:08:09 -0800 Message-Id: <7ADCB3C0-A8B6-49AD-9460-CBAC8906359F@gmail.com> References: <82E25C9F-37B3-4BD1-B864-9B988538635E@gmail.com> <549740D6.5070107@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/tools-discuss/4t6AKNCBTj8l1q3BHI733L5RRes Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] Datatracker Email addresses X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2014 23:08:34 -0000 --Apple-Mail=_4BF06147-900B-44C7-B234-38F255B87782 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Robert, On Dec 21, 2014, at 1:51 PM, Robert Sparks wrote: >=20 > On 12/21/14 2:16 PM, Bob Hinden wrote: >> Hi, >>=20 >> I discovered that the data tracker had four email addresses for me, = of which only one was active, and a few had been disabled more than ten = years ago. I discovered this because someone forwarded me a bounce for = an auth-48 email. Not good since I wasn't seeing email I should have. = Since I discovered this, I went into the datatracker manage accounts and = disabled the old non-working emails. >>=20 >> If it happen to me, it is probably happening to others. I don't = understand why all of these old email addresses were all marked active = since there must have been countless bounces. =20 >>=20 >> Could someone explain how this is supposed to work and what we an do = to avoid this problem in the future? >=20 > I'm not sure what you're asking with "how this is supposed to work", = but I'll provide some context you might find useful. >=20 > As for avoiding the problem, anyone can (and should) look at what = addresses the tracker knows for them by using the "Manage account link" = after logging in. > It's also a good way to check what address you have associated with = your various roles. >=20 > The addresses in the tracker come from several places. >=20 > For most people, the primary source is their datatracker login (and = this is the only address the tracker knows for them). >=20 > For active draft authors, at least in recent years, new addresses are = learned from drafts. > New addresses can also come in via the nomcom process. >=20 > Now, for people who have been around for more than a few years, some = addresses came from legacy systems=20 > (this was most likely the source for the addresses in question for = you). > When those were imported, there was no notion of active or not, and at = the time we had to assume they were active. >=20 > Your particular case of an auth48 bouncing is odd - it should have = been using the addresses for the authors of the draft. > I didn't think the RFC Editor was using the datatracker addresses for = that yet - if so, pleasant surprise. > Would you be willing to forward the bounce to me and let me track down = how the older address got selected? > (If you were in that loop due to a role other than author, let me = know, the answer there could be different). I was the w.g. chair, not an author in this case. I raised the issue = with Heather who suggested it was a datatracker issue. Hence this = email. I will forward you the email separately. I do note, that I don't know how many times this has happened nor in = what context, since I would, of course, not receive the email. =20 >=20 > As for taking action on bounces: Until very recently (February 2014) = the tracker had no visibility into bounces. > Last February, we added a notification to the secretariat when an = address generated an error on submission, > and they work with the affected person to change their account = configuration as necessary. > Auth48 email isn't sent by the tracker, though, so it won't know about = bounces in that workflow. >=20 > Hope this helps, Yes, but as I said in the email, what ever is the problem here, it = probably effects more than me. Having a bunch of email addresses that = don't work marked as active seems like a problem to me. Thanks, Bob >=20 > RjS >>=20 >> Thanks, >> Bob >>=20 >> p.s At least it didn't have all of the addresses listed in RFCs and = IDs I have written over the years :-) >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > --=20 > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss >=20 > Please reports datatracker.ietf.org bugs at = http://tools.ietf.org/tools/ietfdb > Please reports tools.ietf.org bugs at = http://tools.ietf.org/tools/issues or > send email to webmaster@tools.ietf.org --Apple-Mail=_4BF06147-900B-44C7-B234-38F255B87782 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUl1LZAAoJEK7rdBF357uo6AoH/0meUx/yIngAjMsMGH9ff/4A zjjtNluTPLQht0vQR2ezD0V9VL4V5c9dd6OI+Hes0NdmzlHdONfue2SQ9YNuWzQF PWadeBIo2Nwgbxz0+XtRQg0d067FURk43zr9Y8JlyAnXLKoA9wjT2kj03YvyAEgg kVwR3rATsU2mnAUjamci4fks+Wly5Vd7F2HxU9xkkexb8bi5zkAPRZfne7Gy+HDi P0Mqhe1mXDsmPbOBvzDXORiyd5eGkX8fiSbzhyxoSuineWcKm0X4w7ej8V+COu3O 5STUE5nKsH+HD6HpvmOIEp6oOGQm8xLPUHjvjzUhXN8PMfJn4hX4ZnsfikdPkjU= =ZTE7 -----END PGP SIGNATURE----- --Apple-Mail=_4BF06147-900B-44C7-B234-38F255B87782-- From nobody Sun Dec 21 15:18:57 2014 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E081A8837 for ; Sun, 21 Dec 2014 15:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbBbgaUx_LFC for ; Sun, 21 Dec 2014 15:18:54 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 296C01A6F2C for ; Sun, 21 Dec 2014 15:18:54 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBLNIoWk042221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 21 Dec 2014 17:18:51 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54975555.7000307@nostrum.com> Date: Sun, 21 Dec 2014 17:18:45 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Bob Hinden References: <82E25C9F-37B3-4BD1-B864-9B988538635E@gmail.com> <549740D6.5070107@nostrum.com> <7ADCB3C0-A8B6-49AD-9460-CBAC8906359F@gmail.com> In-Reply-To: <7ADCB3C0-A8B6-49AD-9460-CBAC8906359F@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tools-discuss/dCW8uo8XBeoAGWV-6gWYYSoxaAw Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] Datatracker Email addresses X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2014 23:18:56 -0000 On 12/21/14 5:08 PM, Bob Hinden wrote: > Robert, > > On Dec 21, 2014, at 1:51 PM, Robert Sparks wrote: > >> On 12/21/14 2:16 PM, Bob Hinden wrote: >>> Hi, >>> >>> I discovered that the data tracker had four email addresses for me, of which only one was active, and a few had been disabled more than ten years ago. I discovered this because someone forwarded me a bounce for an auth-48 email. Not good since I wasn't seeing email I should have. Since I discovered this, I went into the datatracker manage accounts and disabled the old non-working emails. >>> >>> If it happen to me, it is probably happening to others. I don't understand why all of these old email addresses were all marked active since there must have been countless bounces. >>> >>> Could someone explain how this is supposed to work and what we an do to avoid this problem in the future? >> I'm not sure what you're asking with "how this is supposed to work", but I'll provide some context you might find useful. >> >> As for avoiding the problem, anyone can (and should) look at what addresses the tracker knows for them by using the "Manage account link" after logging in. >> It's also a good way to check what address you have associated with your various roles. >> >> The addresses in the tracker come from several places. >> >> For most people, the primary source is their datatracker login (and this is the only address the tracker knows for them). >> >> For active draft authors, at least in recent years, new addresses are learned from drafts. >> New addresses can also come in via the nomcom process. >> >> Now, for people who have been around for more than a few years, some addresses came from legacy systems >> (this was most likely the source for the addresses in question for you). >> When those were imported, there was no notion of active or not, and at the time we had to assume they were active. >> >> Your particular case of an auth48 bouncing is odd - it should have been using the addresses for the authors of the draft. >> I didn't think the RFC Editor was using the datatracker addresses for that yet - if so, pleasant surprise. >> Would you be willing to forward the bounce to me and let me track down how the older address got selected? >> (If you were in that loop due to a role other than author, let me know, the answer there could be different). > I was the w.g. chair, not an author in this case. I raised the issue with Heather who suggested it was a datatracker issue. Hence this email. I will forward you the email separately. > > I do note, that I don't know how many times this has happened nor in what context, since I would, of course, not receive the email. > >> As for taking action on bounces: Until very recently (February 2014) the tracker had no visibility into bounces. >> Last February, we added a notification to the secretariat when an address generated an error on submission, >> and they work with the affected person to change their account configuration as necessary. >> Auth48 email isn't sent by the tracker, though, so it won't know about bounces in that workflow. >> >> Hope this helps, > Yes, but as I said in the email, what ever is the problem here, it probably effects more than me. Having a bunch of email addresses that don't work marked as active seems like a problem to me. And what would you do about it other than what we put in place last February? (which is identifying those when we try to use them, at least those that produce immediate failures on send). Would a high-visibility reminder to people that the Manage Account page exists and that they should inspect it > > Thanks, > Bob > > >> RjS >>> Thanks, >>> Bob >>> >>> p.s At least it didn't have all of the addresses listed in RFCs and IDs I have written over the years :-) >>> >>> >>> >>> >>> >>> >>> >>> >> -- >> Tools-discuss mailing list >> Tools-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-discuss >> >> Please reports datatracker.ietf.org bugs at http://tools.ietf.org/tools/ietfdb >> Please reports tools.ietf.org bugs at http://tools.ietf.org/tools/issues or >> send email to webmaster@tools.ietf.org From nobody Sun Dec 21 15:29:35 2014 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAEC1A6F2C for ; Sun, 21 Dec 2014 15:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QVzBx7jz49O for ; Sun, 21 Dec 2014 15:29:31 -0800 (PST) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948371A1BEF for ; Sun, 21 Dec 2014 15:29:31 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id v10so4681134pde.12 for ; Sun, 21 Dec 2014 15:29:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Bzttl5+FwO71VoHGegMy3IhEktBDiSIub05ofUhxOj4=; b=T6fg9qsuLWfpMMmKi2OeBDmEAfuzaCMHxfJ0SNX3S8iIo5VaVIZ1P772oNQm5ogpEA qHSawe0e/2XLDjiU871RWtgCiL/8N7XsuaWSel4YX+tc3CFlYxKfTgLorBefxhWARYem 5twMnmJS71S5voAp6zBDTuZAsO0a/pEdDIxKsuCgvlV4QIjwVS+upTxMqa0GvlTHhiMh GMz1VvcX2kt7sWwhac5dZ586VuR1wFrQNXTSzEXOyL5/MF9y9OrqO6Qa7U3uPsBCGE// NQvZiuD5S3F954aukrKIyDFZgIDUyDh/P02qgvRkV4MvnyCdRF2wXKLDGcZG2WNCuKHz IHdw== X-Received: by 10.70.36.111 with SMTP id p15mr30207923pdj.122.1419204570896; Sun, 21 Dec 2014 15:29:30 -0800 (PST) Received: from [10.0.0.38] (c-71-202-19-53.hsd1.ca.comcast.net. [71.202.19.53]) by mx.google.com with ESMTPSA id nt6sm15501242pdb.26.2014.12.21.15.29.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Dec 2014 15:29:29 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_8144731A-0C5F-4CCE-8849-29077A7FA760"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Bob Hinden In-Reply-To: <54975555.7000307@nostrum.com> Date: Sun, 21 Dec 2014 15:29:15 -0800 Message-Id: <6E3383E2-9EAF-4D70-8548-1EBDE430DE4F@gmail.com> References: <82E25C9F-37B3-4BD1-B864-9B988538635E@gmail.com> <549740D6.5070107@nostrum.com> <7ADCB3C0-A8B6-49AD-9460-CBAC8906359F@gmail.com> <54975555.7000307@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/tools-discuss/k3mXcW5YQNqdtSyBEwJqvlB1GmM Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] Datatracker Email addresses X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2014 23:29:33 -0000 --Apple-Mail=_8144731A-0C5F-4CCE-8849-29077A7FA760 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Robert, >>>=20 >>> Hope this helps, >> Yes, but as I said in the email, what ever is the problem here, it = probably effects more than me. Having a bunch of email addresses that = don't work marked as active seems like a problem to me. > And what would you do about it other than what we put in place last = February? (which is identifying those when we try to use them, at least = those that produce immediate failures on send). Apparently what is put in place doesn't work for everything. =20 A first step might be do a run on all of the addresses and see which = bounce. Then either mark them not-active (or something), or if any of = the addresses didn't bounce check with the person at a working address = and ask them to go to manage account and update them. I wasn't aware I = could do this. >=20 > Would a high-visibility reminder to people that the Manage Account = page exists and that they should inspect it As above, this is probably only needed if the person has more than one = address and is getting bounces. Thanks, Bob >>=20 >> Thanks, >> Bob >>=20 >>=20 >>> RjS >>>> Thanks, >>>> Bob >>>>=20 >>>> p.s At least it didn't have all of the addresses listed in RFCs and = IDs I have written over the years :-) >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>> --=20 >>> Tools-discuss mailing list >>> Tools-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/tools-discuss >>>=20 >>> Please reports datatracker.ietf.org bugs at = http://tools.ietf.org/tools/ietfdb >>> Please reports tools.ietf.org bugs at = http://tools.ietf.org/tools/issues or >>> send email to webmaster@tools.ietf.org >=20 --Apple-Mail=_8144731A-0C5F-4CCE-8849-29077A7FA760 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUl1fLAAoJEK7rdBF357uoI7IH/1FJ2enJyfFCS4QRwM09pqAr 1XX31PP6rGhtCCtJmVMgmU/ApnBiEzMFsvrqnD92CqSNlRSc5BJLNM45Guw/Lt7a MfmPqgHEFxsZF84ZbbY2Ida+EJYyCUy/qckw24k9EDEwK2mpke+8Miuve/URXLI0 qPR4LoV0WnNL9lITu+8jHv2SGNAx7RZq9T2tsRNF/zuL7/lWsMdyg3gmHfFpY/D0 zpjnrN8PLY8EZeAoQnkBOd9dXI6Wa1VWXWfeXgD5fSDYmA2pa/TSkCUgSzXC8hMm luRB7kADg/PSkd2bJm2lK9Eoqr7lycOFr6SnLR5e0nR9Hdt1KkZtRrvQua+Ovuo= =GtJO -----END PGP SIGNATURE----- --Apple-Mail=_8144731A-0C5F-4CCE-8849-29077A7FA760-- From nobody Sun Dec 21 15:30:08 2014 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27871A872F for ; Sun, 21 Dec 2014 15:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wKIbiuliNog for ; Sun, 21 Dec 2014 15:30:03 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 EC98E1A1BEF for ; Sun, 21 Dec 2014 15:30:02 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBLNU2IK043039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 21 Dec 2014 17:30:02 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <549757F5.6030209@nostrum.com> Date: Sun, 21 Dec 2014 17:29:57 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: tools-discuss@ietf.org References: <82E25C9F-37B3-4BD1-B864-9B988538635E@gmail.com> <549740D6.5070107@nostrum.com> <7ADCB3C0-A8B6-49AD-9460-CBAC8906359F@gmail.com> <54975555.7000307@nostrum.com> In-Reply-To: <54975555.7000307@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tools-discuss/V5PLYDHPj4KowAYXcekEsUTUGT0 Subject: Re: [Tools-discuss] Datatracker Email addresses X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2014 23:30:06 -0000 That got minorly mangled - fixup inline: On 12/21/14 5:18 PM, Robert Sparks wrote: > > On 12/21/14 5:08 PM, Bob Hinden wrote: >> Robert, >> >> On Dec 21, 2014, at 1:51 PM, Robert Sparks wrote: >> >>> On 12/21/14 2:16 PM, Bob Hinden wrote: >>>> Hi, >>>> >>>> I discovered that the data tracker had four email addresses for me, >>>> of which only one was active, and a few had been disabled more than >>>> ten years ago. I discovered this because someone forwarded me a >>>> bounce for an auth-48 email. Not good since I wasn't seeing email >>>> I should have. Since I discovered this, I went into the >>>> datatracker manage accounts and disabled the old non-working emails. >>>> >>>> If it happen to me, it is probably happening to others. I don't >>>> understand why all of these old email addresses were all marked >>>> active since there must have been countless bounces. >>>> >>>> Could someone explain how this is supposed to work and what we an >>>> do to avoid this problem in the future? >>> I'm not sure what you're asking with "how this is supposed to work", >>> but I'll provide some context you might find useful. >>> >>> As for avoiding the problem, anyone can (and should) look at what >>> addresses the tracker knows for them by using the "Manage account >>> link" after logging in. >>> It's also a good way to check what address you have associated with >>> your various roles. >>> >>> The addresses in the tracker come from several places. >>> >>> For most people, the primary source is their datatracker login (and >>> this is the only address the tracker knows for them). >>> >>> For active draft authors, at least in recent years, new addresses >>> are learned from drafts. >>> New addresses can also come in via the nomcom process. >>> >>> Now, for people who have been around for more than a few years, some >>> addresses came from legacy systems >>> (this was most likely the source for the addresses in question for >>> you). >>> When those were imported, there was no notion of active or not, and >>> at the time we had to assume they were active. >>> >>> Your particular case of an auth48 bouncing is odd - it should have >>> been using the addresses for the authors of the draft. >>> I didn't think the RFC Editor was using the datatracker addresses >>> for that yet - if so, pleasant surprise. >>> Would you be willing to forward the bounce to me and let me track >>> down how the older address got selected? >>> (If you were in that loop due to a role other than author, let me >>> know, the answer there could be different). >> I was the w.g. chair, not an author in this case. I raised the issue >> with Heather who suggested it was a datatracker issue. Hence this >> email. I will forward you the email separately. >> >> I do note, that I don't know how many times this has happened nor in >> what context, since I would, of course, not receive the email. >> >>> As for taking action on bounces: Until very recently (February 2014) >>> the tracker had no visibility into bounces. >>> Last February, we added a notification to the secretariat when an >>> address generated an error on submission, >>> and they work with the affected person to change their account >>> configuration as necessary. >>> Auth48 email isn't sent by the tracker, though, so it won't know >>> about bounces in that workflow. >>> >>> Hope this helps, >> Yes, but as I said in the email, what ever is the problem here, it >> probably effects more than me. Having a bunch of email addresses >> that don't work marked as active seems like a problem to me. > And what would you do about it other than what we put in place last > February? (which is identifying those when we try to use them, at > least those that produce immediate failures on send). > > Would a high-visibility reminder to people that the Manage Account > page exists and that they should inspect it this is missing "help?" at the end. >> >> Thanks, >> Bob >> >> >>> RjS >>>> Thanks, >>>> Bob >>>> >>>> p.s At least it didn't have all of the addresses listed in RFCs and >>>> IDs I have written over the years :-) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> -- >>> Tools-discuss mailing list >>> Tools-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/tools-discuss >>> >>> Please reports datatracker.ietf.org bugs at >>> http://tools.ietf.org/tools/ietfdb >>> Please reports tools.ietf.org bugs at >>> http://tools.ietf.org/tools/issues or >>> send email to webmaster@tools.ietf.org > From nobody Sun Dec 21 15:39:45 2014 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7496E1A702F for ; Sun, 21 Dec 2014 15:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qi2PpWry89lB for ; Sun, 21 Dec 2014 15:39:42 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 721741A1BEF for ; Sun, 21 Dec 2014 15:39:42 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBLNdfwH043870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 21 Dec 2014 17:39:42 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54975A38.9000807@nostrum.com> Date: Sun, 21 Dec 2014 17:39:36 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: tools-discuss@ietf.org References: <82E25C9F-37B3-4BD1-B864-9B988538635E@gmail.com> <549740D6.5070107@nostrum.com> <7ADCB3C0-A8B6-49AD-9460-CBAC8906359F@gmail.com> <54975555.7000307@nostrum.com> <6E3383E2-9EAF-4D70-8548-1EBDE430DE4F@gmail.com> In-Reply-To: <6E3383E2-9EAF-4D70-8548-1EBDE430DE4F@gmail.com> Content-Type: multipart/alternative; boundary="------------010207060809000002040300" Archived-At: http://mailarchive.ietf.org/arch/msg/tools-discuss/bm9tuxNwqiKdjjc2R7RF0kGiFn0 Subject: Re: [Tools-discuss] Datatracker Email addresses X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2014 23:39:44 -0000 This is a multi-part message in MIME format. --------------010207060809000002040300 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 12/21/14 5:29 PM, Bob Hinden wrote: > Robert, > >>>> Hope this helps, >>> Yes, but as I said in the email, what ever is the problem here, it probably effects more than me. Having a bunch of email addresses that don't work marked as active seems like a problem to me. >> And what would you do about it other than what we put in place last February? (which is identifying those when we try to use them, at least those that produce immediate failures on send). > Apparently what is put in place doesn't work for everything. I rather think it is, well enough, but we can look for improvements. In particular, it's not yet clear that the bounced address you're dealing with came (at least recently) from the tracker in the first place. Lets take some time to finish chasing that down. > > A first step might be do a run on all of the addresses and see which bounce. Then either mark them not-active (or something), or if any of the addresses didn't bounce check with the person at a working address and ask them to go to manage account and update them. That means sending mail to everyone, at every alias they have in the system in one big spam-like burst. I don't think the community would appreciate that. And if we were to go down a path like that, it's definitely (or something). Disabling an email address based on one test bounce is known to be too aggressive. > I wasn't aware I could do this. > >> Would a high-visibility reminder to people that the Manage Account page exists and that they should inspect it > As above, this is probably only needed if the person has more than one address and is getting bounces. I think there are some additional things we can do when we see a failure on send, but rather than scatter-shot engineering on this thread, let me go look into it deeper and get back later? > > Thanks, > Bob > > >>> Thanks, >>> Bob >>> >>> >>>> RjS >>>>> Thanks, >>>>> Bob >>>>> >>>>> p.s At least it didn't have all of the addresses listed in RFCs and IDs I have written over the years :-) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> -- >>>> Tools-discuss mailing list >>>> Tools-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tools-discuss >>>> >>>> Please reports datatracker.ietf.org bugs at http://tools.ietf.org/tools/ietfdb >>>> Please reports tools.ietf.org bugs at http://tools.ietf.org/tools/issues or >>>> send email to webmaster@tools.ietf.org > > --------------010207060809000002040300 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 12/21/14 5:29 PM, Bob Hinden wrote:
Robert,


Hope this helps,

Yes, but as I said in the email, what ever is the problem here, it probably effects more than me.  Having a bunch of email addresses that don't work marked as active seems like a problem to me.

And what would you do about it other than what we put in place last February? (which is identifying those when we try to use them, at least those that produce immediate failures on send).

Apparently what is put in place doesn't work for everything.
I rather think it is, well enough, but we can look for improvements.
In particular, it's not yet clear that the bounced address you're dealing with came (at least recently) from the tracker in the first place. Lets take some time to finish chasing that down.


A first step might be do a run on all of the addresses and see which bounce.  Then either mark them not-active (or something), or if any of the addresses didn't bounce check with the person at a working address and ask them to go to manage account and update them.
That means sending mail to everyone, at every alias they have in the system in one big spam-like burst. I don't think the community would appreciate that.
And if we were to go down a path like that, it's definitely (or something). Disabling an email address based on one test bounce is known to be too aggressive.
 I wasn't aware I could do this.


Would a high-visibility reminder to people that the Manage Account page exists and that they should inspect it

As above, this is probably only needed if the person has more than one address and is getting bounces.

I think there are some additional things we can do when we see a failure on send, but rather than scatter-shot engineering on this thread, let me go look into it deeper and get back later?

Thanks,
Bob



Thanks,
Bob



RjS

Thanks,
Bob

p.s At least it didn't have all of the addresses listed in RFCs and IDs I have written over the years :-)









-- 
Tools-discuss mailing list
Tools-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/tools-discuss

Please reports datatracker.ietf.org bugs at http://tools.ietf.org/tools/ietfdb
Please reports tools.ietf.org bugs at http://tools.ietf.org/tools/issues or
send email to webmaster@tools.ietf.org


      

      

      

      

      

    

    

  


--------------010207060809000002040300--


From nobody Sun Dec 21 15:43:01 2014
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7607C1A702F for ; Sun, 21 Dec 2014 15:42:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaTzNpMUr6gS for ; Sun, 21 Dec 2014 15:42:57 -0800 (PST)
Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F3B1A6F2C for ; Sun, 21 Dec 2014 15:42:57 -0800 (PST)
Received: by mail-pa0-f50.google.com with SMTP id bj1so4792428pad.9 for ; Sun, 21 Dec 2014 15:42:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=kIuDNAo1OsIQZumWB1vR5oBd3DMvU5ita7+ttolKb1w=; b=kloQ77gNVgH0Fn+sEHbPhm2r9clbxR9DDCvZQ2FdHA3ZcPVbkfI2zlLPGCDSNnSh+G 3g5zci93VAw7I74M5Wqb/+A3wBJsu/zcMLjQ35ApjHebICoTPWucNOa1x1nn3n8miO+D fKD1rYvkUBXLpHt+/2gtcJreLsnJEJ7jeb7sx0aKxfjDW2RNfDa2/trLFBPF83+wyqC2 Crz/a78onjhiQdUx9QnNllmgFecKCIXJIwY47LmmRfmtqJLZgNg9cwPv6x8UlE4QSDbL WLdPr3URIllZHo3hV9Bd+QAgbbhnnDoH+G7gmA+g9RA1d6Qi+6dpxXaITsBgmaudSyXc zfng==
X-Received: by 10.66.100.136 with SMTP id ey8mr30262843pab.93.1419205376746; Sun, 21 Dec 2014 15:42:56 -0800 (PST)
Received: from [10.0.0.38] (c-71-202-19-53.hsd1.ca.comcast.net. [71.202.19.53]) by mx.google.com with ESMTPSA id df1sm15539245pbb.2.2014.12.21.15.42.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Dec 2014 15:42:55 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_64E5EA3B-AB13-485F-897E-3C9E9CB6C2CC"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Bob Hinden 
In-Reply-To: <54975A38.9000807@nostrum.com>
Date: Sun, 21 Dec 2014 15:42:45 -0800
Message-Id: <9E5DC829-FADD-417C-8799-804509AB5DFB@gmail.com>
References: <82E25C9F-37B3-4BD1-B864-9B988538635E@gmail.com> <549740D6.5070107@nostrum.com> <7ADCB3C0-A8B6-49AD-9460-CBAC8906359F@gmail.com> <54975555.7000307@nostrum.com> <6E3383E2-9EAF-4D70-8548-1EBDE430DE4F@gmail.com> <54975A38.9000807@nostrum.com>
To: Robert Sparks 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/tools-discuss/Q-XSOGYlCqaaQ-3VhvAQDw_pHTg
Cc: tools-discuss@ietf.org
Subject: Re: [Tools-discuss] Datatracker Email addresses
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Dec 2014 23:42:59 -0000

--Apple-Mail=_64E5EA3B-AB13-485F-897E-3C9E9CB6C2CC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Robert,

I agree that sending a zillion emails to folks isn't so good, and it =
would be good to find out what really happened.

But as I said in the first email, having addresses listed as active that =
haven't worked for 10 years isn't ideal either.  Something picked one of =
them up and tried to use it.

Thanks,
Bob

On Dec 21, 2014, at 3:39 PM, Robert Sparks  wrote:

>=20
> On 12/21/14 5:29 PM, Bob Hinden wrote:
>> Robert,
>>=20
>>=20
>>>>> Hope this helps,
>>>>>=20
>>>> Yes, but as I said in the email, what ever is the problem here, it =
probably effects more than me.  Having a bunch of email addresses that =
don't work marked as active seems like a problem to me.
>>>>=20
>>> And what would you do about it other than what we put in place last =
February? (which is identifying those when we try to use them, at least =
those that produce immediate failures on send).
>>>=20
>> Apparently what is put in place doesn't work for everything. =20
> I rather think it is, well enough, but we can look for improvements.
> In particular, it's not yet clear that the bounced address you're =
dealing with came (at least recently) from the tracker in the first =
place. Lets take some time to finish chasing that down.
>=20
>>=20
>> A first step might be do a run on all of the addresses and see which =
bounce.  Then either mark them not-active (or something), or if any of =
the addresses didn't bounce check with the person at a working address =
and ask them to go to manage account and update them.=20
>>=20
> That means sending mail to everyone, at every alias they have in the =
system in one big spam-like burst. I don't think the community would =
appreciate that.
> And if we were to go down a path like that, it's definitely (or =
something). Disabling an email address based on one test bounce is known =
to be too aggressive.
>>  I wasn't aware I could do this.
>>=20
>>=20
>>> Would a high-visibility reminder to people that the Manage Account =
page exists and that they should inspect it
>>>=20
>> As above, this is probably only needed if the person has more than =
one address and is getting bounces.
>=20
> I think there are some additional things we can do when we see a =
failure on send, but rather than scatter-shot engineering on this =
thread, let me go look into it deeper and get back later?
>>=20
>> Thanks,
>> Bob
>>=20
>>=20
>>=20
>>>> Thanks,
>>>> Bob
>>>>=20
>>>>=20
>>>>=20
>>>>> RjS
>>>>>=20
>>>>>> Thanks,
>>>>>> Bob
>>>>>>=20
>>>>>> p.s At least it didn't have all of the addresses listed in RFCs =
and IDs I have written over the years :-)
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>> --=20
>>>>> Tools-discuss mailing list
>>>>>=20
>>>>> Tools-discuss@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/tools-discuss
>>>>>=20
>>>>>=20
>>>>> Please reports datatracker.ietf.org bugs at=20
>>>>> http://tools.ietf.org/tools/ietfdb
>>>>>=20
>>>>> Please reports tools.ietf.org bugs at=20
>>>>> http://tools.ietf.org/tools/issues
>>>>>  or
>>>>> send email to=20
>>>>> webmaster@tools.ietf.org
>>=20
>>=20
>=20
> --=20
> Tools-discuss mailing list
> Tools-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/tools-discuss
>=20
> Please reports datatracker.ietf.org bugs at =
http://tools.ietf.org/tools/ietfdb
> Please reports tools.ietf.org bugs at =
http://tools.ietf.org/tools/issues or
> send email to webmaster@tools.ietf.org


--Apple-Mail=_64E5EA3B-AB13-485F-897E-3C9E9CB6C2CC
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJUl1r1AAoJEK7rdBF357uoflAIAMA57MFiihSAyxBr/gx4NZEw
NNCZKgW4rtjI/B/HWsIdE7/qDHDN9e2/Q6Kb5tGwghEf7Zr91WD6zK295Bb1Dyaw
p39i+EaQfSbuHuqRT7bUgNBPsSqF6qUn1UZm/nsdpJ62Vp3c00yg1BSeNHvDLGn2
4FHG1uxF88XMdhPV+IgPZwWk4uNuhGszglNz+cap7aLSX+/GX4NVBCKH8l0qZvsj
3BgmMU49IiLPe6vloipYFkV0YW0StOg1LFXkNkrQacHPcqDspg+ryZE39IWAD1u5
9Vwx1/qkiAB4AXjDzmRvDV5QE3+t7nF2QjN9NdqYEWRZ0k9csb8yIbvVEsn7XIk=
=icY+
-----END PGP SIGNATURE-----

--Apple-Mail=_64E5EA3B-AB13-485F-897E-3C9E9CB6C2CC--


From nobody Sun Dec 21 15:54:33 2014
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF7A1A710C for ; Sun, 21 Dec 2014 15:54:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.897
X-Spam-Level: 
X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUzC9W0PP5vz for ; Sun, 21 Dec 2014 15:54:29 -0800 (PST)
Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id 633481A6F2C for ; Sun, 21 Dec 2014 15:54:29 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id A66E3D9FA37; Sun, 21 Dec 2014 18:56:26 -0500 (EST)
X-Virus-Scanned: amavisd-new at sobco.com
Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-ZBOS03Zh6V; Sun, 21 Dec 2014 18:56:26 -0500 (EST)
Received: from [10.0.1.16] (173-166-5-69-newengland.hfc.comcastbusiness.net [173.166.5.69]) by sobco.sobco.com (Postfix) with ESMTPSA id 72EE8D9FA2D; Sun, 21 Dec 2014 18:56:26 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: "Scott O. Bradner" 
In-Reply-To: <549740D6.5070107@nostrum.com>
Date: Sun, 21 Dec 2014 18:54:28 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <37EAC472-DEBF-4BDE-A61A-8EF8687F7813@sobco.com>
References: <82E25C9F-37B3-4BD1-B864-9B988538635E@gmail.com> <549740D6.5070107@nostrum.com>
To: Robert Sparks 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/tools-discuss/gaJRn82F5hpmhlomTgr-mJl3VIc
Cc: tools-discuss@ietf.org
Subject: Re: [Tools-discuss] Datatracker Email addresses
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Dec 2014 23:54:30 -0000

> As for avoiding the problem, anyone can (and should) look at what =
addresses the tracker knows for them by using the "Manage account link" =
after logging in.

is there a way to change the base email address?  (the one I login =
with?)

I added a 2nd address but that one does seem to permit me to login with =
it (and the same password I used for the
primary one)

I would think this would be a useful function since people move around =
these days

Scott


From nobody Sun Dec 21 15:56:26 2014
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19D11A6F2C for ; Sun, 21 Dec 2014 15:56:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-qFx_Q8aVd9 for ; Sun, 21 Dec 2014 15:56:22 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C926D1A702F for ; Sun, 21 Dec 2014 15:56:22 -0800 (PST)
Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBLNuMpd045107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 21 Dec 2014 17:56:22 -0600 (CST) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local
Message-ID: <54975E21.1080801@nostrum.com>
Date: Sun, 21 Dec 2014 17:56:17 -0600
From: Robert Sparks 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Scott O. Bradner" 
References: <82E25C9F-37B3-4BD1-B864-9B988538635E@gmail.com> <549740D6.5070107@nostrum.com> <37EAC472-DEBF-4BDE-A61A-8EF8687F7813@sobco.com>
In-Reply-To: <37EAC472-DEBF-4BDE-A61A-8EF8687F7813@sobco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tools-discuss/7ltp5Pn3L_7iAoiWk6Ejf1IrCoM
Cc: tools-discuss@ietf.org
Subject: Re: [Tools-discuss] Datatracker Email addresses
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Dec 2014 23:56:23 -0000

On 12/21/14 5:54 PM, Scott O. Bradner wrote:
>> As for avoiding the problem, anyone can (and should) look at what addresses the tracker knows for them by using the "Manage account link" after logging in.
> is there a way to change the base email address?  (the one I login with?)
At the moment, you would have to ask the secretariat to do that. We can 
look into making it something a user can do on their own.
>
> I added a 2nd address but that one does seem to permit me to login with it (and the same password I used for the
> primary one)
>
> I would think this would be a useful function since people move around these days
>
> Scott
>


From nobody Sun Dec 21 22:55:52 2014
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C545C1A89C6 for ; Sun, 21 Dec 2014 22:55:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqNUuo-hBYdS for ; Sun, 21 Dec 2014 22:55:46 -0800 (PST)
Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id D89081A89BB for ; Sun, 21 Dec 2014 22:55:46 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 81D371E5A3B; Sun, 21 Dec 2014 22:55:03 -0800 (PST)
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 XL0TX27Z3IoM; Sun, 21 Dec 2014 22:55:03 -0800 (PST)
Received: from [10.0.0.3] (c-73-35-192-216.hsd1.wa.comcast.net [73.35.192.216]) by c8a.amsl.com (Postfix) with ESMTPSA id A626A1E5A39; Sun, 21 Dec 2014 22:55:02 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Alice Russo 
Date: Sun, 21 Dec 2014 22:55:46 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <549740D6.5070107@nostrum.com>
To: Robert Sparks 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/tools-discuss/eVsarH3E38-8Pif5gMNOSDXBXHA
Cc: tools-discuss@ietf.org
Subject: [Tools-discuss] Fwd:  Datatracker Email addresses
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Dec 2014 06:55:49 -0000

On Dec 21, 2014, at 1:51 PM, Robert Sparks  wrote:
> Your particular case of an auth48 bouncing is odd - it should have =
been using the addresses for the authors of the draft.
> I didn't think the RFC Editor was using the datatracker addresses for =
that yet - if so, pleasant surprise.
> Would you be willing to forward the bounce to me and let me track down =
how the older address got selected?
> (If you were in that loop due to a role other than author, let me =
know, the answer there could be different).

Robert,

In this case, the address comes from
http://datatracker.ietf.org/doc/draft-ietf-6man-why64/doc.json

specifically:
 "shepherd": "\"Robert M. Hinden\" ",=20

[For background: Upon approval of a draft for publication as an RFC, the =
RFC Editor database is automatically populated with the datatracker's =
data, per the implementation of RFC 6359, Section 4.2.  This is not =
new.]

This issue occurs for regularly for the addresses of document shepherds. =
I reported the issue to you in April, and we discussed it. For a given =
user, you wrote "at the moment that guess is the most recently edited =
active email address" - and I replied that the determination of "most =
recently edited" seems broken.

In the RPC db, we can manually remove the out-of-date addresses that =
have been propagated from the datatracker, if we spot them or are =
notified of them. For the datatracker, we advise:

"As for removing it from the IETF datatracker, we suggest that you sign =
in
(https://datatracker.ietf.org/accounts/) and update your contact =
information,
or contact the IETF Secretariat at iesg-secretary@ietf.org."

Please let us know if we should be advising otherwise.

Thanks,
Alice=


From nobody Mon Dec 22 07:14:38 2014
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED711A19F8 for ; Mon, 22 Dec 2014 07:14:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DG07Jb-6F9h9 for ; Mon, 22 Dec 2014 07:14:33 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5EEDD1A8F4D for ; Mon, 22 Dec 2014 07:14:33 -0800 (PST)
Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBMFELwc025103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Dec 2014 09:14:22 -0600 (CST) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local
Message-ID: <54983548.2090709@nostrum.com>
Date: Mon, 22 Dec 2014 09:14:16 -0600
From: Robert Sparks 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Alice Russo 
References: <549740D6.5070107@nostrum.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tools-discuss/9R3Dgch95GPhdULyqCeGab15ztw
Cc: tools-discuss@ietf.org
Subject: Re: [Tools-discuss] Fwd:  Datatracker Email addresses
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Dec 2014 15:14:36 -0000

Thanks Alice!

On 12/22/14 12:55 AM, Alice Russo wrote:
> On Dec 21, 2014, at 1:51 PM, Robert Sparks  wrote:
>> Your particular case of an auth48 bouncing is odd - it should have been using the addresses for the authors of the draft.
>> I didn't think the RFC Editor was using the datatracker addresses for that yet - if so, pleasant surprise.
>> Would you be willing to forward the bounce to me and let me track down how the older address got selected?
>> (If you were in that loop due to a role other than author, let me know, the answer there could be different).
> Robert,
>
> In this case, the address comes from
> http://datatracker.ietf.org/doc/draft-ietf-6man-why64/doc.json
>
> specifically:
>   "shepherd": "\"Robert M. Hinden\" ",
>
> [For background: Upon approval of a draft for publication as an RFC, the RFC Editor database is automatically populated with the datatracker's data, per the implementation of RFC 6359, Section 4.2.  This is not new.]
Right- and if the shepherd's address changes in the tracker after that 
point, will you pick that up?
>
> This issue occurs for regularly for the addresses of document shepherds. I reported the issue to you in April, and we discussed it. For a given user, you wrote "at the moment that guess is the most recently edited active email address" - and I replied that the determination of "most recently edited" seems broken.
Yes, we've made incremental improvements to how this field gets set 
since April, but we're still in the window of dealing with documents 
whose shepherd got set before then.

>
> In the RPC db, we can manually remove the out-of-date addresses that have been propagated from the datatracker, if we spot them or are notified of them. For the datatracker, we advise:
>
> "As for removing it from the IETF datatracker, we suggest that you sign in
> (https://datatracker.ietf.org/accounts/) and update your contact information,
> or contact the IETF Secretariat at iesg-secretary@ietf.org."
>
> Please let us know if we should be advising otherwise.
That is the the right thing to be doing.

RjS
>
> Thanks,
> Alice


From nobody Mon Dec 22 15:36:15 2014
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCA11A6FFC for ; Mon, 22 Dec 2014 15:36:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAegfxnL6qfR for ; Mon, 22 Dec 2014 15:36:13 -0800 (PST)
Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 988F41A6FF1 for ; Mon, 22 Dec 2014 15:36:13 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 7AE591E5A2E; Mon, 22 Dec 2014 15:35:27 -0800 (PST)
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 HCfkagWb66L2; Mon, 22 Dec 2014 15:35:27 -0800 (PST)
Received: from [10.0.0.3] (c-73-35-192-216.hsd1.wa.comcast.net [73.35.192.216]) by c8a.amsl.com (Postfix) with ESMTPSA id 4CB5A1E59C4; Mon, 22 Dec 2014 15:35:27 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Alice Russo 
In-Reply-To: <54983548.2090709@nostrum.com>
Date: Mon, 22 Dec 2014 15:36:12 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <549740D6.5070107@nostrum.com>  <54983548.2090709@nostrum.com>
To: Robert Sparks 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/tools-discuss/7zSuB-icnI8-ErBKqbN4jp8jZ-E
Cc: tools-discuss@ietf.org
Subject: Re: [Tools-discuss] Datatracker Email addresses
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Dec 2014 23:36:14 -0000

On Dec 22, 2014, at 7:14 AM, Robert Sparks  wrote:
> Right- and if the shepherd's address changes in the tracker after that =
point, will you pick that up?

No. Currently, it's a one-time pickup upon approval of the document.

Thanks,
Alice=