Full email header Encryption

Full email header Encryption

This section details all aspects of the email header. It mainly provides users with a theoretical basis for setting up email servers and provides administrators with a real source for discovering spam in case of email spam. Based on the knowledge of the mail header, it helps to discover forged emails. It is also helpful for users who want to know How emails are transmitted over the network.

Although the discussion tries to avoid forging an email, the content in the discussion may be used by malicious readers as the basis for creating forged emails. BecauseArticleFor example, there are several Fictitious Domain Names and randomly assigned IP addresses in this article. These domain names and IP addresses are randomly selected and forged, and have nothing to do with the real domain names and IP addresses on the Internet.

Ii. Email transmission process

This section contains a simple analysis of an email's lifecycle. This is a very important background information for understanding what information the mail header can provide for you.

On the surface, it seems that an email is directly transmitted from the sender's machine to the recipient's address, but this is usually not the case. A typical email must go through at least four computers in its lifecycle.

This is because most enterprises or organizations have a dedicated server called "email server" to process emails, which is generally not the computer on which users read emails. For ISP, a user calls a computer from the home to access the ISP network. Here, the computer in the user's home is called a client, and the computer that the ISP specifically processes the mail is called a mail server. When a user sends an email, he usually edits the email on his computer and sends the email to the ISP's email server. The client has completed its work, and the subsequent work is completed by the ISP's email server. The ISP mail server first finds the IP address of the email server specified by the recipient, and then sends the email to the target server. Now, emails are stored on the recipient's email server, waiting for receiving from the recipient. When the recipient obtains the email sent to him from the receiving email server to his PC, the email is usually deleted.

Suppose there are several fictitious users and. Zhangsan is the dialing user of the ISP 263. Use outook express as the email customerProgramSend and receive emails. Lisi is a fictitious user of the Chinese Emy of sciences. He uses a workstation to connect to the Internet through a LAN.

If Lisi wants to send an email to zhangsan, he edits the email on the workstation (assuming the name is alpha.zky.ac.cn) and the edited letter is sent from the workstation to the mail server mail.zky.ac.cn of the Chinese Emy of sciences. Once a mail is sent to mail.zky.ac.cn, the subsequent mail sending process will be irrelevant to zhangsan. The CAS email server finds that this is a mail sent to a user of 263.net. It communicates with 263 of email servers, such as mail.263.net, and delivers the mail to it. Now the mail is stored on mail.263.net until zhangsan connects to the 263 network by dialing on its own PC to view and receive the mail. Then mail.263.net delivers the stored mail to zhangsan's PC.

In this process, the mail header will be added to the mail three times: added by the mail client program during editing; added by mail.zky.ac.cn when the mail is transmitted to mail.zky.cn; mail.263.net is added when the mail is sent from mail.zky.ac.cn to mail.263.net. Generally, the mail header is not added when the customer receives the mail. Next we will take a closer look at how these mail headers are generated.

When Lisi's email client program edits the mail and sends it to mail.zky.ac.cn, the Mail content is as follows. These content is added by the mail Editor (Outlook Express:

From: lisi@zky.ac.cn (Li Si)

To: zhangsan@263.net

Date: Tue, Mar 18 1997 14:36:14 PST

X-mailer: Outlook Express 5.5

Subject: Lunch?

After an email is sent from mail.zky.ac.cn to mail.263.net, the content of the email changes to (the newly added content is changed from mail.zky.ac.cn ):

Received: From alpha.zky.ac.cn (alpha.zky.ac.cn [124.211.3.11])

Mail.zky.ac.cn (8.8.5) ID 004a21; Tue, Mar 18 1997 14:36:17-0800 (PST)

From: lisi@zky.ac.cn (Li Si)

To: zhangsan@263.net

Date: Tue, Mar 18 1997 14:36:14 PST

Message-ID:

X-mailer: Outlook Express 5.5

Subject: Lunch?

When mail.263.net receives a letter and stores the Message Waiting For zhangsan to receive it, the Mail content changes to (the newly added content is added by mail.263.com ):

Received: From mail.zky.ac.cn (mail.zky.ac.cn [124.211.3.78])

Mail.263.net (8.8.5/8.7.2) with esmtp id laa20869;

Tue, 18 Mar 1997 14:39:24-0800 (PST)

Received: From alpha.zky.ac.cn (alpha.zky.ac.cn [124.211.3.11])

Mail.zky.ac.cn (8.8.5) ID 004a21; Tue, Mar 18 1997 14:36:17-0800 (PST)

From: lisi@zky.ac.cn (Li Si)

To: zhangsan@263.net

Date: Tue, Mar 18 1997 14:36:14 PST

Message-ID:

X-mailer: Outlook Express 5.5

Subject: Lunch?

The content of the last letter is what zhangsan collects and reads. The following is a detailed analysis of the content:

Received: From mail.zky.ac.cn

The preceding content indicates that the email is sent from a server claiming to be mail.zky.ac.cn.

(Mail.zky.ac.cn [124.211.3.78])

This statement indicates that the real name of the server is indeed mail.zky.ac.cn, that is, its self-claimed identity is correct, and its IP address is 24.211.3.78.

By mail.263.net (8.8.5/8.7.2)

The machine that receives the email is mail.263.net. The running mail program is sendmail, and the version is 8.8.5/8.7.2.

With esmtp id laa20869

The server that receives the email has the ID number laa20869 (This number is usually used internally by the email server, but the administrator can search for information about the email in the log file based on this ID number, but usually this number is meaningless ).

For;

This message is sent to the address zhangsan@263.net. You can see that the email header does not have to: related content.

Tue, 18 Mar 1997 14:39:24-0800 (PST)

This email transmission takes place at Tuesday, March 18,199 7, at 14:39:24 (Pacific time, because it is 8 hours later than Greenwich mean time, so it is "-0800 ").

Received: From alpha.zky.ac.cn (alpha.zky.ac.cn [124.211.3.11])

Mail.zky.ac.cn (8.8.5) ID 004a21; Tue, Mar 18 1997 14:36:17-0800 (PST)

This header records the transfer of the email from alpha.zky.ac.cn (Lisi workstation) to mail.zky.ac.cn. The transfer occurred at 14:36:17 Pacific Time. The sender's computer claimed to be alpha.zky.ac.cn. Its real name was indeed alpha.zky.ac.cn, its IP address was 124.211.3.11, and the mail server software was Sendmail v8.8.5. The ID number assigned by mail.zky.ac.cn of the email server is 004a21.

From: lisi@zky.ac.cn (Li Si)

The message is sent by the lis@zky.ac.cn and its name is Li Si.

To: zhangsan@263.net

The mail destination address is: zhangsan@263.net.

Date: Tue, Mar 18 1997 14:36:14 PST

The email editing time is 14:36:14 Pacific Standard Time on Tuesday, March 18,199 7.

Message-ID: mail.zky.ac.cn assigned this number to the email to identify it. It is different from the esmtpid of the SMTP machine in the received ed header. Because this number is always accompanied by the entire email. Other IDs are associated only in the mail Transmission Phase on a specific mail server. Therefore, the ID number of this machine is meaningless to other machines. Sometimes message-ID contains the sender's email address.

X-mailer: Outlook Express 5.5

The message is sent using Outlook Express with the version 5.5.

Subject: Lunch?

Email title.

Email Protocol

This part is more rational than other parts, mainly discussing how emails are transmitted from one point to another. You don't need to understand every sentence, but being familiar with this content helps you understand the problem when mail Transmission encounters strange phenomena. Spam senders often deliberately create strange situations to hide their identities, so it is very useful to understand these strange phenomena to deal with these guys.

To transmit data over the network, the computer network protocol uses an access portal called a port. You can regard a port as a channel through which the computer can listen to network communication to provide services. To listen to multiple communications at the same time, the computer needs to use port numbers to identify multiple different ports to differentiate these communications. The Port Related to email transmission is 25.

Normal

let's discuss the above example again, but this time we only care about the communication process between mail.zky.ac.cn and mail.263.net. First, mail.zky.edu. c opens a connection to port 25 of mail.263.net, and then sends emails through this connection. Of course, there are some management command interaction processes in the mail sending process. Commands in interaction are more or less readable. Commands are stipulated by the SMTP protocol. If you listen for communication between the two, the following content may exist: (the bold part is sent by mail.zky.ac.cn)

220 mail.263.net ESMTP Sendmail 8.8.5/1.4/8.7.2/1.13; Tue, Mar 18 1997

14:38:58-0800 (PST)

Helo mail.zky.ac.cn

250 mail.263.net Hello mail.zky.ac.cn [124.211.3.78], pleased to meet you

Mail from: lisi@zky.ac.cn

250 lisi@zky.ac.cn... sender OK

Rcpt to: zhangsan@263.net

250 zhangsan@263.net... recipient OK

Data

354 enter mail, end with "." on a line by itself

Received: From alpha.zky.ac.cn (alpha.zky.ac.cn [124.211.3.11])

Mail.zky.ac.cn (8.8.5) ID 004a21; Tue, Mar 18 1997 14:36:17-0800 (PST)

From: lisi@zky.ac.cn (R. T. Hood)

To: zhangsan@263.net

Date: Tue, Mar 18 1997 14:36:14 PST

Message-ID:

X-mailer: Outlook Express 5.5

Subject: Lunch?

Do you have time to meet for lunch?

-- Lisi

.

250 laa20869 message accepted for delivery

Quit

221 mail.263.net closing connection

The entire transmission relies on five SMTP core commands (of course, there are some other commands in SMTP, but they are not used to complete real mail Transmission): HELO, mail from, rcpt, data and quit.

The mail sender HELO command is used to identify the sender. Helo mail.zky.ac.cn can be interpreted as "Hi, I am mail.zky.ac.cn ". Of course, the sender may lie here, but there is no mechanism to prevent the sender from saying "hi, I am mail.xxx.com" or "Hi, I am mail.yyy.com ". However, in most cases, the receiver has some methods to confirm the real identity of the sender.

The mail from command marks start mail Transmission, meaning "I have emails sent from someone ", the address followed by this command is the so-called "envelope address" (we will discuss it later). The FROM address of the envelope is not necessarily the address of the sender. This obvious security vulnerability is inevitable (because the recipient does not know the addresses on the sender's machine), but it is a useful feature under specific circumstances.

Rcpt to and mail from complement each other. It specifies the email recipient. An email can be sent to multiple recipients through multiple rcpt to commands. (This feature will be explained in the subsequent email relay section to address some insecure system misuse ). The address followed by this command is called "envelope to" address. It specifies the users to which the mail will be delivered, and the to: Address in the mail does not matter.

The Data command indicates that the actual mail content is transmitted. Any content entered after the data command is considered as part of the email. The format is not limited. A line starting with an English word plus a colon is generally considered as a mail header by the mail program. The line starting with the English ending sign (.) is considered to end the mail content.

The quit command terminates the connection.

The SMTP protocol specification is defined in RFC 821.

Abnormal

The above example is too simple. The preceding example assumes that the email servers of two organizations can directly access each other without going through security devices such as proxies and firewalls. This is often the case in the current Internet environment. However, because security is very important to some organizations and the network or organization may become larger and larger, the situation is not that simple. For mail Transmission with a proxy firewall system, the difference is that there is a record of the forwarding process in the mail header, that is, the mail is first sent from the sender's mail server

Firewall, and then send it from the firewall to the target email server.

Email relay

Relay

Some mail headers with special "life" cycles may be different from the situations discussed earlier:

Received: From unwilling.intermedia.com (unwilling.intermedia.com

[98.134.11.32]) by mail.zky.ac.cn (8.8.5) ID 004b32;

Wed, Jul 30 1997 16:39:50-0800 (PST)

Received: From linuxaid.com.cn ([202.99.11.120]) by unwilling.intermedia.com

(8.6.5/8.5.8) with smtp id laa000041; wed, Jul 30 1997 19:36:28-0500 (EST)

From: anonymous spammer

TO: (Recipient List suppressed)

Message-ID:

X-mailer: massive annoyance

Subject: Want to make alot of money ???

The difference between this email header and the previous one may make you think it is a spam email, but here you suspect that it is the "Received:" header. From the "Received:" header, the email is from linuxaid.com.cn and then transmitted to unwilling.intermedia.com from here, and then transmitted to the final destination address mail.zky.ac.cn again. From the "Received:" header, this is the case, but why does unwilling.intermedia.com appear in the middle? Because it has no direct relationship with the sender and receiver.

To understand the cause, you need to understand the SMTP protocol. Essentially, the transmission process is like this: linuxaid.com.cn connects to the SMTP port of unwilling.intermedia.com. Tell it "Please send this email to the rth@zky.ac.cn. It may be implemented in the most direct way: rcpt to: rth@zky.ac.cn. So far, unwilling.intermedia.com has taken over the handling of this email. Because it is notified to forward the mail to another domain: zky.ac.cn, it finds the mail server for the domain name zky.ac.cn and then forwards the mail to zky.ac.cn. This process is usually called mail relaying ).

There is a historical reason for email relay. It is advantageous to use email relay. By the end of 1980s, many computers on the network did not directly communicate to transmit emails. Instead, the mail is transmitted through the mail Routing Server step by step. This is very troublesome. The sender often needs to manually specify the mail routing server that an email needs to go through. For example, you need to send an email from San Francisco to New York, add the following content to the envelope:

San Francisco, Sacramento, Reno, Salt Lake City, Rock Springs, Laramie,

North Platte, Lincoln, Omaha, Des Moines, Cedar Rapids, Dubuque, Rockford,

Chicago, Gary, Elkhart, Fort Wayne, Toledo, Cleveland, Erie, Elmira,

William sport, Newark, New York City, Greenwich Village, #12 Desolation Row,

Apt. #35, r.a. Zimmermann

This model is very useful for post office staff. At Gary's post office, you only need to know how to communicate with the neighboring Post Office, Chicago, and Elkhart, instead of consuming resources to compute how to send emails to NewYork (it is clear at this time why this mode is so bad for the sender and why this method is discarded ). But this is the process of mail Transmission. Therefore, it was important for the server to have such a relay capability at that time.

Currently, relay is usually used as an immoral advertiser to hide their original addresses and pass complaints to the servers used for relay rather than the ISP technology. Likewise, the mail sending load can be transferred to the relay server through relay, so as to steal the service resources of the relay server. The most important thing here is that the mail content is edited at the sending point linuxaid.com.cn. The intermediate server nwilling.intermedia.com is only involved in the intermediate transmission work and cannot be binding on the sender.

In the above example, we should note that "message-ID:" is not entered by the sender server (linuxaid.com.cn) but by the relay computer (unwilling.intermedia.com. This is a typical feature of the forwarded mail. It reflects the fact that the sending server does not provide a message-id.

Envelope Header

The above discussion about SMTP mentioned the difference between the "message" header and the "envelope" header. The differences and consequences will be discussed in detail here.

Simply put, the "envelope" header is actually generated by the mail server that receives the message, rather than the sender server. According to this definition, the "stored ed:" header is the envelope header, which is usually indicated by "envelope from" and "envelope.

The "envelope from" header is obtained from the mail from command. If the sender's mail server issues the command mailfrom: ideal@linuxaid.com.cn, the recipient server generates an "envelope from" header:> from ideal@linuxaid.com.cn.

Note that a colon-"from" instead of "from:" is missing :". That is to say, there is no colon behind the envelope header. Of course, this Convention is not a standard, but it is worth noting.

"Envelope to" also comes from the rcpt to command. If the sender server issues the command rcpt to: ideal@btamail.net.cn. Then "envelope to" is the ideal@btamail.net.cn. In general, there is actually no such mail header, which is often included in the Received: header.

An important result of envelope information is that the message from: And to: become meaningless. From: The header is provided by the sender, And to: is also provided by the sender. Therefore, the mail is only based on "envelope to" for forwarding routing, rather than based on the message :.

To understand this concept in practice, let's look at the mail Transmission as follows:

Helo galangal.org

250 mail.zky.ac.cn Hello linuxaid.com.cn [202.99.11.120], pleased to meet

You

Mail from: forged-address@galangal.org

250 forged-address@galangal.org... sender OK

Rcpt to: lisi@zky.ac.cn

250 lisi@zky.ac.cn... recipient OK

Data

354 enter mail, end with "." on a line by itself

From: another-forged-address@lemongrass.org

TO: (here your address is concealed to forward and harass confidential emails)

.

250 oaa08757 message accepted for delivery

The corresponding mail header is as follows:

> From forged-address@galangal.org

Received: From galangal.org ([202.99.11.120]) by mail.zky.ac.cn (8.8.5)

...

From: another-forged-address@lemongrass.org

TO: (your address suppressed for stealth mailing and annoyance)

Note that the content of "envelope from" and the content of the message from: and the content of the message to: are specified by the sender, so they are both unreliable. This example illustrates why the envelop from, message from: and message to: may be unreliable in forged emails because they are too easy to forge.

"Received:" header importance

As we can see in the above example, the "Received:" header provides detailed message transmission history, so even if other mail headers are forged, it may be based on "received: "header to get some conclusions about the original source and transfer process of the letter. This section will discuss in detail some issues related to abnormal important message headers, especially how to defeat common forgery technologies.

Undoubtedly, the only important and valuable counterfeit protection in the "Received:" header is the information recorded by the receiving server. As mentioned above, the sender can forge his/her identity (by reporting the wrong identity in the HELO command ). Fortunately, modern mail server programs can detect and correct such errors.

If the real IP address of linuxaid.com.cn on the server is 202.99.11.120 and an email is sent to mail.zky.ac.cn, but the helo galangal.org command is used to forge your identity, the "required ed:" That should be transferred may be as follows:

Received: From galangal.org ([202.99.11.120]) by mail.zky.ac.cn (8.8.8.5)... (other information is omitted for clarity ). Note that although zky.ac.cn does not explicitly state that galangal.org is not the real identity of the sender, it records the correct IP address of the sender. If a receiver deems galangal.org in the message header as a forged identity, he can view the IP address 202.99.11.120 to obtain the correct domain name linuxaid.com.cn, rather than galangal.org. That is to say, record the IP address of the sending server to provide sufficient information to confirm possible forgery.

Many modern email programs actually automate the process of viewing the corresponding domain name based on the IP address. (This viewing process is called reverse DNS resolution ). If mail.zky.ac.cn uses this software, the "Received:" header becomes

Received: From galangal.org (linuxaid.com.cn [202.99.11.120])

Mail.zky.ac.cn...

Here we can clearly see the forgery. The message header clearly states that the IP address of linuxaid.com.cn is 202.99.11.120, But it declares its identity as galangal.org. Such information is very useful for verifying and tracking forged letters. (Therefore, spam senders often do not use the email servers that record the sender's address for spam forwarding. Sometimes they can find servers that do not record senders, but there are very few such servers on the Network)

Another increasingly common trick for counterfeits is to add a spoofed "Spoofed:" header before sending spam. This means that the content of the "Received:" header of the hypothetical email sent from linuxaid.com.cn may be:

Received: From galangal.org ([202.99.11.120]) by mail.zky.ac.cn (8.8.8.5 )...

Partitioned ed: From nowhere by fictitious-site (8.8.3/8.7.2 )...

Stored ed: No information here, go away!

Obviously, the last two lines of content are completely unambiguous and are written by the sender and attached to the email before being sent. Once the email leaves linuxaid.com.cn, the sender has no control over the email. In addition, the new "Received:" header always appears in the header of the message, so the forged "Received:" header always appears at the end of the "Received:" header list. This means that anyone who reads the "Received:" header list from start to end and tracks the mail Transmission history can safely remove content after the first spoofed header. Even if the "Received:" header seems real, it is actually forged.

Of course, the sender may not confuse you with obvious SPAM information. A deliberate counterfeiter may create a seemingly real "Spoofed:" header list as shown below:

Received: From galangal.org ([202.99.11.120]) by mail.zky.ac.cn (8.8.8.5 )...

Received: From lemongrass.org by galangal.org (8.7.3/8.5.1 )...

Received: From graprao.com by lemongrass.org (8.6.4 )...

The only cause of the counterfeit vulnerability is the IP address of galangal.org In the first "Received:" header. If lemongrass.org and graprao.com are entered as the real IP addresses, such forgery is still very difficult to detect. However, the mismatch between the domain name and IP address in the first "Received:" header still exposes that the message is forged, and the email is injected into the network by a server with the network address of 202.99.11.120. However, most email header counterfeits are generally not so tricky. Generally, the added "Spoofed:" header is obviously a fake spam.