RFC service headers. Mail message structure
An email message usually consists of two parts:
header(header), containing service information that controls the delivery and processing of the message;
body(body), containing directly the user message: text and attached data (graphics, sound files, etc.).
the headline of the message
The mail message is plain text in ASCII format. Therefore, the message header is a sequence of text lines like:
The mail message standard provides a large number of fields. Some of them are mandatory, i.e. Without them, it is impossible to carry out the correct delivery of messages, and some are optional. The most commonly used fields are listed below.
Message-ID– unique message identifier. The uniqueness of the value of this field is guaranteed by the software of the sending node, so it is generated automatically.
Date– “Date” field. Contains the date the message was sent. The field value is set automatically by the email client when sending a message.
From– “From” field. Contains the address that the message sender specifies as the originating address.
Sender– “Sender” field. Contains the address from which the message was actually sent. This field may not be in the header if the From field contains the actual sender's address.
To– “To” field. Contains the address of the primary recipient of the message.
Cc– “Copy” field. Contains the addresses of additional message recipients.
Bcc– “Blind carbon copy” field. Contains the addresses of additional message recipients. Recipients listed in the "To" and "Cc" fields will not know that recipients in the "Bcc" list received a copy of the message.
Reply-to– “Reply” field. Contains the address to which the recipient should send a response. This field is optional: if it is missing, responses are sent to the address specified in the "From" field.
Subject– “Message Subject” field. This field usually contains a brief description (subject) of the message.
Message body
It was originally intended that mail messages could only contain ASCII text. And since the ability to transmit non-text information was not provided, email transmission protocols may not process such messages correctly. In this regard, at one time a special standard was developed that defined the principles for converting non-text data to text form. This standard is called MIME(Multipurpose Internet Mail Extension, multi-purpose Internet mail extension).
MIME assumes that the following types of information can be carried in the body of a message:
text – plain text in ASCII format, as well as text in RTF or HTML format;
graphic images – files in JPEG and GIF format;
audio and video data;
data in the formats of various applications, for example, Microsoft Office documents, as well as data in any format (including various executable files).
One email message can contain different types of data. Such messages are a structure with a general header and several blocks within the body, each of which contains information of its own type.
This is widely used when sending messages with investments(attachments) – additional “attached” files that may contain various information. For example, you can attach a graphic file with a photo of the sender to a text message.
In addition, this can be useful when the message text needs to be transmitted in different formats. For example, a sent message in HTML format containing some design may not be correctly perceived by the recipient's client program. To avoid such problems, the sender's email client can generate an alternative representation of the message in plain text.
To ensure correct transmission of messages with non-text data in MIME, two transcoding algorithms are provided that convert such data to a test form:
the "Quoted-printable" algorithm, designed to replace bytes that are not ASCII characters with a group of three bytes representing only standard characters;
the "Base64" algorithm, which converts three arbitrary bytes into four ASCII characters.
To ensure correct interpretation of data by the MIME standard, additional special fields are introduced into the message header.
Content-type– “Content type” field. Responsible for correctly determining the type of data contained in the message header message. The field value indicates a specific data type, or informs that the body contains several different types of blocks.
Content-Transfer-Encoding– field "Content encoding type". Defines the method of converting (recoding) source data into text form.
According to email messaging standards, emails support certain headers, each of which must be on a new line. By default, the mailer already contains the necessary ones: MIME-Version, Content-Type, From, Reply-To, Subject, To. New entries recorded in the title field RFC email, will be added to the existing ones listed above.
Please note that all mail agents perceive these standards differently. Though and are indicated in official protocols, they can be ignored or misinterpreted, so they should be tested before sending out emails.
Popular RFC letter headers
* - means for example. Cc: (Carbon Copy) * Cc: [email protected]This header is an extension of the "To:" field and specifies additional recipients of the message. There is really no difference between "To:" and "Cc:", except that some email programs treat them differently when generating a response to a message.Bcc: (Blind Carbon Copy) * Bcc: [email protected]
If you see this header in a received message, something is wrong. This header is used in the same way as "Cc:" (see below), but does not appear in the header list. The main idea behind this header is to be able to send copies of an email to people who don't want to receive replies or appear in the headlines. Blind carbon copies are very popular among spammers, as many inexperienced users find themselves confused when they receive an email that does not appear to be addressed to them.List-Unsubscribe: * List-Unsubscribe:
According to the described functionality, the field should automatically unsubscribe the user if he clicked on the “SPAM” button, but often a separate “Unsubscribe” button is displayed under this field. The header is not perceived by all email programs, because... This is a great opportunity to check email addresses for use.Priority: (X-MSMail-Priority: Importance:)* Priority: 1
A header that specifies the priority of the message. Sometimes specified as X-Priority:, X-MSMail-Priority:, Importance:, takes the values "Higt", "Normal", "Urgent", "Non-urgent" or for X-Priority "1", "3", "5". Most programs ignore it. Often used by spammers to attract attention to a message by setting 1.Comments: * Comments: I love books
This header is not standard and can contain any information. Such headers are added by some email programs (in particular, the popular Pegasus program) to identify the sender, but they are often added manually by spammers, so they should be treated with caution.Organization: * Organization: OJSC Kostoprav
A completely free header, usually containing the name of the organization through which the sender of the message gains access to the network. The sender usually controls this title, so it might well say something like "The Royal Society of Putting One Over Another."Precedence: * Precedence: bulk
Values: "bulk", "junk", "list". Indicates whether the letter belongs to a mass mailing. Synonyms X-List:*, X-Mirror:*, X-Auto:*, X-Mailing-List:*.List-Owner: *List-Owner:
Email address of the mass mailing organizer.X-Mailer: * X-Mailer: ePochta Mailer Disposition-Notification-To: * Disposition-Notification-To: [email protected]
A read receipt will be sent to the specified details. Often ignored by mailers in order to combat spam. Synonyms: X-Confirm-Reading-To:, Return-Receipt-To:X-*** * X-List:, X-Mailer:, X-...
As RFC standards say, headers starting with X are the own headers of individual mail programs that are informative in nature. But some are widely accepted, such as X-Mailer. Nothing but additional information in the email code...
The information provided above is for informational purposes only. This does not mean that specifying any header will necessarily be carried out by every mail program. More information about headers can be found at
However, few people pay attention to message headers. Some of them that users see constantly when reading email are lines starting with To:, From: and Subject:. However, the headers contain not only friendly mailer prompts, but also other, very meaningful information. The headers can tell you the name and version number of your email client, as well as the type of operating system, the name and version number of the mail server, internal IP addresses, and the type of firewall your organization uses (if any).
Therefore, it makes sense to take a closer look at email message headers to better understand why they are needed, what information they may contain, and why firewalls sometimes remove some data from them.
STANDARDS
Email headers, like all Internet components, must conform to standards, in this case RFC 822. A separate standard, RFC 821, defines the "envelope" format and describes mail transmission protocols, but that is beyond the scope of this article. RFC 822 was proposed to replace an earlier standard (RFC 733) to enable the transfer of email messages between different networks. The headers discussed in this article are required to forward any email message over the Internet or between two internal email servers if they use standard TCP/IP protocols. These concepts are explained in Figure 1.
Your email program may allow you to view message headers. For example, in the case of Outlook, by selecting the Show Fields submenu from the View menu, you will see a dialog box with the names of some of the possible fields that can appear in email messages.
Each header begins with a field name, always followed by a colon and a space, such as To: or Received:. Long header lines are “collapsed,” or represented as multiple lines, with each additional line starting with at least one space. In Figure 1, the first header field is Received:, which actually spans three lines, followed by another three-line Received: field.
Some of the field names, such as Date:, To:, Subject: and From:, are self-explanatory. For example, after the From: field name there is a return address, and after To: there is the recipient's address. The SMTP protocol (RFC 821) does not require that the address placed in the From: field accurately represent the sender. SMTP has no real means of verifying that the sender is using their own address, although most mail servers will at least check that the sender's domain exists. The lack of control makes it easier to falsify the addresses of message senders, which is typical, in particular, for spam.
RECIPIENTS
From the point of view of obtaining real information about the sender of an email message, the Received: headers are significantly more interesting than the From: headers, which are easily falsified. Generally speaking, any header line can be forged to some extent, since headers are only text data, and only those generated by trusted servers can be considered reliable. Received headers: are added by each mail server that relayed a given message, with the most recent mail server in the chain in the first position and the first server that relayed the message in the last position. In Figure 1, the first Received: header indicates that the bear.spirit.com server has received a message for the recipient [email protected] from node 0nus.l0pht.com.
The first heading provides other interesting information. Data in parentheses, such as (0nus.l0pht.com), is accepted as comments by compatible mail servers. In this case, the sendmail program is on the bear.spirit node. com verified that the sender's system actually has the name 0nus.l0pht.com and the IP address 199.201.145.3. Reviewing the TCP/IP connection parameters allowed sendmail to determine the IP address, and then a DNS lookup revealed the server's domain name.
The second Received: header is more interesting. Note that the message was received from , i.e. the absolute IP address of the 0nus system is indicated, and it is also shown as 199.201.145.3. According to RFC 1918, IP addresses starting with 172.16 are reserved for private networks, so they are not intended for transmission over the Internet and may be repeated. In our example, the Received: header indicates that 0nus is acting as a firewall for the l0pht domain (or part of it) and performing Network Address Translation (NAT). At the same time, this Received: header informs that the 0nus domain is running Postfix, a new mail server that Wietse Venema has developed to ensure the highest possible level of security.
In the example in Figure 1, the message contains only two Received: headers. Sometimes there are many more, and these headers can reveal other internal network addresses and mail server names, as well as internal server names. The importance of Received: lines is also that they help identify instances of looping, where one mail server forwards a message to another, which in turn sends it back again, creating a loop. On the other hand, the lines in the Received: field also contain a lot of data that may be of interest to an external attacker.
By now, based on the information in the Received: headers, we have identified two mail servers: sendmail and Postfix. Other Unix mail servers, as well as Microsoft Exchange and Lotus Notes, also leave marks in the Received: headers.
There is a certain degree of probability that 0nus.l0pht.com is a firewall for the l0pht domain. In some cases, you can not only guess, but also accurately determine the presence of a firewall. Sometimes it will be called "firewall", "eagle", "fw1" or some other easily recognizable name, which will be reflected in the Received: headers. Some firewalls, such as those from Interlock, explicitly announce their presence by adding a comment to the Received: line. Other vendor's firewalls put a much less descriptive line in this field, indicating that "private information has been removed." However, since only this vendor uses this specific comment, the presence of its firewall becomes almost as obvious as the Interlock firewall.
DISAPPEARING HEADLINES
Received headers: are designed to analyze email delivery problems. Removing these headers is not considered a sign of good form on the Internet, but some firewalls still remove them at the request of the administrator. I think removing such headers from messages leaving your organization is a reasonable action: if you are responsible for email problems within your organization, then you are unlikely to want to give outsiders the ability to analyze the structure of your email system (and network). Not all firewalls allow this yet. (As a rule, only firewalls with application gateways are smart enough to handle this type of operation correctly.)
RFC 822 requires Received: headers in a message, so removing them may be considered a violation of the Internet standard. In private email correspondence with support staff at the sendmail.org Web site, a consultant recommended this method of selectively removing Received headers: Modifying sendmail and creating a configuration file that contains the server addresses to be removed. At the same time, the sendmail support team recognized such a modification as contrary to the spirit of the RFC standard and recommended hiding private data in the headers by replacing them with hashed records.
THAT'S NOT ALL
Some of the known attacks were made possible by exploiting header parsing errors. Most recently, Microsoft released a patch for the inetcomm.dll module that Outlook and Outlook Express access to analyze, among other things, the Date: header. Date field overflow: These email programs have experienced crashes or even arbitrary code execution (if the transferred data used a buffer overflow).
How can you find out which program a given user is working with: Outlook, Outlook Express or some other? Look at the x-mailer: header. In the case shown in Figure 1, the sender, Jolly, was using the Claris Emailer client, which also suggests that he was running on a Macintosh computer (the Claris application suite is only available for the Macintosh).
Internet mail, like much of its content, was not designed to fend off internal attacks. For many years, the Internet has been a means of communication for enthusiasts, connecting computers based on common protocols defined by RFC standards. Security and the original purpose of the Internet - providing interconnection - are in conflict with each other.
Encryption and digital signature tools for email, such as PGP (Pretty Good Privacy), do not solve the problem, since they only ensure the confidentiality of email messages and authenticate the sender. To prevent the abuses we face today, email standards must change radically. But now the headers of your organization's outgoing email can be filtered to remove internal information that could be used by an outside attacker.
Rick Farrow is an independent security consultant. He can be contacted at: [email protected].
Internet resources
The Internet standard for email headers is published at: http://www.faqs.org/rfcs/rfc822.html .
Wietse Venema's Postfix mail server is located on the page http://www.porcupine.org/postfixmirror/start.html .
Microsoft's guidance regarding errors in the inetcomm.dll module for parsing a number of mail message headers can be found at: http://www.microsoft.com/technet/security/bulletin/ms00-043.asp .
Helpful tips on using sendmail for masquerading (rewriting message headers so that they all contain the domain address rather than the addresses of your domain's internal systems) can be found at:
Technical Headings
According to email messaging standards, emails support certain headers, each of which must be on a new line. By default, the necessary ones are already specified: MIME-Version, Content-Type, From, Reply-To, Subject, To. New ones recorded in the header field will be added to the existing ones listed above.
All mail agents perceive these standards differently. Although these email headers and are specified in the official RFC protocols, they can be ignored or misinterpreted, so you should test them on yourself before sending out emails.
Popular RFC letter headers
Cc: (Carbon Copy) * Cc: [email protected]This header is an extension of the "To:" field and specifies additional recipients of the message. There is really no difference between "To:" and "Cc:", except that some email programs treat them differently when generating a response to a message.Bcc: (Blind Carbon Copy) * Bcc: [email protected]
If you see this header in a received message, something is wrong. This header is used in the same way as "Cc:" (see below), but does not appear in the header list. The main idea behind this header is to be able to send copies of an email to people who don't want to receive replies or appear in the headlines. Blind carbon copies are very popular among spammers, as many inexperienced users find themselves confused when they receive an email that does not appear to be addressed to them.Comments: * Comments: I love books
This header is not standard and can contain any information. Such headers are added by some email programs (in particular, the popular Pegasus program) to identify the sender, but they are often added manually by spammers, so they should be treated with caution.Organization: * Organization: OJSC Kostoprav
A completely free header, usually containing the name of the organization through which the sender of the message gains access to the network. The sender usually controls this title, so it might well say something like "The Royal Society of Putting One Over Another."Priority: (X-MSMail-Priority: Importance:)* Priority: 1
A header that specifies the priority of the message. Sometimes specified as X-Priority:, X-MSMail-Priority:, Importance:, takes the values "Higt", "Normal", "Urgent", "Non-urgent" or for X-Priority "1", "3", "5". Most programs ignore it. Often used by spammers to attract attention to a message by setting 1.Precedence: * Precedence: bulk
Values: "bulk", "junk", "list". Indicates whether the letter belongs to a mass mailing. Synonyms X-List:*, X-Mirror:*, X-Auto:*, X-Mailing-List:*.List-Owner: *List-Owner:
Email address of the mass mailing organizer.X-Mailer: * X-Mailer: ePochta Mailer Disposition-Notification-To: * Disposition-Notification-To: [email protected]
A read receipt will be sent to the specified details. Often ignored by mailers in order to combat spam. Synonyms: X-Confirm-Reading-To:, Return-Receipt-To:List-Unsubscribe: * List-Unsubscribe:
According to the described functionality, the field should automatically unsubscribe the user if he clicked on the “SPAM” button, but often a separate “Unsubscribe” button is displayed under this field. The header is not perceived by all email programs, because... This is a great opportunity to check email addresses for use.X-*** * X-List:, X-Mailer:, X-...
As RFC standards say, headers starting with X are the own headers of individual mail programs that are informative in nature. But some are widely accepted, such as X-Mailer. Nothing but additional information in the email code...
The information provided above is for informational purposes only. This does not mean that specifying any header will necessarily be carried out by every mail program. More information about headers can be found at
The Internet email message header provides a list of technical information about the message, such as who sent it, created it and what email servers it passed through on its way to the recipient's software. In most cases, only the administrator needs to view the Internet headers for the message. If you want to add a subject line to your email message, see Apply a theme, background color, or letterhead color to your email messages.
Viewing Internet Message Headers
In Outlook for Office 365, 2016, 2013, or 2010 on PC
Double-click an email message to open it outside the reading pane.
Select file> properties.
The header information will be displayed in the field Internet Headlines.
Advice: highlight information in this field, press keys Ctrl+C to copy and paste into Notepad or Word to see the entire top one at once.
Contents of Email Message Headers
Let's consider email correspondence between two users: Sergey Zaitsev and Olga Zueva. Sergey's email address - [email protected], Olga's address - [email protected]. Olga uses Microsoft Office Outlook 2007. The Internet header from Olga's letter to Sergey looks like this:
Microsoft Mail Internet Headers Version 2.0Received: from mail.litwareinc.com () by mail.proseware.com with Microsoft SMTPSVC(6.0.3790.0);Wed, 12 Dec 2007 13:39:22 -0800Received: from mail ( RDNS failed) by mail.litware.com with Microsoft SMTPSVC(6.0.3790.0);Wed, 12 Dec 2007 13:38:49 -0800From: "Kelly J. Weadock"
When Olga sends a message to the address [email protected], she creates it on her computer, which is identified as (i101-177.nv.litwareinc.com). The text of the message is transmitted from her computer to the email server mail.litwareinc.com. Olga will no longer see her message - further processing is performed by mail servers without her participation. When Olga's mail server receives a message sent to [email protected], it will contact Proseware's mail server and deliver the message to it. It will be stored on the proseware.com server until Sergey checks his work email.
Interpreting email message headers
Below is a description of the standard email header fields.
Microsoft Mail Internet Headers Version 2.0
This header is added by Outlook.
Received: from mail.litwareinc.com () by mail.proseware.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 12 Dec 2017 13:39:22 -0800
This information indicates that the message was transmitted on Tuesday, December 12, 2017 at 13:39:22 (1: US) Pacific Standard Time (this is 8 hours later than Greenwich Mean Time (GMT); thus "- 0800").
Received: from mail (RDNS failed) by mail.litware.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 12 Dec 2017 13:38:49 -0800
This transmission occurred on Tuesday, December 12, 2017 at 13:38:49 (1:00) Pacific Standard Time (this is 8 hours later than Greenwich Mean Time (UTC); thus “–0800”).
From: "Kelly J. Weadock"
The message was sent by Olga Zueva from the email address [email protected].
To:
Recipient of the message.
CC:
Recipients of copies of the message.
Note: Bcc recipients are not indicated in the header.
Subject: Review of staff assignments
Subject of the email message.
The date and time the email message was sent, based on the sender's computer clock.
MIME-Version: 1.0
The MIME protocol version used by the sender.
Content-Type: multipart/mixed;
Additional MIME header. It is intended for MIME-compatible email programs and specifies what type of content to expect in the message.
X-Mailer: Microsoft Office Outlook, Build 12.0.4210
The message was sent using Microsoft Office Outlook, build version 12.0.4210.
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
The mail program (MIME OLE software) used by the sender.
Thread-Index: AcON3CInEwkfLOQsQGeK8VCv3M+ipA==
This header is used to combine multiple messages into one stream. For example, in Microsoft Outlook, this information can be used in Conversation View to search for messages within a single conversation thread.
Return-Path: [email protected]
Message sender address.
Message-ID:
A number assigned to a message by the mail.litware.com server for identification purposes. This ID will always accompany the message.
A timestamp that is added to a message the first time it passes through the Microsoft Exchange server.
