SMTP message transfer
SMTP (Simple Mail Transfer Protocol) is a communication protocol for transferring electronic mail (emails/messages/letters). Today, the extended ESMTP (Extended SMTP) is predominantly used. It is an internet standard described in RFC 5321. An SMTP server typically uses TCP port 25. SMTP is a text-based protocol that uses a connection-oriented communication. The principle involves sending commands (text strings) and corresponding data, and receiving responses.
A mail client (or application server) sends messages using SMTP to a specified mail server (alternatively, it may use a proprietary protocol like Microsoft MAPI for Exchange). For receiving messages, the POP3 or IMAP protocol is commonly used. Mail servers and other Message Transfer Agents (MTAs) use SMTP to send and receive mail messages between each other. Routing is done using set rules or DNS MX (Mail Exchanger) records of the domain.
SMTP envelope
During mail message transfer, the SMTP client and server communicate. The term SMTP Envelope is used for SMTP commands that encapsulate the actual message and ensure its delivery. The main SMTP commands are HELO, MAIL FROM, RCPT TO, DATA.
Mail message header
The actual mail message (email) consists of header fields (The Header Section of the Message) followed by the body. The email format (Internet Message Format - IMF) is described in RFC 5322. The header is a sequence of lines of defined syntax, and the body is a simple sequence of characters separated from the header by a blank line (CRLF). Header fields start with the field name followed by a colon and the field body. The only mandatory header fields are Date: (Origination Date) and From: (Originator Address).
The header may contain Destination Address fields like To:, Cc:, and Bcc:. In the SMTP envelope, the RCPT TO command is always used and must include all recipients (repeated for each one). For the client, it can be distinguished in the header whether it is a direct recipient (To), a carbon copy (Cc), or a blind carbon copy (Bcc), where the server removes the Bcc: line upon delivery.
Some header fields are added by mail servers during message processing (e.g., Received:). Theoretically, they can change any information, although the standard specifies which fields must not be removed or modified and which must be in a specific order.
Analogy to a letter
The whole situation can be compared to sending a letter via traditional mail. We have an envelope on which we write the sender and recipient, and these details are used by the postal service for delivery. Inside the envelope is a sealed letter (which the postal service does not see) that also contains information about the sender and recipient, which may differ from the details on the envelope. The recipient can respond to the details in the letter when replying.
Example of sending a message using SMTP
Below is an example of SMTP communication (transaction), where S stands for Server, and C is the client. The bold text does not belong to the SMTP communication and indicates the respective part (envelope and email, divided into header and body).
SMTP Envelope S: 220 mail.company.com ESMTP C: HELO test.com S: 250-mail.company.com C: MAIL FROM:<user@test.com> S: 250 2.1.0 Sender OK C: RCPT TO:<user@company.com> S: 250 2.1.5 Recipient OK C: DATA S: 354 Start mail input; end with <CRLF>.<CRLF> Message Header C: From: User Test <user@test.com> C: To: User Company <user@company.com> C: Date: Tue, 17 Dec 2019 16:02:43 +0100 C: Subject: Test mail C: Message Body C: Mail text ... C: . SMTP Envelope S: 250 2.6.0 Queued mail for delivery C: QUIT S: 221 2.0.0 Service closing transmission channel
Different sender addresses
For email verification, it can be problematic that a mail message can have multiple sender details.
Message header - Header From
The details used by the mail client are found in the message header and are described in RFC 5322. The most common is the sender's address in the From: field, which should specify the author of the message (who wrote the email). Users typically reply to this address. The behavior can change if there is a Reply-To: field in the header, which is the author's suggestion of the address to reply to (mail clients usually use it for replies).
Another possible header field is Sender:, which specifies the address (mailbox) of the agent responsible for the actual transmission of the message (who sent the email, this address is not replied to). Thus, this address sent the email on behalf of the address listed in From. For example, a mailing service (or a secretary) should be listed as Sender and my address as From. The mail client then often displays to the recipient mailing@service.com on behalf of me@company.com.
SMTP envelope - Envelope From
Another address that may be different is seen by the mail server in the SMTP envelope. This is the Envelope Sender address from the SMTP command MAIL FROM. This address is stored in the header as Return-Path:, described in RFC 5321. In practice, it is intended for server responses, for example, if we have a special address for receiving NDR (Non-Delivery Report - Bounce Message). Commonly, the Return-Path address is the same as From. Spammers exploit the fact that addresses can be different. They then put a spoofed address in the From field, which the recipient considers trustworthy.
Technically, Return-Path serves as information for message tracing (records are inserted into the message by SMTP servers upon receipt of the message and allow tracking how the message traveled; another such header field is Received). It is inserted into the header by the destination mail server (the source system must not send a message containing this header field).
Summary of sender addresses
- Envelope Sender - entered in the SMTP command
MAIL FROM(the domain should also be inHELO/EHLO), typically stored in theReturn-Path:header field, not usually displayed by the mail client, used by the server for sending errors - Header Sender - found in the
From:orSender:header field, displayed by the mail client, not handled by the mail server
There are no comments yet.