SMTP Smuggling

[madires]

Some security researchers had fun with SMTP's end-of-message sequence (<CR><LF>.<CR><LF>):
SMTP Smuggling - Spoofing E-Mails Worldwide (https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide)

A few MTAs accept variations of the end-of-message sequence, e.g. <CR>.<CR>, and enable an attacker to smuggle and spoof emails including SPF. GMX and Microsoft have fixed the security issue, while Cisco claims it's a feature. It can be configured by the customer, but the default setting is to allow messages with an invalid end-of-message sequence and to convert it into the standard format.

[Halcyon]

So the takeaway is, implement a strong DMARC policy (which is the default recommendation on all reputable email services, including Google Workspace, Microsoft 365 etc...).

For those on M365, set up a mail flow rule that actually rejects emails that fail DMARC (as opposed to going to Quarantine). Microsoft in their wisdom ignore the p=reject tag and decide to do their own thing.

Sysadmins that think their mail servers that they set up 15 years ago are still secure need to reconsider their profession.

[madires]

... after an extensive period of testing. SPF is pretty simple, but DKIM causes headaches. Some large mail hosters do stupid things which break the DKIM check when receiving emails. For example, one mail hoster adds a specific header line if it's not set already. When the sender MTA signs the non-existence of that header line in DKIM, the mail hoster's MTA adds the header line and the DKIM verification fails. Also, the RFCs for DKIM are sloppy and a few mail hosters have created their own standards.