Google 讓不支援 OAuth 的程式可以用傳統的 username + password 的方式連線，產生一組 application password 讓這些程式使用，這個在 Google 的系統裡被稱作是 Less Secure Apps (LSAs)，主要是 protocol-based 的方式：
This includes all third-party apps that require password-only access to Gmail, Google Calendar, Contacts via protocols such as CalDAV, CardDAV, IMAP, SMTP, and POP.
主要的安全性考量應該是在 application password 貼到對應的應用程式這段，會隨著不同的貼法而有資安疑慮。透過非 end-to-end encryption 的 IM 傳輸，那麼 IM 的系統裡面就會有這組 application password 了。
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.
You are sending to Amazon SES from an Amazon EC2 instance via port 25 and you cannot reach your Amazon SES sending limits or you are receiving time outs—Amazon EC2 imposes default sending limits on email sent via port 25 and throttles outbound connections if you attempt to exceed those limits. To remove these limits, submit an Amazon EC2 Request to Remove Email Sending Limitations. You can also connect to Amazon SES via port 465 or port 587, neither of which is throttled.
Amazon EC2 throttles traffic on port 25 of all EC2 instances by default, but you can request that this throttle be removed for your instance at Request to Remove Email Sending Limitations (you must sign in with your root account credentials). Provide a description of your use case for sending email, and then choose Submit.
Elie Bursztein, the head of Google’s anti-abuse research team, said at RSA Conference that SMTP STS will be a major impediment to man-in-the-middle attacks that rely on rogue certificates that are likely forged, stolen or otherwise untrusted. Google, Microsoft, Yahoo and Comcast are expected to adopt the standard this year, a draft of which was submitted to the IETF in March 2016.
