|
|||
|
|
|
| Home |
| About |
| Hobbies |
| Software |
| Hardware |
| ICT Hotlist |
| Purpose |
React:
ICT-Hotlist Topic
Back to the ICT-Hotlist...Effectively blocking phishing and malware mails by implementing RFC 5321 section 2.5.3 The internet e-mail standard.
How to effectively prevent cybercrime by blocking most phishing and malware mails.
A short background on Phishing and malware risks
The UK Department for Science, Innovation & Technology reported1 that just over four in ten UK businesses (43%) and three in ten charities (30%) reported having experienced any kind of cyber security breach or attack in 2025. Of businesses or charities that experienced a breach or attack in 2025, phishing attacks remain the most prevalent and disruptive type of breach or attack (experienced by 85% of businesses and 86% of charities). The qualitative interviews highlighted that phishing attacks were often cited as time-consuming to address due to their volume and the need for investigation and staff training. The qualitative interviews also found that organisations had a growing consciousness that increasingly sophisticated methods, such as AI impersonation, were becoming mainstream.
Percentage of types of breaches or attacks in 2025, among UK organisations that have identified any breaches or attacks.
| Type | Businesses | Charities |
|---|---|---|
| Phishing attacks, i.e. staff receiving fraudulent emails or arriving at fraudulent websites | 85% | 86% |
| Others impersonating, in emails or online, your organisation or your staff | 34% | 35% |
| Organisation's devices being targeted with other malware (e.g. viruses or spyware) | 18% | 14% |
| Takeovers or attempts to take over your website social media accounts or email accounts | 7% | 9% |
| Organisation's devices being targeted with ransomware | 6% | 4% |
| Hacking or attempted hacking of online bank accounts | 6% | 5% |
| Denial of service attacks, i.e. attacks that try to slow or take down your website, applications or services | 5% | 4% |
| Unauthorised accessing of files or networks by staff even if accidental | 2% | 4% |
| Unauthorised accessing of files or networks by people outside your organisation (other than staff or students) | 2% | 3% |
| Unauthorised listening into video conferences or instant messaging | 0% | 0% |
| Any other breaches or attacks | 4% | 4% |
Using the Simple Mail Transfer Protocol (SMTP) internet standard to combat cybercrime
Believe it or not, but the old standard for e-mail transport over the internet provides a valuable weapon against attacks on organisations using e-mail. The RFC 5321 states that any mail server on the internet MUST have it's Full Qualified Domain Name (FQDN) specified with an address (A) or mail exchange (MX) record in DNS. Cyber attackers want to hide their servers as best as possible and reuse them for sending mails that "mimic" or "spoof" a lot of different reputable companies. Updating DNS records for a spoofed sender e-mail address for aliases costs them a lot of work and gaining attention but is not possible for the real domain name of a reputable company.
What does the RFC 5321 define?
The RFC 5321 on the Simple Mail Transfer Protocol section 2.3.52 states:
2.3.5. Domain Names
A domain name (or often just a "domain") consists of one or more
components, separated by dots if more than one appears. In the case
of a top-level domain used by itself in an email address, a single
string is used without any dots. This makes the requirement,
described in more detail below, that only fully-qualified domain
names appear in SMTP transactions on the public Internet,
particularly important where top-level domains are involved. These
components ("labels" in DNS terminology, RFC 1035 [2]) are restricted
for SMTP purposes to consist of a sequence of letters, digits, and
hyphens drawn from the ASCII character set [6]. Domain names are
used as names of hosts and of other entities in the domain name
hierarchy. For example, a domain may refer to an alias (label of a
CNAME RR) or the label of Mail eXchanger records to be used to
deliver mail instead of representing a host name. See RFC 1035 [2]
and Section 5 of this specification.
The domain name, as described in this document and in RFC 1035 [2],
is the entire, fully-qualified name (often referred to as an "FQDN").
A domain name that is not in FQDN form is no more than a local alias.
Local aliases MUST NOT appear in any SMTP transaction.
Only resolvable, fully-qualified domain names (FQDNs) are permitted
when domain names are used in SMTP. In other words, names that can
be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
in Section 5) are permitted, as are CNAME RRs whose targets can be
resolved, in turn, to MX or address RRs. Local nicknames or
unqualified names MUST NOT be used. There are two exceptions to the
rule requiring FQDNs:
o The domain name given in the EHLO command MUST be either a primary
host name (a domain name that resolves to an address RR) or, if
the host has no name, an address literal, as described in
Section 4.1.3 and discussed further in the EHLO discussion of
Section 4.1.4.
o The reserved mailbox name "postmaster" may be used in a RCPT
command without domain qualification (see Section 4.1.1.3) and
MUST be accepted if so used.
Example diagram
This diagram and stepwise explanation outlines a highly effective, standards-based strategy for blocking the vast majority of phishing and malware emails at the mail server level, before it even enters in the end-users mailbox.
Diagram explaining using the internet standard to battle cybercrime
- Cyber criminals send very large amounts of phishing or some spear phishing e-mails "originating" from spoofed reputable companies over the internet.
- At the internet provider the large amounts of mails are received. The mail server notices (the spoofed) reputable company domain name and the ip-address of the cyber criminal in the e-mail message header and performs a Domain Name query.
- The Domain Name Server queries the DNS zones over the internet if there is an Address (A) or Message Exchange (MX) address for the (spoofed) reputable company domain name.
- The DNS servers that are responsible for the DNS zone holding the reputable company domain name provides an answer.
- The answer is sent back to the internet provider over the internet.
- The e-mail processing of the internet provider decides if the (spoofed) reputable company domain name stores a valid address (A/AAAA) or mail exchange (MX) record for the mail server and if it is equal to the internet address provided by the cyber criminal
- When the originating mail server is not correctly configured (i.e. the reputable company name e-mail server does not match the server address of the cyber criminal) the mail gets silently discarded without a notification to the sender and receiver. The bulk of the phishing and malware e-mails will follow this route.
- When the e-mail server FQDN is correctly configured for the reputable company, the mail is processed and delivered to the happy end user.
Why it works
- Every device on the internet gets its own unique IP-address. Servers get a fixed address assigned; other devices can get a variable address;
- Only the reputable company can update their (secured) DNS records at their domain registrar;
- The Fully Qualified Domain Name (FQDN) for the mailserver can only be registered by the reputable company;
- Every e-mail message contains the ip-address of the e-mail server and the Fully Qualified Domain Name of the e-mail server;
- The cyber criminal can not register his mailserver's IP-address in the DNS records of the reputable company (He has no access to the DNS records);
- The internet provider extracts the ip-address and de FQDN of the e-mailserver from the e-mail message to check the validity.
- When the internet provider performs an ip-address lookup with the DNS registrar, the ip-address of the cyber criminal's mailserver can not be found;
- E-mails that do not confirm to the e-mail standard are silently dropped so the reputable company is not burdened.
Caveats
Even reputable companies can make errors in their domain registration. If for example company.com has a mailserver mail.company.com and an additional mailserver in the region Europe mail.europe.company.com. Only registering the mailserver mail.company.com in DNS will effectively get all mails from mail.europe.company.com dropped.
Footnotes
- Direct link to the Cyber security breaches survey 2025 of the UK Department for Science, Innovation & Technology: https://www.gov.uk/government/statistics/cyber-security-breaches-survey-2025/cyber-security-breaches-survey-2025#chapter-6-cyber-crime
- Direct link to the RFC paragraph:https://www.rfc-editor.org/rfc/rfc5321#section-2.3.5
Scripts and programming examples disclaimer
Unless stated otherwise, the script sources and programming examples provided are copyrighted freeware. You may modify them, as long as a reference to the original code and hyperlink to the source page is included in the modified code and documentation. However, it is not allowed to publish (copies of) scripts and programming examples on your own site, blog, vlog, or distribute them on paper or any other medium, without prior written consent.Many of the techniques used in these scripts, including but not limited to modifying the registry or system files and settings, impose a risk of rendering the Operating System inoperable and loss of data. Make sure you have verified full backups and the associated restore software available before running any script or programming example. Use these scripts and programming examples entirely at your own risk. All liability claims against the author in relation to material or non-material losses caused by the use, misuse or non-use of the information provided, or the use of incorrect or incomplete information, are excluded. All content is subject to change and provided without obligation.
