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