I used to think this was necessary, but after some expereince as list owner
I am not so sure.  It DOES make a difference to the busy list owner when an
ISP changes their mail routing.  But, hopefully, this does not happen
often.
 
A couple of years ago my address was @home.interaccess.com For various
reasons, my ISP needed to expand their capacity and over the course of a
week my address changed 3 times ([log in to unmask],
@cluster.interaccess.com, etc)  while they got all the headaches sorted
out.  Fortunately they finally settled on simply @interaccess.com and they
handle anything else needed locally, which seems to me the way it should
be.
 
The real problem comes as the ISP's fail to properly inform their users of
the changes. I didn't discover the problem until I tried posting to a
LISTSERV(tm) list and got back a 'you are not subscribed' rejection msg.
Needless to say I got a bit disturbed and went round & round with the ISP
before I figured out what happened.
 
So the ability to handle this shortened/changed form of address might be
good, but as I think about it, LISTSERV(tm) should (in the converse of the
new 'probe' test) issue an 'Address has apparently changed' warning msg
both to the user and the list-owner, so we'll have to deal with it anyway.
It doesn't seem smart not to call attention to such changes and even if
posting is allowed to pass through, the SET and SIGNOFF and other more
serious account controls still need to be 'frozen' until the identity can
be verified.
 
Most people know that if they move to a new address, they have to give a
Change of Address notice to the Post Office.  What is happening here
however is the poepl haven't moved, but the Post Office decides to rename
their street, without telling them.  It's clear whose fault it is, we just
don't have a good way of making them do the dirty work.
 
The one tool that might help the list owner would be a new command of
"CHANGE olduserID TO newuserID" rather than the current DEL/ADD double
command, especially if this kept the users special settings for digest,
etc., which are otherwise lost in the ADD/DEL cycle.
 
 ________________________________________________________________________
 Ben Parker ............ (Oak Park IL) .......... [log in to unmask]
  Owner DPRV-L