< That would also allow you to subscribe someone else to a list without his
< consent.
 
Good point.  So change the command so that the following sequence is
necessary to accomplish the task:
 
USER A:    Issues the NEWADDR command to change his AFDs, FUIs, subscriptions
to USER B.  The LISTSERV to which this command is sent does not act on it,
but stores it away in a table that it keeps around for, say, two weeks.
 
USER B: Issues some command, maybe some variant of NEWADDR, to the same
LISTSERV as USER A did above to signal acceptance of USER B's subscriptions.
The LISTSERV to which all commands have been sent now acts on the request.
 
Are there still problems with this approach?
 
Thanks,
Will