Re: [anti-spam-wg@localhost] Contacts

["Dr. Jeffrey Race" <]

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.