The non-privileged form of the CHANGE command is issued from the old address and specifies the new address as a command parameter. Confirmation is then required from both addresses, otherwise someone could hijack your subscription. Confirmation from the old address may, however, be provided using other forms of authentication than the OK mechanism – for instance, web login. If LISTSERV is satisfied that the command is authentic, it will only require confirmation from the new address.

 

The confirmation request sent to the old address, if any, is your garden-variety OK request and there has never been a problem with that first step.

 

As originally implemented, the confirmation request sent to the new address was special but… I am not sure how to explain that without getting into complex implementation details. Let’s say that it was special, but not special enough. It was vital for the OK confirmation response to be received from the new address, or it would not be recognized as the second-step confirmation, and a new second-step confirmation request would be sent. This process could repeat endlessly if the confirmation response kept coming from an address other than the new address.

 

Independently of the above, the web interface is most often used with login cookies that, depending on the user’s specific circumstances, might refer to either the old or new address. If still set to the old address, the web interface would send the confirmation response from the “wrong” address. Hence the frequent suggestion to confirm CHANGE commands by e-mail only.

 

A change was made in 16.0, but after the original release date, to make the second confirmation request… More special. It no longer matters what address the confirmation is received from. I believe that this is the APAR that introduced this improvement:

 

155-0069 10/03/08 [I] Make CHANGE process more reliable

 

So if you have the original 16.0 build, rather than the level set that was released later on, the first thing to do is to install the level set.

 

The APPLE server does have the level set, but to troubleshoot this I would need the exact circumstances. The logs on these servers are massive and I need to know what to look for exactly.

 

  Eric

 



To unsubscribe from the LSTOWN-L list, click the following link:
http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=LSTOWN-L&A=1