Simple Mail Transfer Protocol

SMTP (Simple Mail Transfer Protocol)

Family:

Operation area:

Feeding in of e-mails (mail submission), collection of e-mails possibly over several stations (mail transfer)

Ports:

25 / TCP (standard MTA)

465 / TCP (only with SSL / TLS )
587 / TCP (only as MSA / for mail clients , often with STARTTLS )

SMTP in the TCP / IP protocol stack :
application	SMTP
transport	TCP
Internet	IP ( IPv4 , IPv6 )
Network access	Ethernet	Token bus	Token ring	FDDI	...

Default:

RFC 5321

The Simple Mail Transfer Protocol ( SMTP , in German about simple e-mail transport protocol ) is a protocol of the Internet protocol family that is used to exchange e-mails in computer networks . It is primarily used to feed in and forward e-mails. Other specialized protocols such as POP3 or IMAP are used to fetch messages . Traditionally, SMTP servers accept connections on port 25 ("smtp").

Newer servers also use port 587 to receive mails exclusively from authenticated users / servers (" Mail Submission Agent "), whereby the existing clear text connection is usually switched to an encrypted connection using STARTTLS in order to protect the authentication data. A clear separation of internal and external users should prevent configuration problems and thus spam (→ SMTP relay server ). In addition, due to the different ports, a simple firewall rule can be used to block uncontrolled outgoing spam messages from your own network without completely excluding connections to external SMTP servers.

history

The Arpanet's predecessors to SMTP were the Mail Box Protocol ( RFC 278 ) from July 1971 and FTP Mail ( RFC 458 ) from February 1973. With the emergence of the Internet from the ARPANET around 1980, Jon Postel suggested that the dependency of the email Decoupling traffic from the FTP service ( RFC 772 ), and published SMTP under RFC 821 in 1982 . In the early 1980s it became a supplement to UUCP , which was mainly used for the e-mail traffic of periodically connected computers. SMTP became the standard for computers that were constantly connected to the network.

One of the first mail transfer agents to implement SMTP and gain popularity was sendmail . There are now countless programs that support SMTP as a client or server, including widespread SMTP servers such as Postfix , qmail , exim , etc. Since many programming frameworks such as .NET or Java have already built in SMTP classes, development is only with them little effort involved.

SMTP began as a pure ASCII protocol, so that no binary files could be transferred with it. Only standards such as MIME ( Multipurpose Internet Mail Extensions ) created this possibility by encoding the binary files in ASCII.

Procedure

The SMTP process is usually carried out invisibly for the user through his mail program, the so-called Mail User Agent (MUA). This program connects to an SMTP server , the Mail Submission Agent (MSA), which transports the mail to the destination via additional SMTP servers, so-called Mail Transfer Agents (MTA). Since SMTP was conceived as a protocol for the transport of locally created mails between servers, a single server on port 25 ("smtp") originally assumed the role of MSA and MTA. The dedicated port 587 ("submission") was only introduced in 1998 in order to meet the different requirements of both tasks: An MSA only accepts messages from authorized users / servers and prepares them in accordance with the standards before being fed into the mail system. Because of the close relationship between the two services, the functionality of the MSA and MTA is usually still provided by just one program, which then accepts connections on both ports.

protocol

As with all text-based protocols that use TCP, an e-mail can also be sent “manually” via SMTP with the help of a Telnet client. As with other procedures, the sender and recipient addresses can be freely selected. For this reason, the sender information for an email is not reliable . In principle, the addresses in the MAIL FROMand RCPT TOcommands (so-called Envelope-Fromor Envelope-To) can differ from the addresses in the From:and To:mail headers.

The server responds to contacts with three-digit status numbers and short texts that vary or may be omitted. The client must react to the status messages with defined character strings. For example, a simple SMTP session to send an email could look like this:

Client	server	Explanation
telnet mail.example.com 25		Client calls server
	220 service ready	Server reports ready
HELO foobar.example.net		Client gives his name
	250 OK	Server confirmed
MAIL FROM: <sender@example.org>		Client gives sender address
	250 OK	Server confirmed
RCPT TO: <receiver@example.com>		Client names recipient address
	250 OK	Server confirmed
DATA		Client announces the content of the email
	354 start mail input	Server ready for this lengthy process
From: <sender@example.org> To: <receiver@example.com> Subject: Testmail Date: Thu, 26 Oct 2006 13:10:50 +0200 Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. .		Client sends the content of the e-mail and marks the end with a line that contains only one period. (There must be a blank line between the header and the body of the text, otherwise no body of text will be displayed to the recipient.)
	250 OK	Server acknowledges and takes responsibility for the message
QUIT		Client requests disconnection
	221 closing channel	Server announces separation

Status codes

The SMTP protocol provides the following status codes for the status of communication between mail server and mail client:

1XX: Mail server has accepted the request, but has not yet taken action itself. A confirmation message is required.
2XX: Mail server successfully completed the request with no errors.
3XX: Mailserver understood the request, but needs more information to process it.
4XX: Mail server encountered a temporary error. If the request is repeated without any change, processing may be able to complete.
5XX: Mail server has encountered a fatal error. The request cannot be processed.

Extended SMTP

When SMTP was defined in RFC 821 in 1982 , there were a manageable number of hosts on the Internet . Because the connections were slow and unstable, great emphasis was placed on reliability. Authentication was not provided, so each mail server was an open mail relay through which mail could be forwarded to every other node. With the growing popularity of the internet, the problem of spam arose .

In 1995 the protocol was expanded with Extended SMTP (ESMTP) in RFC 1869 (previously in 1993 in RFC 1425 and 1994 in RFC 1651 ). This extension allows further commands (SMTP verbs) to be defined using a modular concept . If the client reports to the server not HELOwith EHLO (Extended HELO) , as shown above , the server informs it in return which protocol extensions it supports. Common examples are STARTTLS (Secure SMTP over TLS ) , 8BITMIME (8bit- MIMEtransport ) , DSN ( Delivery Status Notifications ) and AUTH ( SMTP-Auth ) .

For encryption via SSL / TLS, SMTPS is recommended, which requires its own TCP port. For this purpose, TCP port 465 has been standardized. Alternatively, the STARTTLS command can be used. It runs on the same TCP port as unencrypted SMTP.

Security concepts

feature	definition	Concepts
Access control	Only authorized users are allowed to use the mail server	SMTP-After-POP , SMTP-Auth , SMTPS
Authentication	A clear assignment of the sender↔message is possible	PGP , S / MIME (see electronic signature ), SPF , DomainKeys
integrity	The message cannot be changed unnoticed on its way through the network	PGP , S / MIME
confidentiality	The message is not transmitted in clear text, but encrypted	PGP , S / MIME , SSL / TLS

software

Some of the most commonly used SMTP servers are Sendmail , Exim , Postfix , qmail , MS Exchange , GroupWise , Kerio Connect , Mercury MTS, and IBM Lotus Domino .

Related Requests for Comments (RFCs)

RFC 821 (SIMPLE MAIL TRANSFER PROTOCOL)
RFC 2821 (SIMPLE MAIL TRANSFER PROTOCOL)
RFC 1845 (SMTP Service Extension for Checkpoint / Restart)
RFC 1870 (SMTP Service Extension for Message Size Declaration)
RFC 1869 (SMTP Service Extensions)
RFC 1894 (An Extensible Message Format for Delivery Status Notifications)
RFC 1985 (SMTP Service Extension for Remote Message Queue Starting - ETRN)
RFC 2034 (SMTP Service Extension for Returning Enhanced Error Codes)
RFC 2047 (Message Header Extensions for Non-ASCII Text)
RFC 2487 (SMTP Service Extension for Secure SMTP over TLS)
RFC 2505 (Anti-Spam Recommendations for SMTP MTAs)
RFC 2554 (SMTP Service Extension for Authentication)
RFC 2606 (Reserved Top Level DNS Names)
RFC 2852 (Deliver By SMTP Service Extension)
RFC 2920 (SMTP Service Extension for Command Pipelining)
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)
RFC 3461 (SMTP Service Extension for Delivery Status Notifications (DSNs))
RFC 3463 (Enhanced Status Codes for SMTP)
RFC 3464 (An Extensible Message Format for Delivery Status Notifications)
RFC 3700 (Internet Official Protocol Standards)
RFC 4409 (Message Submission for Mail, introduces port 587 for Message Submission)
RFC 5321 (Simple Mail Transfer Protocol)
RFC 5322 (Internet Message Format)
RFC 5336 (SMTP Extension for Internationalized Email Addresses)
RFC 6409 (Message Submission for Mail, Internet Standard, replaces RFC 4409 )
RFC 6152 (SMTP Service Extension for 8bit-MIMEtransport)
RFC 7505 (A "Null MX" No Service Resource Record for Domains That Accept No Mail)
RFC 8314 (Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access)

Web links

Individual evidence

↑ Chris Newman, Keith Moore: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access. Accessed February 11, 2019 .

[1] Chris Newman, Keith Moore: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access. Accessed February 11, 2019 .