In particular, the sequence "<LF>.<LF>" (bare line feeds, without carriage returns) MUST NOT be treated as equivalent to <CRLF>.<CRLF> as the end of mail data indication.
但除了被禁止的 \n.\n 外，這次的攻擊用了其他的排列組合嘗試。
在 GMX、Ionos 以及 Microsoft Exchange Online 的 SMTP server 上發現都吃 \n.\r\n：
However, as already mentioned, SMTP smuggling doesn't work for every receiving inbound SMTP server and, in this case, requires inbound SMTP servers to accept <LF>.<CR><LF> as end-of-data sequence.
Same as GMX and Ionos, Exchange Online allowed smuggling via a <LF>.<CR><LF> end-of-data sequence as well, which makes it possible to smuggle from every domain pointing their SPF record to Exchange Online.
而 Cisco Secure Email (Cloud) Gateway 支援 \r.\r：
By default, Cisco Secure Email (Cloud) Gateway accepts . as end-of-data sequence, which does not get filtered by the following SMTP servers when sending outbound:
Unfortunately, criticial information provided by the researcher was not passed on to Postfix maintainers before publication of the attack, otherwise we would certainly have convinced SEC Consult to change their time schedule until after people had a chance to update their Postfix systems.
As part of a non-responsible disclosure process, SEC Consult has published an email spoofing attack that involves a composition of email services with specific differences in the way they handle line endings other than <CR><LF>.
As documented in the timeline of the blog post, the vulnerabilities were initially identified in June 2023 and after further internal research we contacted the specific, affected vendors (Microsoft, Cisco, GMX/Ionos). GMX and Microsoft fixed the issues promptly. But after receiving some feedback from Cisco, that our identified vulnerability is just a feature of the software and not a bug/vulnerability, we contacted CERT/CC on 17th August to get some help for further discussion with Cisco and involve other potentially affected vendors (such as sendmail) through the VINCE communication platform.
