The problem is not LISTSERV's strict compliance with the RFCs.

The real problem is that the **human interface** allows for
too many variations.

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

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.

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

Thanks,
Glenn

> Date:    Fri, 12 Nov 2004 01:02:37 +0100
> From:    Eric Thomas <[log in to unmask]>
> Subject: Re: Inconsistency in allowed format on 'add' via web & 'add' via email
>
> > I acknowledge that [log in to unmask] is not a valid email address,
>
> It IS a valid e-mail address. Unless you mean that this particular =
> mailbox doesn't exist.
>
> > the web
> > interface needs to be internally consistent in its handling of user
> > input. At preent, it is not internally consistent.
>
> I don't see why, perhaps because I'm not sure what you mean by =
> "internally consistent."
>
> > 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.
>
> Nobody said anything about e-mail addresses. LISTSERV doesn't require =
> you to use angle brackets in e-mail addresses. I myself publish my =
> e-mail address without angle brackets, because it is a valid syntax and =
> I can't think of any reasons to type angle brackets for no reasons. In =
> fact, to be a purist, if you read RFC822 carefully you will find that it =
> does NOT permit:
>
> To: <[log in to unmask]>
>
> But this is not what we are talking about here, we are talking about a =
> combination of name and e-mail address, where the name can be just about =
> anything and contain just about any characters.
>
> Now there are two ways to parse this, the deterministic way and the =
> heuristic way. The deterministic way, which LISTSERV chose, is to note =
> that the Internet community adopted a standard for mail headers 22 years =
> ago, and that by now this standard is very solidly entrenched. You then =
> implement RFC822, with all the pros and cons that come with it. Granted, =
> *I* would not have done things like RFC822, but for better or for worse, =
> this is the worldwide standard. It does have the advantage of being a =
> deterministic standard. If you give me an e-mail address and a name, I =
> can turn them into an RFC822 address line that LISTSERV will process =
> correctly. If you give me 100,000 e-mail addresses and names from a =
> database and need them imported in a LISTSERV list, you will end up with =
> 100,000 subscriptions.
>
> The heuristic approach is to do as you suggest and try to make best =
> guesses about what the user really meant. If there is something in the =
> name that looks like an e-mail address, then clearly this must be the =
> e-mail address, and whatever is left is the name.
>
> Example 1: Henry Brown [log in to unmask]
>
> The e-mail address is [log in to unmask]
>
> Example 2: Henry Brown [log in to unmask]
>
> The e-mail address is [log in to unmask]
>
> Example 3: Henry Brown henry. [log in to unmask]
>
> The e-mail address is brown@somewhere.com... Oops, now let's see, we =
> need another rule here. If there is a period at the end of what remains =
> before the part that looks like an address, this is also included in the =
> address.
>
> Example 4: henry . [log in to unmask]
>
> The e-mail address is [log in to unmask] Well, we could add another =
> rule saying that, if the address starts with a period, clearly whatever =
> was before needs to be prepended to it.
>
> Example 5: Jane Smith, Ph.D. [log in to unmask]
>
> The e-mail address is [log in to unmask] No big deal, we can =
> just add another rule to recognize Ph.D., and PhD., and MD, and M.D., =
> and JD, and... Keep'em coming, there are hundreds of professional =
> abbreviations that have been translated to hundreds of languages each.
>
> We can keep adding more rules until we think we get it right 99% of the =
> time (although that's optimistic). And when importing 100,000 addresses, =
> we will lose 1,000 subscribers in passing. Or maybe 10,000 in a less =
> optimistic case.
>
> I can see your point though, but only where the web interface is =
> concerned. The correct solution is to introduce an inconsistency between =
> the web interface and the e-mail command. The command remains unchanged, =
> but the web interface can do some sanity checks and request confirmation =
> when in doubt. The command can't really do that, well it could, but it =
> isn't really appropriate. There might be a SET command after the ADD =
> command and that will fail because the ADD command was not sure and =
> requested some kind of OK confirmation (or a thousand). Commands need to =
> be deterministic. When you code 'rm *.lsit' in a script, you expect it =
> to delete all the files with an extension of lsit. You wouldn't want the =
> system to delete all your lists instead just because statistics have =
> shown that when users type 'lsit', 99.8% of the time they were really =
> trying to type 'list'. In a script this kind of nonsense would have no =
> place. But in an interactive interface, you could have a helpful =
> animated "assistant" pulling a light bulb out of its back pocket and =
> asking if maybe perhaps you didn't mean to wipe out all your hard drive, =
> "click OK if you want me to do this for you now."
>
> I have added this suggestion to the to do list, but we are supposed to =
> have a feature freeze now.
>
>   Eric