·
Apparently-To: Messages with many recipients sometimes have a long
list of headers of the form "Apparently-To: rth@bieberdorf.edu" (one
line per recipient). These headers are unusual in legitimate mail; they are
normally a sign of a mailing list, and in recent times mailing lists have
generally used software sophisticated enough not to generate a giant pile of
headers.
·
Bcc: (stands for "Blind Carbon Copy") If you
see this header on incoming mail, something is wrong. It's used like Cc: (see
below), but does not appear in the headers. The idea is to be able to
send copies of email to persons who might not want to receive replies or to
appear in the headers. Blind carbon copies are popular with spammers, since it
confuses many inexperienced users to get email that doesn't appear to be
addressed to them.
·
Cc: (stands for "Carbon Copy", which is
meaningful if you remember typewriters) This header is sort of an extension of
"To:"; it specifies additional recipients. The difference between
"To:" and "Cc:" is essentially connotative; some mailers
also deal with them differently in generating replies.
·
Comments: This is a nonstandard, free-form header field. It's
most commonly seen in the form "Comments: Authenticated sender is
<rth@bieberdorf.edu>". A header like this is added by some mailers
(notably the popular freeware program Pegasus) to identify the sender; however,
it is often added by hand (with false information) by spammers as well. Treat
with caution.
·
Content-Transfer-Encoding: This header relates to MIME, a standard way of
enclosing non-text content in email. It has no direct relevance to the delivery
of mail, but it affects how MIME-compliant mail programs interpret the content
of the message.
·
Content-Type: Another MIME header, telling MIME-compliant mail
programs what type of content to expect in the message.
·
Date: This header does exactly what you'd expect: It
specifies a date, normally the date the message was composed and sent. If this
header is omitted by the sender's computer, it might conceivably be added by a
mail server or even by some other machine along the route. It shouldn't be
treated as gospel truth; forgeries aside, there are an awful lot of computers
in the world with their clocks set wrong.
·
Errors-To: Specifies an address for mailer-generated errors,
like "no such user" bounce messages, to go to (instead of the
sender's address). This is not a particularly common header, as the sender
usually wants to receive any errors at the sending address, which is what most
(essentially all) mail server software does by default.
·
From (without colon) This is the "envelope
From" discussed above.
·
From: (with colon) This is the "message From:"
discussed above.
·
Message-Id: (also Message-id: or Message-ID:) The Message-Id is
a more-or-less unique identifier assigned to each message, usually by the first
mailserver it encounters. Conventionally, it is of the form
"gibberish@bieberdorf.edu", where the "gibberish" part
could be absolutely anything and the second part is the name of the machine
that assigned the ID. Sometimes, but not often, the "gibberish"
includes the sender's username. Any email in which the message ID is malformed
(e.g., an empty string or no @ sign), or in which the site in the message ID
isn't the real site of origin, is probably a forgery.
·
In-Reply-To: A Usenet header that occasionally appears in mail,
the In-Reply-To: header gives the message ID of some previous message which is
being replied to. It is unusual for this header to appear except in email
directly related to Usenet; spammers have been known to use it, probably in an
attempt to evade filtration programs.
·
Mime-Version: (also MIME-Version:) Yet another MIME header, this
one just specifying the version of the MIME protocol that was used by the
sender. Like the other MIME headers, this one is usually eminently ignorable;
most modern mail programs will do the right thing with it.
·
Newsgroups: This header only appears in email that is connected
with Usenet---either email copies of Usenet postings, or email replies to
postings. In the first case, it specifies the newsgroup(s) to which the message
was posted; in the second, it specifies the newsgroup(s) in which the message
being replied to was posted. The semantics of this header are the subject of a
low-intensity holy war, which effectively assures that both sets of semantics
will be used indiscriminately for the foreseeable future.
·
Organization: A completely free-form header that normally contains
the name of the organization through which the sender of the message has net
access. The sender can generally control this header, and silly entries like
"Royal Society for Putting Things on Top of Other Things" are
commonplace.
·
Priority: An essentially free-form header that assigns a
priority to the mail. Most software ignores it. It is often used by spammers,
usually in the form "Priority: urgent" (or something similar), in an
attempt to get their messages read.
·
Received: Discussed in detail above.
·
References: The References: header is rare in email except for
copies of Usenet postings. Its use on Usenet is to identify the
"upstream" posts to which a message is a response; when it appears in
email, it's usually just a copy of a Usenet header. It may also appear in email
responses to Usenet postings, giving the message ID of the post being responded
to as well as the references from that post.
·
Reply-To: Specifies an address for replies to go to. Though
this header has many legitimate uses (perhaps your software mangles your From:
address and you want replies to go to a correct address), it is also widely
used by spammers to deflect criticism. Occasionally a naive spammer will
actually solicit responses by email and use the Reply-To: header to collect
them, but more often the Reply-To: address in junk email is either invalid or
an innocent victim.
·
Sender: This header is unusual in email (X-Sender: is
usually used instead), but appears occasionally, especially in copies of Usenet
posts. It should identify the sender; in the case of Usenet posts, it is a more
reliable identifier than the From: line.
·
Subject: A completely free-form field specified by the
sender, intended, of course, to describe the subject of the message.
·
To: The "message To: "described above. Note
that the To: header need not contain the recipient's address!
·
X-headers is the generic term for headers starting with a
capital X and a hyphen. The convention is that X-headers are nonstandard and
provided for information only, and that, conversely, any nonstandard
informative header should be given a name starting with "X-". This
convention is frequently violated.
·
X-Confirm-Reading-To: This header requests an automated confirmation
notice when the message is received or read. It is typically ignored;
presumably some software acts on it.
·
X-Distribution: In response to problems with spammers using his
software, the author of Pegasus Mail added this header. Any message sent with
Pegasus to a sufficiently large number of recipients has a header added that
says "X-Distribution: bulk". It is explicitly intended as something
for recipients to filter against.
·
X-Errors-To: Like Errors-To:, this header specifies an address
for errors to be sent to. It is probably less widely obeyed.
·
X-Mailer: (also X-mailer:) A freeform header field intended
for the mail software used by the sender to identify itself (as advertising or
whatever). Since much junk email is sent with mailers invented for the purpose,
this field can provide much useful fodder for filters.
·
X-PMFLAGS: This is a header added by Pegasus Mail; its
semantics are nonobvious. It appears in any message sent with Pegasus, so it
doesn't obviously convey any information to the recipient that isn't covered by
the X-Mailer: header.
·
X-Priority: Another priority field, used notably by Eudora to
assign a priority (which appears as a graphical notation on the message).
·
X-Sender: The usual email analogue to the Sender: header in
Usenet news, this header purportedly identifies the sender with greater reliability
than the From: header. In fact, it is nearly as easy to forge, and should
therefore be viewed with the same sort of suspicion as the From: header.
·
X-UIDL: This is a unique identifier used by the POP
protocol for retrieving mail from a server. It is normally added between the
recipient's mail server and the recipient's actual mail software; if mail
arrives at the mail server with an X-UIDL: header, it is probably junk (there's
no conceivable use for such a header, but for some unknown reason many spammers
add one).