A look at email history shows us that this automated medium of communication was first developed with the deliverability of messages in mind and not with an email protection emphasis. However, today’s virtual mail, although designed on a protocol intended to handle only text-based correspondence (SMTP), has greatly expanded across service extensions to accommodate other message types (such as MIME). This is where it’s important to provide stable SMTP.
With phishing attacks spiking more than 660 percent in March alone, while the probability of email-based cyber attacks has continued to escalate over the years, it is easy to see why security features that rely on SSL/TLS, end-to-end encryption, etc. have been implemented to enable safe SMTP communications.
But how do you keep your personal and private messages protected with offenders getting smarter and more experienced in their attacks? Here are a few security pointers for emails that will help us stay protected:
10 Email Protection Tips Sent via Mail Transfer Protocols to Secure Messages
Below, we will discuss 10 realistic tests you can use for your email accounts to achieve safe SMTP, IMAP, and POP3 communications:
Learn to Inspect Message Headers
Your email message headers are typically obscured by default, but the initial message headers for your unique email client can be seen by Google. For example, if you’re using an email client from Outlook 365:
- To open it in a new browser, double-click on an email.
- Go to the File menu, then pick Properties.
- In the Properties pane, you can see a field at the bottom that includes information about the email header.
Once the headers can be seen, search for the “Received From” field that records the path to reach you by the message going through the net through servers. Check for the sender’s IP and do a reverse lookup to map the message back to where it came if you get a strange text. You will also search whether the message fails to check the Sender Policy Framework (SPF) and Identity Mail (DKIM) domain keys.
While most mail systems have email protection indications like a red question mark in Gmail for unauthenticated addresses, it is a valuable skill to know how to inspect email headers.
Avoid Clicking on Links or Downloading Attachments
And most of us know, the greatest flaw in email protection always comes down to human error. Security professionals and engineering gurus are constantly hammering this reality into our heads. It is not unlikely, however, to get too curious to know what an attachment is, or to be too absentminded to realize that we have unintentionally clicked on a connection. Even the best of us, at least the well-crafted ones, will fall victim to phishing attacks. This is why we must be vigilant not to open any attachments or click on links from unknown senders, in addition to getting spam filters and antimalware enabled (or attackers pretending to be Gary from the accounts department).
Update Your DMARC Records With the Domain Registrar
In addition to running checks on messages using SPF and DKIM specifications, DMARC is the only approach that notifies the receiving server of the step it can take if the message fails to execute these measures. If you’re a domain owner, try setting up DMARC records for the domain registrar, in addition to configuring SPF and DKIM. If you are confused about the procedure, they should be able to assist you with it.
Neither SPF nor DKIM will prevent the “From” address shown in your inbox from being forged by attackers. DMARC verifies, though, that the “from” fits the SPF verified return route and the domain name in the DKIM signature.
Test Your SMTP Server
To do this, by tracking the SPF, DMARC records, consider sending test emails to see how it reacts to legitimate and spam messages. Adjust the default settings and replace them with more stable alternatives if you can tweak the SMTP settings (starting with changing default admin usernames and passwords).
Make Use of SMTP SSL/TLS Ports
SMTPS has historically used port 465 as a way to secure SMTP by running it over a TLS link on the transport layer. That’s exactly what we mean when we refer to an SMTP SSL port (or, more precisely, SMTP TLS port)-it’s a way to safely share messages over SSL/TLS channels between the email client and the email server.
Using two methods, opportunistic TLS or coerced TLS, TLS implementation can be achieved. We are attempting to switch from the usage of unencrypted SMTP to a stable TLS encrypted channel using the STARTTLS SMTP command with opportunistic (explicit) TLS. The transmission returns in plain text if the attempt fails, which means without the use of any cryptography. However, the email client and server are either able to agree an encryption version of coerced (implicit) TLS that they can all endorse, or the transfer stops and the email exchange doesn’t advance. Based on if you want optimum deliverability or full privacy, you should make your pick.
The Internet Assigned Numbers Authority (IANA) registered port 465 for SMTPS, but the Internet Engineering Task Force never released it as an official SMTP channel (IETF). By the end of 1998, port 465 had been allocated to a new service. While 465 was a stable SMTP port, port 25 continues to be used as the default SMTP relay port. The use of port 25 for SMTP connections (to send emails over the net) has been constrained by ISPs and hosting services, and most current email clients do not use this port at all. Usually, you do not see any traffic via this port unless you are managing a mail server (a message transfer agent or an MTA).
As suggested by IETF, port 587, along with TLS encryption, should be used as the default protected SMTP port for message submission in compliance with RFC 6409, which distinguishes message submission (port 587) from message relay (port 587) (port 25). Since many legacy systems continue to use port 465 for SMTPS, the ISP or hosting service will still be able to find support for it, but it is not advised to use this port. Finally, port 2525, while not formally recognised, is a widely used solution accepted by most email service providers if port 587 is blocked.
Deploy End-to-End Encryption for Maximum Email Security
With the notice from the writers of RFC 5321 in mind, suggest utilizing end-to-end encryption protocols such as S/MIME or PGP to encrypt messages on the sender’s computer as well as during delivery, a note that suggests that SMTP mail is fundamentally vulnerable. This means that what they receive is garbled data that makes little sense, even though the message falls into the hands of an intruder.
An added advantage of having a S/MIME certificate (or, as it is often called, an email signing certificate) is that it helps you to incorporate a digital signature. This verifies the sender’s validity and validates the credibility of the post.
Use TLS With IMAP and POP3
So, what are IMAP and POP3? The Internet Protocol for Accessing Messages (IMAP) and the Post Office Protocol (POP3, version 3) handle the processing of messages from the receiving server. This are the protocols used for receiving the emails from mail servers through email clients like Outlook. Although IMAP syncs messages through all of your computers, before extracting it from the cloud, POP3 copies the message to a single computer so that it is accessible offline. POP3 encrypted links use port 995 (also known as POP3S), and port 993 is used by IMAPS.
Maintain IP Blacklists to Block Targeted Spams
It makes sense to block them on your email server if you are regularly the victim of garbage and spam messages from IP addresses that exchange unsolicited ads and sales pitches.
DNS blacklists (e.g., DNSBL, Spamhaus, etc.) or spam URI real-time block lists can be used to do this (e.g., SURBL, URIBL, etc.). A fast Google search will show you a lot of options open, but be careful to use these kinds of resources, which are not free of controversy and may block any legitimate emails inadvertently.
Use Restrictive Mail Relay Options
As any spammer from anywhere in the world will use your server and services to spam others, you don’t want to be a free relay. The parameter for the mail relay determines which domains or IPs your server will forward mail to. If you want to stop being on a blacklist, customize these choices with the utmost consideration.
Other Considerations to Improve Email Security
Any additional considerations for email protection that could be useful include, but are not limited to, the following:
- Limit the number of your SMTP server connections. As these tests can avoid denial of service stacks, you can do this depending on use and server hardware requirements.
- Define the setup of a failover for MX documents. To maximize availability, provide a failover setup wherever possible when listing MX data.
- As authentication fails, set the reverse DNS lookup to block IPs. Trigger a reverse DNS lookup that blocks emails if there is an IP overlap between the sender’s host name and domain name.
Final Thoughts on Email Security
With criminals benefiting from the global health crisis, email protection has arisen as a key area of concern. Barracuda Networks estimates that since the beginning of March, 467,825 cases of spear-phishing attacks have been reported. Although the figures are definitely troubling, the good news is that by adequately educating workers on simulated attack scenarios, these numbers will decline, especially at a time when most employees are telecommuting to work.
Hopefully, when configuring mail servers, or to exercise caution if you happen to receive any unusual emails, the above pointers on stable SMTP will come in handy.