[unix-history] / usr / src / share / doc / usd / 07.Mail / mail7.nr

.\" Copyright (c) 1980 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\"    must display the following acknowledgement:
.\"	This product includes software developed by the University of
.\"	California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\"    may be used to endorse or promote products derived from this software
.\"    without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\"	@(#)mail7.nr	6.3 (Berkeley) 4/17/91
.\"
.sh 1 "Format of messages"
.pp
This section describes the format of messages.
Messages begin with a
.i from
line, which consists of the word
.q From
followed by a user name, followed by anything, followed by
a date in the format returned by the
.i ctime
library routine described in section 3 of the Unix Programmer's
Manual.  A possible
.i ctime
format date is:
.(l
Tue Dec  1 10:58:23 1981
.)l
The
.i ctime
date may be optionally followed by a single space and a
time zone indication, which
should be three capital letters, such as PDT.
.pp
Following the
.i from
line are zero or more
.i "header field"
lines.
Each header field line is of the form:
.(l
name: information
.)l
.i Name
can be anything, but only certain header fields are recognized as
having any meaning.  The recognized header fields are:
.i article-id ,
.i bcc ,
.i cc ,
.i from ,
.i reply-to ,
.i sender ,
.i subject ,
and
.i to .
Other header fields are also significant to other systems; see,
for example, the current Arpanet message standard for much more
information on this topic.
A header field can be continued onto following lines by making the
first character on the following line a space or tab character.
.pp
If any headers are present, they must be followed by a blank line.
The part that follows is called the
.i body
of the message, and must be ASCII text, not containing null characters.
Each line in the message body must be no longer than 512 characters and
terminated with an ASCII newline character.
If binary data must be passed through the mail system, it is suggested
that this data be encoded in a system which encodes six bits into
a printable character (i.e.: uuencode).
For example, one could use the upper and lower case letters, the digits,
and the characters comma and period to make up the 64 characters.
Then, one can send a 16-bit binary number
as three characters.  These characters should be packed into lines,
preferably lines about 70 characters long as long lines are transmitted
more efficiently.
.pp
The message delivery system always adds a blank line to the end of
each message.  This blank line must not be deleted.
.pp
The UUCP message delivery system sometimes adds a blank line to
the end of a message each time it is forwarded through a machine.
.pp
It should be noted that some network transport protocols enforce
limits to the lengths of messages.
Commit	Line	Data
ff262511 KB	1	.\" Copyright (c) 1980 The Regents of the University of California.
ff262511 KB	2	.\" All rights reserved.
cedd6a8e	3	.\"
af359dea C	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.
ff262511	19	.\"
af359dea C	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
cedd6a8e	33	.\"
c7091918 KD	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
8c80966d	80	information on this topic.
c7091918 KD	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.
8c80966d CL	88	Each line in the message body must be no longer than 512 characters and
8c80966d CL	89	terminated with an ASCII newline character.
c7091918 KD	90	If binary data must be passed through the mail system, it is suggested
c7091918 KD	91	that this data be encoded in a system which encodes six bits into
8c80966d	92	a printable character (i.e.: uuencode).
c7091918 KD	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.