ARC (Authenticated Received Chain)

標題的 ARC 是指 Authenticated Received Chain,是前陣子在 Hacker News 上看到「Gmail accepts forged YouTube emails (john-millikin.com)」這篇才發現的東西,原文在「Gmail accepts forged YouTube emails」這邊。

作者發現 Gmail 收了從不是直接從 YouTube 發出來的信件:

主要的原因是,Gmail 除了使用標準的 SPFDKIM 判斷外,還吃上面提到的 ARC。

查了一下 ARC,標準是 RFC 8617,目前還是被標成 experimental,主打是解決 forwarding 的問題,看了一下作者群是 LinkedIn (Microsoft)、GoogleValimail

ARC 這東西與之前 Google 在強推的 AMP (然後被罰) 以及現在在推的 Signed HTTP Exchanges 都有相同的味道,無視 security & privacy concern 的東西...

其他非 Google 的 Email Hosting 服務

先前在「Cloudflare 的 Email Routing 功能可以讓一般人用 (包括免費帳號)」這邊有提到,因為 Google Workspace 要廢掉免費版本,所以 Cloudflare 推出了 E-mail forwarding 的方案讓大家用,所以一種簡單的解決方法就是註冊另外一個免費的 Gmail 帳號,然後用 Cloudflare 把信件 forward 到新的帳號裡。

但如果想要避開 Google 的服務的話,在 Hacker News 上的「Ask HN: Best hosted alternative to Google Workspace for email?」這邊就有討論不少可能的替代方案,主要是付費的為主。

討論裡常被提起的方案:

我自己是很愛 Fastmail,他的 webmail 界面速度很快 (即使 www.fastmail.com 需要連到美國的伺服氣上),而且鍵盤快速鍵與 Gmail 幾乎相同,所以學習成本很低,就把其中一個 domain 掛上去用,然後把一些服務的註冊 email 都往這邊掛。

而費用的部份,除了可以月繳外,年繳與三年繳都有另外再給 discount (30GB 版本是 US$5/mo、US$50/y 與 US$140/3y),第一次用一年後,後面就是刷三年了...

如果有在用 Office 的話,Microsoft 365 應該也是個選擇方案,不過我對 Outlook 的 folder-based 的設計邏輯用不慣...

然後是 iCloud+,看討論裡面提到穩定度似乎不太行,但也有人用的好好的,我自己是只有拿來同步 Apple 裝置用,沒有用到郵件服務的部份...

另外是自己有架設 Email service,話說這年頭自己搞 Email system 超麻煩的,對於沒搞過的人 SPFDKIM 加上 DMARC 絕對會搞死自己,乖乖丟雲端服務比較省事,我純粹是要保持多路暢通而已...

用 Userscript 在 Gmail 裡面展開連結

前一篇「在 Gmail 裡面展開 GitHub 信件連結的 Userscript」是展開 GitHub 的連結,但這個套件是用document.querySelectorAll() 抓出來,裡面寫死了不少東西...

用了幾天後我還是只想開 commit 相關的連結 (用 regex 表示的話就是 ^https://github\.com/[^/]+/[^/]+/commit/),所以就找看看 Tampermonkey 能不能有 Config Page 或是 Option Page 可以讓使用者設定,結果發現本身沒支援:「Create a “config” or “options” page for a Greasemonkey script」。

但回覆裡面有提供一些方案可以用,我後來選了 MonkeyConfig,至少可以讓使用者設定 regex...

新的 Userscript 放在「open-links-in-gmail」這邊。

Gmail 宣佈支援 MTA-STS

Gmail 宣佈支援 MTA-STS:「Gmail making email more secure with MTA-STS standard」。這邊提到的 MTA-STS 是透過某些設定,讓 SMTP 送信時強制使用 TLS 的機制,可以參考「SMTP 的強加密連線機制」這篇。

可以看到有 TXT,也有 .well-known 檔案:

;; ANSWER SECTION:
_mta-sts.gmail.com.     300     IN      TXT     "v=STSv1; id=20171114T070707;"

$ curl https://mta-sts.gmail.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: gmail-smtp-in.l.google.com
mx: *.gmail-smtp-in.l.google.com
max_age: 86400

如果要自己設定的話可以參考 Google 提供的「About MTA-STS and TLS Reporting」這篇,不過目前中文版文件還沒有更新,請切到英文版...

另外一套將新版 Gmail 介面改回舊版的 CSS

先前是用「Gmail Old 2018 Nov」撐著,後來在「shellscape/gmail-classic」這邊看到另外一組 css,看起來這組好一些... 拿作者的圖片:

圓框與各種浮誇的 hover 效果都儘量關掉,用起來會好一些。

幾個 Web API Manager 要設定的東西...

在上一篇提到的「控制瀏覽器裡的 Web API」,用了一兩天後有遇到一些問題,大概整理一下...

  • Gmail 會開不起來,需要將 mail.google.com 列入白名單 (一個阻擋條件都不能設),這是因為遇到瀏覽器的 bug,在「General breakage on specific site · Issue #55 · snyderp/web-api-manager」這邊作者有找到問題,他判斷是瀏覽器的問題後開了 ticket 給 FirefoxChrome,不知道什麼時候會好...
  • 同理,Facebook 右上角的通知也出不來,也是同樣的問題,需要把 www.facebook.com 列入白名單。
  • 另外是 Google Maps 用滑鼠滾輪滾動本來是平滑式的縮放,現在用起來會變成階段式的縮放,原因是 Google Maps 用到 WebGL Specification (在 Lite 裡面會阻擋)。這有兩個方向可以改,一個是把 www.google.com (或是 www.google.com.tw,看你用的網域) 另外開一組設定管理,另外一個是直接把 WebGL Specification 的阻擋關掉。

目前遇到的大概就是這些了...

Gmail 支援第三方軟體掛入了...

以往都是第三方廠商要透過 browser extension 硬掛進去 (當 Gmail 改版的時候又要修),現在 Gmail 直接提供界面讓他們掛進來了:「Do more from your inbox with Gmail Add-ons」。

包括 Gmail 以及 G Suite 都能用 (應該會需要管理員掛進來?):

Knock out action items the minute they hit your inbox. G Suite and Gmail users can check out the G Suite Marketplace to find and install Gmail Add-ons.

另外也可以自己開發掛入:

If you're a developer, you can also easily create add-ons for your app or your organization—write your add-on code once and it will run natively in Gmail on web and Android right away. Learn more.

Gmail 要開始導入 SMTP Strict Transport Security 了

SMTP MTA Strict Transport Security 算是 SMTP STARTTLS 裡的 HSTS 機制,而 Google 的人在 RSA Conference 上提出要開始用了:「SMTP STS Coming Soon to Gmail, Other Webmail Providers」。

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.

補上去後對於 SMTP 的隱私保護就會更好了...