Email Headers

Header fields are NOT required to occur in any particular order, except that the message body must occur AFTER the headers. It is recommended that, if present, headers be sent in the order "Return- Path", "Received", "Date", "From", "Subject", "Sender", "To", "cc", etc. (RFC2822)

Apparently-To: Inserted by sendmail when there is no "To:" recipient in the original message. This causes the recipients derived from the envelope to be listed in the message heading. This behavior is not quite proper, MTAs should not modify headers (except inserting Received lines), and it can in some cases cause Bcc recipients to be wrongly divulged to non-Bcc recipients. Non-standard header that is discouraged in use, mentioned in RFC1211.

Apparently-To: gboyd@expita.com

Approved-By: Name of the moderator of the mailing list to which this message is sent; necessary on a posting sent to a moderated mailing list to allow its distribution to the list members. Non-standard for use in e-mail. Defined in RFC1036.

Approved-By: gboyd@expita.com

Bcc: ("Blind Carbon Copy") A copy of the mail message that is sent to one or more recipients without the knowledge of the primary recipients. Primary recipients are listed in the To: and Cc: lines. This is useful if you want to copy a message to many people without each of them seeing who the other recipients are. If you see this header on incoming mail, something is wrong because it does not appear in the headers.

Cc: ("Carbon Copy") This header can be considered an extension of the "To:" field as it is used to specifiy additional recipients. In this case, the copy of an e-mail message sent to a recipient has the recipient''s address appearing in the message. This is useful if you want to copy a message to many people with each of them seeing who the other recipients are; contrast with Bcc above. This header does appear in incoming e-mail.

Cc: gboyd@netcom.com

Comments: This is a free-form header field defined in RFC2822. The header is used to place explanatory text into the header portion of an e-mail message. The field may contain arbitrary text.

Pegasus mail adds a modified version of the Comments: field with an Authenticated sender. However, this is non-standard so you cannot rely on the authentication.

Comments: Authenticated sender is gboyd@netcom.com

The Comments: Authenticated sender is is an attempt by your POP3 (Post Office Protocol version 3 - defined in RFC1939) mailer daemon to resolve the sender''s address. Don''t be fooled by "Authenticated sender" messages. They are easily faked and mean nothing. They don''t "authenticate" anything. It''s just an attempt to resolve an address. Some are valid, some are not.

Content-Type: The second of three MIME headers that generally is found. The "Content-Type" defines the format of content (character set etc.) Note that the values for this header are defined in different ways in RFC1049 and in MIME (RFC2045). Look for the MIME-version: header to understand if Content-Type is to be interpreted according to RFC1049 or according to MIME (RFC2045). The MIME definition should be used in generating mail.

Historically, Content-Type field was proposed in RFC1049. In it, Content-Type did not distinguish type and subtype like RFC2045 does.

Content-Type: text/plain; charset="us-ascii"
Content-type: text/plain; charset=US-ASCII
Content-Type: text/plain; charset="iso-8859-1"
Content-Type: text/plain; charset=koi8-r
Content-Type: text/plain; charset=unknown-8bit

ISO-8859-1 (International Organization for Standardization (ISO), "Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin Alphabet No.1", ISO 8859-1:1987) is a MIME character set (charset) for west-European languages written by Latin script. It is an 8bit coded character set based on ISO 2022 and is defined in RFC2046.

ISO 8859 consists of the following parts, under the general title Information technology - 8bit single-byte coded graphic character sets:

1. Latin 1 (West European)
2. Latin 2 (East European)
3. Latin 3 (South European)
4. Latin 4 (North European)
5. Cyrillic alphabet
6. Arabic alphabet
7. Greek alphabet
8. Hebrew alphabet
9. Latin 5 (Turkish)
10. Latin 6 (Nordic)
11. Thai alphabet
12. unassigned
13. Latin 7 (Baltic)
14. Latin 8 (Celtic)
15. Latin 9 (Updated Latin 1)
16. Latin 10 (Updated Latin 2)

See Michael Everson''s ISO/IEC 8859-16: Latin Alphabet No. 10 document.

Most Microsoft Windows users and programs use ISO-8859-1.

koi8-r is a Russian character more widely used than IS0-8859. It is also common on Russian Internet sites and is described in RFC1489.

The default media type of "text/plain; charset=us-ascii" for Internet mail describes existing Internet practice. That is, it is the standard coded character set of Internet mail defined by RFC2822. It is a 7bit coded character set based on ISO 2022 and contains only ASCII, no code extensions are allowed. If a MIME charset is not specified, US-ASCII is used as default.

Other registered media types can be found at Media Types.

The first registered Character sets and IETF Policy on Character Sets and Languages define improvements over US-ASCII.

Content-Transfer-Encoding: The third of the MIME-related headers. Indicates the coding method used in a MIME message body. It has no direct relevance to the delivery of mail, but it affects how MIME compliant mail programs interpret the content of the message. Defined in RFC2045.

Content-Transfer-Encoding: 8bit
Content-transfer-encoding: 7BIT
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: quoted-printable

The Base64 Content-Transfer-Encoding is an encoding method defined in the MIME standard RFC2045. It is designed to represent arbitrary sequences of 8-bit data in a form that need not be humanly readable. Note the difference from "quoted-printable" discussed below. Typically, this coding will be used with all binary file types (.EXE, .ZIP, .AVI, .BMP, etc.) and foreign language character sets (charset) such as Chinese Big5 and Japanese.

MIME-Version: 1.0
Content-Type: text/html; charset=big5
Content-Transfer-Encoding: base64

PGh0bWw+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250
ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9YmlnNSI+DQo8dGl0bGU+Zmx5c2hvc2U8L3RpdGxl
Pg0KPC9oZWFkPg0KDQo8Ym9keSBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIj4N
CjxkaXYgYWxpZ249ImNlbnRlciI+DQoNCjxwPg0KPG9iamVjdCBjbGFzc2lkPSJjbHNpZDpE
[snip]

Quoted-printable is an encoding method defined in the MIME standard RFC2045. It is used primarily to encode 8-bit text (such as text that includes foreign characters) into 7-bit US ASCII, creating a document that is mostly readable by humans, even in its encoded form. All MIME compliant applications can decode quoted-printable text, though they may not necessarily be able to properly display the document as it was originally intended.

Quoted-printable encoding currently implemented by Microsoft has the annoying habit of not encoding printable ASCII characters (values 33 through 126, excluding 61), tabs and spaces that do not appear at the end of lines, and end-of-line characters. Other characters are represented by an equal sign ("=") immediately followed by that character''s hexadecimal value. Lines that are longer than 76 characters are shortened by line breaks, with the equal sign marking where the breaks occurred. For more information, see the Knowledge Base articles Q146629 Microsoft Exchange Internet Mail Lines End with a "=" and Q168779 OLEXP: No Quote Characters When Using Quoted Printable Format.

7-bit coding was the original method for sending e-mail. The SMTP (Simple Mail Transfer Protocol - RFC2821) data is 7-bit ASCII characters. Each character is transmitted as an 8-bit byte with the high-order bit cleared to zero.

Date: This header specifies a date (and time), normally the date the message was composed and sent. In X.400 mail systems, the time a message was submitted. Some Internet mail systems also use the date when the message was submitted. 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.

What you may not know is that the information in the "Date:" line is supplied by the time on the sender''s computer, which may or may not be set correctly. Also, the "Date:" header does not normally indicate when the message was sent, but only when it was composed.

The date is in the form 3 character day-of-week (Sun - Sat), day number (1-31) dd, 3-character month name, 4-digit year yyyy, followed by time (24-hour) hh:mm:ss and zone zzz format. Time Zone (zzz) is either the 3-character time zone or the local differential in hours and minutes offset from UTC (Universal Time Coordinated - old Greenwich Mean Time). "-" indicates west and "+" indicates east of UTC.

No standard Time Zone definitions seem to exist. Many UNIX versions understand a great range of abbreviations, but the most exhaustive list I found was the GNU tar manual Timezone item and documentation for the Perl date manipulation module TIMEZONES.

Date: Tue, 9 Jan 2001 23:40:00 -0800
Date: Sun, 1 Apr 2001 22:52:04 EDT
Date: Mon, 2 Apr 2001 16:02:19 +0200
Date: Fri, 30 Mar 2001 10:47:15 -0800

Errors-To: This is a non-standard RFC2822 message header added by sendmail and other e-mail clients.

Ordinarily, errors are bounced to the envelope sender. The "Errors-To:" header specifies the address, or addresses, to which sendmail should send additional notification of delivery errors. This header is intended for use by mailing lists, in order to prevent errors in a list from being resent to the list as a whole.

On mailing lists, the From: header allows replies to be submitted for distribution to the mailing list. If an arror is detected, we want it to be handled by someone other than the list.

This header is also used for reporting of errors in USENET postings to the source of the posting.

Internet standards recommend the use of RCPT TO and Return-Path, not Errors-To, for where delivery notifications are to be sent.

From (without colon) This is the "envelope From" and should never appear in e-mail being sent. This header is used in the so-called UNIX mailbox format, also known as Berkely mailbox format or the MBOX format. This is a format for storing a set of messages in a file. A line beginning with "From "(note space) is used to separate successive messages in such files. Thus, this header will appear when you use a text editor to look at a file in the UNIX mailbox format. Some mailers also use this format when printing messages on paper.

The information in this header should NOT be used to find an address to which replies to a message are to be sent.

However, this header is used in USENET News mail transport (See RFC0976) to indicate the path through which an article has gone when transferred to a new host. It is sometimes called the "From_" header.

This is header is inserted automatically by MTAs, unless one is already present and only then if it seems valid.

From: (with colon) This is the "message From:". This field contains the identity of the person(s) who wished this message to be sent. The message-creation process should default this field to be a single, authenticated machine address, indicating the AGENT (person, system or process) composing the message. If this is not done, the "Sender:" field MUST be present. If the "From:" field IS defaulted this way, the "Sender:" field is optional and is redundant with the "From:" field.

From: "Gerald E. Boyd" gboyd@expita.com

The second "From:" is generated by the MUA (your personal mailer), either by configuration, or by the user. The rewrite rules in sendmail and most filtering programs concern themselves with the "From:", "To:", "Cc:", and "Reply-To:" headers.

Followup-To: Not standardized for use in e-mail. Defined in RFC1036 for used in USENET News to indicate that future discussions (follow-ups) on an article should go to a different set of newsgroups than the replied-to article. The most common usage is when an article is posted to several newsgroups, and further discussions is to take place in only one of them.

In e-mail, this header may occur in a message which is sent to both e-mail addresses and USENET News, to show where follow-up in USENET news is wanted. The header does not say anything about where follow-up in e-mail is to be sent.

Note that the value of this header must always be one or more newsgroup names, never an e-mail addresses.

In-Reply-To: Reference to message which this message is a reply to. The contents of this field identify previous correspondence which this message answers. Note that if message identifiers are used in this field, they must use the "Message-ID:" specification format.

In-Reply-To: <75437062.984144269@orangebrain>
   of Fri, 09 Mar 2001 13:24:29 -0500
In-Reply-To: <200103110322.WAA28920@listserv.aol.com>
In-Reply-To: <000b01c0aa2f$28426a80$21142ed8@win98>

Message-ID: (also Message-Id: or Message-id:) This field is like a serial number and contains a unique identifier (the local-part address unit) which refers to THIS version of THIS message. The uniqueness of the message identifier is guaranteed by the host which generates it. This identifier is intended to be machine readable and not necessarily meaningful to humans. A message identifier pertains to exactly one particular message; subsequent revisions to the message should each receive new message identifiers. sendmail constructs the field from the data, the time, a unique file name, and the originating machine name.

Message-ID: <02ba01c07ad8$898fc840$c900000a@checkoway.com>
Message-ID: 
Message-ID: <3AC8A28B.27099.198FF5E1@localhost>
Message-Id: <3.0.5.32.20010330104715.007ac100@lineuponline.com>
Message-ID: <9377.010228@busk.cc.lv.ukrtel.net>

MIME-Version: (also Mime-Version:) The first of usually three MIME related message headers. An indicator that this message is formatted according to the MIME standard and indicating which version of MIME is utilized. Originally defined in RFC1521 and obsoleted by RFC2045.

Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit

Newsgroups: In USENET News (defined in RFC1036), the group(s) to which this article was posted. Some systems provide this header also in e-mail although it is not standardized there. Unfortunately, the header can appear in e-mail with two different and contradictory meanings:

1. Indicating the newsgroup recipient of an article/message sent to both e-mail and USENET News recipients.
2. In a personally addressed reply to an article in a newsgroup, indicating the newsgroup in which this discussion originated.

This header only appears in e-mail that is connected with USENET --- either e-mail copies of USENET postings, or e-mail replies to postings.

Newsgroups: comp.mail.misc,news.admin.net-abuse.email
Newsgroups: mindspring.users.shell

Organization: A completely free-form header that normally contains the name of the organization to which the sender of this article belongs. Defined in RFC1036 but is a non-standard header for use in e-mail.

Organization: ivolio Corporation
Organization: WorldAccess
Organization: People Who Are Not Old Enough For UNIX (Honorary Member Emeritus)
Organization: The University of New England, Armidale, Australia.

Precedence: Sometimes used as a priority value which can influence transmission speed and delivery. Common values are "bulk", "junk", and "first-class". Other uses is to control automatic replies and to control return-of-content facilities, and to stop mailing list loops. This is a non-standard controversial header that is discouraged from use.

Most common programs using or creating this header are sendmail, Eudora e-mail, Majordomo mailing list manager (MLM), and Procmail. The UNIX vacation program uses it to skip replies to messages, Eudora uses it for filtering e-mail, Majordomo adds it to outgoing messages (to prevent accidental mail loops), and Procmail users add it to their autoresponders.

Precedence: bulk

Priority: An essentially free-form header that assigns a priority to the mail. Most software ignores it. Can be "normal", "urgent" or "non-urgent" and can influence transmission speed and delivery. Defined in RFC1327, not for general usage.

Priority: normal

Received: A copy of this field is added by each MTA that relays the message. The information in the field can be quite useful for tracing problems. The names of the sending and receiving hosts and time-of-receipt may be specified. The "via" parameter may be used, to indicate what physical mechanism the message was sent over and the "with" parameter may be used to indicate the mail-, or connection-, level protocol that was used, such as the SMTP mail protocol, or X.25 transport protocol.

Note: Several "with" parameters may be included, to fully specify the set of protocols that were used. Some MTAs queue mail; the internal message identifier that is assigned to the message may be noted, using the "id" parameter. When the sending host uses a destination address specification that the receiving host reinterprets, by expansion or transformation, the receiving host may wish to record the original specification, using the "for" parameter. For example, when a copy of mail is sent to the member of a mailing list, this parameter may be used to record the original address that was used to specify the list.

The general format of a Received: line is ["from" sending host] "by" receiving host ["via"network, the physical path] ["with" link/mail protocol] "receiver unique id" string ["for recipent" address] ";" date

Optionally you can think of it as Received from Named Server([sending server IP address]) by Receiving server (receiving server software)

Received: from Randy ([65.166.2.47])
    by no2.superb.net (8.11.1/8.11.1) with SMTP id f3LKU6b07804
    for ; Sat, 21 Apr 2001 16:30:06 -0400 (EDT)

References: The contents of this field identify other correspondence which this message references. Note that if message identifiers are used, they must use the "msg-id" specification format. The References: header used in e-mail to reference to other related messages and in USENET News to reference to replied-to-articles. Its use on USENET is to identify the "upstream" posts to which a message is a response; when it appears in e-mail, it''s usually just a copy of a USENET header. It may also appear in e-mail responses to USENET postings, giving the message ID of the post being responded to as well as the references from that post.

References: <01a901c0a72a$42237960$610ca8c0@hostel1.giki.edu.pk>
References: 

Reply-To:The Reply-To: header forces replies to messages to go to an address that is different than that of the original sender. This header is usually inserted by mailing list software, where the "From:" is the address of the original sender or mailing list, and the Reply-To: is the address of the mailing list or list''s maintainer.

Reply-To: ACCMAIL Discussion List 
Reply-To: pcworks@imagicomm.com
Reply-To: 
Reply-to: Internet Help Resource 
Reply-To: swalert@VNET.IBM.COM
Reply-To: scs@eskimo.com (Steve Summit)
Reply-to: Ann.Tothill@pixie.co.zae

This header is meant to indicate where the sender wants replies to go. Unfortunately, this is ambiguous, since there are different kinds of replies, which the sender may wish to go to different addresses. In particular, there are personal replies intended for only one person, and group replies, intended for the whole group of people who read the replied-to message (often a mailing list, a newsgroup name cannot appear here because of different syntax, see "Followup-To").

Some mail systems use this header to indicate a better form of the e-mail address of the sender. Some mailing list programs put the name of the list in this header. These practices are controversial.

Return-Path: Intended to show the envelope address of the real sender as opposed to the sender used for replying (the "From:" and "Reply-To:" headers) Defined in RFC2821 and RFC1123.

When posting to USENET news, the "Return-Path:" shows news and the "From:" shows the address of the posting user. In General, "Return-Path:" should never be used for replying to mail. It is soley intended to be used for notification of delivery errors.

sendmail and UNIX Pine both use this header.

Return-Path: 
From: "Gerald E. Boyd" 
X-Sender: gboyd@no2.superb.net

Sender: The person or agent submitting the message to the network, if other than shown by the From: header. Normally inserted by mailing list software but appears 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.

Sender: ACCMAIL Discussion List 
Sender: owner-pcworks@imagicomm.com
Sender: owner-faq-maintainers@landfield.com

Status: Status is a non-standard RFC2822 message header added by Eudora and other e-mail clients after message delivery to indicate the status of delivery for this message when stored. Common values of this field are:

• U message is not downloaded and not deleted.
• R message is read or downloaded.
• O message is old but not deleted.
• D to be deleted.
• N new (a new message also sometimes is distinguished by not having any "Status:" header.

Combinations of these characters can occur, such as "Status: RO" to indicate that a message is downloaded but not deleted.

Status: RO
Status:

Subject: A completely free-form field specified by the sender, intended, of course, to describe the subject of the message.

Subject: Doing everything via e-mail

To: This header line is used to indicate the primary recipient(s) of the message. One of the standard headers defined in RFC2822 and RFC1123.

Usually a name will precede the actual address, though this is not required. The "To:" line may also contain more than one address, each separated by a comma. In this case, the e-mail will be delivered to each address listed in this line, as well as the "Cc:" line and the otherwise invisible "Bcc:" line (see Cc: and Bcc:) There really is no functional difference between an address contained in the "Cc:" or "To:" lines of an e-mail message. Note that the "To:" header need not contain the recipient''s address if the message is sent to members of a mailing list.

To: 
To: pcworks@imagicomm.com
To: faq-maintainers@faqs.org
To: "Gerald E. Boyd" 
To: gboyd@netcom.com

A blank "To:" header is almost always a sure sign of spam. Many of the spam e-mail programs leave the "To:" field blank (or use a bogus address) and include all the persons to be "spammed" on the "Bcc:" line.

The formats allowed are:

• "Gerald E. Boyd"  [quotes if names contain special characters]
• Gerald Boyd  [names and address]
• [address in carets]
• gboyd@netcom.com [address only]

X-headers The "X-" prefix is used to create custom headers that are legal under RFC2822 but are non-standard and provided for information only. Conversely, any non-standard informative header should be given a name starting with "X-".

X-Envelope-From: steveha@NET-SERVICES.COMPULINK.CO.UK

X-Apparently-From: and X-Apparently-To: Added by eGroups (now Yahoo groups) to postings in an attempt to identify the mailing list group the message belongs to and also to identify the sender. AOL and Yahoo among others also add the X-Apparently-From: header.

X-Confirm-Reading-To: Pegasus Mail was the first e-mail program to use this non-standard directed confirmation header field. "The Bat!" mail client and Exim MTA system filter also support this header. This header requests an automated confirmation notice when the message is received or read. Typically it is ignored by almost all e-mail programs including Pegasus mail.

The reason for this is that the old confirmation header field X-pmrqc: was implemented and most Pegasus mail versions respond to it as best as they can.

X-pmrqc: 1

The RFC standard header for automated confimation is "Disposition-Notification-To" (RFC2298). Outlook, Netscape and Eudora and most MIME aware e-mail programs use this.

X-Distribution: Pegasus Mail now adds one of three new headers to messages it sends when more than 50 recipients are present in the message. These headers can be used as filtering triggers to delete such messages. The headers are based on the number of recipients, and are as follows:

• 0-50 recipients - no added header
• 50-499 recipients - "X-Distribution: Moderate"
• 500-4999 recipients - "X-Distribution: Bulk"
• 5000+ recipients - "X-Distribution: Mass"

X-Envelope-To: added by sendmail version 8 to specify the actual recipient when using a multidrop mailbox (multiple users in a virtual domain that go to a single mailbox).

X-Errors-To: Like Errors-To: this header specifies an address for errors to be sent to. It is rarely seen except for some ftpmail servers and News mailing services.

X-Errors-To: usenet@LITech.NET
X-Errors-To: sr1@inf.tu-dresden.de

X-Mailer: (also X-mailer:) A freeform header field intended for the e-mail software to identify itself. Most Windows e-mail clients identify the e-mail program, version number, and other information.

X-Mailer: The Bat! (v1.38e) S/N A1D26E39 / Educational
X-Mailer: The Bat! (v1.023) S/N 26756776
X-Mailer: FEddy 1.3
X-Mailer: Juno 2.0.11
X-Mailer: Mutt 0.91.1i
X-Mailer: Mozilla 3.01 Gold (Win16; I)
X-Mailer: Mozilla 4.05 [en] (Win95; I)
X-Mailer: Mozilla 4.05 [de]C-QXW03103 (WinNT; I)
X-Mailer: Mozilla 4.5 (Macintosh; U; PPC)
X-Mailer: Pegasus Mail v3.40 (NDS)
X-Mailer: Pegasus Mail for Windows (v2.53/R1)
X-Mailer: Pegasus Mail for Win32 (v3.12b)
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
X-Mailer: Microsoft Outlook Express 4.72.3007.0
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
X-Mailer: Microsoft Mail V3.0

X-MIME-Autoconverted: This is handled by LISTSERV mailing list program. Starting with version 1.8d of LISTSERV, if you include 8-bit characters (e.g., accented or national language characters) in templates, LISTSERV will automatically encode the templates on-the-fly in MIME quoted-printable encoding. While there is no guarantee that every mail program will be able to properly display 8-bit characters, those mail programs that understand MIME quoted-printable encoding should have no trouble doing so.

Sendmail also converts from 8bit to Base64 or quoted-printable (depending on which is shorter for the particular message) and inserts this line in the header if the receiving MTA doesn''t specify 8BITMIME according to "SMTP Service Extension for 8bit-MIMEtransport" RFC1652 in the reply to EHLO command of SMTP or ESMTP protocols.

X-MIME-Autoconverted: from quoted-printable to 8bit by listserv.ops.aol.com id PAA01630
X-MIME-Autoconverted: from quoted-printable to 8bit by listserv.aol.com id RAA07
X-MIME-Autoconverted: from 8bit to quoted-printable by cygnus.com id LAB09233
X-MIME-Autoconverted: from quoted-printable to 8bit by lista.sulinet.hu id SAA01538

X-PMFLAGS: Pegasus Mail adds this header to any message sent. The number after the keyword is a hexadecimal number and contains information about whether the mail was already read, the color the mail is displayed, whether this mail has been answered and other items.

X-PMFLAGS: 34078848 0
X-PMFLAGS: 33554560 0
X-PMFLAGS: 34078848 0
X-PMFLAGS: 570949760 0

X-Priority: Used mainly by Eudora to assign a priority (which appears as a graphical notation on the message) to incoming and outgoing messages. There are five priority levels available, 1 being the highest, 5 being the lowest. Priority 3 is Normal.

X-Priority: 3 (Normal)

X-Sender: This header is used by Eudora and Pine to identify the sender with greater reliability than the "From:" header.

X-Sender: gboyd@netcom.com
From: "Gerald E. Boyd" 

When the senders SMTP or POP3 server address differs from the actual server used to send the e-mail. Eudora adds an "(Unverified)" to the senders e-mail address.

X-Sender: gboyd@netcom.com (Unverified)

UNIX Pine always adds this when you send e-mail from a virtual domain. It shows the actual SMTP server address that e-mail was sent from as compared with the users actual e-mail address.

From: "Gerald E. Boyd" 
X-Sender: gboyd@no2.superb.net

X-UIDL: The X-UIDL header is standard with POP3 mail servers and clients. It''s defined in RFC1725. But it''s not an RFC2822 standard header, therefore, it''s still an "X" header.

The X-UIDL header is added by the POP3 mail server to give it a unique message ID. This unique identifier is used by the POP3 protocol for retrieving mail from a POP3 mail server. The field is added at your location just before you recieve the message. It''s not from the sender. Valid ones have exactly 32 hexadecimal characters. They are generated by an algorithm involving the date and time to arrive at a unique ID.

X-UIDL: 46b42c1a4222b127e2eec3046603285c
X-UIDL: e3a131b31956ffc5606e25f1dc6e3444

Different "X-" and other headers I''ve seen

Additional Interesting Articles

t-SQL Cursor
C# Needle In Haystack String Replacements
SQL Create Procedure
Creating Reports in SSRS, SSIS, and SQL
Block File Leechers Using PHP
SQL Check Existence of Table or Temp Table

©2008 AndrewKimball.com