Subject: [Tools-discuss] Updates to [email-masked] aliases stalled?

From: Pekka Savola <[email-masked]>
Date: Wed, 16 Dec 2009 10:53:42 +0200 (EET)

Hello,

Are [email-masked] aliases supposed to be updated when a 
document is updated?  If yes, there appears to be some problem here 
(I've experienced this a couple of times).

For example, when sending mail to 
[email-masked], I get an autoresponder from 
[email-masked].  That was the contact in -05 of the 
document published on June 3, 2009.  In -06 it was "esiegel@????.com". 
In -07 through -09 it has been "[email-masked]".

It appears the updates have stalled for some reason. (Hopefully the 
????.com didn't mess this up?).  Not sure if this is a generic problem 
or specific to some document(s).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 17 Dec 2009 14:03:39 +0100

Hi Pekka,

On 2009-12-16 09:53 Pekka Savola said the following:
> document is updated?

Yes, with some reservations with respect to discarding old addresses,
see further down.

> If yes, there appears to be some problem here 

The alias file has the following entry for this draft.  As you see, the
defunct address is part of the alias, but all the current authors are
also there:

  draft-ietf-dkim-deployment: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

(There has been a lot of inconsistency in the sources for the the author
email addresses over time, and simply replacing old addresses with the
most recent listed in for instance the database has repeatedly resulted
in no addresses at all.  For this reason the code which is maintaining
the alias list is quite reluctant to abandon old known addresses...)

> or specific to some document(s).  

As far as I can see this is not a generic problem -- the alias lists were
most recently updated 30 minutes ago, as I write.  If you have examples
where some authors are *not* getting the emails they should be getting
(as opposed to the case above where the emails also go to an old defunct
address) I'd be very interested in getting the specifics.

Best,

	Henrik

---

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Dec 2009 15:08:35 +0200 (EET)

> address) I'd be very interested in getting the specifics.

Ok, I understand this better now.  From the user's perspective this is 
inoptimal, as you get bounces from malfunctioning addresses, and if 
you don't know the implementation specifics, you can't know if the 
author really got the message or not.

But I suppose the problem is not reliably fixable.  Maybe old 
addresses could be removed after X iterations or Y months, but not 
sure if that would be easy to implement or much better.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Dec 2009 14:19:59 +0100

Pekka Savola wrote:
> inoptimal, as you get bounces from malfunctioning addresses, and if you 
> don't know the implementation specifics, you can't know if the author 
> really got the message or not.
> 
> But I suppose the problem is not reliably fixable.  Maybe old addresses 
> could be removed after X iterations or Y months, but not sure if that 
> would be easy to implement or much better.

For IDs which are submitted with XML source, extracting the email 
addresses could be made reliable, so there'd be no point in trying to 
get them from the TXT version, and keeping old ones...

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 17 Dec 2009 14:57:04 +0100

Hi Pekka,

> sure if that would be easy to implement or much better.

I've revisited the code which merges old and new addresses, and managed
to make some fixes which should result in better address lists, even given
the preference for hanging on to old addresses if new are missing.  When
testing this on the particular example you had, the address list is much
improved, and this should be reflected in the alias list the next time it
is regenerated.

Best,

	Henrik