|
Sender: |
|
Subject: |
|
From: |
|
Date: |
Mon, 15 Mar 1993 03:12:54 +0100 |
Reply-To: |
|
Release 1.7f will introduce a command confirmation system (to be fully
exploited in the following release), with the first application being a
return address verification system for public lists with large numbers of
subscribers from unreliable networks. This feature is enabled by coding
"Subscription= Open,Confirm". When the user sends a subscription request,
he is mailed a confirmation request message:
-------------------------------------------------------------------------
Date: Mon, 15 Mar 1993 01:59:31 +0100
From: BITNET list server at SEARN (1.7f) <[log in to unmask]>
Subject: Command confirmation request (1A5FE8)
To: Eric Thomas <[log in to unmask]>
X-LSV-ListID: L202
Your command:
SUBSCRIBE L202 Eric Thomas
must undergo a return address verification procedure whose purpose is to
prevent addresses that cannot be replied to or are otherwise unreliable from
being added to the list. This is a typical procedure for high-volume lists.
All new subscribers are subjected to it, except those on LISTSERV's own
system which can be checked directly. We have tried to make this
confirmation as simple and painless as possible, and apologize for the
inconvenience.
With most mail programs, simply replying to this message and typing "ok"
(without the quotes) as the message text will confirm the command. If that
does not work, send an "ok 1A5FE8" command using the same procedure with
which you sent the command you are now asked to confirm. In other words, it
will always works if you retype the confirmation code, but with most mail
programs you only need to type "ok". Finally, the command will be
automatically cancelled if you do not confirm it within 48h. There is no
need to cancel it manually if you change your mind - it does not waste much
resources on the server to leave it unconfirmed until it expires on its own.
-------------------------------------------------------------------------
If this message bounces, it gets to the list owner for information but
the subscriber is NOT added. Thus, only this one message will have
generating delivery errors. If the user confirms, you know that there is
a working path from LISTSERV to him. The confirmation delay can be set
with "Confirm-Delay= nnn" (in hours). The default, for now, is 48h. A
longer delay may be necessary for UUCP users, but on the other hand you
may want not to let in users whose mail system isn't reasonably
responsive (there is no penalty for not confirming; if you were away for
a few days, you can just try again when you come back).
Eric
|
|
|