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

abel

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

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

沒看到這個,
我用的是 sendmail ,
你所提的這種問題不管有沒有 check user 肯定都是存在的,因為要猜出一個 Mail Server 一兩個帳號是很簡單
的,只要猜出一個就夠了,不是嗎 ?
我所用的 MTA 自身也可以做 Rate Control 及 Max Rcpt 數量限制, 我只要限定非我屬意的一個 IP 的 connect rate , 就很容易避免這類的問題了

同時,這個問題聯想也有做,做法至少和我一樣

hzqbbc

原帖由 abel 于 2005-10-31 17:45 发表

沒看到這個,
我用的是 sendmail ,
你所提的這種問題不管有沒有 check user 肯定都是存在的,因為要猜出一個 Mail Server 一兩個帳號是很簡單
的,只要猜出一個就夠了,不是嗎 ?
我所用的 MTA 自身也可以做 Ra ...

这个帖子比较有意思，讨论了一个很久以前我曾经迷惑的问题，就是到底要不要在smtp阶段就返回unknow user？

最早期用的是qmail，qmail不管3721，一律全收。显而易见，遇到邮件DOS风暴，如病毒爆发，大量spam，qmail很容易就堵塞甚至崩溃了，后来更换成postfix后，就能将不存在的rcpt to立刻拦截，负载降了一大截。

后来做反垃圾邮件相关的设计时，又需要截获那些投敌给不存在本地的用户的垃圾邮件，因此设置了catchall，所有的邮件都收下来分析。

可见，拒与不拒，我认为还是应根据实际需求而定。如果是经常性的超大量邮件inbound，能reject掉还是reject，可以减弱损害；如果在机器负载允许的前提下，什么都收下来，不无好处，我现在的hzqbbc.com的邮件基本上都是这样的。

当然，其他形式的反垃圾邮件手段是很重要的，单靠拦截猜测地址还远不勾。频率控制和rcpt to控制是一个比较有效的方法，对于大量的spam是挺有用的。

hzqbbc

原帖由 abel 于 2005-10-31 17:34 发表

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

对于大量的user unknow的邮件，理论上如果立刻拒收，消耗的资源一定比收下来要高。因为一旦收下来，那么一封信引起的磁盘的i/o至少要2-3次以上（以postfix为例，qmail就更多些，sendmail不会比这个数量少）。量一大，磁盘的瓶竟就会暴露的了。

如果是以减少服务器被这种类型的邮件（有点象攻击的了）为目的，reject后负载会大为减少。配合频率控制的话，效果更好。

hongfengyue

嗯，我使用courier MTA，就是不存在的用户直接拒收。但是abel的话也蛮有道理。看来还是要根据实际情况来看。
长了见识。哈哈，做mail倒是没有考虑到这一层关系。

思一克

To abel,

我是这样做的：如果SPAM试探连续几个INVALID RCPTTO，就断掉连接并记录IP。如果再连接上来试探，就自动BLOCK。

所以好坏通吃并不能说是ANTI-SPAM的技术；到可以说是SPAM邮件的受害者。
其实它只是协议没有规定的一种（有时是因为无奈，有时是故意）的一种做法而已。

大麻

hzqbbc 说得对，邮件系统真正怕的垃圾病毒邮件风暴，因为现在病毒邮件泛滥造成的垃圾邮件占的比例非常之大，其中包含有由此产生的退信（例如，由病毒伪造我的地址发送的垃圾邮件，被对方邮件服务器过滤拒收后的退信），说实话，这种情况才是真正的烦人。不知道大家都什么好的办法来处理？

abel

原帖由 大麻 于 2005-11-1 10:39 发表
hzqbbc 说得对，邮件系统真正怕的垃圾病毒邮件风暴，因为现在病毒邮件泛滥造成的垃圾邮件占的比例非常之大，其中包含有由此产生的退信（例如，由病毒伪造我的地址发送的垃圾邮件，被对方邮件服务器过滤拒收后的退 ...

"邮件风暴" 除了提高系統性能外,只要確實作好 Mail Server 的監管就可以避免,例如
當你的 Load Average 大於某數值後,進行 delay 或 refused 等處理,當然這種情況下
正常的信件也不能接收,但至少风暴當頭, Mail Server 不會做 "儘力" 處理的行為,而造
成整個系統崩潰

ardi

还有种设计方法:
就是根据mail from  和 rcpt to 检查发件人或收件人是不是本系统帐号, 如果不是,
还是照收不误, 免得spam 制造者猜真实用户, 但接收后,直接丢弃, 不放在队列,
这样一来就不会增加系统负担.

hzqbbc

原帖由 ardi 于 2005-11-1 12:45 发表
还有种设计方法:
就是根据mail from  和 rcpt to 检查发件人或收件人是不是本系统帐号, 如果不是,
还是照收不误, 免得spam 制造者猜真实用户, 但接收后,直接丢弃, 不放在队列,
这样一来就不会增加系统负担.

按队列来说，只要rcpt to不reject，那么之后进入data后，就应该产生临时文件的了。所有data的内容也将放入文件里。不放队列应该是说不过去的。

除非经过特殊改造，在rcpt to时触发一个spamtrap之类机制，将邮件（data）的内容直接写到/dev/null里。。不知道sendmail能否实现，postfix是不行的，qmail正常的话应该不行，但不知道是否存在类似补丁。

abel

原帖由 hzqbbc 于 2005-11-1 13:31 发表


按队列来说，只要rcpt to不reject，那么之后进入data后，就应该产生临时文件的了。所有data的内容也将放入文件里。不放队列应该是说不过去的。

除非经过特殊改造，在rcpt to时触发一个spamtrap之类机制，将 ...

就我的能力來說, sendmail 做不到直接進 /dev/null ,
如同 postfix 般,需要用 LUSER_RELAY 將信導到一個 account(real account or aliases) ,
再從 account 轉到 /dev/null