resting on top of several existing physical networks.  These
    networks include, but are not limited to, UUCP, the Internet, an
    Ethernet, the BLICN network, an NSC Hyperchannel, and a BERKNET.
    What is important is that two neighboring systems on USENET have
    some method to get a new message, in the format listed here, from
    one system to the other, and once on the receiving system, processed
    by the netnews software on that system.  (On UNIX systems, this
    usually means the rnews program being run with the message on the
    standard input. )

    It is not a requirement that USENET hosts have mail systems capable
    of understanding the Internet mail syntax, but it is strongly
    recommended.  Since "From", "Reply-To", and "Sender" lines use the
    Internet syntax, replies will be difficult or impossible without an
    Internet mailer.  A host without an Internet mailer can attempt to
    use the "Path" header line for replies, but this field is not
    guaranteed to be a working path for replies.  In any event, any host
    generating or forwarding news messages must have an Internet address
    that allows them to receive mail from hosts with Internet mailers,
    and they must include their Internet address on their From line.

4.1.  Remote Execution

    Some networks permit direct remote command execution.  On these
    networks, news may be forwarded by spooling the rnews command with
    the message on the standard input.  For example, if the remote
    system is called remote, news would be sent over a UUCP link
    with the command:

                              uux - remote!rnews

    and on a Berknet:

                              net -mremote rnews








 
RFC 1036              Standard for USENET Messages         December 1987


    It is important that the message be sent via a reliable mechanism,
    normally involving the possibility of spooling, rather than direct
    real-time remote execution.  This is because, if the remote system
    is down, a direct execution command will fail, and the message will
    never be delivered.  If the message is spooled, it will eventually
    be delivered when both systems are up.

4.2.  Transfer by Mail

    On some systems, direct remote spooled execution is not possible.
    However, most systems support electronic mail, and a news message
    can be sent as mail.  One approach is to send a mail message which
    is identical to the news message: the mail headers are the news
    headers, and the mail body is the news body.  By convention, this
    mail is sent to the user newsmail on the remote machine.

    One problem with this method is that it may not be possible to
    convince the mail system that the "From" line of the message is
    valid, since the mail message was generated by a program on a
    system different from the source of the news message.  Another
    problem is that error messages caused by the mail transmission
    would be sent to the originator of the news message, who has no
    control over news transmission between two cooperating hosts
    and does not know whom to contact.  Transmission error messages
    should be directed to a responsible contact person on the
    sending machine.

    A solution to this problem is to encapsulate the news message into a
    mail message, such that the entire message (headers and body) are
    part of the body of the mail message.  The convention here is that
    such mail is sent to user rnews on the remote system.  A mail
    message body is generated by prepending the letter N to each line of
    the news message, and then attaching whatever mail headers are
    convenient to generate.  The N's are attached to prevent any special
    lines in the news message from interfering with mail transmission,
    and to prevent any extra lines inserted by the mailer (headers,
    blank lines, etc.) from becoming part of the news message.  A
    program on the receiving machine receives mail to rnews, extracting
    the message itself and invoking the rnews program.  An example in
    this format might look like this:












 
RFC 1036              Standard for USENET Messages         December 1987