The Basic Mail Transfer Protocol (SMTP), which is used by many email clients to transfer outbound email messages, has endured a long and boring struggle to get where it is today. Several RFCs later, we now have a standard that not only discusses efficient mail transfer, but also looks at how email messages can be safe. But none of this can benefit you if you continue using the non-encrypted ports when configuring your mail servers!
In the following pages, we’ll look at how, in terms of some of the authentication mechanisms available for use today, SMTP security has developed. We are also going to talk about protected SMTP port 587, port 465, port 2525, etc. But let’s have an outline of SMTP protection before all of that.
SMTP Security
SMTP is an unreliable protocol in and of itself. Basically, it lacks any real security features, which is why other authentication mechanisms and protected transmissions are necessary.
About 2004, researchers attempted to solve the issue of how to trust where the message came when SMTP was structured in a way that the “From” sender field shown does not need to fit the “Mail From” field of the envelope sender. So then, how would you confirm if your friend Jerry sent you a note, or if he was impersonated by someone?
This is why, in an effort to deter the exchange of malicious emails via phishing attacks or spoofed addresses, authentication strategies such as Sender Policy Framework (SPF), DomainKeys Defined Mail (DKIM), etc. came into the picture.
Another way of increasing email authentication is email signature certificates, which can not only use end-to-end email protection, but can help check the sender’s identity. Through encrypting the email servers themselves, SSL/TLS certificates also provide additional levels of protection.
The three DNS records that are your gateway to email security: SPF, DKIM, and DMARC:
Sender Policy Framework
SPF documents map IP addresses to particular domains to show which addresses will send emails on behalf of a domain to the receiving recipient. An sign of spoofed email addresses may be an abnormal SPF record (with permerror, crash, etc.). Domain-linked DNS records (a device that converts domain names to IPs) let the client know which server they want to connect with, or whether a client sends a request to which server they’re referring to.
SPF data may be kept by a TXT log, a form of DNS record, which is used to show to a mail exchange server which hosts from a domain are able to send emails. This is not a foolproof process, however, and it often involves administrative efforts to monitor the records and time any time the fields are changed for any updates to spread across the internet.
Most of the time, companies use a soft failure mechanism that displays an alert message if an email with unverified values is sent, instead of introducing a hard failure that can obstruct critical emails.
DomainKeys Identified Mail
DKIM, on the other hand, is a digital signature used to declare authenticity and validate that an email message’s content has been changed.
Domain-based Message Authentication, Reporting, and Conformance
In the year 2015, DMARC was specified in RFC 7489 and is intended to function together with SPF and DKIM as a framework defining how to respond to potentially spoofed emails. To authenticate an email, it basically depends on one form or the other. The receiving server will either deny or quarantine the email, based on the meaning of the ‘p’ flag in DMARC. By setting the value as zero, they may even choose to do nothing and simply gain attention without disrupting the flow.
Another popular flag that can be used to designate a list of URIs where input can be submitted (such as the protection group’s email address in the form “mailto:dummyaddress@example.com”) is “rua”. The “pct” tag specifying the proportion of your inbox on which an action will be applied is another flag worth noting. For eg, if your DMARC record is set to “p=reject, pct=0,” the reject policy will be extended to zero percent of messages from the domain.
A word of caution: be vigilant when you see this flag, or if you’re a domain owner, about using it. The benefit that DMARC offers for email protection can be totally undermined.
Secure SMTP SSL Ports
In the days gone by, Simple Mail Transfer Protocol Secure (SMTPS) used port 465 to secure SMTP on the transport layer by wrapping it within a TLS (transport layer security) connection. The misunderstanding about protected SMTP ports is understandable because, at one point, the Internet Assigned Numbers Authority (IANA) took the liberty to register port 465 for SMTPS use.
To get a deeper understanding of protected SMTP ports, let’s take a look at each of these ports individually:
Port 465
Port 465 has never been formally recognised as an SMTP port by the IETF, but because IANA has registered it to be used for SMTPS, it can still be used in some legacy systems as an SMTP SSL port. However, by the end of 1998, IANA had allocated this port to a new service. As such, even though the service provider provides support for it, it is best not to use it as a stable SMTP interaction.
Port 25
In a nutshell, for SMTP relaying, port 25 is still used. In fact, port 25 continues to be used with SMTP STS, which segregates message submission and message relay, to relay a message from one mail server to another. However, this port may be disabled for you because you are in charge of handling a message transfer agent (MTA) or a mail server, and you can usually have no traffic on this port.
Port 587
As per the guidelines set by the Internet Engineering Task Force, port 587 should be used as the default port to send email messages to a mail server along with TLS encryption (IETF). In two cases, opportunistic (explicit) TLS or by coerced (implicit) TLS, transport layer protection can be enforced.
First, an attempt to relay the message in an encrypted manner with opportunistic TLS is rendered by switching from a non-encrypted channel to a protected one using the STARTTLS command. However, the message is sent in plaintext if both client and email servers are unable to agree on an encryption standard.
In the other hand, in the case of forced TLS, if the agreement fails, and the email client and server do not accept the same encryption requirements, the transmission of messages then also fails.
Port 2525
Port 2525 is not publicly recognised by either IETF or IANA, although most email service providers typically accept it in the event that port 587 has been closed for any reason.
In Summary
Hopefully, your questions have been answered about SMTP protection and protected SMTP ports that allow encrypted email communications. While email security is still a work in progress, from the days of open relay, we have come a long way. We can now sign our addresses, block IPs, make the server perform a clear action if authentication fails and exchange input to gain insight on where we might go wrong, as you have learned.
New email protection standards, the latest being SMTP STS, established by RFC 8461, are constantly being developed. It operates alongside STARTTLS and is a method that attempts to prevent downgrades to encryption. The first email provider to support SMTP MTA STS and SMTP TLS reporting was Gmail.