⟦e9d2ac0ac⟧

TextFile

Part 2:  Cleaning up a header.

	Headers for mail originating at the local site should be in
	reasonable conformance to RFC822 before being sent.  To do
	this, some conventions used by users and by some mail user
	agents need to be cleaned up.  These generally involve making
	addresses in headers conform as much as is reasonable, making
	sure that addresses are cleanly separated when multiple
	addresses appear in one field, and ensuring that all required
	header fields exist.  This last part must be done for all
	mail, not just mail originated locally.


Section 2.1:  Which header fields contain addresses to be cleaned

	Given one interpretation of RFC822, we must either cleanup
	the following headers:

		Resent-Sender:
		Resent-From:
		Resent-To:
		Resent-Cc:
		Resent-Bcc:

	or we must cleanup the headers:

		Sender:
		From:
		To:
		Cc:
		Bcc:

	the former list will be used if any member of the list exists.
	Thus, previous to cleanup, a scan must be made of the headers
	to determine the set to cleanup.  In the following sections,
	any reference to an above header without the ``Resent-'' prefix
	should be applied to the ``Resent-'' version of the header
	under the condition stated above.

	Note:  A Bcc: header field should be removed from locally
	generated mail before being delivered.  It is a ``Blind
	Carbon Copy'' after all, so it doesn't do any good if other
	people can see it!  Optionally, it could be left in headers
	for copies sent to people referenced in the Bcc: line.


Section 2.2:  How to cleanup addressing header fields.

	The following headers must be created if they do not exist:

		From: <from_address>

		To: <to_address>(, <to_address>)*

	where:	<from_address> = address of the originator
		<to_address> = a appointed recipient of the message

	In addition to this, either the ``From:'' or a ``Sender:'' field 
	must exist that correctly states the address of the user sending
	the mail.  A local user cannot specify a Sender: field himself,
	and any attempt to do so will be replaced by a field filled in
	by the smail.

	A created ``From:'' or ``Sender:'' field should contain the
	address of the sender of a message in the form:

		From: <user>@<domain>[ (<full_name>)]
	or	Sender: <user>@<domain>[ (<full_name>)]

	where:	<user> = the mailbox id of the sender.  A From: field
			 created for a message where the sender is
			 known only as a return path should use the
			 !-route return path here.
		<domain> = the fully qualified name of the local domain.
		<full_name> = the full name of the sender, if known.  If
			 this is not known, the optional part of the
			 field should not be included.

	On locally originated messages, addresses that are not fully
	qualified addresses should be transformed into fully qualified
	domain addresses.  Hosts that are not reachable within the
	context of a local domain should be qualified in the UUCP domain.

	It is an unfortunate difficulty that users and programs who
	generate mail do not generally put commas between addresses in
	header fields.  Thus, an important part of cleaning up these
	fields is to identify correctly the boundaries of addresses
	and put commas between them if commas do not exist already.

	Example:

	    Given the following two header fields from a message, where
	    tron originated the message from a machine in the domain
	    ``kremvax.kgb.comm'', and where ``kgbvax'' is another machine
	    in the ``kgb.comm'' domain and ``rsrch'' is a subdomain
	    of ``kgb.comm'':

		From: debbie (Debbie McCormackov)
		To: les@glotz gorbie him@kray.rsrch her@kgbvax

	    These headers should be transformed into:

		From: debbie@kremvax.kgb.comm (Debbie McCormackov)
		To: les@glotz.uucp, gorbie@kremvax.kgb.comm,
			him@kray.rsrch.kgb.comm, her@kgbvax.kgb.comm

	    Note that changing white space in a header field should be 
	    done only if the changed header field is longer.

	Example:

	    Given the following header with the same context as the
	    previous example, and ``moscvax'' being a machine in the
	    local domain (``.kgb.comm''), and with ``nsavax'' being a
	    machine in ``nsa.gov'':

		From: sys-op-group: gavrilov (A.I. Gavrilov),
			smirnov (Z.Z. Smirnov),
			debbie (Debbie McCormackov);
		To: edm@burbank.nbc.com, kgbvax!glotz!namei!chongo
		Cc: brown@nsavax, gorbie@moscvax

	    This should become:

		Sender: debbie@kremvax.kgb.comm (Debbie McCormackov)
		From: sys-op-group: gavrilov@kremvax.kgb.comm (A.I. Gavrilov),
			smirnov@kremvax.kgb.comm (Z.Z. Smirnov),
			debbie@kremvax.kgb.comm (Debbie McCormackov);
		To: edm@burbank.nbc.com, kgbvax!glotz!namei!chongo
		Cc: brown@nsavax.nsa.gov, gorbie@moscvax.kgb.comm

	    The ``Sender:'' header field was added because the ``From:''
	    header field did not contain only the user that sent the
	    message.

Section 2.2.2:  Addresses for mail going to another machine in UUCP.

	If mail is being sent to a machine that does not require
	strict conformance to RFC822 (such as allowing !-route notation)
	then a change may be made to the ``From:'' and ``Sender:''
	header fields.  If an address in such a header field is in
	!-route notation, then the name of the current host should
	be prepended to the current path.

	This follows a loosely followed standard since more sendmail
	configuration files seem to do this than otherwise.  This
	interpretation is unpredictably correct.  For example, many
	System V sites without sendmail do not change any header fields.

	Example:

	    The following header received on the machine ``namei'' that
	    is to be sent to another machine in UUCP:

		Sender: walldrug!hustead@wall.com
		From: walldrug!hustead
		To: namei!amdahl!tron, namei!amdahl!chongo

	    Should be transformed, before being sent, into:

		Sender: walldrug!hustead@wall.com
		From: namei!walldrug!hustead
		To: namei!amdahl!tron, namei!amdahl!chongo


Section 2.2.3:  Addresses for mail going outside the UUCP domain.

	For mail going outside the UUCP domain, e.g., to the ARPAnet or
	some other strictly RFC822-conforming region, all addresses
	must be fully-qualified in either route-addr form or in
	user@domain form.  Thus, if a ``Sender:'' or ``From:'' field is
	given in user@sender-domain form, the string ``@sender-domain''
	should be added to each !-route or isolated user name.

	If the sender is only obtainable as a bang-route, then all
	!-route addresses, or lone user names should be prepended with
	the route back to the sender and should then be qualified in
	the domain of the local host.

	Example:

	    Given the following mail delivered to ``seismo'' that is to be
	    sent to the ARPAnet:

		From namei!postmast Mon Jan 12 10:12:11 1987 remote from amdahl
		To: ames!pyramid!csg, amdahl!seismo!prep.ai.mit.edu!rms,
		Cc: amdahl!sun!ucbvax!fair

	    The transformation should be:

		From: amdahl!namei!postmast@seismo.css.gov
		To: amdahl!namei!ames!pyramid!csg@seismo.css.gov,
		  amdahl!namei!amdahl!seismo!prep.ai.mit.edu!rms@seismo.css.gov
		Cc: amdahl!namei!amdahl!sun!ucbvax!fair@seismo.css.gov

	    Even though this looks like it needs to be improved, this
	    is the only way to guarantee that a !-route is interpreted
	    within the context of the originating host on replies.


Section 2.3:  Header fields that must exist.

	There are many non-addressing header fields that must
	exist and/or may be added.


Section 2.3.1:  The Received field.

	For use in tracing/debugging mail, all hosts should add a
	``Received:'' field at the beginning of the header.  It should
	identify the host, current date and time, and any unique
	message ID information.  It can also give version numbers for
	mail transport agents and such.  A sample Received:  field is:

		Received: by kray.rsrch.kgb.comm; id <AA01992@localhost.com>;
			Thu,  1 May 86 12:11:01 1986

	See RFC822 for a complete list of standard options that can
	be added here, though I recommend keeping the Received: fields
	short.  The above information should be adequate for normal
	tracing/debugging needs.


Section 2.3.2:  The Message-ID field.

	Every message should have a reasonably unique message ID.
	These are for logging purposes.  The message ID should be
	assigned by the host originating a message, though a host is
	free to assign a message ID to a pass through message if it
	does not already have one.

	A reasonable method of making unique IDs is to use the current
	date, time and an inode number or process ID.  Note that your
	complete domain should be attached to the message-ID, as well.

	Assuming the use of date, time process ID, the message-ID
	field might look like:

		Message-ID: <8711141457-00127@kgbvax.comm>

	NOTE:  This is not a ``<>'' pattern, it is an example.
\f
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦e9d2ac0ac⟧ TextFile

Derivation

TextFile
