On 11/11/2004 3:04 PM, Eric Thomas wrote:

>>LISTSERV interprets this information in the following manner:
>>
>>       Name: Brown [log in to unmask]
>>       Address: Henry
>
> You are right, LISTSERV is in error. In terms of user expectations, Outlook
 > sets the standard, and it interprets this information as follows:
>
> Name: none
> Address: "henry brown henry"@somehwere.com
>
> One could make a case for changing LISTSERV to comply with Outlook, but I
 > would only consider this case if the Outlook interpretation resulted in a
 > valid e-mail address, which is not the case.
>
>   Eric

I acknowledge that [log in to unmask] is not a valid email address,
as defined by the relevant standards, however, we are not discussing
inter-system SMTP sessions, we are discussing interactive sessions
involving human users and a web interface. In that context, the web
interface needs to be internally consistent in its handling of user
input. At preent, it is not internally consistent.

I do not consider Outlook to be the standard by which all other products
should be judged. The only reason I have Outlook installed on my workstation
is because it is one of several email clients which are supported by our
Help Desk, and I occasionally need to test its interaction with our mail
servers.

I have tested a number of email clients on several platforms and I am not
aware of any which *REQUIRE* the user to explicitly include <> delimiters
when entering email addresses. Those delimiters are required for message
tranmission to a mail server, however, virtually all email clients add the
delimiters, if they were not specified by the user.

In another message in this thread, Margaret King <[log in to unmask]> suggested
option (c), which I must admit is superior to either of the options that I
suggested. Her proposal: LISTSERV should parse the input as it does now, but
issue an error message if the subscriber's name contains [log in to unmask] I would modify
that option by suggesting that an error should also be issued if the email
address consists of an unqualified username. These two additional tests would
eliminate most, if not all, of the current problems.

--
Paul Russell
Senior Systems Administrator
OIT Messaging Services Team
University of Notre Dame