Subject: | |
From: | |
Reply To: | |
Date: | Sat, 24 Feb 2007 13:45:24 -0700 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
On Sat, 24 Feb 2007 14:59:59 -0500, John Cunniff <[log in to unmask]> wrote:
>[log in to unmask]
>[log in to unmask]
...
>I think it is the bug in LISTSERV ...
No, it's not a bug, it's a 'feature'. The primary internet standard for
email, RFC821, requires that the case of the UserID part of the email address
(the part left of @) must be respected, while the case of the domain part of
the email address (the part right of @) must be ignored. Thus, according to
RFC821 (and it's replacement RFC2821) the 2 addresses above must be treated as
2 different users. LISTSERV obeys RFC821 (and other applicable email
standards) so, LISTSERV also will treat these 2 addresses as 2 different
users. No mail system I know of actually implements this feature, but the
standard remains unchanged since adopted in 1982 and has, in the past, lead
other List Owners/Site Admins to exactly the confusion you have experienced.
Fortunately, a configuration feature was added to LISTSERV 14.1 and later that
disables this case-checking and allows the addresses such as the above to be
treated as one and the same user.
At the site-wide level Site Administrators can set
IGNORE_EMAIL_CASE=1
in site.cfg (unix users must remember the 'export' this variable in go.user)
then stop/restart LISTSERV. This will set this for all lists on the server.
(I set this value for all servers that I administer, precisely to avoid this
problem.)
List Owners can also set this at the List level for their own list(s), even if
the Site Admin has not set it for the whole server. In the List Header, put
Misc-Options= IGNORE_EMAIL_CASE
Note that adding this setting will not suddenly cause LISTSERV to sort through
all of its lists to find the now-duplicate addresses. You will need to do
that manually, with appropriate DEL/ADD commands to cleanup any now-duplicates
that you find. This setting will only prevent such duplicates from being
added in the future.
|
|
|