联想的MAIL服务器做的也不是很好。

思一克

lenovo有6个收件轮循，其中一个好象是DOWN掉了，如果轮到它，我的发件就失败。

还有它们的SERVER对于胡乱写的收件人的邮件一律先收下。对于大公司的反垃圾是个不好的事情。

abel

lenovo.com.             86400   IN      MX      10 ig6.lenovo.com.
lenovo.com.             86400   IN      MX      10 ig7.lenovo.com.
lenovo.com.             86400   IN      MX      20 ig2.lenovo.com.
lenovo.com.             86400   IN      MX      10 ig3.lenovo.com.
lenovo.com.             86400   IN      MX      10 ig4.lenovo.com.
lenovo.com.             86400   IN      MX      10 ig5.lenovo.com.

這樣有什麼不好 ? 當掉任一個也不會有問題吧,除非 10 有一部當掉了,
而同時 20 也掛了, 也才 20% 的機會寄不到

至於 "胡乱写的收件人的邮件一律先收下" 我們也是這樣做的,通常這些信只有 1% 不到的筆誤而錯寄,
但其中 99% 是 spam , 有什麼不恰當呢 ?
這不到 1% 在我們的 mail server 上觀察可是數萬分之 1 以下的機會,但對其他
數萬的 spam 來說巳經微不足道了

思一克

6个有一个DOWN掉，当然信还可以发过去，但是这种情况怎么可以允许长期保持而不改正？

”胡乱写的收件人的邮件一律先收下“，SERVER收到后在做判断，会无谓地消耗系统资源。对于一个好的SERVER是不合适的。

abel

原帖由 思一克 于 2005-10-31 11:53 发表
6个有一个DOWN掉，当然信还可以发过去，但是这种情况怎么可以允许长期保持而不改正？

”胡乱写的收件人的邮件一律先收下“，SERVER收到后在做判断，会无谓地消耗系统资源。对于一个好的SERVER是不合适的。

長時間 DOWN 掉確實不對,不過若 mx10某一部當掉,你的信會轉到mx20 去, 而 mx20 再 relay
回 mx10 任一部,而他們仍然可以正確的收到信,影響層面應該不會很大才是,不過這樣的確是不好的

至於 "胡乱写的收件人的邮件一律先收下" 這個看法很兩極,不過個人認為是沒有錯的,只是他們公司怎麼想的而以
在台灣,最大的 ISP hinet 也是這麼做的,這對於防別人猜帳號是有很大的幫助的,至於 user unknown 的信,
直接進 null 或 pipe 給 RBL , 如此並不會消耗多大的資源吧,至少我們單位的 mail server 目前感覺起來沒有
什麼差別,也因為好用所以目前都這樣用

思一克

To abel,

你用的是什么系统？ 一些系统的INVALID RECIPIENT信件是和其它正常信件一样进队列（QUEUE）的。如果这样，对于大系统消耗就是问题。如果有不地道的人一个SMTP连接可以向QUEUE中送大量的内容。

大麻

根据我维护系统的情况，最好还是不接手这种地址错误的信件为好，这样消耗的资源的确太大了。

abel

原帖由 大麻 于 2005-10-31 14:20 发表
根据我维护系统的情况，最好还是不接手这种地址错误的信件为好，这样消耗的资源的确太大了。

我不知道兩位版主兄以什麼 MTA 為 base 為情況,就我以 sendmail 而言並沒有這樣的感覺,
但另一方面還要看 scope , 我再以台灣最大的 isp hinet 為例:

[root@log log.mydomain.net.tw]# telnet msa.hinet.net 25
Trying 168.95.4.211...
Connected to msa.hinet.net.
Escape character is '^]'.
220 msr12.hinet.net ESMTP Sendmail V8; Mon, 31 Oct 2005 14:58:49 +0800 (CST)
ehlo log.mydomain.net.tw
250-msr12.hinet.net Hello log.mydomain.net.tw [211.72.210.251], pleased to meet you
250-8BITMIME
250-SIZE
250-DSN
250-ONEX
250-XUSR
250 HELP
mail from: <abel@log.mydomain.net.tw>
250 <abel@log.mydomain.net.tw>... Sender ok
rcpt to: <aaaaaaaaaaaaaaaaaaaaaa.bbbbbbbbbbbbbbbbbbbbbbb@msa.hinet.net>
250 <aaaaaaaaaaaaaaaaaaaaaa.bbbbbbbbbbbbbbbbbbbbbbb@msa.hinet.net>... Recipient
ok


這個 msa.hinet.net 在台灣至少有上百萬人在用,他們就不耗資源 ?
在 sendmail 而言,不過一兩行就可以完成了,至接把 user unknown 的都導到 null 去會耗資源 ?
這我是不相信的,除非你們都還要把 user unknown 拿去做  spam/virus filter

大麻

原帖由 abel 于 2005-10-31 15:04 发表

這個 msa.hinet.net 在台灣至少有上百萬人在用,他們就不耗資源 ?
在 sendmail 而言,不過一兩行就可以完成了,至接把 user unknown 的都導到 null 去會耗資源 ?
這我是不相信的,除非你們都還要把 user unknown 拿去做  spam/virus filter

不同的系统构架肯定处理结果会不一样，至少我认为目前的 qmail+qmail-scanner+vpopmail 是这样的，至于你不相信，是可能你并太了解qmail的这些缺陷的缘故吧，毕竟这是一套几乎没有更新的系统，可以原谅他，因为很多人还在继续使用。所以我才说“建议”一词。

其实，一开始很多企业用户特别喜欢 vpopmail 的 catch-all 功能，但是后来 spam 越来越多，这个功能就没有任何可用之处了。

思一克

To abel,

一些大公司的（比如10万人）无法当场快速查出一个收信人是否合法，如果能查出，也比较费时间。所以只好收下后在研究看是否是合法RECIPIENT。

收下后，还是要判断的，判断难道不费资源？
如果在DILIVER时判断，就更费了。

问题是你好坏皆收，捣乱者给你多少，你就会收下多少（因为你无法当场决绝），那不是让SERVER做更多的无用工作吗？

abel

原帖由 思一克 于 2005-10-31 17:19 发表
To abel,

一些大公司的（比如10万人）无法当场快速查出一个收信人是否合法，如果能查出，也比较费时间。所以只好收下后在研究看是否是合法RECIPIENT。

收下后，还是要判断的，判断难道不费资源？
如果在DI ...

任何信收下來都是要判斷這沒有錯,
不過收下來後判斷 user unknown 就丟掉應該是不會耗太多資源的
而這樣做的理由通常是猜帳號,以一般的 MTA 的帳號原則,是很容易用機器人跑出一個 List 的,
而這個 List 恐怕都是非常有效的 spam 對象

當然您這樣的看法也沒有錯,所以我前面才會說兩極,因為要取捨的是
1. RCPT TO 不拒,別人就不道我有什麼 valid account 了, 這也是一種 anti-spam 的技術, 其中的負擔在於 data (smtp protocol) 後的東西, 但 spam mail 的 mail size 通常不會太大,所佔資源因為僅判斷帳號
是否存在的 CPU loading, 及 Disk I/O 為主
2. RCPT TO 非帳號不收,今天你躲過了這個 spam , 但相對的 spamer 知道了你有什麼合法的帳號,
下次他只要針對你這些合法的人來送就好了

所以,這是我的觀點,我開了這個功能前功能後的 spam 數據是有很大的不同,
而且我還收集這些東西(user unknown) 做整理,整批的 submit 到 RBL 組織去
下次再來的機會就不多了,而且間接的保護了真正的 email 被猜出來的機會