Simple Mail Transfer Protocol ( SMTP ) is an Internet standard for electronic mail transmission (email). First defined by RFC 821 in 1982, last updated in 2008 with additional SMTP additions by RFC 5321, which is a widely used protocol today.
Although mail servers and other mail transfer agents use SMTP to send and receive email messages, user-level email client applications typically use only SMTP to send messages to the mail server to forward. To retrieve messages, client applications typically use IMAP or POP3.
SMTP communications between mail servers use TCP port 25. Email clients on the other hand, often send outbound mail to the mail server on port 587. Although it is out of use, email providers sometimes still allow the use of non-standard port 465 for this purpose.
SMTP connection is secured by TLS, known as SMTPS, can be created using STARTTLS.
Although proprietary systems (such as Microsoft Exchange and IBM Notes) and webmail systems (such as Outlook.com, Gmail and Yahoo Mail) use their own non-standard protocols to access mailbox accounts on their own email servers, all use SMTP when sending or receiving email from outside their own system.
Video Simple Mail Transfer Protocol
Histori
Different forms of electronic one-to-one messages were used in the 1960s. People communicate with each other using systems developed for certain mainframe computers. As more and more computers are connected, especially in the US Government ARPANET, standards are developed to allow different system users to email each other. SMTP grew out of these standards developed during the 1970s.
SMTP can trace its roots to two implementations described in 1971: Mailbox Protocol, whose implementation has been debated but addressed in RFC 196 and other RFCs, and the SNDMSG program, which, according to RFC 2235, Ray Tomlinson of BBN was found for TENEX computers for send email messages to the entire ARPANET. Fewer than 50 hosts are connected to ARPANET at this time.
Further implementation included the FTP Mail and Mail Protocol, both from 1973. Development work continued throughout the 1970s, until the ARPANET switched to the modern Internet around 1980. Jon Postel then proposed the Letter Transfer Protocol in 1980 that began removing email dependence on FTP. SMTP was published as RFC 788 in November 1981, also by Postel.
The SMTP standard is developed around the same time as Usenet, a one-to-many communication network with some similarities.
SMTP became widely used in the early 1980s. At that time, it is a complement to Unix to a copy of the Unix Copy Program (UUCP), which is more suitable for handling intermittent intermittent email transfer between machines. SMTP, on the other hand, works best when the sending and receiving machines are connected to the network all the time. Both use save and forward mechanisms and are examples of push technology. Although the Usenet newsgroup is still disseminated with UUCP between servers, UUCP as a mail transport has been lost along with the "bang path" used as the message routing header.
Sendmail, released with 4.1cBSD, right after RFC 788, is one of the first mail transfer agents that implements SMTP. Over time, when BSD Unix became the most popular operating system on the Internet, sendmail became the most common MTA (mail transfer agent). Some other popular SMTP server programs include Postfix, qmail, Novell GroupWise, Exim, Novell NetMail, Microsoft Exchange Server, and Oracle Communications Messaging Server.
Messaging (RFC 2476) and SMTP-AUTH (RFC 2554) were introduced in 1998 and 1999, both illustrating new trends in email delivery. Initially, the SMTP server is usually internal to the organization, receives mail for organizations from outside , and passes messages from the out organization. But over time, SMTP servers (mail transfer agents), in practice, expanded their role to become mail delivery agents for Mail user agents, some of which are now delivering outbound mail from organizations. (For example, a company executive wants to send mail while on the go using the company's SMTP server.) This problem, the consequence of the rapid expansion and popularity of the World Wide Web, means that SMTP must include specific rules and methods for delivering mail and authenticating users to prevent abuse send unsolicited email (spam). The messaging work (RFC 2476) originally started because popular email servers often rewrite letters in an attempt to fix the problems therein, for example, adding a domain name to an unqualified address. This behavior helps when a message is fixed is the initial delivery, but it is dangerous and dangerous when it comes from somewhere else and is being submitted. Splitting emails cleanly into submissions and relays is seen as a way to allow and encourage rewriting submissions while prohibiting rewriting relays. As spam becomes more common, it is also seen as a way to authorize mail sent out of the organization, as well as traceability. The separation of relays and submissions quickly became the basis of modern email security practices.
Since this protocol starts pure ASCII-based text, this protocol does not handle binary files well, or characters in many languages ​​other than English. Standards such as Multipurpose Internet Mail Extensions (MIME) are developed to encode binary files for transfer via SMTP. Mail transfer agents (MTAs) developed after Sendmail also tend to be implemented in 8-bit-clean, so the "only send eight" strategy can be used to transmit arbitrary text data (in 8-bit ASCII-like character encoding) via SMTP. Mojibake is still a problem because different characters manage the mapping between vendors, although the email address itself is still allowed only ASCII. 8-bit-clean MTAs today tend to support 8BITMIME extensions, allowing binary files to be transmitted almost as easily as plain text. Recently the SMTPUTF8 extension was created to support UTF-8 text, allowing international content and addresses in non-Latin scripts like Cyrillic or Chinese.
Many people contribute to the core SMTP specifications, including Jon Postel, Eric Allman, Dave Crocker, Ned Freed, Randall Gellens, John Klensin, and Keith Moore.
Maps Simple Mail Transfer Protocol
Mail processing model
Email sent by email client (mail user agent, MUA) to mail server (mail delivery agent, MSA) using SMTP on TCP port 587. Most mailbox providers still allow delivery on traditional ports 25. MSA sends mail to a mail transfer agent ( mail transfer agent, MTA). Often, these two agents are examples of the same software launched with different options on the same machine. Local processing can be done either on one machine, or shared among multiple machines; mail agent processes on one machine can share files, but if processing is done across multiple machines, they transfer messages between each other using SMTP, where each machine is configured to use the next machine as a smart host. Each process is an MTA (SMTP server) in itself.
The MTA limit uses the Domain name system (DNS) to look up mail exchanger records (MX records) for the recipient domain (part of the email address to the right @ ). MX records contain the target host name. Based on the target host and other factors, MTA chooses an exchange server: see the MX record article. MTA connects to the exchange server as an SMTP client.
Message delivery can occur in a single connection between two MTAs, or in a series of hops via an intermediate system. The recipient SMTP server may be the ultimate destination, an intermediate "relay" (that is, storing and forwarding messages) or "gateway" (that is, it can forward messages using multiple protocols other than SMTP). Each hop is the official responsibility for a message, in which the recipient server must deliver the message or report the failure correctly to do so.
After the last hop receives the incoming message, he hands it over to the mail delivery agent (MDA) for local delivery. MDA stores messages in the relevant mailbox format. As with sending, this reception can be performed using one or more computers, but in the diagram above the MDA is depicted as a box near the mail exchanger box. MDA may send messages directly to storage, or forward them over the network using SMTP or other protocols such as the Local Mail Transfer Protocol (LMTP), a derivative of SMTP designed for this purpose.
Once sent to the local mail server, mail is stored for batch retrieval by an authenticated mail client (MUAs). Mail is retrieved by an end-user application, called an email client, using the Internet Message Access Protocol (IMAP), a protocol that facilitates access to email and manages stored mail, or Post Office Protocol (POP) which typically uses a traditional mailbox mbox file format or proprietary system such as Microsoft Exchange/Outlook or Lotus Notes/Domino. Webmail clients can use either method, but the retrieval protocol is often not a formal standard.
SMTP defines messages transport instead of content messages. Thus, it defines mail envelope and its parameters, such as envelope senders, but not headers (except trace information ) or the body of the message itself. STD 10 and RFCÃ, 5321 define SMTP (envelopes), while STD 11 and RFCÃ, 5322 define messages (header and body), formally referred to as Internet Message Formats.
Protocol overview
SMTP is a connection-oriented text-based protocol in which the sender communicates with the mail recipient by issuing the command string and providing the necessary data through a reliable order data flow channel, usually a Transmission Control Protocol (TCP) connection. The SMTP session consists of commands originating from an SMTP client (an initiation, sender, or transmitter agent) and the appropriate response from the SMTP server (listening agent, or recipient) so that the session is opened, and session parameters are exchanged. Sessions may include zero or more SMTP transactions. The SMTP transaction consists of three command/reply sequences:
- MAIL command, to set the return address, also called return path, return path, bounce address, mfrom, or envelope sender. The
- RCPT command, to specify message recipients. This command can be issued multiple times, one for each recipient. This address is also part of the envelope.
- DATA to mark the start of the message text ; message content, as opposed to the envelope. It consists of a message header and message body separated by a blank line. DATA is actually a group of commands, and the server replied twice: once to the DATA command itself, to acknowledge that it was ready to accept the text, and the second after the end-data sequence, to accept or reject the whole message.
In addition to the intermediate answer for DATA, each server reply can be either positive (2xx reply code) or negative. Negative answers can be permanent (5xx code) or temporary (code 4xx). A deny is a permanent failure and the client must send a bounce message to the server it receives. A drop is a positive response followed by a discard message rather than a delivery.
The initiate host, the SMTP client, can be an end-user mail client, functionally identified as an email user agent (MUA), or a relay mail server relay agent (MTA), an SMTP server that acts as an SMTP client, in a relevant session, for send an email. The SMTP server is capable of fully maintaining the message queue to try transmitting messages that result in a temporary failure.
A MUA knows the outgoing mail server SMTP server of its configuration. The relay server usually determines which servers are connected by searching the DNS MX (Mail eXchange) records records for each recipient domain name. If no MX records are found, the conforment conformant server (not all of them) will search for records A. Relay servers can also be configured to use smart hosts. A relay server initiates a TCP connection to the server on the "famous port" for SMTP: port 25, or to connect to MSA, port 587. The main difference between MTA and MSA is that connecting to an MSA requires SMTP Authentication.
SMTP vs. retrieval
SMTP is the only shipping protocol. In normal use, email is "pushed" to the destination mail server (or next hop email server) once it is received. Mail is routed based on the destination server, not the individual user addressed. Other protocols, such as the Post Office Protocol (POP) and Internet Message Access Protocol (IMAP) are specifically designed for use by individual users who take messages and manage mailboxes. To allow an intermittently connected mail server to pull messages from a remote server when requested, SMTP has the feature to start processing email queues on a remote server (see Remote Message Queue below). POP and IMAP are unsuitable protocols for relaying emails with intermittently connected computers; they are designed to operate after the final delivery, when important information for the correct operation of the mail relay ("mail envelope") has been removed.
Remote Message Queue
Remote Message Queue Starting is an SMTP feature that allows the remote host to start processing mail queues on the server so it can receive messages destined for it by sending the TURN command. However this feature is considered unsafe and extended in RFC 1985 with the ETRN command that operates safer using authentication methods based on Domain Name System information.
On-Demand Mail Relay
On-Demand Mail Relay ( ODMR ) is a standardized SMTP standard in RFC 2645 that allows intermittent intermittent SMTP servers to receive queued emails when connected.
Internationalization
Users whose original manuscripts are not Latin-based, or who use diacritics not in the ASCII character set have difficulties with the requirements of a Latin email address. RFC 6531 was created to solve the problem, providing internationalization features for SMTP, SMTPUTF8 extensions and support for multi-byte and non-ASCII characters in email addresses, such as diacritics and other language characters such as Greek and Chinese.
Current support is limited, but there is a strong interest in the widespread adoption of RFC 6531 and related RFCs in countries such as China which have a large user base where Latin (ASCII) are foreign scripts.
Outgoing SMTP server
An email client needs to know the IP address of the initial SMTP server and this should be provided as part of its configuration (usually given as DNS name). This server will send outgoing messages on behalf of the user.
Outgoing mail server restrictions
The server administrator needs to implement a control that the client can use to use the server. This allows them to handle abuse, such as spam. Two solutions have been commonly used:
- In the past, many systems imposed restrictions on use by the client's location , allowing only use by clients whose IP address is one that is controlled by the server administrator. Use of other client IP addresses is not allowed.
- Modern SMTP servers typically offer alternative systems that require client authentication based on credentials before allowing access.
Restrict access by location
Under this system, the ISP SMTP server will not allow access by users outside of the ISP's network. More precisely, the server only allows access to users with IP addresses provided by the ISP, which is equivalent to requiring them to connect to the Internet using the same ISP. Mobile users may often be on a network other than their normal ISP, and will then discover that sending emails fails because configured SMTP server options are no longer accessible.
This system has several variations. For example, an organization's SMTP server can only provide services to users on the same network, enforcing this with a firewall to block access by users on the wider Internet. Or the server can perform a range check on the client's IP address. This method is typically used by companies and institutions such as universities that provide SMTP servers for outgoing mail only for internal use within the organization. However, most of these agencies now use client authentication methods, as described below.
Where the user is a mobile phone, and can use different ISPs to connect to the internet, this type of usage restriction is burdensome, and changing the email address of the configured email SMTP is not practical. It is desirable to be able to use the email client configuration information that does not need to be changed.
Client authentication
Modern SMTP servers typically require client authentication based on credentials before allowing access, rather than restricting access by location as described earlier. This more flexible system is friendly to mobile users and allows them to have a fixed choice of configured outbound SMTP servers. SMTP Authentication, often abbreviated SMTP AUTH, is an extension of SMTP to log in using authentication mechanisms.
Open relay
Servers that are accessible on the wider Internet and do not enforce such access restrictions are known as open relays. This is now generally considered to be a bad practice worthy of blacklisting.
Port
Communication between email servers generally always uses a standard TCP port 25 that is intended for SMTP.
Mail clients but generally do not use this, instead using "send" custom ports. The email service generally accepts email submissions from clients in one of the following:
- 587 (Submission), as formalized in RFCÃ, 6409 (formerly RFC 2476)
- 465 This port has been out of use since RFC 2487, after being briefly assigned to secure SMTP in the 1990s. However, this is usually used by mail providers
Port 2525 and others may be used by some individual providers, but never officially supported.
Most Internet service providers are now blocking all outbound traffic from their 25 customers as an anti-spam measure. For the same reason, businesses will usually configure their firewalls to only allow ports out of traffic from the designated mail server.
SMTP transport examples
Common examples of sending messages through SMTP into two mailboxes ( alice and theboss ) located in the same email domain ( example.com or localhost.com ) reproduced in the following session exchange. (In this example, the conversation section begins with S: and C: , for servers and clients respectively; this label is not part of the exchange.)
Once the sender of the message (SMTP client) assigns a reliable communication channel to the message recipient (SMTP server), the session opens with a speech by the server, usually containing fully qualified domain names (FQDN), in this case smtp.example. com . The client initiates its dialog by responding with the HELO command that identifies itself in the command parameter with its FQDN (or literal address if it does not exist).
S: 220 smtp.example.com Postfix ESMTP C: HELO relay.example.com S: 250 smtp.example.com, I'm glad to meet you C: MAIL FROM: & lt; bob@example.com> S: 250 Ok C: RCPT TO: & lt; alice@example.com> S: 250 Ok C: RCPT TO: & lt; theboss@example.com> S: 250 Ok C: DATA S: 354 End data with & lt; CR & gt; & lt; LF & gt ;. & lt; CR & gt; & lt; LF & gt; C: From: "Bob Example" & lt; bob@example.com> C: To: Alice Example & lt; alice@example.com> C: Cc: theboss@example.com C: Date: Tue, January 15, 2008 16:02:43 -0500 C: Subject: Test message C: C: Hello Alice. C: This is a test message with 5 header columns and 4 lines in the body of the message. C: Your friend, C: Bob C: S: 250 Ok: queue as 12345 C: QUIT S: 221 Bye {Server closing connection}
The client notifies the recipient of the message's origin email in the MAIL FROM command. This is also the return or bounce address if the message can not be sent. In this example, email messages are sent to two mailboxes on the same SMTP server: one for each recipient listed in the To and Cc header columns. The corresponding SMTP command is RCPT TO . Each successful acceptance and execution of a command is recognized by the server with the result code and response message (e.g., 250 Ok).
Transmission of the contents of an email message starts with the DATA command after which it is transmitted verbatim line by line and ends in a data-end order. This sequence consists of a new row (& lt; CR & gt; & lt; LF & gt;), a full stop point (dot), followed by another new row. Since the message body can contain rows with only periods as part of the text, the client sends two periods each time the line starts with a dot; Correspondingly, the server replaces each sequence of two periods at the beginning of a line with a single point. This escape method is called dot-stuffing .
The server's positive answer to end-of-data, as exemplified, implies that the server has taken responsibility for messaging. A message may be duplicated if there is a current communication failure, e.g. due to scarcity of power: Until the sender receives the 250 reply, it must be assumed the message is not sent. On the other hand, once the recipient has decided to receive the message, he should assume the message has been sent to him. So, during this time span, both agents have a copy of the current message they will try to convey. The probability that a communication failure occurs right at this step is directly proportional to the amount of filtering the server performs on the message body, most often for anti-spam purposes. The limited timeout is set to 10 minutes.
The QUIT command terminates the session. If the email has another recipient located elsewhere, the client will be QUIT and connect to the appropriate SMTP server for the next recipient after the current destination has been queued. The information that the client sends in the HELO and MAIL FROM commands is added (not visible in the sample code) as an additional header column to the message by the receiving server. It adds a header field Received and Return-Path .
Some clients are implemented to close the connection after the message is received ( 250 Ok: queued as 12345 ), so the last two lines can actually be removed. This causes an error on the server when trying to send a reply 221 .
Optional extensions
The client learns what options the server supports, using the EHLO utterance, as exemplified below, instead of the original HELO (example above). The client goes back to HELO only if the server does not support SMTP extensions.
The modern client can use the keyword extension ESMTP SIZE to request the server for the maximum message size to be received. Older clients and servers may try to transfer redundant messages that will be rejected after using network resources, including connection time to paid network links every minute.
User can manually specify the maximum size accepted by ESMTP server. The client replaces the HELO command with the EHLO command.
S: 220 smtp2.example.com Postfix ESMTP C: EHLO bob.example.com S: 250-smtp2.example.com Hello bob.example.org [192.0.2.201] S: 250-SIZE 14680064 S: 250-PIPELINING S: 250 HELP
So smtp2.example.com specifies that it will receive a maximum message size of no larger than 14,680,064 octets (8-bit bytes). Depending on the actual use of server resources, it may not currently be able to receive this large message.
In the simplest case, the ESMTP server will immediately declare SIZE maximum after receiving EHLO . According to RFC 1870, however, the numerical parameter to the SIZE extension in the EHLO response is optional. Instead, the Client can issue the MAIL FROM command, including a numerical estimate of the size of the message they are transferring, so the server can reject message reception that is too large.
Spoofing and spamming
The original design of SMTP does not have the facility to authenticate the sender, or check that the server is authorized to send on their behalf, with the result that email spoofing is possible, and commonly used in spam email and phishing.
Source of the article : Wikipedia
0 Comments