dat@hpcnof.UUCP (10/11/85)
This note is to solicit information on improving the following
document. Thanks!
-- Dave Taylor
..ihnp4!hpfcla!d_taylor
..hplabs!hpcnof!dat
-----------------------------------------------------------------------------
Summary of Network Mail Headers
-------------------------------
Dave Taylor
Hewlett Packard, Colorado Networks Operation
Last Revision: October 11th, 1985
This document contains an exhaustive description of each of the
possible mail headers from electronic messages sent/received or
shipped through any of the following networks: USENET (uucp),
ARPANET, BITNET, and CSNET.
While every effort has been made to make this list complete, there
are still some headers that are not included. If any errors, inac-
curacies or omissions are found, please mail the information includ-
ing a sample header to me at ihnp4!hpfcla!d_taylor or
hplabs!hpcnou!d_taylor.
(This list is ordered more or less alphabetically)
1. Apparently-To:
This header indicates that the message is destined to a network
that does not do address verification. For example, if a message
were sent from ARPA to a non-ARPA address, it would have this header
included.
Example:
Apparently-To: <hplabs!hpfcla!d_taylor@HEWLETT-PACKARD.COM>
2. Bcc:
This is used by the sender of the message to have copies of the
message go to people without the 'main' adressees knowing about it.
They are the "lowest" of the three groups of people who can receive
a message (This is like giving a Xerox (tm) of your memo to your
office mate...)
Example:
Bcc: jack@NLM-VAX, my_boss
3. Cc:
This header indicates whom the secondary recpients of the mes-
sage are. These people will receive copies of the message, but not
via directl addressing. (This is similar to the carbon-copies func-
tion on a standard office memo).
Example:
Cc: hplabs!hpcnof!d_taylor, joe@HARVARD.EDU
4. Comments:
This is for the addition of arbitrary text in the header of an
outgoing message.
Example:
Comments: This mail was generated by a test version of mailit,
a new program that does inter-domain host verification
using psychic communications. If it doesn't get the
mail to you - you'll feel a slight chill...
5. Date:
The date and time the message was sent (or the date and time
that the message hit the first 'intelligent' mailer - which will add
this field if it isn't present).
Example:
Date: Fri, Jan 19, 1985 12:04 MST
6. Encrypted:
This header is for the sending and receiving of encrypted mail,
and (usually) indicates the encryption program used. It can option-
ally include a public key encryption key (which, by itself, is use-
less).
Example:
Encrypted: public-encode, SECUREMAIL
7. From
The From line where From isn't followed by a colon is added by
the receiving mail system and simply indicates what time the mail
was received. If the mail was sent by someone else on the same sys-
tem, the second field will indicate their username, otherwise it is
essentially useless information.
Example:
From dat Wed Aug 7 1985 00:04:03 MST
8. From:
This From line is generated by the senders mail system, and
will usually indicate not only the address the message took to get
there, but also has the full name of the sender. Sometimes this
header will be generated by a mailer en-route, in which case only
the address will be present. "Smartmailers" (mail transport sys-
tems) update the address on the From: line as it passes through
their machine...
Example:
From: ihnp4!dartvax!eddy (Eddy Van Halen)
9. >From
Certain mailers (the 'un-smartmailers') don't update the From:
line and in fact do absolutely the minimum needed to indicate pas-
sage of the message. This includes simply rewriting the "From" line
(see the first "From" header above) by prefixing it with a '>' char-
acter and appending "remote from <hostname>".
Example:
>From uucp Wed Sep 25 03:40:09 1985 remote from veeger
10. In-Reply-To:
This header is generated when a message is a direct response to
another message and can have two forms; either using the Message-Id
or actually using the From: line and the Date: line. The following
is an example of the latter form...
Example:
In-Reply-To: Message from "wrap@AMES (Joe Wrap)" of 12 Sep 85 20:37:01 EDT
11. Keywords:
This is used to indicate keywords or phrases to help categorize
the incoming message. It is generated by the sender...
Example:
Keywords: mail, electronic communications, standards, addressing
12. Message-Id:
This is a unique message identification number and is generated
by the sending mailer. The format for the id number is (usually):
YYMMDDHHMM{SS}.<message-number>@hostname{domain(s)}
For example, if a message is sent by someone at MIT-LAB on the 6th
of August 1985 at 9:02:03 am, the message id would be:
Message-Id: <850806090203.xxxx@MIT-LAB.EDU.ARPA>
Also, if the sender doesn't generate this header, a 'smartmailer'
along the way will include one relative to that machine.
Example:
Message-Id: <8502040302.42432@HP.COM.ARPA>
13. Posted-Date:
This is a permutation of the "Date:" field. See "Date:".
Example:
Posted-Date: Mon, 12 Aug 85 23:30:46 pdt
14. Received:
This is added by each mail transport system relaying the mes-
sage. It indicates sending and receiving hosts and the current date
and time at that point. Oftentimes, this header will also include a
unique message identification number for tracking purposes.
Examples:
Received: by HP-VENUS id AA00541; Mon, 7 Oct 85 10:29:09 pdt
Received: from CMU-CS by UCB-VAX.ARPA (4.24/5.3)
15. References:
This is used to indicate a referenced article or message (as
opposed to "replying to" a message). Most commonly, this is used in
conjunction with notes or news (electronic conferencing systems) to
indicate mail in reference to a specified article or posting.
Example:
References: Your posting in net.mail (hpcnoe.302) of 4 Jan, 85
16. Reply-To:
This indicates a return address for the receiver if they desire
to respond to the message. This address superscedes the address
generated (en-route) on the "From:" line. Most commonly, this is
used by an individual mailing for a group so that any response to
the individual will go to the group instead.
Example:
Reply-To: HUMAN-NETS@RUTGERS
17. Resent-
When someone forwards mail to a third party the original
headers will be prepended with "Resent-" to preserve the informa-
tion. The headers that currently are allowed to be prefixed in this
manner are:
Resent-Bcc:
Resent-Date:
Resent-From:
Resent-Message-ID:
Resent-Reply-To:
Resent-Sender
Resent-To:
Resent-cc:
Each field is documented elsewhere herein.
18. Return-Path:
This header is added at message recption by the mail transport
system and is intended to indicate the return address of the sender.
This is superceded by 'Reply-To:' for responses, if it's present.
Example:
Return-Path: basic!doug@uw-july
19. Sender:
This is used when the person originating the message is dif-
ferent from the person actually sending the message. For example,
if I have a secretary, my mail could be "From:" me, but the
"Sender:" would be my secretary.
Example:
Sender: hplabs!STEFAN@USC-ECL
20. Sent:
A variation of the "Date:" field.
Example:
Sent: Friday, June 28th 1985 at 3:19 pm
21. Subject:
This indicates, in one line usually, a summarized subject of
the message.
Example:
Subject: thoughts on your proposal...
22. To:
Indicates the person or persons that the mail message is
directly addressed to (as opposed to 'cc:' and 'bcc:' above). The
list of names may appear on an arbitrary number of lines.
Example:
To: Dave Taylor <hpcnou!dat%hplabs.csnet@CSNET-RELAY>
23. Via:
Usually indicative of a gateway transition, this is added by
the gateway software transitioning from one network to another. The
example below is from a message sent from the CSNET to the Usenet..
Example:
Via: CSNet; 18 Sep 85 14:26-PDT
Extensions and User Defined Fields
----------------------------------
There are many more headers that can be found in electronic mail
(some of which are listed below) and often the personal headers are
prefixed by "X-", since it is guaranteed that any extensions to the
mail headers will not begin with these two letters.
It is important to note that this section is by no means complete -
there are a great number of strange headers floating about. I've
tried to document the most common and most interesting ones here.
24. Latitude:
This header indicates the relative Latitude and Longtitude
(geographic location) of the sender. Theoretically, if you have a
"Great Circle" program, you could feed it these entries and your own
location and figure out how far away from you they are. It's of
dubious use, though.
Example:
Latitude: 40.4166 Longitude: 86.9166
25. Organization:
This is a quite common header (with it's European variant
"Organisation:") and indicates the organization that the sender
works for or is attending (in the case of a University).
Examples:
Organisation: the Antelope project, Kruislaan 312, Amsterdam
Organization: Hewlett Packard, Colorado Networks Operation
26. Origin:
This is mostly used to verify that the sending username is
actually the person who sent it. it contains the tty device sending
the message, the hostname of the machine and the date sent.
Example:
Origin: tty613 on hpccc; Mon, 23 Sep 85 09:48:38 PDT
27. Phase-Of-The-Moon:
This is a strangely popular header that is presumed to indicate
what phase the moon is in at the senders' site...more dubious infor-
mation!
Example:
Phase-Of-The-Moon: Waning Crescent (18% of Full)
28. Phone:
The telephone number by which the sender can be reached (usu-
ally their work phone number).
Example:
Phone: +31 20 5924122, +31 20 947183
29. Postal-Address:
The "overland" (non-electronic) mail address for the sender of
the message.
Example:
Postal-Address: Dave Taylor,
HP Colorado Networks,
3404 East Harmony Road
Fort Collins, Colorado
80525
30. Sunrise:
What time sunrise and sunset are at the senders location.
Example:
Sunrise: 6:23 Sunset: 19:08 (CST)
31. Telephone:
This is the same as 'Phone:' above.
Example:
Telephone: (415) 857-5875
32. X-Location:
This is the geographic location of the sender.
Example:
X-Location: Fort Collins, Colorado, USA
33. X-Mailer:
This indicates what mailer the sender used to compose and actu-
ally transmit the message. It's usually used to indicate non-
standard mailers...
Example:
X-Mailer: fastmail [version 1.0]
34. X-Sent-By-Nmail-Version:
This is the same as the "X-Mailer:" header, only much more
specific. It should, in fact, be absorbed into the previous header.
Example:
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
------------------------------------------------------------------------------lauren@vortex.UUCP (Lauren Weinstein) (10/16/85)
I do hope people aren't going to take that document in its current
form and use it as a reference. In particular, the descriptions of
From_ (From followed by space)
>From_
From:
Return-Path:
Sender:
are woefully inadequate and misleading. By failing to indicate the
important variations between uucp format and 822 format use of such
headers, all sorts of confusion may result. For example, saying that
smart sites SHOULD update the From: line is very misleading. Updating
of that sort has caused lots of problems since the From: line (which
is supposed to be an 822 format line) is not subject to uniform
handling across the networks. Especially when @-sign addresses are
present, but in general even when only ! addresses are present, the
From:, To:, and other 822 lines should be LEFT ALONE by all intermediate
sites. The uucp From_ line (and >From_ lines), must
either be left on messages to provide routing info or else folded
into a single From_ line (NOT a From: line unless the site doing the
folding is absolutely certain it is folding all info from the various From_
and >From_ lines CORRECTLY, and only when @-addresses are not in use).
If a site insists on folding From_ and >From_ lines, it should never do
so unless Received: lines are being added, since otherwise important
date/time transit info is lost. If a site is going to try create
a new From: line from the From_ and >From_ lines, it must do so only
completely on that basis, NOT by simply trying to update the existing
From: line which may rooted off of a different address. If an @ address
is present it must not try do this under any conditions, since incorrect
hybrid addresses almost always result. And the site
must still always be sure to properly add a new From_ line, update the >From_
lines or create a new folded From_ line as appropriate. The existence
of From_ and >From_ lines is critical. Once again, the best solution
is to never count on the From: line as being an accurate route back
to the author unless it is in 822 @-form. Such addresses, especially,
should not be touched by intermediate sites under any conditions.
Return-Path is also not reliable as a return address. In general,
for pure uucp mail, the only valid return address for replies is that
generated from the From_ and >From_ lines. Use of the From: line
is possible in some cases, especially when @-addresses are present
instead of ! addresses with smart mailers. But if intermediate
sites insist on trying to do simple updates of the From: lines based
on existing From: lines, the information in the From: line frequently
will be incomplete. The recommendation is that sites stop trying to update
the From: lines at all, both in the presence of @ addresses and in the
presence of simple ! addresses or hybrids. Leaving From: alone in all
cases is probably the best solution in all cases in the long run.
As we move toward domain addressing, many of these problems with
From:, etc. will gradually become of less significance (assuming
we can get sites to stop modifying these lines and just leave them
alone in most cases!)
--Lauren--david@ukma.UUCP (David Herron, NPR Lover) (10/18/85)
In article <841@vortex.UUCP> lauren@vortex.UUCP (Lauren Weinstein) writes: > For example, saying that >smart sites SHOULD update the From: line is very misleading. Updating >of that sort has caused lots of problems since the From: line (which >is supposed to be an 822 format line) is not subject to uniform >handling across the networks. Especially when @-sign addresses are >present, but in general even when only ! addresses are present, the >From:, To:, and other 822 lines should be LEFT ALONE by all intermediate >sites. But --Lauren--!! What if you're an intermediate site and the message is leaving the domain? For instance, when seismo gateways uucp mail into arpanet it munges the From: line so the uucp addresses will read user@host.UUCP. The reason for this is that most arpa sites would not know what to do with an a!b!c address so they are given an address which they can deal with. But other cases would be where you have a subnet and people within the subnet can use abbreviated addresses. They may also be able to use an abbreviated address (like leave off the topmost domain name) to address sites outside their subnet. To be proper the header would have to include complete addresses. But in this case, at least, the issues are known. You know where all the machines in your subnet are and the addressing issues for each one. -- David Herron, cbosgd!ukma!david, david@UKMA.BITNET. English is a second language to me -- Baby talk was my first language.
lauren@vortex.UUCP (Lauren Weinstein) (10/18/85)
Gateways have special responsibilities, but even the ones that try to modify the From: lines now often make matters worse. Throwing an address like: From: foo@bar.UUCP at the typical ARPA site doesn't do it too much good YET. But this will change (see below). In the meantime, some gateways are trying to deal with the problem in our current hybrid situation with varying levels of success. Eventually, ARPA people should be able to reliably reply to gatewayed addresses like foo@bar.UUCP without any From: modification taking place at the gateways at all. In any case, I don't object too strongly to a smart site taking a !-only address (no @'s; not already in domain form) and turning it into a simple domain address (not a route). What causes the problems is sites that try to create From: lines in ! form based on the existing From: line (which may contain !'s, @'s, or both [hybrid]). These new ! or hybrid based From: lines are often misleading or totally incorrect. If they were created totally from From_ info and didn't use the original From: line as a starting point such problems would be reduced, but these sites often even take perfectly valid domain-based @ addresses and modify them into inaccurate !-paths (as I discussed in my previous message). This causes particular confusion on !-only paths, but in general can cause confusion for any sort of path. Now, in the interests of mail working in our current hybrid environment, there are ARPA sites that do limited From: modification for some sites, but to do it "right" they have to use the From_ routing instead of the existing From: line as a base for creating the new line if they are more than one !-hop away from the message originator. If the message already has a domain form address, even these gateway sites will ultimately want to leave the address completely alone once we have a more fully domainized environment, at least as far as the gateways are concerned. This matter is complex enough that I'll have to generate a longer discussion in more detail when I can dig up some time. There are issues of dealing with the current hybrid environment vs. the approaching domain environment that enter into this at various levels. --Lauren--
avolio@decuac.UUCP (Frederick M. Avolio) (10/19/85)
In article <2297@ukma.UUCP>, david@ukma.UUCP (David Herron, NPR Lover) writes: > But --Lauren--!! What if you're an intermediate site and the message > is leaving the domain? For instance, when seismo gateways uucp mail > ... I wrote a long note to Dave Taylor with my comments on his document. In it I agree with Lauren with David Herron's exception -- no one should think they are smart enough (as in smart mailer) to change the From: field. EXCEPT if you are a gateway and need to protect one side or the other from certain forms onthe From: line. So, an APRA <--> UUCP gateway should try to make the From: line be in "user@host.dom" format if that is what is needed. An ENET <--> UUCP gateway, such as decuac, should change addresses in the form "node::user" and make it "user@node.DEC" to 1) get rid of colons in addresses which bother many sites and 2) make the address look like the addressing form adopted by the UUCP community's common use of ".DEC" to indicate DEC's ENET. (ANd decuac does this with mail passing though us from the Enet.) Fred.
rick@seismo.CSS.GOV (Rick Adams) (10/19/85)
But --Lauren--!! What if you're an intermediate site and the message --> is leaving the domain? For instance, when seismo gateways uucp mail unto arpanet it munges the From: line so the uucp addresses will read user@host.UUCP. The reason for this is that most arpa sites would not know what to do with an a!b!c address so they are given an address which they can deal with. funny, I wasn't aware of that. ---rick