> Already one of the two dozen people who have subscribed to our new list in
> the past week has complained loudly about a very similar situation.  In his
> case, he definitely got subscribed and received the list's welcome message,
> the one I wrote that is more clear than the LISTSERV default.  Then two
> days later he got this message:
>
>      Your command:
>
>      SUBSCRIBE LISTNAME-L John Doe (with the real names)
>
>      has remained unconfirmed  for more than 48h and is  being cancelled. If you
>      did want it executed but were unable to send the confirmation in time, just
>      re-issue the command to get a new  confirmation code. The one you were sent
>      before can no longer be used.
>
> So he couldn't understand if he was really subscribed already or not.  I assured
> him that he was still subscribed.  Still, we'd both like to avoid seeing these
> confusing messages in the future.

One cause of this that we've seen here is a mail client (Microsoft Exchange in
our case) that simply indents the original text when replying, without prefixing
it with >.  The user replies to the confirmation message with an OK, but sends
the original text along.  Since the text of the confirmation message contains
the original command, it gets executed by LISTSERV a second time and the user
gets a second confirmation request.  Generally they ignore the second request,
so it times out.  I've made two suggestions to L-Soft for dealing with this:

(1)  In the confirmation message, put a > in front of the original command.
This will cause LISTSERV to ignore the command if it is sent back.

(2)  Change the text of the confirmation message to tell the user to delete
the original text of the message when replying.

I don't think that Eric agreed with either suggestion, so if you do, it
might be helpful to make your opinion known to L-Soft.