Google Groups 脫離 Usenet 系統

先前在「Google Groups 將在 2024/02/22 斷開與 Usenet 的連接」這邊提到的,Google Groups 在 2024/02/22 會斷開與 Usenet 的 NNTP peering,日子到了...

在 Google Groups 上官方更新 banner 訊息了:

從我自己架的 News Server 上也可以從 innreport 中 incoming feed 的各個指標看到差異了:

可以再觀察幾個月看看後續的量,原先使用 Google Groups 的人會跑來 Usenet 上面嗎?或是 Usenet 就繼續萎縮下去...?

停止使用 Spamhaus DNSBL

剛剛看到「If you query Spamhaus Projects’ legacy DNSBLs via DigitalOcean move to the free Data Query Service」這篇,覺得愈來愈詭異了,研究了目前的情況後決定停用 Spamhaus

現在已經愈來愈少自己架設 mail server 了,不過我自己還是留了幾個 domain 跑在自己架設的 Postfix 上面,最主要是 command line 下面用 Mutt 讀信還是蠻方便的,另外一方面是確保一個信箱是不受到大企業的管制。

如果不是拿套裝軟體直接架設的話,自己架設 mail server 會有不少東西要設定:在 MTA 這端通常會使用 DNSBL 擋掉已知會發 spam 的 IP address。

DNSBL 的原理不難,就是拿 IPv4 address 組合一個 hostname,透過 DNS 查詢就會知道這個 IPv4 address 是否在清單;換句話說,就是拿 DNS protocol 當作 API,當作資料庫查詢。

舉個例子來說,假設我要查 188.235.18.134 這個位置的情況 (從「Worst /24 blocks based on total spam count」這邊翻出來的),這邊使用 SpamCop 的清單,我先把 IPv4 address 反過來變成 134.18.235.188,然後再加上 SpamCop 所指定的 bl.spamcop.net,變成 134.18.235.188.bl.spamcop.net,接下來查詢就可以查到:

134.18.235.188.bl.spamcop.net has address 127.0.0.2

如果是 168.95.1.1 的話,同樣方法組合成 1.1.95.168.bl.spamcop.net 可以看到沒有在 SpamCop 清單內:

Host 1.1.95.168.bl.spamcop.net not found: 3(NXDOMAIN)

這邊選擇用 DNS 的好處包括了 DNS resolver 及 DNS library 自然的 cache,不需要 Postfix 這類 MTA 再自己實作 cache 層,對於有大量信件 (無論是正常的或是 spam) 進來的時候也不會造成提供清單的服務大量的負載。

回頭來說 Spamhaus 的情況,他們公告要擋 DigitalOcean 的理由很奇怪,因為 DigitalOcean 架設了自己的 mirror 所以他們不知道使用的量,要使用者去 Spamhaus 上註冊申請後拿到一個自己的 your_DQS_key.zen.dq.spamhaus.net 使用。

有了 unique key 在 query,這樣就給了 Spamhaus 很清晰追蹤資料,加上 Privacy Policy 裡面的資訊:

We may have to share your personal data with the parties set out below for the purposes set out in the table in paragraph 4.
[...]
– Third parties to whom we may choose to sell, transfer, or merge parts of our business or our assets. Alternatively, we may seek to acquire other businesses or merge with them. If a change happens to our business, then the new owners may use your personal data in the same way as set out in this privacy notice.

這樣就知道他們想要做什麼了...

另外一方面,查資料的時候發現他們已經擋掉 Google Public DNS 以及 Cloudflare DNS

這是我自己架設 Unbound 的查詢:

gslin@home [~] [05:09/W4] host 2.0.0.127.zen.spamhaus.org
2.0.0.127.zen.spamhaus.org has address 127.0.0.10
2.0.0.127.zen.spamhaus.org has address 127.0.0.4
2.0.0.127.zen.spamhaus.org has address 127.0.0.2

這是 Google Public DNS (8.8.8.8):

gslin@home [~] [05:09/W4] host 2.0.0.127.zen.spamhaus.org 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases: 

Host 2.0.0.127.zen.spamhaus.org not found: 3(NXDOMAIN)

這是 Cloudflare DNS (1.1.1.1):

gslin@home [~] [05:09/W4] host 2.0.0.127.zen.spamhaus.org 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases: 

2.0.0.127.zen.spamhaus.org has address 127.255.255.254

在 Spamhaus 的「Frequently Asked Questions (FAQ)」這篇裡面有提到 127.255.255.254 的回應是「Query via public/open resolver」:

127.255.255.252	Any	Typing error in DNSBL name
127.255.255.254	Any	Query via public/open resolver
127.255.255.255	Any	Excessive number of queries

所以還蠻清楚這家的東西已經不能碰了...

Google Groups 將在 2024/02/22 斷開與 Usenet 的連接

在 news.admin.peering 上看到的消息:「Effective February 15, 2024, Google Groups will no longer support new Usenet content」,在 Google Groups 上面也可以看到:

Effective February 15, 2024, Google Groups will no longer support new Usenet content. Posting and subscribing will be disallowed, and new content from Usenet peers will not appear. Viewing and searching of historical data will still be supported as it is done today.

而在 Hacker News 上也有討論「Google Groups ending support for Usenet (support.google.com)」。

話說先前寫的「Google Groups 的 spam 的量又下降了不少...」這篇,後來又有發現不是 Google Groups 的 spam 減少,而是 Cleanfeed 裡面用 SpamAssassin 會造成跑久以後會 100% CPU,反而接收的速度慢下來...

在上了 workaround 後 (每個小時自動重跑一次 innd),可以看到其實完全沒有變少,反而愈來愈多:

倒是後來一直丟 corpus 進去練 SpamAssassin 後看起來效果好很多了,還是會看到一些 spam,但就沒那麼多了...

Google Groups 的 spam 的量又下降了不少...

延續「從 Google Groups 送出來的 spam 數量稍微下降...」這邊的觀察,從 10/22 到 10/29 降了 2/3 左右,再往後拉七天到了 11/5 可以看到又少了 3/4 左右。

另外整個 article volume 看起來也有降很多,從三個不同的 peering 來的量都有降,看起來是從源頭就有做一些事情。

這是 10/22 的量:

這是 10/29 的量:

這是 11/5 的量:

從 Google Groups 送出來的 spam 數量稍微下降...

先前在「Google Groups 的巨量 spam」這邊提到從 Google Groups 倒進 usenet 大量的 spam,最近看起來稍微緩解了一些。

這是 10/22 的量:

這是 10/29 的量:

可以看出來整體被 Perl filter 擋下來的量大幅降低了,在 comp.lang.c 也可以看出來 10/28 後似乎暫時停了...?

只能繼續觀察看看了...

在 Cleanfeed 裡面用 Mail::SpamAssassin 的 Bayesian filter 來擋 Google Groups 的垃圾

本來單純用 Cleanfeed + Mail::SpamAssassin 擋,效果其實不太好:「Google Groups 的巨量 spam」。

後來在 news.software.nntp 討論區裡面有人提到應該要用 sa-learn 訓練:

OK, now you need a ~/.spamassassin directory for your news user and a user_prefs file in that directory. After that you can start adding rules for Usenet spam. You will also need to feed several hundreds of spam and ham articles to sa-learn --spam or sa-learn --ham as the news user. After that, SpamAssassin will gradually improve.

死馬當活馬醫看看,結果看起來效果就出來了:

累積了幾天下來後,單看跑進 comp.lang.c 裡面的 spam 與 Mail::SpamAssassin 這邊擋下來的量,差不多是 99%+ 的量,接下來就是有看到的部分再丟進去 train。

目前看起來唯一的問題就是 Google Groups 的 spam 量真的很大,導致 innd 因為跑 Mail::SpamAssassin 的 bayesian 運算時 CPU usage 會高不少,偶而會撞到 100%,但不是常態所以還好。

繼續觀察看看...

Google Groups 的巨量 spam

Google Groups 的 spam 使得 Usenet 上不少群組都受到波及了,像是 comp.lang.c 的 spam 量已經多到是每天上萬則在上面:

目前看起來 Cleanfeed 擋不住,我試著寫個小 hack (是還蠻 hack 的),在 cleanfeed.local 裡面用 SpamAssassin 過濾,效果也很不好:

目前最佳解應該就是直接擋掉 Google Groups,另外似乎是有人包裝好 NoCeM 出來,也許後續也可以看看...

Amazon SES 寄到 Gmail 受到阻擋的情況

我自己沒遇過,但是 Hacker News 上看到有人有遇到,所以記錄起來:「Tell HN: Gmail rate limiting emails from AWS SES」。

Amazon SES 預設是共用 IP pool,所以遇到這種情況不算太意外,但應該是暫時性的,不過發問的作者有提到後來的解法是花 US$25/mo 使用 Dedicated IP 解決 IP reputation 的問題 (在 id=37177533 這邊):

Thanks you all for comments. I have made a decision to subscribed to dedicated IPs (credits: @slau).

The differentiating factor between our current AWS SES plan and the competitors (mentioned in the comments) is having a dedicated IP. With our current volume, none of the competitors are anyway near AWS SES costs. So, moving to a dedicated IPs thats cost 25$ extra not only solves our issue, but also no change in code/infrastructure.

記得以前另外一個教訓是,寄信還是儘量用 IPv4 address 去寄,因為 IPv6 address 的 reputation 得養頗久... 不過這個也是很久前的事情了。

Fake GitHub Star 的生意

昨天在 Hacker News 首頁上看到「Tracking the Fake GitHub Star Black Market (dagster.io)」這篇,原文在「Tracking the Fake GitHub Star Black Market with Dagster, dbt and BigQuery」這邊。

作者群想要偵測 GitHub 上面 fake star 的行為,所以就跑去找黑市買,然後找到了兩家,Baddhi Shop (1000 個 $64) 與 GitHub24 (每個 €0.85,大約是 $0.91),價錢差異很大,「品質」差異也很大:貴的 star 在一個月後還是存在,而便宜的看起來有一些有被 GitHub 偵測到而清除掉:

A month later, all 100 GitHub24 stars still stood, but only three-quarters of the fake Baddhi Shop stars remained. We suspect the rest were purged by GitHub’s integrity teams.

接下來就是想要系統化分析,切入點是 GH Archive 這個服務,可以直接下載 GitHub 全站上的 public evnets 資料:

GH Archive is a project to record the public GitHub timeline, archive it, and make it easily accessible for further analysis.

想要偵測兩種不同的 fake account,第一種是 obvious fake account,定義成這樣:

  • Created in 2022 or later
  • Followers <=1
  • Following <= 1
  • Public gists == 0
  • Public repos <=4
  • Email, hireable, bio, blog, and twitter username are empty
  • Star date == account creation date == account updated date

從定義就可以看出來完全就是灌水帳號,開出來就沒在動的。從 screenshot 可以看出這種帳號長的都一樣:

另外一種則是透過演算法去分析,這邊拿 unsupervised clustering 類的演算法分析出來的結果,可以看到抓到很多:

最近 NN 類的 machine learning 演算法太多,看到這些傳統的 machine learning 演算法還是覺得頗新鮮的...

關於自己架設 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,沒有低消所以個人用起來不貴...