Re: [anti-spam-wg@localhost] Contacts
- Date: Wed, 29 Jan 2003 15:44:34 +0700
- Priority: Normal
On 19 Jan 2003 21:54:37 +0000, Nick Foobar wrote:
>Jeffrey, your document states many things which many people would like
>to see. However, your proposed role for registrars is completely
>unworkable in practice:
[snip]
>As for dealing with the complexity of the problem, take the difficulty
>of dealing with an individual situation like this, multiply the
>situation across 10E{3,4,5}'s of records for each company, multiply by a
>suitable factor to take into account the difficulty of maintaining
>multiple contact databases per company (it happens and it's not going to
>change), and then multiply by the number of LIR's. It is a practically
>impossible task.
This just in! See the appended "probe" message which purports to
automate this process so little manual intervention is required.
Submitted for my friends on the list to comment on its potential
applicability to the issue of maintaining a clean database
Jeffrey Race
------------------------------------------------------------------------
Received: from grape.ease.lsoft.com ([209.119.1.39])
by prserv.net (in1) with ESMTP
id <2003012511014810106br488e>; Sat, 25 Jan 2003 11:01:48 +0000
Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com
(LSMTP for OpenVMS v1.1b) with SMTP id <2.0033C55B@localhost;
Sat, 25 Jan 2003 6:01:43 -0500
Date: Sat, 25 Jan 2003 06:00:31 -0500
From: "L-Soft list server at PEACH.EASE.LSOFT.COM (1.8e)"
LISTSERV@localhost
Subject: Subscription probe for SPAM-L - please ignore
To: Jeffrey Race jrace@localhost
X-LSV-ListID: SPAM-L
Sat, 25 Jan 2003 06:00:31
This message is a "probe" for your subscription to the SPAM-L list. You
do not need to take any action to remain subscribed to the list, and in
particular you should not reply to this message. Simply discard it now,
or read on if you would like to know more about how this probing
mechanism works.
A "probe" is a message like the one you are reading, sent to an
individual subscriber and tagged with a special signature to uniquely
identify this particular subscriber (you can probably not see the
signature because it is in the mail headers). If the subscriber's e-mail
address is no longer valid, the message will be returned to LISTSERV and
the faulty address will be removed from the list. If the subscriber's
address is still valid, the message will not bounce and the user will not
be deleted.
The main advantage of this technique is that it can be fully automated;
the list owner does not need to read a single delivery error. For a large
or active list, the manpower savings can be tremendous. In fact, some
lists are so large that it is virtually impossible to process delivery
errors manually. Another advantage is that the special, unique signatures
make it possible to accurately process delivery errors that are otherwise
unintelligible, even to an experienced technical person.
The drawback, however, is that this method lacks flexibility and
forgiveness. Since the Internet does not provide a reliable mechanism for
probing an e-mail address without actually delivering a message to the
human recipient, the subscribers need to be inconvenienced with yet
another "junk message." And, unlike a human list owner, LISTSERV follows
a number of simple rules in determining when and whether to terminate a
subscription. In particular, a common problem with automatic probes is
mail gateways that return a delivery error, but do deliver the message
anyway. LISTSERV has no way to know that the message was in fact
delivered, and in most cases the subscriber is not aware of the existence
of these "false" error reports. If this happens to you, LISTSERV will
send you another message with a copy of the delivery error returned by
your mail system, so that you can show it to your technical people.
