On 11/12/2004 3:45 AM, Eric Thomas wrote: > > 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. > Right! There is nothing wrong with the 'add' command. My comments apply only to the web interface, which allows the user to enter either address name or name <address> however, if the user chooses the second form, the <> delimiters are required by LISTSERV. If they are not present, LISTSERV treats the first word as the email address, even when the most casual observer can see that the last word is the email address. In another message in this thread, you explained that name <address> is supported because it makes it easy to cut-and-paste the subscriber's name and email address from the 'From:' line of an email message. I understand the rationale for *ALLOWING* the use of <> delimiters, and I am not suggesting that the use of delimiters should be prohibitted. I am suggesting that delimiters should be optional. The problem of parsing the input is not that complex. The following logic model should "do the right thing" with any input string that includes a syntactically-valid email address, with or without <> delimiters, as either the first or last blank-delimited word. 1. Does the input string contain one and only one instance of '@'? If no, issue an error message and stop processing. 2. Does the '@' appear in either the first or last blank-delimited word? If no, issue an error message and stop processing. If yes, put the word containing the '@' to the email address field and the rest of the input string in the name field. 3. Does the email address begin or end with '@'? If yes, issue an error message and stop processing. 4. Does the email address begin or end with a dot? If yes, issue an error message and stop processing. 5. Does the RHS of the email address consist of at least two dot-delimited words? If no, issue an error message and stop processing. 6. Does the email address contain illegal characters? If yes, issue an error message and stop processing. I think this model supports everything supported by the current logic, while eliminating the requirement for <> delimiters when the email address follows the name in the input string. Examples of valid input: [log in to unmask] <[log in to unmask]> [log in to unmask] Paul Russell <[log in to unmask]> Paul Russell Paul Russell [log in to unmask] Paul Russell <[log in to unmask]> Examples of invalid input: prussell@@nd.edu Paul Russell [log in to unmask] [log in to unmask] prussell Paul Russell prussell@nd Paul Russell Paul Russell prussell@ [log in to unmask] edu Paul Russell prussell@nd .edu Paul Russell prussell @nd.edu Paul Russell -- Paul Russell Senior Systems Administrator OIT Messaging Services Team University of Notre Dame