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