Internet protocol suite
| Layer |
Protocols |
| Application |
DNS, TLS/SSL, TFTP, FTP, HTTP, IMAP, IRC, NNTP, POP3, SIP, SMTP, SNMP, SSH, TELNET, BitTorrent, RTP, rlogin, … |
| Transport |
TCP, UDP, DCCP, SCTP, IL, RUDP, … |
| Network |
IP (IPv4, IPv6), ICMP, IGMP, ARP, RARP, … |
| Data link |
Ethernet, Wi-Fi, Token ring, PPP, SLIP, FDDI, ATM, DTM, Frame Relay, SMDS, … |
Simple Mail Transfer Protocol (SMTP) is the de facto standard for e-mail transmissions across the Internet. Formally SMTP is defined in RFC 821 (STD 10) as amended by RFC 1123 (STD 3) chapter 5. The protocol used today is also known as ESMTP and defined in RFC 2821.
|
Contents
- 1 History
- 2 Sample SMTP communications
- 3 SMTP Security and Spamming
- 4 Related Requests For Comments (RFCs)
- 5 See also
- 6 External links
- 6.1 cr.yp.to links
- 6.2 Other links
|
History
SMTP is a relatively simple, text-based protocol, where one or more recipients of a message are specified (and in most cases verified to exist) and then the message text is transferred. It is quite easy to test an SMTP server using the telnet program (see below).
SMTP uses TCP port 25. To determine the SMTP server for a given domain name, the MX (Mail eXchange) DNS record is used, falling back to a simple A record in the case of no MX (not all MTAs (Mail Transfer Agents) support fallback).
SMTP started becoming widely used in the early 1980s. At the time, it was a complement to UUCP (Unix to Unix CoPy) which was better suited to handle e-mail transfers between machines that were intermittently connected. SMTP, on the other hand, works best when both the sending and receiving machines are connected to the network all the time.
The article about sender rewriting contains technical background info about the early SMTP history and source routing before RFC 1123 (1989, obsoleted by RFC 2821).
Sendmail was one of the first (if not the first) mail transfer agents to implement SMTP. As of 2001 there are at least 50 programs that implement SMTP as a client (sender of messages) or a server (receiver of messages). Some other popular SMTP server programs include Postfix, qmail, Novell GroupWise, Exim, Novell NetMail and Microsoft Exchange Server.
Since this protocol started out as purely ASCII text-based, it did not deal well with binary files. Standards such as Multipurpose Internet Mail Extensions MIME were developed to encode binary files for transfer through SMTP. MTAs developed after sendmail also tended to be implemented 8-bit-clean, so that the alternate "just send eight" strategy could be used to transmit arbitrary data via SMTP. Non-8-bit-clean MTAs today tend to support the 8BITMIME extension, permitting binary files to be transmitted almost as easily as plain text.
SMTP is a "push" protocol that does not allow one to "pull" messages from a remote server on demand. To do this a mail client must use POP3 or IMAP. Another SMTP server can trigger a delivery in SMTP using ETRN.
Developers
Many people edited or contributed to the core SMTP specifications, among them Jon Postel, Eric Allman, Dave Crocker, Ned Freed, Randall Gellens, John Klensin, and Keith Moore.
Sample SMTP communications
After establishing a connection between the sender (the client) and the receiver (the server), the following is a legal SMTP session. In the following conversation, everything sent by the client is prefaced with C: and everything sent by the server is prefaced with S:. On most computer systems, a connection can be established using the telnet command on the client machine, for example.
telnet www.example.com 25
which opens a TCP connection from the sending machine to the MTA listening on port 25 on host www.example.com.
S: 220 www.example.com ESMTP Postfix
C: HELO mydomain.com
S: 250 Hello mydomain.com
C: MAIL FROM:<sender@mydomain.com>
S: 250 Ok
C: RCPT TO:<friend@example.com>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: Subject: test message
C: From: sender@mydomain.com
C: To: friend@example.com
C:
C: Hello,
C: This is a test.
C: Goodbye.
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye
Although optional and not shown above, nearly all clients ask the server which SMTP extensions the server supports, by using the EHLO greeting to invoke Extended SMTP (ESMTP). These clients use HELO only if the server does not respond to EHLO.
Contemporary clients will use the ESMTP extension keyword SIZE to inquire of the server the maximum message size that will be accepted. Older clients and servers will try to transfer huge messages that will be rejected after wasting the network resources, including a lot of connect time to dialup ISPs that are paid by the minute.
For the edit planning of giant files or sending with older clients, users can manually determine in advance the maximum size accepted by ESMTP servers. The user telnets as above, but substitutes "EHLO mydomain.com" for the HELO command line.
S: 220-serverdomain.com ESMTP {postfix version and date}
S: 220 NO UCE. {etc., terms of service}
C: EHLO mydomain.com
S: 250-serverdomain.com Hello mydomain.com [127.0.0.1]
S: 250-SIZE 14680064
S: 250-PIPELINING
S: 250 HELP
This serverdomain.com declares that it will accept a fixed maximum message size no larger than 14,680,064 octets (8-bit bytes). Depending on the server's actual resource usage, it may be currently unable to accept a message this large.
In the simplest case, an ESMTP server will declare a maximum SIZE with only the EHLO user interaction. If no number appears after the SIZE keyword, or if the current message limit must exactly determined, the user can further interact by simulating the ESMTP header of a message with an estimated size. See External Link RFC 1870 below.
SMTP Security and Spamming
One of the limitations of the original SMTP is that it has no facility for authentication of senders. Therefore the SMTP-AUTH extension was defined. However, the impracticalities of widespread SMTP-AUTH implementation and management means that E-mail spamming is not and cannot be addressed by it.
Modifying SMTP extensively, or replacing it completely, is not believed to be practical, due to the network effects of the huge installed base of SMTP. Internet Mail 2000 is one such proposal for replacement.
Spam is enabled by several factors, including vendors implementing broken MTAs (that do not adhere to standards, and therefore make it difficult for other MTAs to enforce standards), the insecurities of Microsoft Windows (when combined with always-on broadband connections) that allow spammers to remotely control end-user PCs and cause them to send spam, and a regrettable lack of "intelligence" in many MTAs still a major problem.
For example, spam can be greatly reduced by a number of simple checks that, unfortunately, few MTA vendors bother to implement:
- Refusing connections from hosts that begin transmission prior to presentation of the receiving host's HELO banner
- Refusing connections from hosts that give an invalid HELO - for example, a HELO that is not an FQDN or is an IP address not surrounded by square brackets
Invalid HELO localhost
Invalid HELO 127.0.0.1
Invalid HELO domain.tld
Valid HELO [127.0.0.1]
- Refusing connections from hosts that give an obviously fraudulent HELO - for example, issuing a HELO using the FQDN or an IP address that doesn't match the IP of the connecting host
Fraudulent HELO friend
Fraudulent HELO -232975332
- Refusing to accept E-Mail claiming to be from a hosted Domain when the sending host has not authenticated
All of these examples are simple checks, all conform to existing standards and RFCs, and all are missing from most commercial MTA implementations available today.
There are a number of proposals for sideband protocols that will assist SMTP operation. The Anti-Spam Research Group of the IRTF is working on a number of E-mail authentication and other proposals for providing simple source authentication that is flexible, lightweight, and scalable. Recent IETF activities include MARID (2004) leading to two approved IETF experiments in 2005, and DKIM in 2006.
Related Requests For Comments (RFCs)
- RFC 1870 SMTP Service Extension for Message Size Declaration (оbsoletes: RFC 1653)
- RFC 2505 Anti-Spam Recommendations for SMTP MTAs (BCP 30)
- RFC 2554 SMTP Service Extension for Authentication
- RFC 2821 The Simple Mail Transfer Protocol (obsoletes RFC 821 aka STD 10, RFC 974, and RFC 1869)
- RFC 2822 Internet Message Format (obsoletes RFC 822 aka STD 11)
- RFC 2920 SMTP Service Extension for Command Pipelining (STD 60)
- RFC 3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages
- RFC 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security (obsoletes RFC 2487 )
- RFC 3461 SMTP Service Extension for Delivery Status Notifications (obsoletes RFC 1891 )
- RFC 3462 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (obsoletes RFC 1892 )
- RFC 3463 Enhanced Status Codes for SMTP (obsoletes RFC 1893 )
- RFC 3464 An Extensible Message Format for Delivery Status Notifications (obsoletes RFC 1894 )
- RFC 3552 Guidelines for Writing RFC Text on Security Considerations (contains SMTP example)
- RFC 3834 Recommendations for Automatic Responses to Electronic Mail
- RFC 4409 Message Submission for Mail (obsoletes RFC 2476 )
See also
- Bounce messages (SMTP non-delivery reports)
- E-Mail Loop
- E-mail authentication
- SMTP-AUTH (ESMTPA)
- Extended SMTP (ESMTP)
- Ident
- Sender Policy Framework (SPF)
- DNSSEC
External links
- RFC2821 in HTML format
- 2821bis draft (2005)
- 2821 security draft (2005)
- Internet Mail Architecture draft (2005)
- Email Submission Access and Accountability draft (2005)
cr.yp.to links
- The Hash Convention for Mail System Status Codes (HCMSSC)
- Internet mail infrastructure
- SMTP reference manual
- Tools in the war on mail loops
- Variable Envelope Return Paths (VERP)
Other links
- SMTP Sequence Diagram (PDF)
- Diagram of e-mail flow (PDF, PNG )
- Spam SMTP Reply Code: Proposal
- Description of protocol (TXT)
- [1] (MIMEDefang, a Sendmail MILTER)
Category: Internet mail protocols
