Subject: [Tools-discuss] Datatracker Email addresses

From: Bob Hinden <[email-masked]>
Date: Sun, 21 Dec 2014 12:16:49 -0800

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?

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 :-)

---

From: Robert Sparks <[email-masked]>
Date: Sun, 21 Dec 2014 15:51:18 -0600

> 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

---

From: Bob Hinden <[email-masked]>
Date: Sun, 21 Dec 2014 15:08:09 -0800

Robert,

On Dec 21, 2014, at 1:51 PM, Robert Sparks <[email-masked]> wrote:

> 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.
> 
> 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.
> Now, for people who have been around for more than a few years, some addresses came from legacy systems 
> 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.

Thanks,
Bob

> -- 
> Tools-discuss mailing list
> [email-masked]
> 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 [email-masked]

---

From: Robert Sparks <[email-masked]>
Date: Sun, 21 Dec 2014 17:18:45 -0600

> 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

---

From: Bob Hinden <[email-masked]>
Date: Sun, 21 Dec 2014 15:29:15 -0800

Robert,

> 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.  

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.

> 
> 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

---

From: Robert Sparks <[email-masked]>
Date: Sun, 21 Dec 2014 17:29:57 -0600

That got minorly mangled - fixup inline:

On 12/21/14 5:18 PM, Robert Sparks wrote:
>>>> 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.
>>>>
>>> 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.
>>>
>>> addresses the tracker knows for them by using the "Manage account 
>>> link" after logging in.
>>> For most people, the primary source is their datatracker login (and 
>>> this is the only address the tracker knows for them).
>>>
>>> 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.
>>> (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.
>> 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.
> 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.

---

From: Robert Sparks <[email-masked]>
Date: Sun, 21 Dec 2014 17:39:36 -0600

> 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.
>

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?

---

From: Bob Hinden <[email-masked]>
Date: Sun, 21 Dec 2014 15:42:45 -0800

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 <[email-masked]> wrote:

> 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.
> 
>> 
> 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 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
>>>>>> 
>>>>> Please reports tools.ietf.org bugs at 
>>>>> http://tools.ietf.org/tools/issues
>>>>>  or
>>>>> send email to 
>>>>> [email-masked]
>> 
>> 
> 
> --

---

From: "Scott O. Bradner" <[email-masked]>
Date: Sun, 21 Dec 2014 18:54:28 -0500

> 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: Robert Sparks <[email-masked]>
Date: Sun, 21 Dec 2014 17:56:17 -0600

> 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.

---

From: Alice Russo <[email-masked]>
Date: Sun, 21 Dec 2014 22:55:46 -0800

Robert,

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

specifically:
 "shepherd": "\"Robert M. Hinden\" <[email-masked]>", 

[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 [email-masked]."

Please let us know if we should be advising otherwise.

Thanks,
Alice

---

From: Robert Sparks <[email-masked]>
Date: Mon, 22 Dec 2014 09:14:16 -0600

Thanks Alice!

> [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.…
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…
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.

> Please let us know if we should be advising otherwise.
That is the the right thing to be doing.

RjS

---

From: Alice Russo <[email-masked]>
Date: Mon, 22 Dec 2014 15:36:12 -0800

On Dec 22, 2014, at 7:14 AM, Robert Sparks <[email-masked]> 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