> Why not change the **web form** to have a separate field for
> name and a separate field for email address?  Problem solved.

You could do that of course. It would indeed solve the problem for novice users, at the cost of creating more work for experienced users.

Personally, I like to cut+paste names and e-mail addresses, because the risk of making a mistake is too high when retyping. With the current approach, I can do that easily. Typically, someone wrote to me asking to be added to the list. With that message open, which is when I decide to add the person to the list, I can click on the "From:" address (not just in Outlook, most mail client allow you to do that), copy, and paste directly into the web interface. Outlook supplies a string with the format:

Joe Smith <[log in to unmask]>

With separate fields for name and e-mail address, I would have to paste twice and, each time, remove the part that is not relevant, hopefully without making a mistake. This takes more time and is more error-prone. A conference secretary who has to process hundreds of such requests a day will certainly appreciate not having to do that.

> In the case of emailed commands, send an email back to the
> submitter asking him or her to clarify what was meant, and
> give hints about proper syntax.

With the RFC822 syntax currently used by LISTSERV, there are only two possible outcomes:

1. The syntax is invalid, and indeed the user is asked to clarify what was meant, if perhaps not in these exact terms.

2. The syntax is valid and results in syntactically correct e-mail address and name.

What you are suggesting is the addition of heuristics at step 2 to try and guess if the address extracted from the command might not be what a statistical, average user would have wanted. In that case, nothing is added and the user is asked to use "proper syntax," but the user did use proper syntax. It's just that the heuristics felt there was a chance that perhaps this was not what the user really wanted. Since commands such as ADD are very often used by scripts (in fact, I would bet that the majority of ADD commands executed on a given day come from a script), the "user" is really in no position to clarify what was meant.

> Extend the TCPGUI interface to accept clearer and deterministic
> delineation of user and name, e.g.
>  ***name*** Henry Brown ***email*** [log in to unmask]

What's not clear or deterministic enough with:

ADD [log in to unmask] Joe Smith

If you put the e-mail address first, everything else is treated as a name.

  Eric