s-o-1036 June 1994

8.3. News Within Mail

It is often desirable to transmit news as mail,  either  for
the  convenience of a human recipient or because that is the
only type of transmission available on a restrictive  commu-
nication path.

Given  the  similarity  between the news format and the MAIL
format, it is superficially attractive to just send the news
article  as  a  mail  message.  This is typically a mistake:
mail-handling software often feels free to manipulate  vari-
ous  headers  in  undesirable  ways  (in some cases, such as
Sender, such manipulation is actually mandatory),  and  mail
transmission  problems etc. MUST be reported to the adminis-
trators responsible for the mail transmission rather than to
the  article's author.  In general, news sent as mail should
be encapsulated to separate the mail headers  and  the  news

INTERNET DRAFT to be        NEWS                    sec. 8.3


headers.

When  the intended recipient is a human, any convenient form
of encapsulation may be used.  Recommended  practice  is  to
use   MIME  encapsulation  with  a  content  type  of  "mes-
sage/news", given that news articles have additional  seman-
tics beyond what "message/rfc822" implies.

     NOTE:  "message/news" was registered as a standard
     subtype by IANA 22 June 1993.

When mail is being used as a transmission path  between  two
relayers,  however,  a  standard  method is desirable.  Cur-
rently the standard method is to send the mail to an address
whose  local part is "rnews", with whatever mail headers are
necessary for successful  transmission.   The  news  article
(including its headers) is sent as the body of the mail mes-
sage, with an "N" prepended to each line.

     NOTE: The "N" reduces the probability of an  inno-
     cent line in a news article being taken as a magic
     command to mail software, and makes  it  easy  for
     receiving software to strip off any lines added by
     mail software (e.g. the trailing empty line  added
     by some UUCP mail software).

This  method  has its weaknesses.  In particular, it assumes
that the mail  transmission  channel  can  transmit  nearly-
arbitrary body text undamaged.  When mail is being used as a
transmission path of last resort, however, the  mail  system
often has inconvenient preconceived notions about the format
of message bodies.  Various  ad-hoc  encoding  schemes  have
been used to avoid such problems.  The recommended method is
to send a news article or batch as the body of a  MIME  mail
message,  using content type "application/news-transmission"
and MIME's "base64" encoding (which is specifically designed
to survive all known major mail systems).

     NOTE:  In  the  process, MIME conventions could be
     used to fragment and reassemble an  article  which
     is  too  large to be sent as a single mail message
     over a transmission path  that  restricts  message
     length.   In addition, the "conversions" parameter
     to the content type could be used to indicate what
     (if  any)  compression  method has been used.  And
     the Content-MD5 header [rrr 1544] can be used as a
     "checksum" to provide high confidence of detecting
     accidental damage to the contents.

     UNRESOLVED ISSUE: The "conversions"  parameter  no
     longer exists.  What should be done about this, if
     anything?

INTERNET DRAFT to be        NEWS                    sec. 8.3


     NOTE: It might look tempting to use a content type
     such  as  "message/X-netnews",  but MIME bans non-
     trivial encodings of the entire body  of  messages
     with  content  type  "message".   The intent is to
     avoid obscuring nested structure underneath encod-
     ings.   For inter-relayer news transmission, there
     is no nested structure  of  interest,  and  it  is
     important  that  the entire article (including its
     headers, not just its body) be  protected  against
     the  vagaries  of intervening mail software.  This
     situation appears to fit the MIME  description  of
     circumstances in which "application" is the proper
     content type.

     NOTE:  "application/news-transmission",   with   a
     "conversions" parameter, was registered as a stan-
     dard subtype by IANA 22 June 1993.

     UNRESOLVED ISSUE: The "conversions"  parameter  no
     longer  exists  in  MIME.  What should we do about
     this?