rfc1429.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 451 行 · 第 1/2 页


RFC 1429              Listserv Distribute Protocol         February 1993


   delivering the message; and TRACE=YES, which does the same but does
   deliver the message. Before making a "live" test with your actual
   recipients list, you should tack the DEBUG=YES option once to make
   sure you got all the parameters and syntax right, and get a rough
   idea of the efficiency of the distribution (see the section on
   performance).

3.3. Giving the list of recipients

   The list of recipients follows the DISTRIBUTE line and is specified
   as follows:

   //To DD *
   user1@host1 BSMTP
   user2@host2 BSMTP
   /*

   The two lines starting with a "/" have to be copied as-is. Each of
   the lines in between contains the address of one of the recipients,
   followed by a blank and by the word "BSMTP", which indicates that you
   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 the
      DISTRIBUTE server is not in the same domain as you: all the
      addresses should be fully qualified.

   b. If the local-part is quoted, it must be quoted from the first word
      on.  Technically, RFC822 allows: Joe."Now@Home"[e-mail], but
      for performance reasons this form is not supported. Just quote the
      first word to tell LISTSERV to run the address through the full
      parser: you would write "Joe"."Now@Home"[e-mail] instead.

   c. The local-part of the address may not start with an (unquoted)
      asterisk.  You can bypass this restriction by quoting the local
      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 is
   always supported within DISTRIBUTE requests.

3.4. Specifying the message text

   After the last recipient and the closing "/*", add the following
   line,




Thomas                                                          [Page 5]

RFC 1429              Listserv Distribute Protocol         February 1993


   //Data DD *,EOF

   followed by the RFC822 message (header + body) that you want
   delivered.  The EOF option indicates that the message header and body
   will extend until the end of the message you are sending to the
   DISTRIBUTE server.  If you are worried about extraneous data being
   appended by a gateway, remove the EOF option, add a closing "/*" line
   after the end of the message, followed by a "// EOJ" card to flush
   any remaining text. This, however, will fail if the message itself
   contains a "/*" line; you would have to insert a space before any
   such line.

4. Examples

   Here is an (intentionally short) example to clarify the syntax:

   ----- cut here -----
   //Test JOB
   Distribute mail Ack=mail Debug=yes
   //To DD *
   [e-mail] BSMTP
   [e-mail] BSMTP
   [e-mail] BSMTP
   [e-mail] BSMTP
   [e-mail] BSMTP
   /*
   //Data DD *,EOF
   Date:         Tue, 19 Jan 1993 10:57:29 -0500
   From:         Robert H. Smith <[e-mail]>
   Subject:      Re: Problem with V5.41
   To:           [e-mail]

   I agree with Jack, V5.41 is not a stable release. I had to fall back
   to V5.40 within 5 minutes of installation...

                                           Bob Smith
   ----- cut here -----

   Note: some of the hostnames are genuine, but the usernames are all
   fictitious.

   You would get the following reply:

   --------------------------------------------------------------------
   Job "Test" started on 20 Feb 1993 01:09:40

   > Distribute mail ack=mail debug=yes
   Debug trace information:



Thomas                                                          [Page 6]

RFC 1429              Listserv Distribute Protocol         February 1993


   ABC.COM                   goes to SEARN    (213) - single recipient
   ALPHA.CC.BUFFALO.EDU      goes to UBVM     (027) - single recipient
   LIBRARY.RICE.EDU          goes to RICEVM1  (022) - single recipient
   TAMVM1                    goes to TAIVM1   (247) - single recipient
   WS-4.XYZ.EDU              goes to SEARN    (213) - single recipient

   Path information:

    TAIVM1  : UGA      RICEVM1  TAIVM1
    UBVM    : UGA      UBVM
    RICEVM1 : UGA      RICEVM1

   (Debug) Mail forwarded to LISTSERV@UGA      for   3 recipients.
   (Debug) Mail posted via BSMTP to [e-mail].
   (Debug) Mail posted via BSMTP to [e-mail].

   Job "Test" ended   on 20 Feb 1993 01:09:40

   Summary of resource utilization
   -------------------------------
    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, you
   would change the first two lines as follows:

   ----- cut here -----
   //Test JOB Echo=NO
   Distribute mail Ack=mail
   --------------------

   And you would get the following reply:

   --------------------------------------------------------------------
   Mail forwarded to LISTSERV@UGA      for   3 recipients.
   Mail posted via BSMTP to [e-mail].
   Mail posted via BSMTP to [e-mail].
   --------------------------------------------------------------------

   Finally, by removing the "Ack=mail" keyword you would perform a
   "silent" distribution without any acknowledgement, suitable for
   production mode.







Thomas                                                          [Page 7]

RFC 1429              Listserv Distribute Protocol         February 1993


5. Performance

   The efficiency of the distribution depends mostly on the quality and
   accuracy of the topological information available to the DISTRIBUTE
   server (and, in some extreme cases, on system load). For BITNET
   recipients, the typical turnaround time for reasonably well connected
   systems is 5-15 minutes. Internet recipients fall in two categories:
   those which can be routed to a machine within or close to the
   recipient's organization (average turnaround time 5-20 minutes), and
   those for which no topological information is available at all. In
   that case the delivery can take much longer, but usually remains
   faster than with a vanilla sendmail setup. At the time being,
   topological information is available for most top-level domains
   outside the US and for many sub-domains of EDU and GOV.

   You can measure the efficiency of the distribution using the
   DEBUG=YES option as explained above. Recipients which get forwarded
   to another server usually get delivered within 5-20 minutes (except
   to poorly connected sites or countries, for which not much can be
   done). Recipients which are handled locally are passed to a local
   SMTP agent whose efficiency depends very much on the amount of
   "burst" queries the local name server can handle in quick succession.

   A number of projects are currently underway to investigate the
   feasibility of improving the quality of the topological information
   available to the DISTRIBUTE servers for the Internet.

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   Eric Thomas
   Swedish University Network
   Dr.Kristinas vaeg 37B
   100 44 Stockholm, Sweden

   E-mail: [e-mail]












Thomas                                                          [Page 8]