一个配置好的MAIL服务器除基本功能外应该具有的其它功能：
* 反垃圾邮件能力。检查连接或内容，阻挡某些认为是不良的连接以及信件。
* 反病毒能力。阻挡带有病毒的附件
* DELIVERY WARNING。当一个邮件在一定时间内还没有发走（比如5小时），先给发件人警告，而不是等到
最后的FAILURE REPORT，几天后才知道信没有送达。
* 立即得到失败的报告。可以实验：比如一个信发给两个用户[email]user1@aaabc.com[/email]；[email]user_none@yahoo.com.cn[/email]
看是否可以立即获得FAILURE REPORT。
* 队列优先级。比如对于反弹信，自动回复等信给予比较低的发送有限级别。
* 支持SSL/TLS收发。非常有用，尤其是跨国收发。
* 支持多发，也就是一个SMTP发件连接应该可以发送给多个收件人，如果他们在一个域中。否则效率太低
* SMART ROUTING。发件可以指定发往TODOMAIN.COM的所有邮件先走1.2.3.4, 如果没有走通，再走原来路径
非常有用。当有专线，为了加速发送TODOMAIN.COM的邮件，必须有此功能。
* 边收边删功能。如果没有，一个在国外的慢速连接用户，他信箱中有100封信，他收到98封时候网络断了，
就非常麻烦了。
* 收发信监控TAP功能。可以设置从A发往B的所有邮件都匿名转发一个给C
* MAP USER功能，所有发给A的信，自动改地址为A1， MAP DOMAIN功能，对域也一样。
* 用户信箱限额
* 用户发件数量限额。有时用户机器闹病毒了，用户会用验证方式发出数千个正常的邮件。要阻挡这种
行为
* 本地用户（有选择地）需要验证才可以发件。比如本地域[email]user1@aaa.com[/email] 发给[email]user2@aaa.com[/email]也需要
验证。
* 检查收件人合法性。可以拒绝接受无主邮件。
* 广播功能。可以设置广播用户，使得他有权力可以发一封信而广播给所有人。
* 用户邮件大小控制。就是qmail的DATABYTES. 但要可以为特殊用户设置不同的大小，而不是一个全局变量。
* 为了使自己不被防垃圾邮件阻挡，必须要有DNS反解析； 必须正确配置helohost名字, 正确配置MX记录
* 还有，想起来了再补充。也欢迎大家来补充。
[ 本帖最后由 思一克 于 2006-5-23 11:29 编辑 ]
anthonyfeng 回复于：2006-05-18 10:44:28
边收边删功能 一直以为是client 端功能，从未想过要在server 端实现，有机会测试一下。
思一克 回复于：2006-05-18 10:48:29
边收边删功能 非常有用，但不是CLIENT端可以作到的。除非CLIENT多次连接。
它是违反POP协议的。但非常有用-- 冒昧说协议有点愚蠢，但许多年前那样的考虑还是有道理的。
[ 本帖最后由 思一克 于 2006-5-18 11:02 编辑 ]
思一克 回复于：2006-05-18 10:51:31
To anthonyfeng,
我说的功能不是现有的邮件系统比如QMAIL， POSTFIX等每一个功能都具备的。所以你要实验，必须先看有无此功能。否则我就误导了。
abel 回复于：2006-05-18 11:16:45
以上,我用 sendmail 可以完全做到,一一說明我的做法
* 反垃圾邮件能力。检查连接或内容，阻挡某些认为是不良的连接以及信件。
# procmail + private rbl
* 反病毒能力。阻挡带有病毒的附件
# procmail
* DELIVERY WARNING。当一个邮件在一定时间内还没有发走（比如5小时），先给发件人警告，而不是等到
最后的FAILURE REPORT，几天后才知道信没有送达。
# sendmail 本來就是這樣,設定在 O Timeout.queue* 項目上
* 立即得到失败的报告。可以实验：比如一个信发给两个用户[email]user1@aaabc.com[/email]；[email]user_none@yahoo.com.cn[/email]
看是否可以立即获得FAILURE REPORT。
# sendmail 本來也就是這樣,100個收件者一個 user unknown 也會把那一個 error 告訴你
* 队列优先级。比如对于反弹信，自动回复等信给予比较低的发送有限级别。
# sendmail 本來就是這樣
* 支持SSL/TLS收发。非常有用，尤其是跨国收发。
# SSL/TLS 是必需的,我們有做,以 sendmail 來說就是要 enable TLS
* 支持多发，也就是一个SMTP发件连接应该可以发送给多个收件人，如果他们在一个域中。否则效率太低
# sendmail 本來就是這樣,即使這個域有100人但10人有問題,那它會把10人當做一封退信給發信者
* SMART ROUTING。发件可以指定发往TODOMAIN.COM的所有邮件先走1.2.3.4, 如果没有走通，再走原来路径 非常有用。当有专线，为了加速发送TODOMAIN.COM的邮件，必须有此功能。
# sendmail 有這個功能,就是 Smart Host , 也有像 routing 的功能,指定我什麼域要先送到什麼主機去轉發(mailertable)
* 边收边删功能。如果没有，一个在国外的慢速连接用户，他信箱中有100封信，他收到98封时候网络断了，
就非常麻烦了。
# 這功能不是 MTA 的功能,而是 client 要支援 retr 一封信後要 dele 掉,會造成來回操做過多,但可避免重收
* 收发信监控TAP功能。可以设置从A发往B的所有邮件都匿名转发一个给C
# 我至少知道 sendmail 有四種以上方法做到這個功能
* MAP USER功能，所有发给A的信，自动改地址为A1， MAP DOMAIN功能，对域也一样。
# sendmail 的 genericstable 可以對人 , 也可以對域
* 用户信箱限额
# sendmail 可以利用 os 的 quota 功能做到
* 用户发件数量限额。有时用户机器闹病毒了，用户会用验证方式发出数千个正常的邮件。要阻挡这种
行为
# 8.13.X 後的 sendmail 提供 rate control , 可以限制連接頻率
* 本地用户（有选择地）需要验证才可以发件。比如本地域[email]user1@aaa.com[/email] 发给[email]user2@aaa.com[/email]也需要
验证。
# 這個功能看不懂,發給 user2 不管什麼人多是可以發的,要驗也不知道驗什麼,除非用 Sender ID, 而 sendmail 目前並未支援 Sender ID , 但有 patch
* 检查收件人合法性。可以拒绝接受无主邮件。
# 拒不拒絕過去曾討論過,我向來不拒絕,但限制連接頻率
* 还有，想起来了再补充。也欢迎大家来补充。
* 要能設定 Load Average ,讓 server 知道自己的負載過高時懂得暫停服務或連接
* 要能設定 DNS 行為,例如 retry,AA Only , retran , timeout 等,避免 DNS 無謂的等待與消耗
* 要能保護及設定 mailling list 是 private (member only of internal) 或是 public 的
* 要能有充份及可讀性高的 log 來了解 mail 運作情形
* 要能提供自動回覆功能,以供長期休假或出差同仁自定義內容
* 要能夠提供其他插件空間,以更增強其功能
* 要能自定義必要狀況的回應訊息(4xx,5xx)
思一克 回复于：2006-05-18 11:25:19
好，abel!
我以上说的，有几个qmail没有。sendmail我不明白。
谢谢你补充。
自动回复我作为基本的了。没有列出。
Load Average 可以通过连接总数限制。
要能設定 Load Average ,讓 server 知道自己的負載過高時懂得暫停服務或連接
* 要能設定 DNS 行為,例如 retry,AA Only , retran , timeout 等,避免 DNS 無謂的等待與消耗
* 要能保護及設定 mailling list 是 private (member only of internal) 或是 public 的
* 要能有充份及可讀性高的 log 來了解 mail 運作情形
* 要能提供自動回覆功能,以供長期休假或出差同仁自定義內容
* 要能夠提供其他插件空間,以更增強其功能
* 要能自定義必要狀況的回應訊息(4xx,5xx)
abel 回复于：2006-05-18 11:26:50
*用户邮件大小控制。就是qmail的DATABYTES. 但要可以为特殊用户设置不同的大小，而不是一个全局变量。
# sendmail 以 milter-length (MILTER) 可以限制那個 IP/From/To 不同的最大 Size ,也可以是一個全部人適用的 Max Size
abel 回复于：2006-05-18 11:29:07
"Load Average 可以通过连接总数限制。"
這個有時不必然是正相關,可能需要注意一下
思一克 回复于：2006-05-18 11:45:36
To Abel,
你实验sendmail, (telnet yourserver 110)
连接后
RETR一个立即DELE 看有用吗？
"
# 這功能不是 MTA 的功能,而是 client 要支援 retr 一封信後要 dele 掉,會造成來回操做過多,但可避免重收
"
abel 回复于：2006-05-18 11:53:26
引用：原帖由 思一克 于 2006-5-18 11:45 发表
To Abel,
你实验sendmail, (telnet yourserver 110)
连接后
RETR一个立即DELE 看有用吗？
"
# 這功能不是 MTA 的功能,而是 client 要支援 retr 一封信後要 dele 掉,會造成來回操做過多,但可避免重收 ...
有用 ? 怎沒用 ?
思一克 回复于：2006-05-18 12:00:33
To Abel,
真的？
RETR 1
DELE 1
RETE 2
DELE 2
RETR 3
DELE 3
和最后DEL 1， DEL 2， DEL 3是一样的。你好好看协议就明白了
abel 回复于：2006-05-18 12:11:14
我不懂你的涵意 ?
我操作過程如下
[root@mydomain mail]# echo "" | mail abelyang -s `date +%s`
[root@mydomain mail]# echo "" | mail abelyang -s `date +%s`
[root@mydomain mail]# echo "" | mail abelyang -s `date +%s`
[root@mydomain mail]# telnet mydomain.net.tw 110
Trying 1.2.3.4...
Connected to mydomain.net.tw (1.2.3.4).
Escape character is '^]'.
+OK POP3 mydomain.net.tw v2003.83rh server ready
user abelyang
+OK User name accepted, password please
pass xxxxxxx
+OK Mailbox open, 66 messages
retr 64
+OK 618 octets
Return-Path: <root@mydomain.net.tw>
Received: from mydomain.net.tw (localhost [127.0.0.1])
by mydomain.net.tw (8.13.6/8.13.5) with ESMTP id k4I470QB015255
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
for <abelyang@mydomain.net.tw>; Thu, 18 May 2006 12:07:01 +0800
Received: (from root@localhost)
by mydomain.net.tw (8.13.6/8.13.5/Submit) id k4I470iH015248
for abelyang; Thu, 18 May 2006 04:07:00 GMT
Date: Thu, 18 May 2006 04:07:00 GMT
From: root <root@mydomain.net.tw>
Message-Id: <200605180407.k4I470iH015248@mydomain.net.tw>
To: abelyang@mydomain.net.tw
Subject: 1147925220
Bogus: No
Status: O
.
dele 64
+OK Message deleted
list
+OK Mailbox scan listing follows
1 444184
2 241877
3 3546
4 12109
5 3968
6 2525
7 44380
8 2087
9 1703
10 77697
11 6839
12 21675
13 27455
14 1096
15 1391
16 1067
17 50864
18 1665
19 2314
20 10311
21 3709
22 12777
23 24818
24 241663
25 69322
26 316734
27 1548
28 319050
29 69758
30 17616079
31 28851
32 188387
33 2587
34 329551
35 4017
36 9611
37 930
38 38867
39 117614
40 1209
41 29088
42 66953
43 1857
44 1699
45 1981
46 24370
47 29061
48 4686
49 112619
50 4258
51 4524
52 833
53 1790
54 12313
55 27163
56 71552
57 10020
58 239278
59 1380
60 1210
61 4104
62 132595
63 142059
65 618
66 618
.
retr 65
+OK 618 octets
Return-Path: <root@mydomain.net.tw>
Received: from mydomain.net.tw (localhost [127.0.0.1])
by mydomain.net.tw (8.13.6/8.13.5) with ESMTP id k4I471UM015326
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
for <abelyang@mydomain.net.tw>; Thu, 18 May 2006 12:07:01 +0800
Received: (from root@localhost)
by mydomain.net.tw (8.13.6/8.13.5/Submit) id k4I4714a015325
for abelyang; Thu, 18 May 2006 04:07:01 GMT
Date: Thu, 18 May 2006 04:07:01 GMT
From: root <root@mydomain.net.tw>
Message-Id: <200605180407.k4I4714a015325@mydomain.net.tw>
To: abelyang@mydomain.net.tw
Subject: 1147925221
Bogus: No
Status: O
.
dele 65
+OK Message deleted
retr 66
+OK 618 octets
Return-Path: <root@mydomain.net.tw>
Received: from mydomain.net.tw (localhost [127.0.0.1])
by mydomain.net.tw (8.13.6/8.13.5) with ESMTP id k4I4725g015391
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
for <abelyang@mydomain.net.tw>; Thu, 18 May 2006 12:07:02 +0800
Received: (from root@localhost)
by mydomain.net.tw (8.13.6/8.13.5/Submit) id k4I4725Q015390
for abelyang; Thu, 18 May 2006 04:07:02 GMT
Date: Thu, 18 May 2006 04:07:02 GMT
From: root <root@mydomain.net.tw>
Message-Id: <200605180407.k4I4725Q015390@mydomain.net.tw>
To: abelyang@mydomain.net.tw
Subject: 1147925222
Bogus: No
Status: O
.
dele 66
+OK Message deleted
list
+OK Mailbox scan listing follows
1 444184
2 241877
3 3546
4 12109
5 3968
6 2525
7 44380
8 2087
9 1703
10 77697
11 6839
12 21675
13 27455
14 1096
15 1391
16 1067
17 50864
18 1665
19 2314
20 10311
21 3709
22 12777
23 24818
24 241663
25 69322
26 316734
27 1548
28 319050
29 69758
30 17616079
31 28851
32 188387
33 2587
34 329551
35 4017
36 9611
37 930
38 38867
39 117614
40 1209
41 29088
42 66953
43 1857
44 1699
45 1981
46 24370
47 29061
48 4686
49 112619
50 4258
51 4524
52 833
53 1790
54 12313
55 27163
56 71552
57 10020
58 239278
59 1380
60 1210
61 4104
62 132595
63 142059
.
quit
+OK Sayonara
思一克 回复于：2006-05-18 12:14:44
问题一开始就是说中间网络短线的情况。
你收一个DELE一个，还没有收完时然后断开，
看什么情况？
abel 回复于：2006-05-18 12:30:30
引用：原帖由 思一克 于 2006-5-18 12:14 发表
问题一开始就是说中间网络短线的情况。
你收一个DELE一个，还没有收完时然后断开，
看什么情况？
我知道你的意思,你指的是 沒有正常 quit 下的離開,信件是沒有被刪的,
這樣的情況下, MUA 需要一封信一連接
至於從 pop3 server 自動去做我覺得也不是必要的,因為 user 搞不好想保留備份在 Server 上,
但是 Server 無法知道這樣的情況
思一克 回复于：2006-05-18 12:33:45
所以你说RETR一个就DELE一个是没有用的。
也就是说这不是CLIENT的问题。
思一克 回复于：2006-05-18 16:17:26
本地验证是有好处的。
设有本地域aaa.com
U1 : [email]user1@aaa.com[/email]
U2: [email]user2@aaa.com[/email]
如果U1发U2不验证也能发，就等于U1将自己的地址胡乱改为[email]xxxxxx@aaa.com[/email]也可以同事发，改为[email]manager@aaa.com[/email]也可以发。冒充问题不说（一般不会故意），但地址不是故意写错了也可以发，同事收到后有将地址加入了自己的地址本，回复时又是个错误地址。这样错-错-反弹等无谓地耗费系统，只有害，没有任何好处。
abel 回复于：2006-05-18 16:25:56
引用：原帖由 思一克 于 2006-5-18 16:17 发表
本地验证是有好处的。
设有本地域aaa.com
U1 : [email]user1@aaa.com[/email]
U2: [email]user2@aaa.com[/email]
如果U1发U2不验证也能发，就等于U1将自己的地址胡乱改为[email]xxxxxx@aaa.com[/email]也 ...
不知您指的是什麼,本地發本地驗 ? 那外地發本地呢 ? 本地不能假外地 ? 發本地要驗什麼東西 ?
至於前面的 MUA client 收信問題,您說的是沒有錯的,但是一個連接只收一封信就 quit 是能避免的,
但是從 Server 上直接 delete 恐怕是更不好的狀況
思一克 回复于：2006-05-18 16:31:37
直接拒绝无收件人邮件的好处和坏处（也和abel讨论）
1）如果不拒绝，系统给不给无法送达回复？邮件系统设计思想之一就是： 成功可以沉默，失败就要表明。
如果发BOUNCE，系统无谓消耗，如果不发，如果真是一个人发的好邮件但地址拼错了一个字母，他以为收见人受到了，但实际泥牛入海了。这等于他被系统欺骗了。
2）如果立即拒绝，上面的问题就不存在了。BOUNCE有发件人（如果是SERVER）生成，如果是CLIENT，他立即就知道地址写错了，立即改正。 如果是其它病毒SERVER乱发，立即拒绝不消耗自己SERVER的资源，发病毒的SERVER自己处理他自己的行为吧。
3）对于可能的（SPAM）实验问题，可以很容易用其他方式解决。
思一克 回复于：2006-05-18 16:34:03
To abel,
外面的发本地当然不验证了！
本地发本地验证的好处太多了。所以有许多人有这个问题。当然，如果你SERVER上人不多，问题不大。随自己喜好。
思一克 回复于：2006-05-18 16:41:55
To abel,
sendmail的连接速率控制，是根据什么限制速率的，比如SRC IP？
abel 回复于：2006-05-18 16:56:43
user unknown 問題我想不會有定論,完全看單位需要過去的討論都在這裏
http://bbs.chinaunix.net/viewthread.php?tid=637627&extra=page%3D1%26filter%3Ddigest
至於本地對本地驗證您無法保證他假造成外地,更何況本地對本地怎麼驗 ?
sendmail 的 rate control 是根據設定,限制 SRC IP 行為(程式寫的很活)
(預設一分鐘,時間可調整)
Conn 就是同時間最多可以有幾個 connect, 0 代表不限
Rate 就是單位時間內最多有幾次連線
ClientConn:127.0.0.1 0
ClientConn:1.2.3.4 2
ClientRate:1.2.3.4 2
ClientRate:127.0.0.1 0
ClientRate: 2
一個 User 一分鐘寄兩封信應該是很合理的,所以這種設計不會因為有個人中毒就造成
Mail Server Loading 大增,而且就算全世界都中毒,只要 Load Average 超過 15 我就
拒絕連接請求,降到 15 以下時才會再允許連接
這些東西都是透過設定就可以完成了,完全不需要為了什麼功能而要改什麼程式
思一克 回复于：2006-05-18 17:07:03
外面的用户发，如果能检查用户的真伪，当然检查最好。遗憾的是基本办不到。
内部用户发件，验证是如此简单，WHY NOT？ 所以才有许多人提出过这要求。
立即拒绝无效地址邮件，问题我上面说的已经清楚了。
根据SRC IP限制CONN RATE有十分有限的效果。尤其对于
CLIENT上出了问题乱发。
abel 回复于：2006-05-18 17:11:37
引用：原帖由 思一克 于 2006-5-18 17:07 发表
外面的用户发，如果能检查用户的真伪，当然检查最好。遗憾的是基本办不到。
内部用户发件，验证是如此简单，WHY NOT？ 所以才有许多人提出过这要求。
立即拒绝无效地址邮件，问题我上面说的已经清楚了。
根 ...
你的意思我完全看不懂,
1. 內部驗證驗什麼 ? 如何防止偽裝成外部 ?
2. 拒絕無效地址我的看法是若不限連接頻率,肯定是會被字典列舉
3. src ip 無效願聞高見 ? 不然您能根據什麼 ?
針對您的看法,舉個例我想是最簡單的說明
思一克 回复于：2006-05-18 17:20:07
几百CLIENT机器的SRC IP出口只有一个，你根据什么限制这个IP的RATE？
放到多大合适？ 如果一个CLIENT病毒工作了，RATE并无大的变化，因为正常的太多了。
所以为才所没多大用途。
abel 回复于：2006-05-18 17:31:26
引用：原帖由 思一克 于 2006-5-18 17:20 发表
几百CLIENT机器的SRC IP出口只有一个，你根据什么限制这个IP的RATE？
放到多大合适？ 如果一个CLIENT病毒工作了，RATE并无大的变化，因为正常的太多了。
所以为才所没多大用途。
Mail Server 根據 連接的 SRC IP 來做 Rate Control, 不是對出口的來做
就算我內部有 1000 個 client , server 最大可能就是 2000信/每分
至於送信給我的其他 MTA 就像 client 一樣,一家公司一分鐘最多送兩分給我不合理 ?
達到2封我回應的是 4.5.1 try later 不合理 ?
一個 client 中毒了再怎麼看對我都不會有影響,一分鐘2封的的 virus mail 有什麼作為
一般 mta 就怕儘量收,封封不放過,卻沒想到吃不下去就陣亡了而來得好吧
而且一分二封就算是大量散佈也影響不了幾個人
我認為我的做法很合理, 怎會沒有用途,我認為是你小看了 sendmail 的彈性
及或是誤會了我的語意了,
驗證那個舉例還希望您能多說明,就講內寄要驗恐怕說服力是不足的吧
註: Rate control 限制的是別人根我連的頻度,不是我去連別人也限
[ 本帖最后由 abel 于 2006-5-18 17:32 编辑 ]
maluyao 回复于：2006-05-18 20:23:50
这样的技术论战，多多益善。
顶!
思一克 回复于：2006-05-19 08:48:21
To Abel,
早上好。
如果你设置从CLIENT过来的最大是2000封信/分钟，那么RATE CONTROL对病毒的情况就没有什么作用了。因为2000/M 已经远在病毒的行动之内了。
还有USER UNKNOWN的问题。我认为不是问题了。
MAIL SERVER和人一样，如果你接受了别人的委托，你只有2个选择
1）给人家做。
2）研究后看自己会做不会做？如果做不了，要尽快告诉人家。
3）如果人家给你任务（即使是尽义务的事情）时，你当时就知道你不会做，那就当场谢绝。
这人的行为规范完全适合于MAIL SERVER。
USER UNKNOWN，你收下了，做不了，回复不回复？回复--垃圾多，不回复会将好人“欺骗”--不符合行为规范。
思一克 回复于：2006-05-19 08:49:45
to maluyao,
我要这个帖子指顶讨论
abel 回复于：2006-05-19 09:08:35
引用：
To Abel,
早上好。
如果你设置从CLIENT过来的最大是2000封信/分钟，那么RATE CONTROL对病毒的情况就没有什么作用了。因为2000/M 已经远在病毒的行动之内了。
还有USER UNKNOWN的问题。我认为不是问题了。
MAIL SERVER和人一样，如果你接受了别人的委托，你只有2个选择
1）给人家做。
2）研究后看自己会做不会做？如果做不了，要尽快告诉人家。
3）如果人家给你任务（即使是尽义务的事情）时，你当时就知道你不会做，那就当场谢绝。
这人的行为规范完全适合于MAIL SERVER。
USER UNKNOWN，你收下了，做不了，回复不回复？回复--垃圾多，不回复会将好人“欺骗”--不符合行为规范。
user unknown 問題早討論過,我認為沒有必要再多說什麼,委託那個例子是在假想 "委託" 都是對的事或是要做的事,但 Mail 中有正常信有廣告信問題不能相提並論,更何況別人給你假委託您又如何,所以完全看各人取捨,
我認為我和聯想做法是沒有問題的,你認為你的想法也是沒有問題的,因為這本來就是一體兩面的東西
2000 問題請你看清楚,一個人2封/每分,1000個人的假設條件,你認為會 1000 個人都中毒 ?
1000 個人都狂發信 ? 我認為你對我指的 rate contorl 認識有誤解,sendmail 可做到,
就算1000人都狂發信,在負載昇高的情況下,我們還是能控制的,一般 mta (我想含 qmail) 就是
1000 個 user 大家能發幾封就發幾封, Server 能收幾封就幾封,完全沒有控制,直到崩潰為止
另外,似乎您對我另一個疑問都沒有看見,內部內寄搞什麼驗證?
思一克 回复于：2006-05-19 09:16:23
RATE CONTROL 不是一点用没有，但作用是有限的。
USER UNKNOW 你接受了，做不了就要告诉人家。否则系统大了，用户多了，一定有用户抱怨。因为他打错了一个字符，你收下了，有无声地给抛弃了。他还以为他发的信早到达目的地了。--- 也就是说他被“骗”了。
所以现在的许多许多系统都是“无法完成的立即谢绝“----这样做即不多耗费太多资源，又有反馈信息。
sendmail 应该也可以作到吧？（我不了解）。
大麻 回复于：2006-05-19 09:23:26
我插两句，rate contorl 对来信 ip 的频率控制是很有必要的，这点对大量群发垃圾邮件和病毒爆发的时候有非常好的效果；abel 的表述没有问题。
但是，对于本地用户通过 smtp 客户端发送本域地址需要做验证，我在实际使用中，也觉得是很有必要的，主要是防止用户伪造来信地址，我在改造的 qmail 中，不仅要求验证，而且还要求用户发送的邮件 header 中的 From: 地址必须与用户验证提供的账号相同才能发送，这样还可以防止用户用该账号来发送别的邮件。
abel 回复于：2006-05-19 09:29:43
引用：原帖由 思一克 于 2006-5-19 09:16 发表
RATE CONTROL 不是一点用没有，但作用是有限的。
USER UNKNOW 你接受了，做不了就要告诉人家。否则系统大了，用户多了，一定有用户抱怨。因为他打错了一个字符，你收下了，有无声地给抛弃了。他还以为他发的信 ...
這是每個公司自己的問題,只要我們有宣導過,而且目的是為了保護同事的 email
不會被 spamer 猜出來(其實那都是用程式猜的,連 13 個字的 account 都可以猜出來)
而 sendmail 本來預設也是會回user unknown 的, sendmail 只要用設定的方式就可以決定回不回錯誤訊息
早和您說了,這個是個人有個人看法,這問題跟本不是我的重點
你覺得 rate control 每有作用那是在你 qmail 的觀念下的感覺,也或許 qmail 根本從未實現過這種功能
在我感覺卻是發常有用,外面有個人給你發 spam , 或用 mail 攻擊你,你不限他,不然等死呀 ?
如果有高明一點,我寫個程式, fork 10000 個,全部連到你的 qmail 佔出你所有的 socket ,也不送什麼 command 或是亂送 command ,一直佔住,你也是等死 , 這種 mta 在允許大量連接的情況下,永遠都是問題
(這種程式很簡單的),你要用 TLS (esmtp STARTTLS),那肯定更早死 !
作用我肯定是非常好,而絕不是您所言的 "有限"
思一克 回复于：2006-05-19 09:31:22
To 大麻，
是的。本地发本地, MAIL FROM 地址还必须和 AUTH USER相同才可以发，这样最好。
不仅仅是纯粹防止伪造，可以可以防止许多错误的情况。
大麻 回复于：2006-05-19 09:36:41
引用：原帖由 思一克 于 2006-5-19 09:31 发表
To 大麻，
是的。本地发本地, MAIL FROM 地址还必须和 AUTH USER相同才可以发，这样最好。
不仅仅是纯粹防止伪造，可以可以防止许多错误的情况。
不仅是smtp 会话过程中，MAIL FROM 必须与 AUTH USER 相同，而且也必须与邮件 header 中的 From: <user@domain> 相同。
思一克 回复于：2006-05-19 09:38:07
to Abel,
我丝毫没有怀疑你的SERVER 用SENDMAIL是很好的。而且你的维护水平很高。
现在不是讨论你自己的SERVER，而是如何做好一般的邮件系统。
abel 回复于：2006-05-19 09:43:18
引用：
但是，对于本地用户通过 smtp 客户端发送本域地址需要做验证，我在实际使用中，也觉得是很有必要的，主要是防止用户伪造来信地址，我在改造的 qmail 中，不仅要求验证，而且还要求用户发送的邮件 header 中的 From: 地址必须与用户验证提供的账号相同才能发送，这样还可以防止用户用该账号来发送别的邮件。
這本來就是應該的,但你們如何防本地本假成外地?
外部不能防又有什麼用
又你們也知道, smtp auth 可以 retry 無數次 (因為不限 rate control , 或 smtp auth fail 次數),
你們又怎防外部郵件利用 smtp auth 猜測 email passwd , 這都是問題!
思一克 回复于：2006-05-19 09:48:17
To Abel,
"這本來就是應該的,但你們如何防本地本假成外地?
外部不能防又有什麼用"
你这观点和逻辑是不对的。我原来和你这个想法完全相同。但后来经过许多不愉快的抱怨，我改变的。
思一克 回复于：2006-05-19 09:50:20
还有rate control对于防止DOS是十分有用的。应该作为MAIL SERVER的一个好的功能。
我前面说的作用十分有限，是说在防止病毒发邮件方面，尤其是防止CLIENT发。作用的确不大。
abel 回复于：2006-05-19 09:51:27
引用：原帖由 思一克 于 2006-5-19 09:48 发表
To Abel,
"這本來就是應該的,但你們如何防本地本假成外地?
外部不能防又有什麼用"
你这观点和逻辑是不对的。我原来和你这个想法完全相同。但后来经过许多不愉快的抱怨，我改变的。
我認知外部根本不能防,不然何來許多 spam ?
內部的人會發 spam 的根本就不多,而且有 IP , auth 資訊可以查,我不覺得那是個問題
大麻 回复于：2006-05-19 09:55:42
引用：原帖由 abel 于 2006-5-19 09:43 发表
這本來就是應該的,但你們如何防本地本假成外地?
外部不能防又有什麼用
又你們也知道, smtp auth 可以 retry 無數次 (因為不限 rate control , 或 smtp auth fail 次數),
你們又怎防外部郵件利用 smtp auth 猜 ...
呵呵，当然我有办法防止外来地址利用假冒的本地地址来发送，所以才会进一步的做本地发送需要验证。我的方法与 hzqbbc 的 apf 类似。综合采用了多种技术，实际使用的效果还是很不错的。
至于防止 pop3 / smtp auth 攻击，最好的办法也是采用 rate control 控制，不过我没有实现，希望能够一起研讨。
abel 回复于：2006-05-19 09:56:30
引用：原帖由 思一克 于 2006-5-19 09:50 发表
还有rate control对于防止DOS是十分有用的。应该作为MAIL SERVER的一个好的功能。
我前面说的作用十分有限，是说在防止病毒发邮件方面，尤其是防止CLIENT发。作用的确不大。
防止病毒发邮件方面恐怕不是每個 anti virus 可以做到的,
在一個新 vrius mail 發作時,所有的 anti virus 軟體根本上有段時間是沒有作用的,
client 當然可以發,但在限制下絕對不會因為他造成大規模問題或是弄跨 server,
過去也曾討論過 "新" 病毒信對 mta 的影響,這都是要顧慮的地方
思一克 回复于：2006-05-19 09:58:39
To Abel,
你的用户数是多少？我记得你曾经说过是，三十多个。如果是，那你太幸运了。我的一个SERVER上就几千个，什么古怪的状况都出现过。比如一个用户中了不知什么东西，用验证方式往（以普通的速率）外发1000多个正常邮件，每个邮件从地址本中找5，6个人。
abel 回复于：2006-05-19 10:09:18
引用：原帖由 思一克 于 2006-5-19 09:58 发表
To Abel,
你的用户数是多少？我记得你曾经说过是，三十多个。如果是，那你太幸运了。我的一个SERVER上就几千个，什么古怪的状况都出现过。比如一个用户中了不知什么东西，用验证方式往（以普通的速率）外发100 ...
這些狀況或許我發生的不如諸位多,
但是我平常看這版,看台灣的一些版,問題也就有是
我也看 comp.mail.sendmail ,我管我們公司 mail 也 5~6 年了
這些東西或奇怪的事發生在目前我們單位來說,還沒解決不了的
人數我不覺得是問題,只是我自己安於現位, 我管最多人的是 voip 的 server ,
有五萬人,事情也不過就是那些,我更管全台灣的 DNS , 事情也不過是那些
人數 , who care
tempaccount 回复于：2006-05-19 11:00:58
楼主，请教一下sendmail可以收邮件么？
abel 回复于：2006-05-19 11:02:10
引用：原帖由 tempaccount 于 2006-5-19 11:00 发表
楼主，请教一下sendmail可以收邮件么？
這是什麼話 ? 您何不另起主題,
另外先把 www.vbird.org 上對 sendmail 的說明看一下吧
merlinyu 回复于：2006-05-19 11:41:12
可以限制一个用户一天的发信数量， 有的商业软件有这个功能
> 边收边删功能。如果没有，一个在国外的慢速连接用户，他信箱中有100封信，他收到98封时候网络断了，
就非常麻烦了。
服务器端实现不合理， foxmail 客户端有这个功能
[ 本帖最后由 merlinyu 于 2006-5-19 11:43 编辑 ]
maluyao 回复于：2006-05-19 11:54:02
感觉abel占了上风，思一克加油
思一克 回复于：2006-05-19 11:54:26
CLIENT端的实现只能靠多次连接来完成。所以更不合理。
SERVER端可以实现，违反了POP协议，所以也是不“合理”的。但不影响速度，工作的还好。
引用：原帖由 merlinyu 于 2006-5-19 11:41 发表
可以限制一个用户一天的发信数量， 有的商业软件有这个功能
> 边收边删功能。如果没有，一个在国外的慢速连接用户，他信箱中有100封信，他收到98封时候网络断了，
就非常麻烦了。
服务器端实现不合 ...
思一克 回复于：2006-05-19 11:56:32
哈哈。
什么上风下风的，目的是为构建出更好的邮件服务器。
引用：原帖由 maluyao 于 2006-5-19 11:54 发表
感觉abel占了上风，思一克加油
abel 回复于：2006-05-19 12:10:18
引用：原帖由 思一克 于 2006-5-19 11:56 发表
哈哈。
什么上风下风的，目的是为构建出更好的邮件服务器。
是呀,大家討論的是觀點,這是沒有對錯的,最多只存在主觀意見,
但是客觀的事實由於我和思兄專注於不同的 mta 難免會有認知上的差別
思一克 回复于：2006-05-19 12:44:24
To Abel,
还有，有的问题一直不被人关注，所以大部分人一直没有真正明白。比如
边收边删的问题，99%人一直认为是RETR一个立即发一个DELE，然后就不怕断线了。其实完全错了。
这样的讨论好处是很多的。
思一克 回复于：2006-05-19 12:55:35
To Abel,
你实验一下，发个mail给
[email]user@aaabc.com[/email], [email]uuuuuuuuas@yahoo.com.cn[/email]
看过多久你能收到FAILURE REPROT？
其他人也可以实验
abel 回复于：2006-05-19 13:21:46
----- The following addresses had permanent fatal errors ----- <[email]uuuuuuuuas@yahoo.com.cn[/email]>
(reason: 554 delivery error: dd This user doesn't have a yahoo.com.cn account ([email]uuuuuuuuas@yahoo.com.cn[/email]) [0] - mta108.mail.cnb.yahoo.com)
----- Transcript of session follows ----- <[email]user@aaabc.com[/email]>... Deferred: Connection timed out with aaabc.com.
... while talking to mta-v1.mail.vip.cnb.yahoo.com.:
>>> DATA
<<< 554 delivery error: dd This user doesn't have a yahoo.com.cn account ([email]uuuuuuuuas@yahoo.com.cn[/email]) [0] - mta108.mail.cnb.yahoo.com
554 5.0.0 Service unavailable
大概只要3秒以內
思一克 回复于：2006-05-19 13:25:47
To Abel,
好。你再给[email]user@aaabc.com[/email], [email]uuuuuuuuas@yahoo.com.cn[/email]，[email]uuuuuuuu222@sina.com[/email],[email]uuuuuuuu3333@yahoo.com.cn[/email]
我们得出有意思的结论
abel 回复于：2006-05-19 13:32:12
Message from yahoo.com.cn.
Unable to deliver message to the following address(es).
<[email]uuuuuuuu3333@yahoo.com.cn[/email]>:
This user doesn't have a yahoo.com.cn account ([email]uuuuuuuu3333@yahoo.com.cn[/email]) [0]
<[email]uuuuuuuuas@yahoo.com.cn[/email]>:
This user doesn't have a yahoo.com.cn account ([email]uuuuuuuuas@yahoo.com.cn[/email]) [0]
abel 回复于：2006-05-19 13:36:12
怎 ?
sina 的寄成了, 因為我看不 到 mail queue 它的踪影
另外一個
----- Transcript of session follows ----- <[email]user@aaabc.com[/email]>... Deferred: Connection timed out with aaabc.com.
思一克 回复于：2006-05-19 13:44:51
To Abel,
To yahoo.com.cn的是在几个SMTP连接中完成的？ 这个不好看出。应该是一个。
结论之一就是： yahoo.com.cn立即拒绝unknown user, 而sina.com接受unknown user了。
abel 回复于：2006-05-19 13:47:05
引用：原帖由 思一克 于 2006-5-19 13:44 发表
To Abel,
To yahoo.com.cn的是在几个SMTP连接中完成的？ 这个不好看出。应该是一个。
结论之一就是： yahoo.com.cn立即拒绝unknown user, 而sina.com接受unknown user了。
yahoo.com.cn 是一個連接兩個 RCPT ,
至於 sina.com 你的看法我不知真偽,因為沒有去注意這些問題
思一克 回复于：2006-05-19 14:13:31
To Abel,
看来sendmail的功能还是相当完善的。
控制邮件大小的功能你说是根据IP（前面的回贴），这不好。因为多数情况是根据用户。比如几个特殊人物要求的大，而无论他们在天涯海角。
abel 回复于：2006-05-19 14:40:29
引用：原帖由 思一克 于 2006-5-19 14:13 发表
To Abel,
看来sendmail的功能还是相当完善的。
控制邮件大小的功能你说是根据IP（前面的回贴），这不好。因为多数情况是根据用户。比如几个特殊人物要求的大，而无论他们在天涯海角。
你沒有看清楚,我說那個 Milter API 提供的 message size 可以根據
From IP
From
To
Default (sendmail.cf)
所以功能是非常好的,用那一個值就是看 first match,都沒有就是看 default ,
不過這種功能在 100 個用 sendmail 大概不會超卨兩個懂吧
思一克 回复于：2006-05-19 15:00:53
林子大了什么鸟都有。公司大了什么要求都有。
xxjoyjn 回复于：2006-05-19 15:04:10
受益匪浅啊
ronaldogreat910 回复于：2006-05-19 15:23:38
但是说实话,sendmail处理信的效率和管理性确实赶不上qmail和postfix,而且qmail和postfix还有很多可以挖掘的地方,只不能他们的出现稍晚于sendmail.
思一克 回复于：2006-05-19 15:37:30
To ronaldogreat910,
看来你用过sendmail. 我一点也不熟悉。可以多说些吗
ronaldogreat910 回复于：2006-05-19 16:00:09
引用：原帖由 思一克 于 2006-5-19 15:37 发表
To ronaldogreat910,
看来你用过sendmail. 我一点也不熟悉。可以多说些吗
实在不好意思,我只不过是一介卤夫,也不是做纯技术方面的工作,见笑了.
我的结论也是看了很多关于这三个MTA的资料和大家讨论的帖子得出来的,确实sendmail出现的早,很多功能都已经被发掘和完善,而qmail和postfix大家都还在不断的讨论和改善,特别从qmail和postfix的结构等各方面来说,技术牛人完全可以做的更好,这点相信恩一克、abel、大麻等肯定会同意,并不一定非要让MTA的始着者来更新才行.
abel 回复于：2006-05-19 16:25:48
你這兩段話不是前後矛盾 ?
"sendmail处理信的效率和管理性确实赶不上qmail和postfix"
"确实sendmail出现的早,很多功能都已经被发掘和完善,而qmail和postfix大家都还在不断的讨论和改善"
sendmail 是做了太多東西了,所以效率來說可能不用,但是可也比一個 收信人一個投遞要來得好呀!
sendmail 預設用 mbox 也可以改成 mail dir , user account 也可以存在 mysql/ldap 哪裏比不上了 ?
sendmail routing 可以根據 CA,RA, LDAP entry , IP , AUTH , 及選擇性的路徑傳送,
加前面我講的一些東西很多 mta 現在都沒有,怎比不上 ?
就講 rate control 也出現快兩二年, exim, qmail 這個部份在哪裏 ?
stattls 更是不知多久了， qmail 現在似乎還沒有個大概
postfix 是唯一和 sendmail 接近的，但我的感覺要達到一個功能要改程式，這種 mta 恐怕還有段路要走
(無他意，因為常看到 qmail 流都說要 patch , 要改程式)
sendmail 使用 Milter 的插件之多，恐怕也是你所不明白的
ronaldogreat910 回复于：2006-05-19 17:26:18
引用：原帖由 abel 于 2006-5-19 16:25 发表
你這兩段話不是前後矛盾 ?
"sendmail处理信的效率和管理性确实赶不上qmail和postfix"
"确实sendmail出现的早,很多功能都已经被发掘和完善,而qmail和postfix大家都还在不断的讨论和改善"
...
谢谢abel,您说的很多我都非常赞同,虽然我理解的不是那么透彻.
其实上面的话的意思是仅仅是指国内(当然台湾也是中国的一部分,准确的说是大陆),使用qmail和postfix的用户肯定是超过sendmail,无论是讨论的人还是技术资料都是很多的,qmail不是有个qmailadmin吗?各方面的情况来说大陆使用这两种MTA架构比sendmail更容易些.当然对一个管理员来说,特别是一些牛人,MTA不是太大的问题,关键是自己熟悉什么,愿意在此基础上去挖掘和改造来更加适合.
bigmoyo 回复于：2006-05-19 17:43:20
——abel 对于 sendmail 真是太熟了，真是如同炖肉一般，熟得透了熟得烂了。佩服佩服。由此看来 sendmail 的功能确实相对完善一些。
——不过有一点，abel 说本地发本地不用验证，这一点我还是以为不然。
——例如，有人 [email]staff1@kkk.com[/email]，他向本域内的 [email]staff2@kkk.com[/email]发信，由于不需口令验证，他就以 [email]boss@kkk.com[/email] 身份向 staff2 发信，从 staff2 这边看，还真以为是 boss 发的信呢。如果 staff1 的主机名在发信前改了，发信后改回来，且公司用DHCP，查起来还需费些周折。比如我们公司数百人，A 以 B 身份去信骂boss，要么就是 B 倒霉，要么就是我倒霉，查起来会很烦的啦。
——我想 sendmail 是不是也可以设定本地发本地也需进行口令认证吧。
——而外边的MTA伪装发信进来的情况，则用大麻兄所说的反垃圾的办法如匹配 域名/IP/邮箱名 等来进行鉴别，可以杜绝技术上非法的垃圾邮件。即，要发进来，一定可以找到对方MTA，且是授权的MTA。
——另外，关于pop3收信不能收一删一，这是pop3协议的先天不足，IMAP是可以做到真正的收一删一。所以也很多方案都建议用IMAP。
maluyao 回复于：2006-05-19 20:30:04
也认识几个台湾的朋友，技术都很不错。
本坛还有个 网中人，也不错。
老马当初学Linux就是靠猛在tw.bbs.comp.tw 提问题。
一个经常回答我问题的人叫”小州“ ，在台湾的Linux界
也算知名人士了。
ecloud 回复于：2006-05-19 23:58:11
sendmail的功能是最强的，这绝对没得说
曾经有些人把Domino搬出来说功能多么多么的强，结果我随便举出sendmail的两个例子他们就干瞪眼了
不过sendmail太难用了，所以很多人还是用postfix和qmail容易点，其实最容易的是exim
楼住的要求基本上过于user-end，很多问题都是同一类技术问题，并且其实大部分是靠procmail这类的MDA来解决的，而非MTA
至于对收邮件的要求，其实很简单，你用imap就行了。pop3服务器自动删邮件是一种非常不负责任的行为，不要因为一时之快而带来更多的隐患。
至于本地发信认证，我不知道为什么要问这个问题？这个在sendmail和postfix里面都是很容易设置的。其实对于身份认证来说，根本解决办法就是数字签名，如果连这点都做不到，那么你们用email也只是收收垃圾邮件列表的水平
对MTA身份的严格检查将会导致国内50%的邮件被你拒收，因为国内DNS反解率<50%，包括著名的163和sina
思一克 回复于：2006-05-20 23:09:18
我在第一贴子提出的功能, 都是可选的功能,而且其中不少是用户可选的.
比如DELE_AFTER_POP, 对个别经常出国的使用拨号的用户用,非常好.
还有,这些功能并非sendmail才有.其它系统也可以实现,而且不难实现.
abel 回复于：2006-05-22 10:07:05
引用：原帖由 思一克 于 2006-5-20 23:09 发表
我在第一贴子提出的功能, 都是可选的功能,而且其中不少是用户可选的.
比如DELE_AFTER_POP, 对个别经常出国的使用拨号的用户用,非常好.
还有,这些功能并非sendmail才有.其它系统也可以实现,而且不难实现.
我認為每一種 MTA 都有其利基點， 並無誰好誰差，
完全看在使用它的人身上，能不能發揮出MTA 應有的功能及水準，
對於 sendmail 他是老牌的 MTA (更早於 internet ) , 自然有些包袱，
但是每一個 Unix-like 都可以看見他的身影，站在 porting 的角度來看，
他還是有一定的優勢的，至於版上普遍認為大陸 多 qmail , 我想這點恐怕
需要一個客觀的統計才知道，我二年曾統計台灣的 MTA ,
其中 sendmail 佔到 40%,postfix 則約 20%, 我的統計是全抽樣
台灣的網域名稱，取其 MX 或 A 記錄，送出 helo/ehlo 讀取訊息，
qmail 在台灣相對是不發達的
如果我們看抽樣的比率來看，僅以台灣的域名(.tw) 為依據不能代表全部，
但是台灣的 .tw 使用率是很高的，台灣的 1000大企業有 95% 使用 .tw 域名
在台灣 CF 有關系到 url 的幾乎都是 .tw 結尾
當然所有的 .tw Domain 查出來的不代表全台灣的結果，但個人相信代表了比例上
是不會有太的的誤差的，而是數量的誤差而以
有人說大陸 qmail 多，我想總是要有一個客觀的證明，我想這才是最重要的 !
有人說大陸反解 <50%, 最好也要有證明，我的證明是查 apnic 全中國的 IP,
用全中國的 IP 查反解得到的答案是 250000 個反解，而分母是多少 ,80000000
所以中國的反解率有人把它看的太高了，其實連 0.5% 都沒有，台灣則是 70% 的反解率
(只要花個一星期跑程式就會有結果)
ecloud 回复于：2006-05-22 12:23:18
引用：原帖由 思一克 于 2006-5-20 23:09 发表
我在第一贴子提出的功能, 都是可选的功能,而且其中不少是用户可选的.
比如DELE_AFTER_POP, 对个别经常出国的使用拨号的用户用,非常好.
还有,这些功能并非sendmail才有.其它系统也可以实现,而且不难实现.
DELE_AFTER_POP这个功能就如同让男人生孩子一样荒唐
因为当初上帝在设计男人的时候就没有考虑这个功能
如果想生孩子，请找女人（imap）
思一克 回复于：2006-05-22 12:30:40
to ecloud,
“DELE_AFTER_POP这个功能就如同让男人生孩子一样荒唐
因为当初上帝在设计男人的时候就没有考虑这个功能
如果想生孩子，请找女人（imap）”
你的比喻非常好。由此知道你对POP协议是十分精通的，否则不会说出这话。
如果人们就喜欢用POP3,又要POP后DELE，那就在SERVER上实现吧。完全可以实现，违反了POP协议，但工作得很好。
ecloud 回复于：2006-05-22 12:38:02
引用：原帖由 abel 于 2006-5-22 10:07 发表
我認為每一種 MTA 都有其利基點， 並無誰好誰差，
完全看在使用它的人身上，能不能發揮出MTA 應有的功能及水準，
對於 sendmail 他是老牌的 MTA (更早於 internet ) , 自然有些包袱，
但是每一個 Unix-like ...
你这种查询反解的方法是错误的
1，很多ISP使用动态域名，当某IP处于不使用状态的时候，他的DNS纪录是release状态，因此你查不到
2，很多动态DNS要求当某IP处于Active状态的时候才给响应，无论IP本身是动态还是静态的，因此这种情况你也查不到
3，公网IP被用于内网（IBM就很多这样的）
最权威的检查结果是某大型网站的IDS纪录
我知道这样的纪录，但是我不能说，因为这是国家保密级别的，我签订过保密协议，具体数据我也无法透露，但是肯定小于50%，但是绝对没有0.5%那么夸张
[ 本帖最后由 ecloud 于 2006-5-22 12:39 编辑 ]
ecloud 回复于：2006-05-22 12:40:53
引用：原帖由 思一克 于 2006-5-22 12:30 发表
to ecloud,
“DELE_AFTER_POP这个功能就如同让男人生孩子一样荒唐
因为当初上帝在设计男人的时候就没有考虑这个功能
如果想生孩子，请找女人（imap）”
你的比喻非常好。由此知道你对POP协议是十分精 ...
同性恋也可以结婚，生孩子，并且孩子很健康:)
变性人生孩子在上个世纪就成功了，但这证明不了男人需要生孩子的功能
[ 本帖最后由 ecloud 于 2006-5-22 12:43 编辑 ]
思一克 回复于：2006-05-22 12:45:23
"同性恋也可以结婚，生孩子，并且孩子很健康" -- 何以见得
DNS反解析的问题，中国的确有许多EMAIL SERVER无反DNS，估计有50%没有。
动态DNS没有反解，或动态IP，都不能做MAIL SERVER。如果硬要做，那只好被许多SERVER拒绝。
abel 回复于：2006-05-22 12:49:29
引用：原帖由 ecloud 于 2006-5-22 12:38 发表
你这种查询反解的方法是错误的
1，很多ISP使用/2006-01/
你看清楚國際上是怎麼做的 , 把新方法論动态域名，当某IP处于不使用状态的时候，他的DNS纪录是release状态，因此你查不到
2，很多动态DNS要求当某IP处于Active状态的时候才给响应，无论IP本身是动态还是 ...
1&2 論點根本是自找事做， CU 是 on 的為何沒反解 ?
多少 bbs 是 on 的哪一個有反解 ?
說你們 0.5% 還是特別高估了，實際上是要打五折的 (0.25%)
http://www.isc.org/ops/ds/reports看懂你就知道了，
自己關起門來反解，那是不對的 !也只有中國人自己會這麼想
超過 你說保不保密十足無關的，從 apnic 上可以看到全中國的 IP ,
這些 IP 反解數就是 250000 , 你沒法證明你的東西及方法論
cn 208277 404217 195940 482 3141 China
講什麼保密協定都可以隨便說說，從 apnic 拿到反解授權而根本沒有多少條， 就算你 30% 也是不可能的
你自己寫一個程式，把北大那個 B 解完你看看多少 % 再來想想看吧
ecloud 回复于：2006-05-22 12:55:11
引用：原帖由 abel 于 2006-5-22 12:49 发表
1&2 論點根本是自找事做， CU 是 on 的為何沒反解 ?
多少 bbs 是 on 的哪一個有反解 ?
說你們 0.5% 還是特別高估了，實際上是要打五折的 (0.25%)
http://www.isc.org/ops/ds/reports看懂 ...
不要拿北大举例子，跟IBM一样，北大也用一些公网IP作为内网使用
CU的问题我不知道，这你要问它的管理员
关门反解很正常，尤其是一些.cn .gov .edu和 .org
isc的report根本不具有意义，很多国内的ip他都连不上
只有你们这些美国的附庸才会不明白关门反解的意义
另外，有很多反解的NS权isc根本就不给中国，当然你不会明白这是为什么
[ 本帖最后由 ecloud 于 2006-5-22 13:00 编辑 ]
思一克 回复于：2006-05-22 13:01:22
to ecloud, 关门反解是什么意思？请明示。
还有，好好讨论技术问题。那种词汇不好。
abel 回复于：2006-05-22 13:13:02
另外，有很多反解的NS权isc根本就不给中国，当然你不会明白这是为什么
光這句就代表你不了解 IP 作業的流程，也代表了你那民族主義的心態
IP 發放是由 IANA 發給個 RIR (ex,APNIC,RIPE,ARIC,LANIC..) 而後由 RIR 發給各單位或國家
如果以 chinanet 為例，他拿到了 59.12.x 的 ip,必是由 cnnic 或是 apnic 取得的,,而 chinanet 的慣例
都是直接向 apnic 拿 IP , 向 APNIC 取得 IP 的時候,同時可以向 APNIC 做反解授權設定
(你的的 ISP 太爛,這一步反解授權都不做,或是向 user 收一年 1000RMB 的反解費用,天下其聞)
所以 ISC 和反解有什麼關係 ? 你有什麼方法論 ? 如果這是你學學問及研究的方法.
NS 不是不給中國，而是中國的 ISP 太爛了，你了解嗎 ? 申請 IP 不懂的申請反解 NS 的實在太多了，
而你們的 DNS 教育有問題，從來只教正解，反解不題，曉得反解授權的人又太少了
abel 回复于：2006-05-22 13:23:46
引用：原帖由 ecloud 于 2006-5-22 12:55 发表
不要拿北大举例子，跟IBM一样，北大也用一些公网IP作为内网使用
CU的问题我不知道，这你要问它的管理员
关门反解很正常，尤其是一些.cn .gov .edu和 .org
isc的report根本不具有意义，很多国内的ip他都连不上 ...
這種公網當內網裏面不是都一樣，
然到 IBM 只在大陸這樣 ?
一個 A 的 HP 就沒有 ?
什麼 active 才有 ptr 根本是吹的，
什麼關門 dns,ptr 你能限制 gov, edu 裏面的 MS 不做反解嗎 ?
關門 DNS 做的那麼好，門外面的像是沙漠一樣 ? 這邏輯也通的太好了
ylcqen 回复于：2006-05-22 17:12:42
能发一份给我吗？[email]ylcqen@163.com[/email]
ecloud 回复于：2006-05-22 19:48:34
好了我不想再啰嗦IP跟NDS的问题了，很多东西不是你们凭想象的
比如铁通222网段的IP都是从国外商业公司那里买来的，甚至路由都没做完全，到61chinanet网段的hops比国外189的都多，你问我为什么要这样买？很简单，通过正规途径弄不来，因为IP已经没得分了。
至于关门，不光是反解，正解也一样，很简单整个国外网段都封掉，也有一些单封某些网段的udp（其实封udp还有其他的原因）
国产的IDS用于国内网络和国外网络的是两个OS，主要是根域指向不同，中国好多政府机构有自己的根域服务器（看上去是完全不合规矩的，但是这是他们需要的，因为有些gov的server还要跟一些com,cn,net的主机有业务联系，他们不会等ROOTSERVER的刷新的），IDS的高级别检测记录是要求所有IP的反解信息的，所以用于不同网络环境的需要不同的配置。
这不是什么民族主义心态，而是凡是关乎到国家安全方面的事情都有特殊的处理方法。IPV6为什么已经成熟的技术迟迟不能应用，就是因为V6的ROOT域解析权，美国不方，为这个事情，中国欧洲和俄国跟美国开过几次会，至今没有什么进展。美国为什么不放呢？你能给我找到一个技术上的解释吗？这不是“民族主义心态”又是什么？Internet OR Usnet?去看看现在V4的ROOTSERVERS里面有几个mil再说吧。不就是ARPNET吗，什么是ARPNET?军用的！
[ 本帖最后由 ecloud 于 2006-5-22 19:51 编辑 ]
大麻 回复于：2006-05-23 09:46:11
引用：原帖由 ecloud 于 2006-5-22 19:48 发表
好了我不想再啰嗦IP跟NDS的问题了，很多东西不是你们凭想象的
比如铁通222网段的IP都是从国外商业公司那里买来的，甚至路由都没做完全，到61chinanet网段的hops比国外189的都多，你问我为什么要这样买？很简单， ...
建议不要把“愤青”那一套来讨论技术问题。我最讨论的就是封锁网络，就像以前不准我们收听短波电台一样。这些东西是长不了。
另外，我同意 abel 的说法，国内的 ISP 的确太烂了，4月份，我还在网上教过广东电信的人做 ptr 解析呢，如果不是因为掌握了做反解的权限，我真不想理他们，机房人员的技术太差了。一个反解析记录居然做了近一个月才做好，前后修改了四次。晕啊！而且还额外收费。
[ 本帖最后由 大麻 于 2006-5-23 09:50 编辑 ]
abel 回复于：2006-05-23 09:47:39
引用：
好了我不想再啰嗦IP跟NDS的问题了，很多东西不是你们凭想象的
比如铁通222网段的IP都是从国外商业公司那里买来的，甚至路由都没做完全，到61chinanet网段的hops比国外189的都多，你问我为什么要这样买？很简单，通过正规途径弄不来，因为IP已经没得分了。
我完全不認為你講的有道理, ISP 買不買 IP 這我不知道,至於什麼 IP 沒得分了更是歪理一堆
我想的是國際通則,你講那什麼 Local Root(那還不如用 BGP anicast, DNS 都不用改呢) 還是金盾工程那
是你們自己的事,IP 沒得分你好好看 www.iana.org 上的
http://www.iana.org/assignments/ipv4-address-space
再說,若連一點 IP 分配的知識都沒有,全部都是二手,三手以上的資訊,而不懂得,亂說一堆,
閱讀 icann,iana, apnic ,rfc, isc 上的文章,只會關起門來說你們都錯了,我想這難免都是中國特色
IP 不夠是問題,但這個不夠不會是十年內的問題,會先不夠的肯定的 AS Number (BGP 交換用), IPv6 你都做
Local Root 和授權巳經沒有關係了,你有 . (ROOT) 就能長 in-addr.arpa , 我想您對 DNS 的知識,IP 相關
的知識恐怕都是不夠的
至於你講的國家安全問題我就不予置評了,講那一狗票全是 Internet 出口/入口 DNS Spoofing ,
設錯的也是一堆,上級交辦 ISP 黑名單 Domain Name 也是一堆
這問題本來是講 Mail 的 requirment , 扯到這邊或許是不太對的,
講中國的反解 <50%, 分明就是自己放大了 100 倍,連反解授權都沒有,還內部自己做呢 !
就連 CNNIC 的 outbound mail server 都沒有反解,你說你們可以做得<50%,
這恐怕是連我們都不敢想像的,我還得在我的 Mail Server 上特別允許 CNNIC
沒有反解的 Mail 能進我們的 sendmail 呢 !
CNNIC 都這樣 ?
社科院都這樣 ?
ISP 都這樣 ?
連 CU 這種站都這樣 ?
還請您想想 50% 有可能嗎?, active 才有 ptr 更是天才想法
http://bbs.chinaunix.net/viewthread.php?tid=385903&extra=page%3D1%26filter%3Ddigest
http://bbs.chinaunix.net/viewthread.php?tid=550823
最後， Local Root 是有必要的，但用自己的列表設定到每一台 DNS 去是白吃作法(現在中國有些是這樣做的),
應該用 BGP anycast (MSDP) 才是最佳解, e 兄若不懂就去 DNS 版找找看過去我說的吧
思一克 回复于：2006-05-23 10:14:43
To Abel,
RDNS 在国内也不是很难（具体做法我不详细明白），因为我们的机器托管在不同的ISP处，让他们给搞好反解析，他们半个月就给做好了。也不用收费。
至于你说很大的主要EMAIL SERVER都没有，那时因为他们的工程师不十分明白RDNS的重要，而没有去做。而不是因为技术上无法做。
还有国内的EMAIL SERVER的反解率绝对不是0。25%（所有IP，是这个比例是可能的）。应该在20%以上。
cyzhu 回复于：2006-05-23 10:54:41
实在是太精彩了,从技术角度谈问题上升到各自信仰的哲学观点的不同.搞技术搞到最强,恐怕就是像上面几位这样上升到从自己的人生哲学角度上处理问题了.
这个问题我和人也讨论过,起初我也不理解,后来领导是这么给我解释的,虽然有点牵强,但是我还是能接受.
他说的特简单:
老美的观点是知道有你这么一个人的时候,首先认为你这个人是好人,然后再慢慢相处......
反过来中国是不会对不认识的人微笑的.
[ 本帖最后由 cyzhu 于 2006-5-23 10:59 编辑 ]
abel 回复于：2006-05-23 12:18:17
引用：原帖由 思一克 于 2006-5-23 10:14 发表
To Abel,
RDNS 在国内也不是很难（具体做法我不详细明白），因为我们的机器托管在不同的ISP处，让他们给搞好反解析，他们半个月就给做好了。也不用收费。
至于你说很大的主要EMAIL SERVER都没有，那时因为他 ...
那思兄有什麼客觀的數據 ?
ISC 跑得不準 ?
我跑得不準 ?
你說 20%, 以 8000 萬個 IP 計，那可是 1600 萬， ISC 的數據只是你們的零頭 ?
ITU (國際電信聯盟) 也有這個數據,CN 也是那麼一丁點，不知那年那月才能跨過 100 萬
abel 回复于：2006-05-23 12:20:30
mail server 最需要反解，所以比率肯定會稍高的，
但以 20 萬個(去掉重覆) 來看， 20% 那您推論全中國的 Mail 約 100 萬部 ?
那還得 20 萬個都用在 mail ptr 上
思一克 回复于：2006-05-23 13:31:50
To Abel,
我是凭空估计。因为国内的许多EMAIL工程师也不是笨的连这个也不知道。如果知道，做起来并不难。
我是说正规的EMAIL SERVER的反解率有20%以上。你可以实验100个，看有多少
abel 回复于：2006-05-23 16:49:43
引用：原帖由 思一克 于 2006-5-23 13:31 发表
To Abel,
我是凭空估计。因为国内的许多EMAIL工程师也不是笨的连这个也不知道。如果知道，做起来并不难。
我是说正规的EMAIL SERVER的反解率有20%以上。你可以实验100个，看有多少
我用 423 個 MX (.cn 域名) 測得實際的反解數是 143 , 這個抽樣是我台灣5000 個域名跑出一些 active 的 cn 域名 1303 個,求其 MX 所得 IP,比例為 32%,而這些域名 (143 個) 有半數左右的反解為這幾個(我不知道這幾個是什麼性質公司)
ce.net.cn
xinnetdns.com
hichina.com
cn.cndata.com
我想抽樣比例雖低，但驗證思兄的說法是對的，我相信誤差應該也不會太大,
不過看來這幾家公司佔中國的 mail 服務比重應該是蠻重的,
也就是一個 MTA 可能管者幾十個或是上百個域的情況非常多,
這是我猜想的情況
思一克 回复于：2006-05-24 15:11:23
基本情况就是Abel说实验的那样。
建议所有搞MAIL SERVER的人一定要建立反DNS解析。否则可以说不是一个完备的MAIL服务器
ecloud 回复于：2006-05-24 23:15:45
BGP anicast？
开玩笑，铁通买来的实际上只是部分到222网段的路由指向，以及人家不再使用这些地址的承诺而已，连AS都没有，还BGP呢，它的主机房旁边就是网通的大BGP网关，可是它要绕将近10个hops从国外转回来才能到他的邻居。北京的铁通是买通了网通的人，私自做了一个到61和202的路由，才使得北京本地铁通用户得到比较好的国内访问质量。实际上这种做法已经严重违反了边界网关协议标准，他跨了几个AS直接连到人家AS内部去了，存在及其严重的路由回环隐患。不是铁通不懂，也不是它没钱，而是实在没办法买不到AS。做生意，被逼无奈没的办法的办法。比如你们很推崇的gmail，还不一样是不严格要求对方MX的反解吗，人家也是为了做生意
别扯什么美国的规则，我说过，那些只对他的附庸有效，甚至欧洲都难办，更不要说中国，222这个网段以前就是欧洲的，当初他们的AS据说是从美国那里“租”来的，只有使用权。就算是美国自己贴出来的规则，也有很多exception
这不今天开了一个会，IBM以后实行严格的每一个月发布一个build的制度，然后一个家伙问3线经理，Should the customer like US Airforce, must wait for one month to get their apar? 然后老家伙说，Oh, I think such kind of customers will have exceptons!
最后，我不再讨论这个问题了，已经严重跑题了，我只想说，不要以为在网上看一些doc就能明白所有的事情，规矩本身不是目的，哪国的规矩都是人定的，不要以为网络就是万能的了，这世界上很多事情并不都在网络上找的到，这世界很大。别以为你很聪明就别人笨，看这个不顺眼那个不服气，有一种东西叫“无奈”，你遇到了才会明白。
最后着重表个态：有能力作反解的，一定要作！
[ 本帖最后由 ecloud 于 2006-5-24 23:18 编辑 ]
abel 回复于：2006-05-25 09:35:04
/20 以上就可以向 apnic 申請 AS number 你懂嗎 ?
沒有 AS , 9394 不是嗎 ?
一方面說別人附庸,可是還是用人家的技術,方法
至於誰聰明誰笨問題,很明顯的那是我笨呀
merlinyu 回复于：2006-05-29 12:12:44
目前 sina,163,sohu 的邮件主机的 ip 基本上有了反解
国外很多的反解是 script 生成的
aeonsun 回复于：2006-07-05 14:39:17
开始挺好，后面就有点变味了！呵呵！
楼主提到的很多功能都是比较有用的，可以让邮件系统更完善。
唯一不同意的就是pop的边收边删功能，因为根本没办法知道客户端的命令组成
如：
outlook的命令为
RETR 1
RETR 2
........
RETR N
完了才
DELE 1
DELE 2
........
DELE N
如果客户的命令为交叉的，那当然没问题，不过这违背了pop协议（当然，要不断发展的协议才会更完美），但我觉得这个不应该加入pop协议中，呵呵(由于这里没加入具体的Mail Server，所以只讨论协议了)！
不过
RETR 1
DELE 1
RETE 2
DELE 2
RETR 3
DELE 3
与最后DEL 1， DEL 2， DEL 3是不是一样的，这个要根据MTA的实现来定，因为在进入更新状态后的异常断开，看有没有再进行更新操作了，如果有，那么就一样，如果没有，那么就不一样了。
而本地验证的确是必要的，前面的兄台说了，我也就不多言了。
由于前些天有事很少来论坛，所以错过了这个帖子，现在忍不住来支持一下。难得一见的好帖，要多出，HOHO。
思一克 回复于：2006-07-05 14:50:30
TO aeosun,
所说的功能和client的RETR DELE组合是没有关系的。
无论怎样组合，都无法解决没有接收完成而断线的问题。必须在SERVER上做手脚。
aeonsun 回复于：2006-07-05 14:56:08
是的，server上可以做，如果是RETR 1
DELE 1
RETE 2
DELE 2
形式的，可以在socket断开后进行状态判断，然后再决定如何处理，而如果是最后DEL 1， DEL 2， DEL 3的话那就没办法了，因为在RETR 1、RETR 2、RETR N时断开，无法获取最后DEL 1， DEL 2， DEL 3命令，所以这样改了也只能解决部份客户端的问题。
思一克 回复于：2006-07-05 15:23:38
to aeronsun,
你还是没有真正明白。和你说的方式没有关系。无论什么方式都可以实现此功能，使得短线后不会重复接收。
思一克 回复于：2006-07-05 15:33:55
因为POP协议决定的 DELE n 命令一旦断线了就自动变为无效。因此发DELE n 的方式对于断线的情况无所谓。
[ 本帖最后由 思一克 于 2006-7-5 15:36 编辑 ]
刘五十三 回复于：2006-07-13 09:44:00
这个文章好，不过本地发本地认证确实有需要，我在sendmail上已经实现了几年了，用milter搞定的，你没有别人密码没法用别人邮箱发信给任何人，就算是内部。起因是有过客户内部冒充老大地址发信骂别人，他把ip,电脑名字一改，发完就改回来。至于内部人用外部信箱发回来根据squid纪录和邮件时间很容易查的。
我觉得还是sendmail好，找资料容易，而且用milter基本上什么都可以搞定了
刘五十三 回复于：2006-07-13 09:47:39
边收边删还是要客户端实现，就算你dele几下，没有成功quit是干不掉的，这种情况我一般叫他们用webmail了。不过邮件多了webmail恨慢，imap要是好用的话我叫他们改用imap好了。
abel 回复于：2006-07-13 10:27:58
引用：原帖由 刘五十三 于 2006-7-13 09:44 发表
这个文章好，不过本地发本地认证确实有需要，我在sendmail上已经实现了几年了，用milter搞定的，你没有别人密码没法用别人邮箱发信给任何人，就算是内部。起因是有过客户内部冒充老大地址发信骂别人，他把ip,电脑 ...
劉兄也精 milter 此道 ?
不知您用哪些 Milter package ? 我雖覺得 mimedefang 不錯, 但這個功能其實 sendmail.cf (ruleset) 就可以做到了,畢竟 Milter 是去 hook 外部的一些程式, 難免增加許多系統負擔,而且會造成 I/O 增多,
當然,彈性是它的最大優點了
刘五十三 回复于：2006-07-13 10:35:46
引用：原帖由 abel 于 2006-7-13 10:27 发表
劉兄也精 milter 此道 ?
不知您用哪些 Milter package ? 我雖覺得 mimedefang 不錯, 但這個功能其實 sendmail.cf (ruleset) 就可以做到了,畢竟 Milter 是去 hook 外部的一些程式, 難免增加許多系統負擔,而且會 ...
我用mimedefang，还有自己也写milter,其实很菜，就是拷贝一个milter模板来修改，系统负担我觉得不用太担心，一般用sendmail的用户不会太多，撑死1000个，有时候milter会死掉，有时候sendmail会死掉，我写了个cronjob,5分钟看看telnet 25回复对不对，不对就重新启动sendmail.客户一般停个1两分钟没大影响，甚至他们根本不知道
abel 回复于：2006-07-13 12:00:27
引用：原帖由 刘五十三 于 2006-7-13 10:35 发表
我用mimedefang，还有自己也写milter,其实很菜，就是拷贝一个milter模板来修改，系统负担我觉得不用太担心，一般用sendmail的用户不会太多，撑死1000个，有时候milter会死掉，有时候sendmail会死掉，我写了个 ...
如果這樣您不如用 daemontools 還較好,
至於 mimedefang 若死掉, sendmail 會回應 4xx , 這個您得要看到 4xx 才能處理恐怕會較費事
而 4xx 成因有可能是 miter 死掉,或 mimedefang 程式出錯 (runtime error), 此時即使重啟恐怕也是沒有用
(Ex: mimedefang 用到 mysql, 但 mysql go away 了, mimedefang 就會有問題)
刘五十三 回复于：2006-07-13 12:46:54
引用：如果這樣您不如用 daemontools 還較好,
至於 mimedefang 若死掉, sendmail 會回應 4xx , 這個您得要看到 4xx 才能處理恐怕會較費事
而 4xx 成因有可能是 miter 死掉,或 mimedefang 程式出錯 (runtime error), 此時即使重啟恐怕也是沒有用
(Ex: mimedefang 用到 mysql, 但 mysql go away 了, mimedefang 就會有問題)
多谢指点，不过，嘿嘿，我自己写的milter不太稳定，有时候莫名其妙就挂了，我都是在脚本中tail maillog后100行，看到有milter erroor就重起sendmail ,懒得换了，我很怕换系统，升级什么的，要不是rh8不能跑论坛的mysql,我会一直用rh8架系统。反正运行了很久都很好用。
思一克 回复于：2006-07-13 18:26:20
sendmail会死? 需要重新启动?
刘五十三 回复于：2006-07-14 08:41:05
引用：原帖由 思一克 于 2006-7-13 18:26 发表
sendmail会死? 需要重新启动?
单纯的sendmail很少死，不过缺省在load average 到了好像是12开始拒绝收信。一般死机都是由于外挂的api milter导致，一般系统负荷过重也是由于杀毒，垃圾处理之类导致系统太忙。
abel 回复于：2006-07-14 09:21:22
引用：原帖由 刘五十三 于 2006-7-14 08:41 发表
单纯的sendmail很少死，不过缺省在load average 到了好像是12开始拒绝收信。一般死机都是由于外挂的api milter导致，一般系统负荷过重也是由于杀毒，垃圾处理之类导致系统太忙。
我用 mimedefang 也沒有發生什麼問題,
用 dk-milter (Domain Key) 也是,
系統跑來好好的,從來也沒有出現問題,
因為要上一個 miter 或對 milter 修改前,巳都做了大量的測試
HawaiiLeo 回复于：2007-04-25 17:24:32
这个帖子太棒了，受益匪浅。
|
