Ports, encryption and logging in

Module 1: How email works · Reading time: 10 minutes

Learning objective: After this lesson, you can say what each mail port is for, explain the difference between STARTTLS and direct TLS, and explain a certificate warning or a rejected login.

Key concepts: port 25, 587, 465, 993, 995, 143, 110, STARTTLS, direct TLS (implicit TLS, RFC 8314), certificate, server name, SMTP authentication (SMTP AUTH), open relay, port 25 blocking, app password, OAuth

A port is a door

A server has one IP address, but many doors. Each service listens on its own port, a number. Your web browser knocks on port 443, your mail program knocks on port 993 to read mail and on 587 or 465 to send it. Choose the wrong door, and nobody answers, or someone answers who speaks a different language. That produces vague error messages like "cannot connect" or "the server is not responding".

The mail ports at a glance:

Why not just use port 25 for sending?

In the past, you'd set port 25 in your mail program. That's history now, for two reasons.

First: on port 25, a mail server accepts mail from anyone, for its own domains. There's no login. A server that also forwards mail from anyone to other domains on port 25 is called an open relay, and spammers will abuse it within a few hours. That's why sending your own mail out to the world has become a separate service: submission on port 587 (and 465), where you always log in first.

Second: many internet providers block outgoing traffic to port 25 from home connections. That means an infected computer in a living room can't send spam directly to mail servers. The result for you: if you try to send from your mail program via port 25, it might not work at home but work fine at the office, or the other way around.

Remember: mail programs send via 587 or 465, with a login. Port 25 is for servers talking to each other.

STARTTLS or direct TLS?

There are two ways to encrypt a mail connection.

Direct TLS (implicit TLS): the connection is encrypted from the very first byte, just like a website with https. This happens on 465, 993 and 995.

STARTTLS: the connection starts unencrypted. The server says "I can encrypt", the client replies STARTTLS, and from that point everything is encrypted. This happens on 587 (and on 25, 143 and 110).

For security, it makes little difference, as long as your program makes STARTTLS mandatory. The risk with STARTTLS lies at the start: someone sitting between you and the server can strip out the "I can encrypt" offer. A program that then quietly continues unencrypted sends your password across the line in plain text. That's why RFC 8314 (2018) recommends direct TLS (465, 993, 995) over STARTTLS for mail programs. In practice, 587 with STARTTLS and 465 with SSL/TLS are both fine, as long as you set encryption in your program to "required" rather than "if available".

A common mistake is the wrong combination: port 587 with "SSL/TLS", or port 465 with "STARTTLS". The program then expects something different from what the server does, and the connection hangs or fails. Remember the pairs: 587 + STARTTLS and 465 + SSL/TLS. Programs sometimes call direct TLS "SSL", "SSL/TLS" or "TLS"; STARTTLS is also sometimes called "TLS". So look at the port.

The certificate and the server name

With every encrypted connection, the server presents a certificate that proves it is who it says it is. Your mail program checks two things: was the certificate issued by a trusted party and is it still valid, and does it contain the name you entered as the server?

That second point goes wrong most often. If you enter mail.example.com, but the certificate only contains server12.hosting.example, you'll get a message like "Cannot verify server identity" or "The target principal name is incorrect". The connection itself is still encrypted, but your program can't be sure it's talking to the real server.

Don't dismiss such a message. The solution is a server name that does appear in the certificate (see lesson 2.1). On a shared server, that's often the server's own name, which your provider gives you. Another well-known cause: a virus scanner that "scans" encrypted mail by inserting its own certificate in between. In that case, the message will show the scanner's name under "issued by".

Logging in when sending

On 587 and 465, you need to log in before the server will send your mail out. This is called SMTP authentication (SMTP AUTH). In your program, the option is called "outgoing server requires authentication", "login required" or "authentication: normal password". You usually use the same username and password as for IMAP.

If authentication is switched off, or the username for the outgoing server has been left blank, you can read mail but not send it. The server then replies with something like 530 5.7.0 Authentication required or 554 5.7.1 Relay access denied. That's the most common reason for "receiving works, sending doesn't".

A second type of rejection: 535 5.7.8 Authentication failed. In that case, the username and password combination is wrong. Note: after a number of failed attempts, many servers block the IP address those attempts come from, to guard against password guessing. An old phone with an old password can end up getting your whole office blocked.

App passwords and OAuth

With large providers such as Google and Microsoft, logging in with just your ordinary password in a standalone mail program works less and less often. They use OAuth: your program sends you to a login page from the provider, you log in there (possibly with two-step verification), and the program receives a key instead of your password. Programs that can't do this sometimes get an app password: a separate, long password that only works for that one program and that you can revoke separately.

With an ordinary mailbox at a hosting company, you usually log in with the password of the mailbox itself. That makes a strong, unique password extra important (lesson 3.4).

In practice: the settings for a mailbox

For a WebOké mailbox, the settings are: IMAP 993 with SSL/TLS, POP3 995 with SSL/TLS, sending 587 with STARTTLS or 465 with SSL/TLS, authentication on with your full email address and the mailbox password. With other providers it works in a similar way: the ports are nearly always the same, only the server name differs. See lesson 2.1 for which server name to choose.

Summary

• Mail programs send via 587 (STARTTLS) or 465 (direct TLS), always with a login. Port 25 is for servers talking to each other and is often blocked at home.
• Reading mail goes via 993 (IMAP) or 995 (POP3), both with direct TLS.
• Combine correctly: 587 + STARTTLS, 465 + SSL/TLS. Set encryption to required.
• A certificate warning usually means: the server name you entered isn't in the certificate. Dismissing it is not a solution.
• "Reading works, sending doesn't" is almost always: authentication for the outgoing server is switched off or left blank.

Quiz

Exercise

Exercise Z1.4: Ports and certificate of a mail server. Enter the incoming and outgoing server name you use for your own mailbox (if you don't have your own mailbox, use imap.gmail.com and smtp.gmail.com). For port 993 (incoming) and ports 465 and 587 (outgoing), choose what you expect: direct TLS, STARTTLS or unreachable, and enter whether you think the name is in the certificate. The program connects to the three ports itself and puts the result next to your answers.

Further reading

The steps in these articles apply to WebOké's control panels; with other providers it works in a similar way.

• DirectAdmin guide 8.1: All settings at a glance: servers, ports and security
• DirectAdmin guide 8.8: Sending or receiving doesn't work: how to fix it
• Certificate error when collecting email
• I can't send email (receiving does work)
• RFC 8314 (direct TLS for mail programs), RFC 6409 (submission), RFC 3207 (STARTTLS), RFC 4954 (SMTP AUTH)