非常嚴謹的 sina.com

最近客戶投訴他在 datacenter 的郵件伺服器不能寄信到 vip.sina.com 的戶口。每次都會退信:

> I'm sorry to have to inform you that your message could not
> be delivered to one or more recipients. It's attached below.
>
> For further assistance, please send mail to
>
> If you do so, please include this problem report. You can
> delete your own text from the attached returned message.
>
> The Postfix program
>
> : host mx1.vip.sina.com[218.30.115.251] said: 554 5.7.1
> : Sender address rejected: Dynamic IP without SPF,
> see http://www.openspf.org (in reply to RCPT TO command)
>

嘩!! 第一次見到收信人要求寄信人一定要有 SPF record!!! 做了一些調查和研究:

1. vip.sina.com 是首先會 check sender smtp server ip address 的，似乎她認為這 ip address 是有懷疑時才要求 sender 要有 SPF record。
2. 這是因為我利用其他 smtp server ，例如 (smtp.netvigator.com) 是可以寄信的。
3. 在DNS 內加上了 SPF Record 後果然可以在原先客戶在 datacenter 的 SMTP server 寄信。
4. 奇怪的是我在其他沒有登記在 SPF Record 內的 smtp server 也可以用客戶 domain name 寄信了。(原先這 smtp server 是寄不到信給 vip.sina.com)。好明顯的是 sina.com 重視的是 SPF Record 存在與否。內容是甚麼似乎是其次。XDDD

Email Migration (續篇)

我在 Email Migration 這一篇介紹了如何利用 postfix 的 transport file 來做 email migration 的過程，但有一點是要留意的:

要和 ISP (或原來的 email provider) 事前計劃好，MX 轉了後，他們仍然會繼續接收 email。

我最近跟 PCCW 的 Netvigator 「搏鬥」了幾小時。原來他們的替客戶 host email 和 DNS MX 是一個整合服務。客戶轉了 MX Record 則代表 email hosting 服務也取消了。我是在轉了 MX Record 的翌日 (即 TTL 完了後) 在 maillog 上發現全部轉到 Netvigator 的 MTA 的電郵都是 "Relaying Denied"。手動測試也證實他們已將我客戶的 domain 在 email hosting 除去了。我立即致電給他們技術支援部，憤怒的是他們要幾小時後才有一位職位較高的技術人員回電給我 (或者可以說轉了又轉才有人知道我是投訴甚麼)。

我跟此人講了接近一小時，我要他明白 Email hosting 和 MX Record 是兩碼子事情，轉了 MX Record 不代表你可以取消 Email hosting 。外面有很多 Email Management 服務公司就是將 MX record 轉了給他們後做 email filtering (或其他處理) 才轉回原有的 hosting 公司。
再者就算取消 email hosting 也不應在 TTL 完了就立即執行 (其實我問過此位技術人員能否好肯定的告訴我是否 TTL 完了就取消，他也不知道...) 全世界有很多 internal DNS server 可能仍然 cache 舊的 netvigator MTA ，你這麼一做就會令對方寄不到信。
但無論我怎麼說，他都是機械地說這是公司的政策，Email hosting 是取消了。

算!!! 收線!! 和客戶商議後立即 postfix 的 transport 轉信取消。

故事到此還未完!! 當我下一天不死心的再測試 Netvigator 的 MTA 時發現他又再接受我客戶的 domain 了。真是一個字 : 妖!!

Email Migration

我的一個客戶一向都是在 ISP host 他公司的電郵的，因為希望有更為大的電郵管理彈性，所以選擇了在公司內 host email server。有關 email migration 的過程可以跟大家分享一下:

MX record 當然要改為新 server 的 ip address。但如果轉了 MX record ，那麼一般用戶就需要兩邊收電郵了 (因為寄件人的 smtp server 可能仍然 cache 舊的 mx record)，為了避免這種情況，我會先將新的 email server 改為轉寄閘道器 (relay gateway) 幾天 (通常我會用 DNS 的 TTL (time to live) x 3)。那麼縱然 MX record 轉了，用戶在這幾天仍然使用 ISP 的 server 收發郵件。

Domain: mycustomer.com.hk
MX record (原本): mail.isp.com.hk
新 MX record: mail.mycustomer.com.hk

以下是 Postfix 需要更改的設定，但其他 MTA 的原理都是一樣的，只是設定名稱不同。

In /etc/postfix/main.cf file:
mydestination = $myhostname, localhost
relay_domains = mycustomer.com.hk
transport_maps=hash:/etc/postfix/transport

In /etc/postfix/transport file:
mycustomer.com.hk smtp:[mail.isp.com.hk]

這樣所有郵件將會先經這部 server 再 relay 到 ISP 的電郵伺服器上。到正式 migration 那天，只需要除去上面設定，再到用戶的 email client:

1. POP 走 ISP email server 上舊的電郵
2. 建立新的郵件帳戶，指向新的 email server

Nolisting -- Poor Man's Greylisting

今天從 Slashdot 看到這篇文章介紹一個 anitspam solution 叫 Nolisting。簡單來說就是:
1. Primary MX 故意地不接 SMTP connection , 而根據 RFC 2821 規定，Client connection 會
2. 轉接到 Secondary MX，而這才是真正的 Email server。
3. 根據作者所說，Spammer 用的軟件大部份是 non-RFC compliance ，所以當 primary MX 不接時就不會再寄垃圾郵件到此地址。

但我自己的實際觀察是:
1. Secondary MX 也有垃圾郵件的。這可以由 headers 中看到!! 有Spammer 反而是故意攻擊 secondary mx --- 因為認為這些 secondary mx 的保護一般會較差。
2. Slashdot 內的評論也說某些正常 SMTP 也是 non-RFC compliance。這些 smtp server 便永遠不能寄信給你了。

已所不欲，勿施於人

上一篇談到 backscatter 問題的文章提到有些 antispam gateway 是 catch all 的，判斷電郵地址正確與否交了給下層的 delivery agent ，這種做法是不正確的。大家看了 Richi Jennings 的兩篇文章，便知道這麼做的嚴重性。如果你不能在 SMTP 層面 reject unknown user ，而要等到 delivery 層面時才 rebound message 的話，最大可能是 rebound 到一些無辜的第三者身上。

我前幾個星期替一個客戶安裝 email server，他不需要我安裝 anitspam 和 firewall function，因為他用上了一間香港「著名」的 antispam 公司的產品 (據講還得了獎)。
當天大家上 datacenter ，分別完成了各自的安裝工作，我奇怪的問那公司的工程人員為何從不問我電郵戶口的資料，他說不需要了，所有 incoming 來信 antispam gateway 都會接收，判斷是否有問題 (virus 或 spam)，無問題的就交給你的 email server ，由我的機器是否需要 rebound。
我跟着解釋這方法的問題所在，他才勉強的接受我 export 一個 text based account list ，好讓他能在 smtp 層面擋 dictionary attack。

巴黎鐵塔 反轉再反轉

有客戶經常收到一些 user unknown rebound message 聲稱是由他發出的，他問我是甚麼原因。這類郵件叫 Backscatter 垃圾郵件 (Backscatter 這字我查來查去都找不到一個好的中文譯名，即管就叫「 巴黎鐵塔 反轉再反轉」吧 XDDD)


1. Spammer 首先會冒認 Victim B 的 domain 為 sender 寄垃圾信。
2. 通常這類郵件會用 Directory Harvest Attach (dictionary attack) 的方式攻擊 Victim A.
3. 如果 Victim B 未能在 SMTP 層面擋截 user known 攻擊，而要在 delivery agent 層面時才知道，(這類情況經常出現在一些 catch all 的 antispam gateway 機器，有機會講講這些 antispam gateway 的問題) 因為 sender domain 是 Victim B，所以 Rebound Message 會返回 Victim B。
4. 我的客戶就是這個 Victim B 了。根本他不認識 Victim A，也無寄電郵給他們。

Victim B 可以做的不多，雖然 Postfix 提供了一個 filtering 方法，但我認為很容易「殺錯良民」。還要詳細研究才敢應用。

Greeting Pause

Sendmail 8.13 有一個新增的功能叫 greet_pause ，它的功能很簡單
當客戶端要連線至本機時， Greeting banner 不會立即出現，要等一個已設定時間才可以開始進行 SMTP conversation，對 spammers 來說，因為要大量寄信，等幾秒也是長時間，故此這方法可以阻擋一部份垃圾郵件，根據我的實際測試，大約少了 5%左右。
應用方法，在 sendmail.mc 檔上加上:

FEATURE(`greet_pause',5000)

Greeting banner 就會 5秒後才會出現。如果你有一些 trusted networks ，可以在 access 檔上加上:

GreetPause:localhost 0
GreetPause:123.124.0.1 0
這樣就可以 "whitelist" 以上 ip address。

我暫時在 Postfix 找不到這樣的一個 feature，因為她們認為 greeting pause 對正常郵件的「懲罰」太大了。