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 後似乎暫時停了...?

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

Google SRE 團隊整理出過去二十年的十一條心得

Google 的 SRE 團隊整理出過去二十年的心得,當看故事的心態在看的:「Lessons Learned from Twenty Years of Site Reliability Engineering」,在 Hacker News 上也有討論:「Lessons Learned from Twenty Years of Site Reliability Engineering (sre.google)」。

裡面的項目大多都會在公司成長時不斷的導入,都是夠大就會遇到的。

比較有趣的是第六條,這是唯一一條全部都用大寫字母列出來的:

COMMUNICATION CHANNELS! AND BACKUP CHANNELS!! AND BACKUPS FOR THOSE BACKUP CHANNELS!!!

到 Google 這個規模的架構,這邊就會規劃找完全獨立於 Google 架構的方案來用;我猜應該是傳統的 colocation 機房 (像是 AT&T 之類的),上面跑 IRC server 之類的?

在 Hacker News 上面也有其他人提到 Netflix 也有類似的規劃,需要有一個備援的管道是完全獨立於 AWS 的;另外同一則 comment 裡也有提到 Reddit 的作法是在辦公室裡面放 IRC server 備援:

Yes! At Netflix, when we picked vendors for systems that we used during an outage, we always had to make sure they were not on AWS. At reddit we had a server in the office with a backup IRC server in case the main one we used was unavailable.

IRC 還是很好用的 XD

在 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 出來,也許後續也可以看看...

GCP 的 IPv4 也要漲價了

前幾天收到 GCP 的信件,提到 2024/02/01 開始 IPv4 address 要漲價了,在「External IP address pricing」這邊也可以翻到這些資訊。

External IP 的部分,漲 25%:

Static and ephemeral IP addresses in use on standard VM instances will go from $.004 to $.005.

Static and ephemeral IP addresses in use on preemptible VM instances will go from $.002 to $.0025.

用一個月 720 小時算,一般 VM 的費用等於是從 $2.88/mo 漲到 $3.6/mo 左右的費用。

Cloud NAT 吃的 IPv4 address 的部分,從本來沒有收變成要收費:

Static and ephemeral IP addresses mapped to Cloud NAT Gateway will go from No Charge to $0.005.

GCP 提供每個區域的 Standard Tier Networking 每個月 200GB 的免費頻寬

GCP 提供每個區域 Standard Tier Networking 每個月有 200GB 的免費頻寬:「Announcing 200 GB free Standard Tier internet data transfer per month」。

這類優惠應該是要給練習或是試用的人用的,吸引他們放一些量上來...

另外雖然是每個區域都有 200GB/mo 的 free bandwidth,但通常也只會用一個或兩個區域,以台灣的 asia-east1 來說,如果有量在上面跑的話,省下來的會是 $0.07/GB 這個部分,大概就是 $14/mo 左右?

Google 翻譯的中文詞彙

先前在網路上看到「Google 翻譯修好了沒? Has Google Fixed Translate Yet?」這個網站,看起來是 2021 年的時候建立的,整理出來希望可以改善 Google 翻譯在台灣所使用的中文 (zh-tw) 的翻譯品質,上面列了五十幾個詞彙,記得當時只有一個有修正,其他都還是中國或是香港的用語。

(話說 Google 翻譯的介面好像沒有分台灣跟香港...)

因為看到有英文的說明,就順手丟上 Hacker News:「Has Google Translate been fixed yet? (isgooglefixed.tw)」,還蠻意外的有些關注與討論... 大概是因為這樣,可能讓 Google 內有個整理過資料可以開 issue,過了一個月,上個禮拜陸陸續續被修正了不少詞彙,目前剩下的那幾個比較接近詞彙準確性的問題。

下一個可能是 Google Maps 上面的翻譯問題?就算切到 zh-tw 下還是會出現港式翻譯:

而把 Google Maps 英文版上看到的「Chophouse restaurant」丟進 Google Translate 翻譯是:

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 得養頗久... 不過這個也是很久前的事情了。

Google Chrome 將在 115 版之後預設使用 HTTPS 連線

Google Chrome (Chromium) 宣布 115 版後將預設使用 HTTPS 連線:「Towards HTTPS by default」。

查了一下 115.0.5790.98 是 2023/07/18 就出的版本,現在才冒出這篇文章有點晚,但大概就是講一下幹了什麼事情?

We're currently experimenting with this change in Chrome version 115, working to standardize the behavior across the web, and plan to roll out the feature to everyone soon.

主要的差異是在於,即使你輸入或是點擊的連結是 http://,他還是會優先嘗試 HTTPS:

Chrome will automatically upgrade all http:// navigations to https://, even when you click on a link that explicitly declares http://.

只有在 http:// 連結遇到 upgrade 到 HTTPS 失敗時才會回頭用 HTTP:

This works very similarly to HSTS upgrading, but Chrome will detect when these upgrades fail (e.g. due to a site providing an invalid certificate or returning a HTTP 404), and will automatically fallback to http://.

而本來就用 https:// 的連線就完全不會碰 HTTP 了。

講到推動 HTTPS 這點,前陣子剛好也是 Snowden 揭露美國 PRISM (菱鏡計畫) 十年的日子,當年在揭露後也因此加速了各種加密技術的基礎建設,像是 Let's Encrypt,而這也使得 HTTPS 更加普及,也讓 Google Chrome 現在可以預設切 HTTPS。