Skip to content

Commit

Permalink
Merge pull request #6828 from wildmanonline/rc-v1.300.0
Browse files Browse the repository at this point in the history
[Release Candidate] v1.300.0
  • Loading branch information
wildmanonline committed Jan 31, 2024
2 parents ee33e6c + 93fed3f commit f5039f8
Show file tree
Hide file tree
Showing 36 changed files with 990 additions and 307 deletions.
345 changes: 156 additions & 189 deletions _vendor/github.com/linode/linode-api-docs/v4/openapi.yaml

Large diffs are not rendered by default.

2 changes: 1 addition & 1 deletion _vendor/modules.txt
Original file line number Diff line number Diff line change
Expand Up @@ -5,4 +5,4 @@
# github.com/bep/turbo/v7 v7.20300.20000
# github.com/gohugoio/hugo-mod-jslibs/instantpage v0.5.1
# github.com/instantpage/instant.page v5.1.1+incompatible
# github.com/linode/linode-api-docs/v4 v4.170.2
# github.com/linode/linode-api-docs/v4 v4.171.0
4 changes: 4 additions & 0 deletions ci/vale/dictionary.txt
Original file line number Diff line number Diff line change
Expand Up @@ -1439,8 +1439,10 @@ msgid
msgpack
msmtp
msps
MTAs
mtr
mtu
MUAs
multiarch
multibyte
multicast
Expand Down Expand Up @@ -1680,6 +1682,7 @@ passwdfile
passwordless
patroni
pathnames
Paulo
paypal
PBCs
pbr
Expand Down Expand Up @@ -2478,6 +2481,7 @@ ust
utils
UTunnel
uuid
uuids
uwls
uwsgi
v1
Expand Down
5 changes: 4 additions & 1 deletion ci/vale/styles/Linode/Terms.yml
Original file line number Diff line number Diff line change
Expand Up @@ -40,6 +40,8 @@ swap:
yaml: YAML
urls: URLs
uris: URIs
uuid: UUID
uuids: UUIDs
Cuda: CUDA
gpu: GPU
stackscript: StackScript
Expand All @@ -48,4 +50,5 @@ swap:
pulumi: Pulumi
markdown: Markdown
vuejs: VueJS
vue: Vue
vue: Vue
Sao Paulo: São Paulo

Large diffs are not rendered by default.

Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
208 changes: 208 additions & 0 deletions docs/guides/email/email-services/what-is-smtp/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,208 @@
---
slug: what-is-smtp
title: "Quick Guide to SMTP: The Protocol That Powers Email"
description: 'What is SMTP and how does it work? Simple Mail Transfer Protocol is the technology behind email communication. ✓ Learn how to use handy SMTP commands here!'
keywords: ['what is smtp','mail transfers','smtp tcp or udp','smtp addressing','how does smtp work','full form of smtp','what is smtp used for','smtp protocol example','what does smtp do','smtp layer']
license: '[CC BY-ND 4.0](https://creativecommons.org/licenses/by-nd/4.0)'
authors: ["David Robert Newman"]
published: 2024-01-17
modified_by:
name: Linode
---

Instant messaging, Slack, and Zoom may get all the attention lately, yet email has remained the most ubiquitous communication method of the Internet for decades. One open standard makes it possible for any user, on any platform, to exchange email with anyone else: the Simple Mail Transfer Protocol (SMTP). SMTP works as a universal mail carrier, connecting users around the world regardless of the hardware and software they use.

This guide explains what SMTP is, what it does, how it works, and what commands it uses. You also learn how SMTP works with other protocols to make end-to-end delivery possible.

## What Is SMTP?

SMTP is a standardized set of commands and replies that mail servers use to send and receive email. As described by the Internet Engineering Task Force in [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321), SMTP defines procedures for email acceptance, formatting, and forwarding. The RFC also describes how to handle error conditions and return mail if servers are down or recipients don’t exist.
Although SMTP operates at the application layer, it is a protocol, not a software package. A mail server (usually special software running on a dedicated machine) implements SMTP to communicate with other servers. A mail server may run SMTP processes, but that’s an implementation detail and not a protocol requirement.

## What Does SMTP Do?

Simply put, SMTP’s job is to *send* and *receive* email. While SMTP does most of the heavy lifting for email delivery, it’s only one of several components in most email systems. Before delving into SMTP and how it relates to other protocols, it’s best to begin with an overview of Internet mail architecture.

To most, "email software" probably means an application for reading and writing messages. Software packages like [Microsoft Outlook](https://www.microsoft.com/en-us/microsoft-365/outlook/email-and-calendar-software-microsoft-outlook) or [Mozilla Thunderbird](https://www.thunderbird.net/en-US/) are technically called mail user agents (MUAs). MUAs don’t actually deliver mail. After composing a message with an MUA, the message is then sent to a mail server running a mail transfer agent (MTA). MTAs communicate via SMTP with one another, and it’s here that mail delivery occurs.

Most mail servers support SMTP. Widely used open source mail servers include [Sendmail](https://www.proofpoint.com/us/products/email-protection/open-source-email-solution), [Postfix](https://www.postfix.org/), and [exim](https://www.exim.org/). Commercial products such as [Microsoft Exchange](https://www.microsoft.com/en-us/microsoft-365/exchange/email) have proprietary engines, but include SMTP connectors to speak with other mail servers. Programming languages such as Perl, Python, and Ruby also include libraries that can act as lightweight SMTP clients and servers.

While SMTP describes ways to *send* and *receive* email, it does not *retrieve* messages. Instead, MUAs use a separate, dedicated protocol such as the [Internet Message Access Protocol (IMAP)](https://www.rfc-editor.org/rfc/rfc9051) or [Post Office Protocol (POP)](https://www.rfc-editor.org/rfc/rfc1939) to pull messages from a mail server. Most modern MUAs use IMAP instead of the older POP.

Although SMTP can handle both MUA-MTA and MTA-MTA connections, it’s usually preferable to separate message *submission* from message *relay*. Separating these functions allows different security and policy decisions to be applied at each step. The submission protocol, defined in [RFC 6409](https://datatracker.ietf.org/doc/html/rfc6409), is a widely implemented counterpart to SMTP. Most mail servers support both protocols, and use submission for getting messages from MUAs to MTAs.

The diagram below provides a simplified overview of Internet email architecture. Although this example shows only a few servers, SMTP works the same way throughout the global Internet.

![Email delivery using SMTP](what-is-smtp_small.png)

When SMTP first appeared in the early 1980s, it lacked security functions such as authentication and encryption. As the Internet grew, it became obvious that SMTP’s lack of security features was an issue. It was trivially easy for attackers to send spam, spoof legitimate users, steal passwords, and conduct man-in-the-middle attacks.

In response, the IETF defined methods to authenticate users and encrypt email traffic in flight. Encryption of SMTP traffic is considered a best practice. [RFC 8314](https://www.rfc-editor.org/rfc/rfc8314) describes the ways to implement encryption.

## How Does SMTP Work?

An SMTP session contains at least five steps:

1. Initiation
1. Message transfer
1. Validation
1. Routing
1. Termination

SMTP conversations consist of commands and replies. An SMTP client (which may be an MTA) usually initiates commands, and replies come from the SMTP server. Replies consist of a 3-digit code, usually followed by text. For example, a server replies "250 OK" to acknowledge receipt of the body of an email.

### Session Initiation

An SMTP session begins when a client opens a connection to a server. SMTP servers most often listen on [TCP](https://www.rfc-editor.org/rfc/rfc9293) port 25 for incoming connections. After a connection opens successfully, the client sends a "hello" command identifying itself. In the command’s basic form, the client essentially says "hello, I am example.com". In the more modern version, the client sends an extended hello command to say "hello, I am example.com, and I would like to know which service extensions you support".

[SMTP service extensions](https://www.iana.org/assignments/mail-parameters/mail-parameters.txt) support the ability to include encoded Multipurpose Internet Mail Extensions (MIME) attachments, pipeline multiple commands, request delivery service notifications, and many other options.

### Message Transfer

Once a connection is open, a client can then send one or more messages to the server. This is a three-step process. First, the client sends a `MAIL FROM:` command with the sender’s email address. Second, the client sends one or more `RCPT` commands, each with the email address of a message recipient. Finally, the client sends a `DATA` command, followed by the message contents, and finished by an end-of-mail indicator.

### Validation

Next, the SMTP server evaluates whether to accept and process each message. A server may return or discard messages with malformed or unrecognized source or destination addresses. Although mail servers can be configured to silently discard email, the SMTP RFC strongly discourages this unless senders are known to be fraudulent or undesirable. For all other mail, the RFC recommends returning undeliverable mail with an error code.

Servers may also optionally rewrite source or destination addresses. As an example of the former, if Company B buys Company A, a mail server might rewrite mail from `CompanyA.com` to appear to originate instead from `CompanyB.com`. As an example of destination address rewriting, a mail server might expand a mailing list’s address into many recipients who subscribe to that list.

### Routing

Assuming an incoming message has passed all validation tests, the next task for an SMTP server is to route the message to its final destination. Although there are many routing options available, all MTAs perform the same four basic steps:

1. Perform an address lookup using the Domain Name System (DNS).
1. Identify the name and host parts of a recipient’s email address.
1. If the host isn’t local, forward the message.
1. If the host is local, store the message.

If a recipient’s email address isn’t local, the mail server becomes an SMTP client. It then hands off email to another SMTP server that can deliver mail for the recipient. If the recipient is on the same server, routing is easy. The MTA simply puts email in a message store, where it remains until the recipient’s MUA retrieves it using IMAP or POP.

### DNS First

Before routing can occur, an MTA server must first query DNS to determine which mail server(s) accept mail for a given domain. DNS has at least one resource record, called an MX record (for Mail eXchanger), for any domain that can receive email. It points to the mail server(s) for that domain.

SMTP depends on DNS in two critical ways. First, at least one valid MX record must exist for each recipient’s domain, and a DNS client must be able to query that record. Simply put, the sender and the recipient *must* have DNS working for mail delivery to work at all. DNS errors are the root cause of many email delivery problems. When troubleshooting mail server problems, it’s best practice to first verify that DNS works correctly.

Second, optionally configure DNS with multiple MX records (one per mail server) to improve the reliability and/or speed of mail delivery. MX records include a preference, with a lower number indicating a higher priority for mail delivery. For example, here are the MX records for gmail.com:

```output
5 gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.
20 alt2.gmail-smtp-in.l.google.com.
30 alt3.gmail-smtp-in.l.google.com
40 alt4.gmail-smtp-in.l.google.com.
```

An MTA trying to send email to Gmail first tries `gmail-smtp-in.l.google.com`, since its preference has the lowest value. If that server is unreachable, the MTA then successively tries the other servers with higher preference values until it’s able to make a connection. Having a primary and one or more secondary MX servers makes mail delivery more reliable in case of server or network outages.

You can also configure MX records with identical preferences to load-balance email across two or more servers. For high-volume domains, distributing the mail load across multiple servers may help speed delivery.

Once a DNS query completes, the server opens an SMTP session with the host in the MX record, and begins forwarding messages. If a destination mail server isn’t available, SMTP keeps retrying delivery for some interval (often 5 days by default). If the destination server is still unavailable after that interval, SMTP returns the message to the sender with an undeliverable reply code.

### Termination

After handing off all messages to a server, the final step for an SMTP client is to close the connection. As with the session initiation, the client always initiates the session close with a `QUIT` command.

## Basic SMTP Commands

Although email exchanges usually occur between MUA and MTA software packages, you can also run SMTP from the command line using a telnet client. This is an excellent way to see SMTP commands at work.

In this exchange, adapted from RFC 5321, a user with the email address `Smith@example.com` attempts to send messages to users `Jones`, `Brown`, and `Green`, all at `example.org`. In this basic example, `example.com` and `example.org` servers connect directly. Also, `Jones` and `Brown` have valid addresses, but `Green` does not have an account.

Here is a step-by-step examination of a complete SMTP session. Note the use of reply codes after each command.

```command
telnet smtp.example.org 25
```

```output
220 example.org Simple Mail Transfer Service Ready
```

You can instruct a telnet client to connect to any TCP port, including port 25, the standard SMTP port. The server’s 220 reply indicates it’s ready to open a connection. At minimum, SMTP servers also return their domain name and the words "Service Ready".

```command
EHLO example.com
```

```output
250-example.org greets example.com
250-8BITMIME
250-SIZE
250-DSN
250 HELP
```

The client’s EHLO (extended hello) command identifies its domain and indicates it wants to know which SMTP extensions the server supports. For each response, the server issues a 250 reply code, meaning it has successfully completed each action. This particular server supports 8-bit MIME encoding of attachments, a message size declaration, delivery status notifications, and help commands.

```command
MAIL FROM:<Smith@example.com>
```

```output
250 OK
```

The client wants to send email from `Smith@example.com`. Because the `example.org` server considers that a valid source address, it returns a `250 OK` reply.

```command
RCPT TO:<Jones@example.org>
```

```output
250 OK
```

```command
RCPT TO:<Brown@example.org>
```

```output
250 OK
```

```command
RCPT TO:<Green@example.org>
```

```output
550 No such user here
```

The client wants to send to three recipients. The server acknowledges Jones and Brown with 250 OK replies, but sends a 550 error reply to indicate that it doesn’t recognize Green.

```command
DATA
```

```output
354 Start mail input; end with <CRLF>.<CRLF>
```

```command
Contents of email message.
.
```

```output
250 OK
```

The client’s `DATA` command indicates it’s ready to start sending the message body. The server’s `354` reply indicates it’s ready to receive input. The server continues to accept input into the message body until it sees a period on a single line. The `250 OK` reply indicates the server successfully received the entire message body.

```command
QUIT
```

```output
221 example.org Service closing transmission channel
```

The final step is for the client to initiate a session close with the `QUIT` command. If successfully received, the server responds with a `221` reply, and terminates the session.

SMTP defines many more commands and reply codes, as discussed in Section 4 of [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321), but these provide an idea of what to expect in any successful SMTP connection. Section 4.1 of the RFC lists all SMTP commands, while Section 4.2.3 lists all reply codes in numerical order.

## Conclusion

The great thing about SMTP is that it’s an open protocol. The client and server in this case could be any type of hardware, running any operating system, with any SMTP-compatible server software. SMTP is truly the means that makes global email communications possible.
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@ description: "Learn how to create and manage configuration profiles for a Comput
keywords: ["configuration profiles"]
tags: ["linode platform","cloud manager"]
published: 2021-04-30
modified: 2023-09-11
modified: 2024-01-30
modified_by:
name: Linode
image: Linode-Configuration-Profiles.jpg
Expand Down Expand Up @@ -70,13 +70,16 @@ When adding or editing a configuration profile on a Compute Instance, the follow
```
{{< /note >}}

- **Network Interfaces:** Assigns either a VLAN or the Public Internet to a network interface in Linux. There are a total of 3 available network interfaces: `eth0`, `eth1`, and `eth2`. If no VLANs are in use, the recommended setting is _Public Internet_ for `eth0` and _None_ for all other interfaces. See [Getting Started with VLANs](/docs/products/networking/vlans/get-started/).
- **Network Interfaces:** Configures network interfaces for the Public Internet, a [VPC](/docs/products/networking/vpc/), or a [VLAN](/docs/products/networking/vlans/). There are a total of 3 available network interfaces, which correspond to the devices assigned within the Linux system: `eth0`, `eth1`, and `eth2`. If no VLANs or VPCs are in use, the recommended setting is _Public Internet_ for `eth0` and _None_ for all other interfaces. When assigning an instance to a VPC, it's recommended to use `eth0` for the VPC interface. If public internet is required along with a VPC, configure the VPC interface as a 1:1 NAT with internet access (the _Assign a public IPv4 address for this Linode_ option under the VPC interface) instead of designating a separate network interface as _Public Intenet_. For more details on assigning a Compute Instance to a VPC or VLAN, review the appropriate documentation:

- [Assign a Compute Instance to a VPC](/docs/products/networking/vpc/guides/assign-services/)
- [Attach a VLAN to a Compute Instance](/docs/products/networking/vlans/guides/attach-to-compute-instance/)

- **Filesystem / Boot Helpers:** Various helper tasks that run when the Compute Instance is booted up. Recommended setting for all helpers: _Enabled_.
- **Enable distro helper:** Helps maintain correct inittab/upstart console device.
- **Disable `updatedb`:** Disables `updatedb` cron job to avoid disk thrashing.
- **Enable modules.dep helper:** Creates a module dependency file for the kernel you run.
- **Auto-mount devtmpfs:** Controls if pv_ops kernels auto-mount devtmpfs at boot.
- **Auto-mount devtmpfs:** Controls if `pv_ops` kernels auto-mount devtmpfs at boot.
- **Auto-configure networking:** Automatically configures static networking. See [Network Helper](/docs/products/compute/compute-instances/guides/network-helper/).

## Create a Configuration Profile
Expand Down
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit f5039f8

Please sign in to comment.