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

其他非 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」也是放著,不知道是卡到什麼東西,可能是專利?

Amazon SES 開東京區與新加坡區了...

Amazon SES 是 2011 年年初發表的服務,過了九年總算想起來這幾區也是需要 SES 的服務了...:「Amazon Simple Email Service is now available in the US East (Ohio), Asia Pacific (Singapore), Asia Pacific (Tokyo), and Asia Pacific (Seoul) Regions」。

這些年來大家應該都是用 us-west-2 或是 us-east-1 workaround 很久了,現在開這些區域主要還是讓 API 的整合會比較方便,如果本來就是透過 IAM user + username + password 的方式寄信的話就沒什麼差...

另外一種是寄比較大的信件 (產生的流量很大),這次這樣可以避免降低跨區而被收兩次流量費用,不過這應該是比較少見的情況...

強制每個 Git Repository 都要設定使用者資訊

看到「Setting Up Git Identities」這篇,裡面提到的方法可以解決 Git 裡有多個身份時常見的用錯身份的問題...

個人的 Git repository 會希望用自己的 email address,而公司的 Git repository 則是希望用公司的 email address,但 Git 預設會使用 username 與 hostname 組一個出來,所以常常是推到公司的機器上後才發現 Git repository 沒設定公司的 email address...

上面提到的文章就是關掉 Git 預設會組合的行為,於是就會記得要設定了:

git config --global user.useConfigOnly true

然後記得要把全域設定裡的 nameemail 拔掉,另外有些人可能會掛上 signingkey 也一起拔掉:

git config --global --unset user.name
git config --global --unset user.email
git config --global --unset user.signingkey

這樣當沒設定時想要 git commit,就會被擋下來要求你提供,就能避免把自己的 email address 混在公司的 Git repository 裡面了...

Amazon SES 增開三區...

Amazon SES 居然加開服務區域了:「Amazon SES is Now Available in Three Additional AWS Regions」。

當初猜測一直沒增加的原因是法規的問題,各國對於 spam 的處理方式不同,有些地區可能會導致 AWS 有連帶責任之類的。這次還是沒開日本與新加坡,看起來應該也是評估後覺得不會有問題的才開:

Amazon Simple Email Service (Amazon SES) is now available in the Asia Pacific (Mumbai), Asia Pacific (Sydney), and EU (Frankfurt) Regions, in addition to the US East (Virginia), US West (Oregon), and Europe (Ireland) regions.

這樣看起來對於東京的使用者應該還是會去用美西的服務,但新加坡的使用者就有機會改用澳洲的服務了...