home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Source Code 1993 July / THE_SOURCE_CODE_CD_ROM.iso / bsd_srcs / share / doc / usd / 07.Mail / mail7.nr < prev    next >
Encoding:
Text File  |  1991-04-17  |  4.2 KB  |  108 lines
  1. .\" Copyright (c) 1980 The Regents of the University of California.
  2. .\" All rights reserved.
  3. .\"
  4. .\" Redistribution and use in source and binary forms, with or without
  5. .\" modification, are permitted provided that the following conditions
  6. .\" are met:
  7. .\" 1. Redistributions of source code must retain the above copyright
  8. .\"    notice, this list of conditions and the following disclaimer.
  9. .\" 2. Redistributions in binary form must reproduce the above copyright
  10. .\"    notice, this list of conditions and the following disclaimer in the
  11. .\"    documentation and/or other materials provided with the distribution.
  12. .\" 3. All advertising materials mentioning features or use of this software
  13. .\"    must display the following acknowledgement:
  14. .\"    This product includes software developed by the University of
  15. .\"    California, Berkeley and its contributors.
  16. .\" 4. Neither the name of the University nor the names of its contributors
  17. .\"    may be used to endorse or promote products derived from this software
  18. .\"    without specific prior written permission.
  19. .\"
  20. .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
  21. .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  22. .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  23. .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
  24. .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  25. .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  26. .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  27. .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  28. .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  29. .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  30. .\" SUCH DAMAGE.
  31. .\"
  32. .\"    @(#)mail7.nr    6.3 (Berkeley) 4/17/91
  33. .\"
  34. .sh 1 "Format of messages"
  35. .pp
  36. This section describes the format of messages.
  37. Messages begin with a
  38. .i from
  39. line, which consists of the word
  40. .q From
  41. followed by a user name, followed by anything, followed by
  42. a date in the format returned by the
  43. .i ctime
  44. library routine described in section 3 of the Unix Programmer's
  45. Manual.  A possible
  46. .i ctime
  47. format date is:
  48. .(l
  49. Tue Dec  1 10:58:23 1981
  50. .)l
  51. The
  52. .i ctime
  53. date may be optionally followed by a single space and a
  54. time zone indication, which
  55. should be three capital letters, such as PDT.
  56. .pp
  57. Following the
  58. .i from
  59. line are zero or more
  60. .i "header field"
  61. lines.
  62. Each header field line is of the form:
  63. .(l
  64. name: information
  65. .)l
  66. .i Name
  67. can be anything, but only certain header fields are recognized as
  68. having any meaning.  The recognized header fields are:
  69. .i article-id ,
  70. .i bcc ,
  71. .i cc ,
  72. .i from ,
  73. .i reply-to ,
  74. .i sender ,
  75. .i subject ,
  76. and
  77. .i to .
  78. Other header fields are also significant to other systems; see,
  79. for example, the current Arpanet message standard for much more
  80. information on this topic.
  81. A header field can be continued onto following lines by making the
  82. first character on the following line a space or tab character.
  83. .pp
  84. If any headers are present, they must be followed by a blank line.
  85. The part that follows is called the
  86. .i body
  87. of the message, and must be ASCII text, not containing null characters.
  88. Each line in the message body must be no longer than 512 characters and
  89. terminated with an ASCII newline character.
  90. If binary data must be passed through the mail system, it is suggested
  91. that this data be encoded in a system which encodes six bits into
  92. a printable character (i.e.: uuencode).
  93. For example, one could use the upper and lower case letters, the digits,
  94. and the characters comma and period to make up the 64 characters.
  95. Then, one can send a 16-bit binary number
  96. as three characters.  These characters should be packed into lines,
  97. preferably lines about 70 characters long as long lines are transmitted
  98. more efficiently.
  99. .pp
  100. The message delivery system always adds a blank line to the end of
  101. each message.  This blank line must not be deleted.
  102. .pp
  103. The UUCP message delivery system sometimes adds a blank line to
  104. the end of a message each time it is forwarded through a machine.
  105. .pp
  106. It should be noted that some network transport protocols enforce
  107. limits to the lengths of messages.
  108.