微軟的 Outlook 系統會自動點擊信件內的連結

前幾天在 Hacker News Daily 上翻到的,微軟的 Outlook 系統 (雲端上的系統) 會自動點擊信件內的連結,導致一堆問題:「“Magic links” can end up in Bing search results — rendering them useless.」,在 Hacker News 上的討論也有很多受害者出來抱怨:「“Magic links” can end up in Bing search results, rendering them useless (medium.com/ryanbadger)」。

原文的標題寫的更批評,指控 Outlook 會把這些 link 丟到 Bing 裡面 index,這點還沒有看到確切的證據。

先回到連結被點擊的問題,照文章內引用的資料來看,看起來是 2017 年開始就有的情況:「Do any common email clients pre-fetch links rather than images?」。

As of Feb 2017 Outlook (https://outlook.live.com/) scans emails arriving in your inbox and it sends all found URLs to Bing, to be indexed by Bing crawler.

在 Hacker News 上的討論也提到了像是 one-time login email 的機制也會因此受到影響,被迫要用比較費工夫的方法讓使用者登入 (像是給使用者 one-time code 輸入,而不是點 link 就可以登入)。

先記起來,以後在設計時應該會遇到,要重新思考 threat model...

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 的東西...

Ptt 信件伺服器 node.ptt.cc 查不到反解的問題

就如同標題所說的,Ptt 對外寄信的伺服器 node.ptt.cc 查不到反解的問題:

$ host node.ptt.cc
node.ptt.cc has address 140.112.172.16
$ host 140.112.172.16
Host 16.172.112.140.in-addr.arpa not found: 2(SERVFAIL)

情況大概是這樣,Ptt 使用的 140.112.172.0/27 這個網段 (尾碼從 0~31) 不是 /24 以上的範圍,而 140.112.172.0/24 是台大計中管轄範圍,所以台大就把 140.112.172.x 這段的反解 PTR record 用 CNAME 的方式指到 x.0-31.172.112.140.in-addr.arpa,像是 140.112.172.16 這樣:

;; ANSWER SECTION:
16.172.112.140.in-addr.arpa. 86400 IN   CNAME   16.0-31.172.112.140.in-addr.arpa.

然後再針對 0-31.172.112.140.in-addr.arpa 設定 NS RR 到 ns0.ptt.ccns1.ptt.cc 兩台 NS server:

;; AUTHORITY SECTION:
0-31.172.112.140.in-addr.arpa. 86400 IN NS      ns1.ptt.cc.
0-31.172.112.140.in-addr.arpa. 86400 IN NS      ns0.ptt.cc.

但是 ns0.ptt.ccns1.ptt.cc 都不見了:

$ host ns0.ptt.cc
Host ns0.ptt.cc not found: 3(NXDOMAIN)
$ host ns1.ptt.cc
Host ns1.ptt.cc not found: 3(NXDOMAIN)

導致反解查不到對應的資料 (會是 SERVFAIL):

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58463

猜了一下,看起來 ns0.ptt.cc 還活著,只是 Cloudflare 上面的 DNS record 沒設定過去:

$ dig ns0.ptt.cc @140.112.172.16

;; ANSWER SECTION:
ns0.ptt.cc.             300     IN      A       140.112.172.16

不過 ns1.ptt.cc (140.112.172.10) 看起來就沒服務了,但至少在 Cloudflare 上補個 DNS record 上去應該就會動了 (只是沒有兩台互相備援)。

關於自己架設 E-mail server 的事情

自己架設 E-mail server 的難處算是每過一陣子在 Hacker News 上就會冒出來討論的題目:「Ask HN: Why can't I host my own email?」。

收信只要有固定 IP,加上 ISP 沒有擋 TCP port 25 就倒不是問題,整個最難的點在於怎麼送信,因為會常常被標成 spam...

最基本要設定的東西大概是 SPF,但通常還是建議連 DKIM 一起搞定。另外 DMARC 也弄一下會比較好。

然後依照經驗,Gmail 擋信的機率低不少,微軟家擋信的情況就多很多 (包括免費的 E-mail 服務與付費的 Microsoft 365)...

目前一般建議是自用就過 Amazon SES,沒有低消所以個人用起來不貴...

Amazon SESv2 的 Deliverability Dashboard

其實是看到「Amazon SES V2 now supports email size of up to 40MB for inbound and outbound emails by default」這篇才注意到寄信的 Amazon SES 服務有了 SESv2,原文主要是講放寬信件的大小限制:

With this launch, the default message size limit in Amazon SES V2 increases from 10MB for email sending and 30MB for email receiving, to 40MB for both sending and receiving .

不過我跑去「Amazon SES pricing」看的時候意外翻到這個貴貴的東西:

The Deliverability Dashboard (via the SES API V2) is available for a fixed price of USD $1,250 per month. This charge includes reputation monitoring for up to five domains and 25 predictive email placement tests.

然後我試著去找 Deliverability Dashboard 是什麼,卻沒有專文介紹?(還是我找錯關鍵字...)

倒是在 2018 年的時候 Amazon Pinpoint 有個公告提到 Deliverability Dashboard,價錢也是 US$1,250/mo:「Amazon Pinpoint Announces a New Email Deliverability Dashboard to Help Customers Reach their Users' Inboxes」。

本來以為是 Amazon Pinpoint 的服務轉移掛到 SESv2 下,但看「Amazon Pinpoint Pricing」這邊,好像還是在啊...

雖然用不太到,但還是一頭霧水 XDDD

Mutt 現有維護者的節能宣告

Hacker News 上看到「Mutt 2.2.0 (mutt.org)」這篇,Mutt 的維護者 (應該是 Kevin McCarthy) 將只會負責 fix 類的事情了:

This obviously isn't a feature, but I wanted to mention that I will be moving away from Mutt maintainership after this release. There isn't a transition plan, so I'll keep maintaining the 2.2.x series with bug fixes and security issues.

It's been my pleasure to keep the releases coming since version 1.5.24. Unfortunately the past year, my time and energy available has been decreasing. So my plan is to focus the time I do have on keeping Mutt stable, secure, and bug free; until someone else has the desire to head up (and support) new-feature releases. Thank you everyone!

有人在討論串裡提到了 NeoMutt,也許之後會找機會看看...

目前還是有一套 email system 是跑在 Postfix + Procmail + Bogofilter + Mutt 上面,短期內應該不會換...

其他非 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 絕對會搞死自己,乖乖丟雲端服務比較省事,我純粹是要保持多路暢通而已...

Cloudflare 的 Email Routing 功能可以讓一般人用 (包括免費帳號)

Cloudflare 宣佈 Email Routing 這個 beta 功能可以讓一般人用 (包括免費帳號):「Email Routing is now in open beta, available to everyone」。

當然,你要先有心裡準備 Cloudflare 會看得到信件裡面的內容,之後可能會幹些有的沒的事情...

這次會把這個功能開放出來,可以看到主要是 G Suite legacy 宣佈要收費的關係:

Most recently, with users wanting to set up Email Routing for more of their domains and with some of G Suite legacy users looking for an alternative to starting a subscription, we have been onboarding tens of thousands of new zones every day into the closed beta.

透過這個功能,至少收信的部份可以透過 Custom addresses 這個功能轉到個人版的 Gmail 或是其他的 email system 上,另外也可以透過 Catch-all address 的功能直接收所有信件,以免費的系統來說,看起來還行,而發信的部份就透過自己本來的 email system 來發,這樣 Cloudflare 看起來也不需要處理 spam 之類的問題。

SendGrid 意外的被幹翻...

看到 Hacker News 上的「Ask HN: Great tools for solo SaaS founders?」這則,在討論有哪些服務好用的,有人提到了 SendGrid 做為 email 發送服務,結果沒想到下面一堆人幹翻 XDDD

蠻多人推薦 Postmark 的,另外有人提到 SparkPost

另外可以看一下「Hacker News Tools of the Trade」,之前要找工具都會往這邊翻翻...

Amazon SES 總算支援 2048 bits RSA key 了

Amazon SES 總算是支援 2048 bits RSA key 了:「Amazon SES now supports 2048-bit DKIM keys」。

然後講一些幹話... 隔壁微軟早在 2019 年就支援 2048 bits RSA key 了:

Until now, Amazon SES supported a DKIM key length of 1024-bit, which is the current industry standard.

另外用 ECC 演算法的一直都沒進 standard,像是已經先 book 了 RFC 8463 位置的 Ed25519,在 draft 狀態放好久了:「A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)」,還有用 ECDSA 的「Defining Elliptic Curve Cryptography Algorithms for use with DKIM」也是放著,不知道是卡到什麼東西,可能是專利?