lenovo有6个收件轮循，其中一个好象是DOWN掉了，如果轮到它，我的发件就失败。
还有它们的SERVER对于胡乱写的收件人的邮件一律先收下。对于大公司的反垃圾是个不好的事情。
abel 回复于：2005-10-31 11:47:30
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 來說巳經微不足道了
思一克 回复于：2005-10-31 11:53:16
6个有一个DOWN掉，当然信还可以发过去，但是这种情况怎么可以允许长期保持而不改正？
”胡乱写的收件人的邮件一律先收下“，SERVER收到后在做判断，会无谓地消耗系统资源。对于一个好的SERVER是不合适的。
abel 回复于：2005-10-31 13:52:37
引用：原帖由 思一克 于 2005-10-31 11:53 发表
6个有一个DOWN掉，当然信还可以发过去，但是这种情况怎么可以允许长期保持而不改正？
”胡乱写的收件人的邮件一律先收下“，SERVER收到后在做判断，会无谓地消耗系统资源。对于一个好的SERVER是不合适的。
長時間 DOWN 掉確實不對,不過若 mx10某一部當掉,你的信會轉到mx20 去, 而 mx20 再 relay
回 mx10 任一部,而他們仍然可以正確的收到信,影響層面應該不會很大才是,不過這樣的確是不好的
至於 "胡乱写的收件人的邮件一律先收下" 這個看法很兩極,不過個人認為是沒有錯的,只是他們公司怎麼想的而以
在台灣,最大的 ISP hinet 也是這麼做的,這對於防別人猜帳號是有很大的幫助的,至於 user unknown 的信,
直接進 null 或 pipe 給 RBL , 如此並不會消耗多大的資源吧,至少我們單位的 mail server 目前感覺起來沒有
什麼差別,也因為好用所以目前都這樣用
思一克 回复于：2005-10-31 14:13:36
To abel,
你用的是什么系统？ 一些系统的INVALID RECIPIENT信件是和其它正常信件一样进队列（QUEUE）的。如果这样，对于大系统消耗就是问题。如果有不地道的人一个SMTP连接可以向QUEUE中送大量的内容。
大麻 回复于：2005-10-31 14:20:36
根据我维护系统的情况，最好还是不接手这种地址错误的信件为好，这样消耗的资源的确太大了。
abel 回复于：2005-10-31 15:04:21
引用：原帖由 大麻 于 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: <[email]abel@log.mydomain.net.tw[/email]>
250 <[email]abel@log.mydomain.net.tw[/email]>... Sender ok
rcpt to: <[email]aaaaaaaaaaaaaaaaaaaaaa.bbbbbbbbbbbbbbbbbbbbbbb@msa.hinet.net[/email]>
250 <[email]aaaaaaaaaaaaaaaaaaaaaa.bbbbbbbbbbbbbbbbbbbbbbb@msa.hinet.net[/email]>... Recipient
ok
這個 msa.hinet.net 在台灣至少有上百萬人在用,他們就不耗資源 ?
在 sendmail 而言,不過一兩行就可以完成了,至接把 user unknown 的都導到 null 去會耗資源 ?
這我是不相信的,除非你們都還要把 user unknown 拿去做 spam/virus filter
大麻 回复于：2005-10-31 16:02:28
引用：原帖由 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 越来越多，这个功能就没有任何可用之处了。
思一克 回复于：2005-10-31 17:19:07
To abel,
一些大公司的（比如10万人）无法当场快速查出一个收信人是否合法，如果能查出，也比较费时间。所以只好收下后在研究看是否是合法RECIPIENT。
收下后，还是要判断的，判断难道不费资源？
如果在DILIVER时判断，就更费了。
问题是你好坏皆收，捣乱者给你多少，你就会收下多少（因为你无法当场决绝），那不是让SERVER做更多的无用工作吗？
abel 回复于：2005-10-31 17:34:45
引用：原帖由 思一克 于 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 被猜出來的機會
abel 回复于：2005-10-31 17:45:22
引用：原帖由 思一克 于 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 回复于：2005-10-31 21:42:38
引用：原帖由 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 回复于：2005-10-31 21:48:11
引用：原帖由 abel 于 2005-10-31 17:34 发表
任何信收下來都是要判斷這沒有錯,
不過收下來後判斷 user unknown 就丟掉應該是不會耗太多資源的
而這樣做的理由通常是猜帳號,以一般的 MTA 的帳號原則,是很容易用機器人跑出一個 List 的,
而這個 List 恐怕 ...
对于大量的user unknow的邮件，理论上如果立刻拒收，消耗的资源一定比收下来要高。因为一旦收下来，那么一封信引起的磁盘的i/o至少要2-3次以上（以postfix为例，qmail就更多些，sendmail不会比这个数量少）。量一大，磁盘的瓶竟就会暴露的了。
如果是以减少服务器被这种类型的邮件（有点象攻击的了）为目的，reject后负载会大为减少。配合频率控制的话，效果更好。
hongfengyue 回复于：2005-10-31 21:57:47
嗯，我使用courier MTA，就是不存在的用户直接拒收。但是abel的话也蛮有道理。看来还是要根据实际情况来看。
长了见识。哈哈，做mail倒是没有考虑到这一层关系。
思一克 回复于：2005-11-01 08:43:00
To abel,
我是这样做的：如果SPAM试探连续几个INVALID RCPTTO，就断掉连接并记录IP。如果再连接上来试探，就自动BLOCK。
所以好坏通吃并不能说是ANTI-SPAM的技术；到可以说是SPAM邮件的受害者。
其实它只是协议没有规定的一种（有时是因为无奈，有时是故意）的一种做法而已。
大麻 回复于：2005-11-01 10:39:52
hzqbbc 说得对，邮件系统真正怕的垃圾病毒邮件风暴，因为现在病毒邮件泛滥造成的垃圾邮件占的比例非常之大，其中包含有由此产生的退信（例如，由病毒伪造我的地址发送的垃圾邮件，被对方邮件服务器过滤拒收后的退信），说实话，这种情况才是真正的烦人。不知道大家都什么好的办法来处理？
abel 回复于：2005-11-01 12:32:10
引用：原帖由 大麻 于 2005-11-1 10:39 发表
hzqbbc 说得对，邮件系统真正怕的垃圾病毒邮件风暴，因为现在病毒邮件泛滥造成的垃圾邮件占的比例非常之大，其中包含有由此产生的退信（例如，由病毒伪造我的地址发送的垃圾邮件，被对方邮件服务器过滤拒收后的退 ...
"邮件风暴" 除了提高系統性能外,只要確實作好 Mail Server 的監管就可以避免,例如
當你的 Load Average 大於某數值後,進行 delay 或 refused 等處理,當然這種情況下
正常的信件也不能接收,但至少风暴當頭, Mail Server 不會做 "儘力" 處理的行為,而造
成整個系統崩潰
ardi 回复于：2005-11-01 12:45:47
还有种设计方法:
就是根据mail from 和 rcpt to 检查发件人或收件人是不是本系统帐号, 如果不是,
还是照收不误, 免得spam 制造者猜真实用户, 但接收后,直接丢弃, 不放在队列,
这样一来就不会增加系统负担.
hzqbbc 回复于：2005-11-01 13:31:12
引用：原帖由 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 回复于：2005-11-01 14:17:08
引用：原帖由 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
hzqbbc 回复于：2005-11-01 15:15:35
引用：原帖由 abel 于 2005-11-1 14:17 发表
就我的能力來說, sendmail 做不到直接進 /dev/null ,
如同 postfix 般,需要用 LUSER_RELAY 將信導到一個 account(real account or aliases) ,
再從 account 轉到 /dev/null
恩。对，和我猜测的没错，一般mta的设计是为了最大限度不丢信，可靠的将信投敌到用户的mailbox，因此作者一般不会接收在data开始之后，将信直接写到/dev/null的做法。而都是立刻写到磁盘上，并纳入队列的管理范围。
所以要drop掉认为垃圾的邮件，只能在队列和mailbox（mda）之间作手脚。
思一克 回复于：2005-11-01 15:41:57
讨论到此，看来大多数系统都是无主邮件也要进队列，然后等DELIVER时候在判断采取相应措施，比如BOUNCE， DELETE等。
如果是，那么这就显然没有直接挡在门外好。
这有点象RELAY的邮件。可以说100%的系统都是立即挡住。而不是放进门再研究行动。
ardi 回复于：2005-11-01 16:59:32
引用：原帖由 hzqbbc 于 2005-11-1 15:15 发表
恩。对，和我猜测的没错，一般mta的设计是为了最大限度不丢信，可靠的将信投敌到用户的mailbox，因此作者一般不会接收在data开始之后，将信直接写到/dev/null的做法。而都是立刻写到磁盘上，并纳入队列的管理 ...
如果mail from 和 rcpt to 都不是系统用户,则邮件肯定是spam 了, 除了特殊的MTA 以外.
这种邮件就应该直接丢弃,不应该进入队列, 至于MTA 做不到,那就是MTA 的问题了
skylove 回复于：2005-11-01 23:43:43
引用：原帖由 ardi 于 2005-11-1 16:59 发表
如果mail from 和 rcpt to 都不是系统用户,则邮件肯定是spam 了, 除了特殊的MTA 以外.
这种邮件就应该直接丢弃,不应该进入队列, 至于MTA 做不到,那就是MTA 的问题了
如果mail from 和 rcpt to 都不是系统用户,则邮件肯定是spam 了, 虚拟方式投递的呢？？？ 不可能都用真实用户作为信箱用户的。。。
abel 回复于：2005-11-02 10:44:09
引用：原帖由 思一克 于 2005-11-1 15:41 发表
讨论到此，看来大多数系统都是无主邮件也要进队列，然后等DELIVER时候在判断采取相应措施，比如BOUNCE， DELETE等。
如果是，那么这就显然没有直接挡在门外好。
这有点象RELAY的邮件。可以说100%的系统都是立 ...
思兄, 任何的做法都存乎一心,並沒有說何者好何者壞, 您所說的行為 (RCPT TO
直接檔掉)是幾乎所有的 MTA 預設的行為,這種方法當然是 MTA 為系統及管理者
所考量下的結果,並且這樣做能預防一時的筆誤而寫錯 email address,能即時返
回錯誤訊息給發信人.
但,
我個人的看法僅在於如何防 spam ,而防守之道首在如何保護巳存在的 user account,
這個想法的第一個要求是 "不返回 user unknown" , 我相信以版上幾位做 Mail 生意
的朋友(我個人並不是),一定很清楚現在 SPAM 的一些具體做法, 猜帳號是一個很難
防的事情,即使 user 再如何保護自己的 email account 不被收集都沒有用.
我自己也寫過這種程式,猜一個 Mail Server 下任意八字元的的 user , 大概也不過
一天內就能跑完,而且幾乎都能命中,如此再如何做也很難避免這些人收到大量的 spam 了
但是若不返回 user unknown ,發 spam 的人就得考慮成本了, 若發 10000 封 spam ,
恐怕沒有幾封能進信箱, 但返回 user unknown 的,發 10000 封,大概8成以上都進信箱了
即使你做 Rate control 也沒有太大作用(因為名單被賣掉了),做 spam filter 更是大
量消耗資源的工作, 在 user 巳知的情況下, spamer 恐怕發個 10000 封都在所不惜
但是,若像聯想一樣,限制連接頻率(rate control),最大收件數(Max Rcpt),不返回 user
unknown 狀況, spamer 要猜帳號是不可能的,而這些 user unknown 被收進來的信並
不丟給 spam filter 處理.
而若返回 user unknown , spamer 間接求得 user list 後,每一封信都得處理好多手續
這種情況下恐怕反而適得其反(版上不是常有人問 anti virus/spam loading 過高?)
我的看法只有一個重點,保護現有存在 user account 不要被猜出來而以
返回 user unknown 最後將是 user known
r2007 回复于：2006-01-04 11:17:32
有一个问题要确认一下：
如果在SMTP会话中判断RCPT TO是否合法，例如RCPT TO: r2007，那么检查之前是否要进行address rewrite，然后再判断呢？ 如果是的话，会不会对响应时间有很大的影响呢？
思一克 回复于：2006-01-04 11:20:05
对于qmail,是用re-write之后得到的reptto判断。
对响应时间没有影响。但如果用户数目巨大，那会影响
r2007 回复于：2006-01-04 13:17:04
RFC2821(PROPOSED STANDARD)中有一段(6.1 Reliable Delivery and Replies by Email)提到RCPT能否进行有效地址检验的问题，虽然还未成为标准rfc，但是可以借鉴一下:
引用： Some delivery failures after the message is accepted by SMTP will be
unavoidable. For example, it may be impossible for the receiving
SMTP server to validate all the delivery addresses in RCPT command(s)
due to a "soft" domain system error, because the target is a mailing
list (see earlier discussion of RCPT), or because the server is
acting as a relay and has no immediate access to the delivering
system.
思一克 回复于：2006-01-04 14:27:28
是的。许多MESSAGES 是在SERVER 接收了却无法交付。这样，SERVER需要再发BOUNCE 信件通知发件人。
Some delivery failures after the message is accepted by SMTP will be
unavoidable. For example, it may be impossible for the receiving
SMTP server to validate all the delivery addresses in RCPT command(s)
due to a "soft" domain system error, because the target is a mailing
list (see earlier discussion of RCPT), or because the server is
acting as a relay and has no immediate access to the delivering
system.
akid 回复于：2006-01-04 14:32:37
我是用Qmail架构，我修改了qmail-smtpd.c，如果是投递到本域当RCPT TO时检查一下文件系统中是否存在该邮箱。如果不存在，就sleep 3秒（当然，可以设置得更长），然后断开SMTP连接。
这样子，Spamer如果想猜用户，将会花费更多得时间。
merlinyu 回复于：2006-01-04 14:33:58
qmail 可以打个补丁, 在 rcpt to时检查收件人是否存在, 不存在直接 reject
|
