Amazon SES 提供 Dedicated IP Address 的養 IP 機制...

透過混搭本來的 shared IP address (已經對各 ISP 有信用) 與客戶租用的 dedicated IP address 混發,然後一段時間後養起來 (最多 45 days):「Amazon SES Can Now Automatically Warm Up Your Dedicated IP Addresses」。

Amazon SES controls the amount of email that can be sent through an IP address. Amazon SES uses a predefined warm-up plan that indicates the maximum number of emails that can be sent daily through an IP address to ensure the traffic is increasing gradually over 45 days.

要注意的是,這個過程需要發五萬封才有辦法養出來,不是設上去就會自己養

After you successfully warm up your dedicated IPs (either by yourself or by using the Amazon SES automatic warm-up mechanism), you must send at least 50,000 emails per dedicated IP per day so that the IPs maintain a positive reputation with ISPs. To avoid throttling by the ISPs, avoid sending a high volume of emails soon after the completion of warm-up; we recommend gradually increasing the volume for better deliverability.

現在弄 mail service 超麻煩的...

用 Google 的 Speech Recognition API 破 Google 的 reCAPTCHA

就是「以子之矛,攻子之盾」的概念,用 Speech Recognition APIreCAPTCHA:「ReBreakCaptcha: Breaking Google’s ReCaptcha v2 using.. Google」。

就算 Google 在 reCAPTCHA 的聲音裡面加入 watermark,讓自家的 Speech Recognition API 拒絕分析,還是有其他家的可以用 (像是 Amazon Lex 或是 Bing Speech API),所以這樣做不是什麼好解法。

自建 Mail System 的難度

Hacker News 上的「Ask HN: Is it possible to run your own mail server for personal use?」這篇道出了現在自建 mail system 的難度。作者遇到信件常常被各大 mail 服務歸類成 spam:

The problem is making sure my mail is not marked as spam by the major MTAs out there, gmail and hotmail both mark my mails as spam.

整理一下現在自己建 mail system 要做到哪些事情:

  • 確認 IP (包括 IPv4/IPv6) 沒有列入任何 Open Relay 清單中。
  • 確認 IP 的反解可以查出對應的正解。
  • 確認 SPF 設定。
  • 確認送出去的信件有 DKIM 簽名,而且 DNS 也有設上對應的設定。
  • 確認 TLS 的發送與接收都正常。
  • 確認 DMARC 機制正確運作。

如同「Exercising Software Freedom in the Global Email System」這邊講的,現在要自己搞 mail system 超累...

Amazon SES 可以收信了...

之前 Amazon SES 只能拿來發信,現在可以收信了:「New – Receive and Process Incoming Email with Amazon SES」。

收信下來後可以放到 S3,也可以用 SNS 接,或是用 Lambda 處理。除此之外還有 Spam & Virus 檢查的功能...

一時間想不到用途 :o

Google 發表計算網頁真實性的演算法 (Knowledge-Based Trust)

Slashdot 上看到 Google 發表了計算網頁真實性的演算法,Knowledge-Based Trust (KBT):「Google Wants To Rank Websites Based On Facts Not Links」,原始的論文 PDF 檔案可以在「Knowledge-Based Trust: Estimating the Trustworthiness of Web Sources」這邊取得。

論文本身的原理不難懂 (其實方法相當有趣),主要是給出了三個貢獻。

首先是能夠區分是取出資訊的方法有問題 (extract 的演算法不夠好),或是網站本身就給出錯誤的資訊:

Our main contribution is a more sophisticated probabilistic model, which can distinguish between two main sources of error: incorrect facts on a page, and incorrect extractions made by an extraction system.

第二個則是在效能上的改善:

Our second contribution is a new method to adaptively decide the granularity of sources to work with: if a specific webpage yields too few triples, we may aggregate it with other webpages from the same website. Conversely, if a website has too many triples, we may split it into smaller ones, to avoid computational bottlenecks (Section 4).

第三個則是提出好的分散式演算法,可以螞蟻雄兵計算出來:

The third contribution of this paper is a detailed, large-scale evaluation of the performance of our model.

KBT 並不是要取代 PageRank,而是跟 PageRank 互相配合,可以有效打擊內容農場 (Content farm) 這類網站,畢竟 PageRank 的假設在一般的狀況下是有邏輯的。

在「High PageRank but low KBT (top-left corner)」這段講到了這件事情:

We consider the 15 gossip websites listed in [16]. Among them, 14 have a PageRank among top 15% of the websites, since such websites are often popular. However, for all of them the KBT are in the bottom 50%; in other words, they are considered less trustworthy than half of the websites. Another kind of websites that often get low KBT are forum websites.

再找時間細讀其他類似的演算法...

把舊站的 comment 關掉...

這幾天 blog 常常出現 504,連到機器上發現 MySQL 很忙,才發現是舊站 spam 的量太大的問題造成的,把舊站的 comment 關掉後就好不少,現在看機器的 CPU loading 應該是正常多了。

新站已經是用 DISQUS 所以比較沒有 comment spam 的問題。舊站那邊除了關掉 comment 外,另外直接進 MySQL 把 2006 年之後的 comment 都丟到 pending 裡面去。(因為 2005 年 8 月後就沒更新舊站了)

來研究看看要怎麼把舊的 comment 丟進 Akismet...

Update:發現只要按下 Check for Spam 的按鈕就會把目前 Pending comments 都丟去 Akismet 掃,先丟著 :p

電冰箱也是會「中毒」的...

Slashdot 上看到電冰箱被攻陷當成跳板,被拿來發廣告信:「The Spamming Refrigerator」。BBC 的報導在「Fridge sends spam emails as attack hits smart gadgets」。

原始報導是「Proofpoint Uncovers Internet of Things (IoT) Cyberattack」這篇。

就報導的文章裡看不出來是什麼智慧型電冰箱...

Google Chrome 上預防 Clickjacking 的套件...

Gene 寫的「如何在你不知情被自動加入粉絲團的秘技, 以 "粉你的" 作示範」這篇裡面用到的技巧叫做 Clickjacking (點擊劫持)。

Facebook 有給出「What is clickjacking?」的說明,不過相當白話 (而且沒有幫助 Orz)。

技術上的解釋是,其中一種實作是在要點擊的對象上加上一層「透明的」DOM 物件,當 click 時就會點到該物件。目前最常見的是 Facebook 的 Like 按鈕。(i.e. Gene 寫的那篇)

Google Chrome 上可以用「Clickjacking Reveal」這個套件:

This extension tries to warn you if it found clickjacking technique on the page you are viewing.

Tired because of webpage tricks you into clicking social network buttons? This extension will try to detect those hidden bad buys and force them to show themselves.

效果是這樣:(範例出自「胖妞變身大美女 甩肉40斤練出腹肌」這篇)

Twitter 與研究員合作打擊 Twitter Spammer

研究員在取得 Twitter 的同意後 (Twitter 的 ToS 禁止帳號販賣轉移),十個月內透過 27 個不同的買家,花了 USD$5000 購買了 12 萬個帳號:「Researchers Buy Twitter Bots To Fight Twitter Spam」、「Buying Battles in the War on Twitter Spam」。

整份研究發在 USENIX Security '13 上:「Trafficking Fraudulent Accounts: The Role of the Underground Market in Twitter Spam and Abuse」,有 PDF 可以下載。

可以看到 Hotmail 是裡面比率最高的:

論文後面提到要如何利用這些買來的帳號,透過演算法計算後,判斷還有哪些帳號是可疑的帳號。然後透過 Twitter 的合作交叉比對,給予這些地下盤商致命性的打擊...