As per Relevance of the word distribution, we have this rfc below:
Network Working Group E.
Request for Comments: 1429 Swedish University
February 1993
Listserv Distribute
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
This memo specifies a subset of the distribution protocol used by
BITNET LISTSERV to deliver mail messages to large amounts
recipients. This protocol, known as DISTRIBUTE, optimizes
distribution by sending a single copy of the message over
loaded links, insofar as topological information is available
guide such decisions, and reduces the average turnaround time
large mailing lists to 5-15 minutes on the average. This
describes a simple interface allowing non-BITNET mailing
exploders (or other bulk-delivery scripts) to take advantage of
service by letting the BITNET distribution network take care of
delivery
Running a mailing list of 1,000 subscribers or more with
"sendmail" while keeping turnaround time to a reasonable level is
easy task. Due mostly to its limited bandwidth in the mid-80's
BITNET has developed an efficient bulk delivery protocol for
mailing lists. Originally introduced in 1986, this protocol
refined little by little and now carries 2-6 million mail messages
day. In fact, this distribution mechanism implements a general
purpose delivery service which can be used by any user of BITNET
the Internet. Thus, a simple solution to the "sendmail"
problem is to wrap the message and recipient list in a
envelope and pass it to a BITNET server for delivery. This may
be the best possible solution, but it has the advantage of being
to implement
In this document we will use the term "production" to refer to
normal operation of the mailing list (or bulk delivery application
you want to pipe through the DISTRIBUTE service. That is,
"production" options are those you should specify once everything
tested and you are confident that the setup is working to
Thomas [Page 1]
RFC 1429 Listserv Distribute Protocol February 1993
satisfaction. In contrast, "test" and "debug" options can be used
experiment with the protocol but should not be used for
operation because of the additional bandwidth and CPU time
to generate the various informational reports
Finally, it should be noted that the DISTRIBUTE protocol
developed to address a number of issues, some of them relevant
to BITNET, and has evolved since 1986 while keeping a
syntax. For the sake of brevity, this RFC describes only a
subset of the available options and syntax. This is why the
may appear unnecessarily complicated or even illogical
1. Selecting an entry point into the DISTRIBUTE
The first thing you have to do is to find a suitable site to
your distributions to. For testing, and for testing ONLY, you
use
LISTSERV@SEARN.SUNET.
For production use, however, you should select a DISTRIBUTE site
your topological vicinity: it would make no sense to pass
distributions from California to a server in Sweden if most of
recipients are in the US. If your organization is connected to
and your BITNET system is part of the DISTRIBUTE backbone, this
to be your best bet. Otherwise you will want to contact
knowledgeable about BITNET (or the author of this RFC if you have
BITNET users). Make sure to run through the following
before sending any production traffic to the site in question
a. Do you have good connectivity to the host in question? Does
host, in general, have decent BITNET connectivity? There are
a few sites that insist on using 9.6k leased lines for BITNET
spite of having T1 IP access. You will want to avoid them
b. Send mail to the server with "show version" in the message
(not in the subject field, which is ignored). Is the server
version 1.7f or higher? If so, it should not have given you
following warning
>>> This server is configured to use PUNCH format for mail <<<
which means that messages with lines longer than 80
cannot be handled properly. If the software version is less
1.7f, the warning will not be present; instead, check the
(bottom) "Received:" field. If it does not say "LMail", do not
this server as it probably cannot handle messages with long lines
Thomas [Page 2]
RFC 1429 Listserv Distribute Protocol February 1993
Finally, make sure that the "Master nodes file" is not
than 2 months: there are a handful of sites which never
their tables due to staffing problems. They cannot be
from running LISTSERV, but you will certainly want to avoid them
c. How big is your workload? If you are planning to use the
for more than 10,000 daily recipients, you should get
from the LISTSERV administrator, both as a matter of courtesy
to hear about any restrictions or regularly scheduled downtime
might have. For instance, some universities might not allow
distributions during prime time, or they may have
DISTRIBUTE machines and will want to make sure you use the "right
one. Send mail to "owner-listserv" at the host in question
give an estimate of the amount of daily messages and recipients
would like to submit. If your message bounces back with "No
local user" or the like, it means the server did not pass the
test (b) and you don't want to use it anyway
An index of sites/hosts which have the required configuration,
connectivity, keep their tables up to date and have generally
to provide this service to anyone in their topological area will
published separately in the future
2. Physical delivery of the DISTRIBUTE
The distribution request is delivered via SMTP to the e-mail
obtained in step 1 (for instance, LISTSERV@SEARN.SUNET.SE). In fact
as long as you can somehow get mail to the server's host, you can
the service; SMTP is just the most convenient way of doing so
2.1. Contents of MAIL FROM:
You should set the MAIL FROM: field to the address of the person
maintains your mailing list or, generally speaking, to the address
a human being who can take action in case the message fails to
the DISTRIBUTE server's host. This is a very rare occurrence
2.2. Contents of RCPT TO:
The RCPT TO: field points to the server's address (for instance
LISTSERV@SEARN.SUNET.SE).
2.3. Contents of the RFC822
After the DATA instruction, you must supply a valid RFC822
with a "From:" field pointing to the mailbox that should
notification of delivery problems, bounced mail, and so on. This
be the same as the MAIL FROM: field, an address of the type "owner
Thomas [Page 3]
RFC 1429 Listserv Distribute Protocol February 1993
xxxx@yourhost", etc. DO NOT PUT THE LIST SUBMISSION ADDRESS THERE
or you will get mailing loops
For testing, the "From:" field should point to your own mailbox,
that you get the responses from the server
As long as RFC822 syntax is respected, the only field that matters
the "From:" field (or "Sender:", "Resent-From:", etc.). In
this means you can just pipe the distribution request into "
listserv@whatever" and let your mail program build all the headers
3. Format of the DISTRIBUTE
The body of the message delivered to LISTSERV defines the
of the distribution and the text (header + body) of the RFC822
message you want to have delivered. The request starts with a "
card", followed by a DISTRIBUTE command, a list of recipients,
finally the message header and body
3.1. Syntax of the JOB
The purpose of the JOB card is to make sure that any spurious
inserted by mail gateways or the like is flushed and not
interpreted as a command. It can optionally be used to associate
"job name" with the request, in case you want to use tools to
you in processing the notifications you get from the
servers when running in test mode. The syntax is as follows
//jobname JOB ECHO=
"jobname" can be anything as long as it does not contain blanks,
can be omitted. LISTSERV generally ignores case when
commands, so you can use "job" or "Job" if you prefer. The ECHO=
keyword is required for production use, to suppress the "
usage summary" you would otherwise get upon completion of
delivery. You may want to omit it when testing
3.2. Syntax of the DISTRIBUTE
Below the JOB card, you must supply the following line
DISTRIBUTE
For production mode, do not specify anything else on that line.
testing, you should add ACK=MAIL in order to get an
confirming the delivery. There are two other useful options
DEBUG=YES, which instructs the server to produce a report showing
the various recipients will be routed, but without
Thomas [Page 4]
RFC 1429 Listserv Distribute Protocol February 1993
delivering the message; and TRACE=YES, which does the same but
deliver the message. Before making a "live" test with your
recipients list, you should tack the DEBUG=YES option once to
sure you got all the parameters and syntax right, and get a
idea of the efficiency of the distribution (see the section
performance).
3.3. Giving the list of
The list of recipients follows the DISTRIBUTE line and is
as follows
//To DD *
user1@host1
user2@host2
/*
The two lines starting with a "/" have to be copied as-is. Each
the lines in between contains the address of one of the recipients
followed by a blank and by the word "BSMTP", which indicates that
do not want the header rewritten. There are four restrictions
a. The address must be a plain "local-part@hostname" - no name string
no angle bracket, no source route, etc. Bear in mind that
DISTRIBUTE server is not in the same domain as you: all
addresses should be fully qualified
b. If the local-part is quoted, it must be quoted from the first
on. Technically, RFC822 allows: Joe."Now@Home".Smith@xyz.edu,
for performance reasons this form is not supported. Just quote
first word to tell LISTSERV to run the address through the
parser: you would write "Joe"."Now@Home".Smith@xyz.edu instead
c. The local-part of the address may not start with an (unquoted
asterisk. You can bypass this restriction by quoting the
part and using a %-hack through the server's host
"***JACK***%jack-ws.xyz.edu"@server-host
d. Blanks are not allowed anywhere in the address
You can use the pseudo-domain ".BITNET" for BITNET recipients: it
always supported within DISTRIBUTE requests
3.4. Specifying the message
After the last recipient and the closing "/*", add the
line
Thomas [Page 5]
RFC 1429 Listserv Distribute Protocol February 1993
//Data DD *,
followed by the RFC822 message (header + body) that you
delivered. The EOF option indicates that the message header and
will extend until the end of the message you are sending to
DISTRIBUTE server. If you are worried about extraneous data
appended by a gateway, remove the EOF option, add a closing "/*"
after the end of the message, followed by a "// EOJ" card to
any remaining text. This, however, will fail if the message
contains a "/*" line; you would have to insert a space before
such line
4.
Here is an (intentionally short) example to clarify the syntax
----- cut here -----
//Test
Distribute mail Ack=mail Debug=
//To DD *
joe@ws-4.xyz.edu
jack@abc.com
jim@tamvm1.bitnet
jill@alpha.cc.buffalo.edu
james@library.rice.edu
/*
//Data DD *,
Date: Tue, 19 Jan 1993 10:57:29 -0500
From: Robert H. Smith
Subject: Re: Problem with V5.41
To: somelist@some.host.
I agree with Jack, V5.41 is not a stable release. I had to fall
to V5.40 within 5 minutes of installation...
Bob
----- cut here -----
Note: some of the hostnames are genuine, but the usernames are
fictitious
You would get the following reply
--------------------------------------------------------------------
Job "Test" started on 20 Feb 1993 01:09:40
> Distribute mail ack=mail debug=
Debug trace information
Thomas [Page 6]
RFC 1429 Listserv Distribute Protocol February 1993
ABC.COM goes to SEARN (213) - single
ALPHA.CC.BUFFALO.EDU goes to UBVM (027) - single
LIBRARY.RICE.EDU goes to RICEVM1 (022) - single
TAMVM1 goes to TAIVM1 (247) - single
WS-4.XYZ.EDU goes to SEARN (213) - single
Path information
TAIVM1 : UGA RICEVM1 TAIVM
UBVM : UGA
RICEVM1 : UGA RICEVM
(Debug) Mail forwarded to LISTSERV@UGA for 3 recipients
(Debug) Mail posted via BSMTP to jack@ABC.COM
(Debug) Mail posted via BSMTP to joe@WS-4.XYZ.EDU
Job "Test" ended on 20 Feb 1993 01:09:40
Summary of resource
-------------------------------
CPU time: 0.086 sec Device I/O: 6
Overhead CPU: 0.045 sec Paging I/O: 5
CPU model: 9221 DASD model: 3380
--------------------------------------------------------------------
To actually perform the distribution and get an acknowledgement,
would change the first two lines as follows
----- cut here -----
//Test JOB Echo=
Distribute mail Ack=
--------------------
And you would get the following reply
--------------------------------------------------------------------
Mail forwarded to LISTSERV@UGA for 3 recipients
Mail posted via BSMTP to jack@ABC.COM
Mail posted via BSMTP to joe@WS-4.XYZ.EDU
--------------------------------------------------------------------
Finally, by removing the "Ack=mail" keyword you would perform
"silent" distribution without any acknowledgement, suitable
production mode
Thomas [Page 7]
RFC 1429 Listserv Distribute Protocol February 1993
5.
The efficiency of the distribution depends mostly on the quality
accuracy of the topological information available to the
server (and, in some extreme cases, on system load). For
recipients, the typical turnaround time for reasonably well
systems is 5-15 minutes. Internet recipients fall in two categories
those which can be routed to a machine within or close to
recipient's organization (average turnaround time 5-20 minutes),
those for which no topological information is available at all.
that case the delivery can take much longer, but usually
faster than with a vanilla sendmail setup. At the time being
topological information is available for most top-level
outside the US and for many sub-domains of EDU and GOV
You can measure the efficiency of the distribution using
DEBUG=YES option as explained above. Recipients which get
to another server usually get delivered within 5-20 minutes (
to poorly connected sites or countries, for which not much can
done). Recipients which are handled locally are passed to a
SMTP agent whose efficiency depends very much on the amount
"burst" queries the local name server can handle in quick succession
A number of projects are currently underway to investigate
feasibility of improving the quality of the topological
available to the DISTRIBUTE servers for the Internet
Security
Security issues are not discussed in this memo
Author's
Eric
Swedish University
Dr.Kristinas vaeg 37
100 44 Stockholm,
E-mail: ERIC@SEARN.SUNET.
Thomas [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
