发往国外的邮件，用户会重复收到多封，还有用户收到一些aaazzzaaazzz内容的信件！
这些既不是垃圾邮件也不是病毒邮件，都是由正常用户发出的！！
最近几天发现的，是否有兄弟遇到同样问题？
[ 本帖最后由 fluke888 于 2006-9-28 09:27 编辑 ]
我家老婆最美丽 回复于：2006-09-26 13:29:44
查maillog吧。
思一克 回复于：2006-09-26 13:33:02
我遇到过。
对方是一个什么MSOUTLOOK的东西，不知道如何搞的不断发这个小邮件。
可以在SERVER上拒绝300字节以下的一切邮件。
freedom_L 回复于：2006-09-26 13:54:30
引用：原帖由 思一克 于 2006-9-26 13:33 发表
可以在SERVER上拒绝300字节以下的一切邮件。
大哥,这个QMAIL怎么设置?
思一克 回复于：2006-09-26 14:49:33
和qmail本身无关。
应该是mail content 扫描程序的工作。比如qmail-scanner等。
fluke888 回复于：2006-09-26 15:02:32
引用：原帖由 思一克 于 2006-9-26 13:33 发表
我遇到过。
对方是一个什么MSOUTLOOK的东西，不知道如何搞的不断发这个小邮件。
可以在SERVER上拒绝300字节以下的一切邮件。
思一克，你好！
关于aaazzz的问题，网络上有很多讨论，但是一直没有结论。
有人说是邮件系统的问题，但是send/postfix等都出现过这个问题。
有人说是cisco pix防火墙造成的。不知道你那里是否有pix防火墙。
还有人说是国内的great firewall造成的。
我现在也在做进一步的判断。就我现在收到的反馈都是发往国外的信件出现问题。
但我这里没有pix防火墙。
另外还有一个问题：用户向外域发出邮件后，接收者通常会收到很多封同样的邮件，但发送者只发送了一遍。
我对比了多封邮件发现，用户到发件服务器再到网关的过程是正常的，只发送了一遍，但是，网关却不停的向目的用户多次发送此封邮件，导致用户大量接收～
另外，网关从早晨到现在处理了5w封信件，log中有近2000次的“Connection reset by”，我没有历史数据，不知道这是否正常。
现在我把邮件网关passby了，看是否还会出现同样的问题，用以确定是否是邮件网关的故障。
abel 回复于：2006-09-26 15:17:46
天底下只有中國往外連的 mail 才有 aaazzzaaazzz
我用 cisco PIX 全世界更有不知多少人用,若是 PIX 這個問題不可能在 google 找不到!
動點大腦
fluke888 回复于：2006-09-26 15:26:24
引用：原帖由 abel 于 2006-9-26 15:17 发表
天底下只有中國往外連的 mail 才有 aaazzzaaazzz
我用 cisco PIX 全世界更有不知多少人用,若是 PIX 這個問題不可能在 google 找不到!
動點大腦
你怎么就知道我不动大脑，就事论事，别张口就说。
aaazzzaaazzz的问题也有不少人遇到，google上也不是那么容易找到结果。
思一克 回复于：2006-09-26 15:42:37
我遇到的情况是美国人发的，他们可能用的lotus notes,或MS OUTLOOK.
发到qmail的用户。
我发觉后让对方重新安装了CLIENT XP，我这边拒绝300字节小于的一切邮件。
abel 回复于：2006-09-26 15:51:05
引用：原帖由 fluke888 于 2006-9-26 15:26 发表
你怎么就知道我不动大脑，就事论事，别张口就说。
aaazzzaaazzz的问题也有不少人遇到，google上也不是那么容易找到结果。
不少人遇到的東西 google 沒有結果 ? 這個推論有問題吧
這種 Search 就只要打 aaazzzaaazzz 就夠了,每一個問的都是大陸,或是進出大陸的 mail 才會有這
種問題,和 PIX 有什麼關係,實在沒有道理
思一克 回复于：2006-09-26 15:58:25
to abel,
不仅仅是大陆有此问题。我半年前遇到（还可以查到当时的帖子）就是美国人从美国通过美国SERVER发到大陆的。
好象和SERVER以及CISCO无关，就是WINDOWS XP上运行的MS OUTLOOK，和WORD造成的。也可能是机器中了病毒之类的造成的。
fluke888 回复于：2006-09-26 16:09:11
这里有几条关于aaazzz的信息，是我搜索后过滤出来的，大家看看是否有帮助：
http://blog.delphij.net/archives/001440.htm
http://www.extmail.org/forum/archive/2/0510/532.html
http://phorum.study-area.net/viewtopic.php?t=36733&highlight=&sid=3a55834614d7a8bd50eee6ed106b8525
由于我这里没有pix，因此无法直接验证其说法，我正在努力想其他方法。
abel 回复于：2006-09-26 16:15:27
我認為,總之一句
"有中國特色的 SMTP 現象"
只有進出大陸就會有這個現象
fluke888 回复于：2006-09-26 16:41:12
引用：原帖由 abel 于 2006-9-26 16:15 发表
我認為,總之一句
"有中國特色的 SMTP 現象"
只有進出大陸就會有這個現象
这没准就是真正原因啊。。。唉...
思一克 回复于：2006-09-26 16:49:08
你看这个上外国人的。和中国无关。
http://www.oclug.on.ca/archives/oclug/2005-April/045272.html
在SERVER上查是哪个CLIENT发的
abel 回复于：2006-09-26 16:56:50
思兄以 Domain 來判斷是有問題的
222.137.59.225 根本就是中國的 IP (CNC) , 只是域名是 .de 而以
所以還是大陸問題,如果是那些 Common AP/Server 是不可能的
# whois 222.137.59.225@whois.apnic.net
[查詢 whois.apnic.net]
[whois.apnic.net]
% [whois.apnic.net node-1]
% Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
inetnum: 222.136.0.0 - 222.143.255.255
netname: CNCGROUP-HA
descr: CNCGROUP Henan province network
descr: China Network Communications Group Corporation
descr: No.156,Fu-Xing-Men-Nei Street,
descr: Beijing 100031
country: CN
admin-c: CH455-AP
tech-c: WW444-AP
mnt-by: APNIC-HM
mnt-lower: MAINT-CNCGROUP-HA
mnt-routes: MAINT-CNCGROUP-RR
changed: hm-changed@apnic.net 20031209
status: ALLOCATED PORTABLE
changed: hm-changed@apnic.net 20060126
changed: hm-changed@apnic.net 20060201
source: APNIC
route: 222.136.0.0/13
descr: CNC Group CHINA169 Henan Province Network
country: CN
origin: AS4837
mnt-by: MAINT-CNCGROUP-RR
changed: abuse@cnc-noc.net 20060118
source: APNIC
role: CNCGroup Hostmaster
e-mail: abuse@cnc-noc.net
address: No.156,Fu-Xing-Men-Nei Street,
address: Beijing,100031,P.R.China
nic-hdl: CH455-AP
phone: +86-10-82993155
fax-no: +86-10-82993102
country: CN
admin-c: CH444-AP
tech-c: CH444-AP
changed: abuse@cnc-noc.net 20041119
mnt-by: MAINT-CNCGROUP
source: APNIC
person: Wei Wang
nic-hdl: WW444-AP
e-mail: abuse@public.zz.ha.cn
address: #37 Wei Wu Road, Zhengzhou, Henan Provice
phone: +86-371-65952358
fax-no: +86-371-65968952
country: CN
changed: wangw@data.zz.ha.cn 20060205
mnt-by: MAINT-CNCGROUP-HA
source: APNIC
思一克 回复于：2006-09-26 16:59:02
To Abel,
问题是我遇到的就是美国公司的人发的，300多个那东西。重新安装了机器就好了。
她既然可以发给我同事，也可以发给任何在其他地方的外国人。
abel 回复于：2006-09-26 17:02:22
引用：原帖由 思一克 于 2006-9-26 16:59 发表
To Abel,
问题是我遇到的就是美国公司的人发的，300多个那东西。重新安装了机器就好了。
她既然可以发给我同事，也可以发给任何在其他地方的外国人。
那是因為他發給在大陸上的你,他發給別人就沒有這種問題 !?
如果這是普遍現象, google 沒有幾萬條也會有上千條,而且什麼語系都會有
就大陸永遠在這個問題上打轉,除了國家做的,還會有別人,或別的軟體 ?
思一克 回复于：2006-09-26 17:05:05
To Abel,
你看这个IP是哪里的167.206.5.186
http://www.pcreview.co.uk/forums/thread-2003702.php
Return-path: <[email]vinrin57@optonline.net[/email]>
Received: from mta25.srv.hcvlny.cv.net
(mta25.srv.hcvlny.cv.net [167.206.5.186]) by mstr6.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
with ESMTP id <[email]0HW2007A2A3ER1@mstr6.srv.hcvlny.cv.net[/email]> for
[email]vinrin57@optonline.net[/email]; Mon, 12 Apr 2004 10:11:40 -0400 (EDT)
Received: from tumsaecomputer ([218.61.5.23]) by mta25.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004))
with ESMTP id <[email]0HW2000MFA0XYN@mta25.srv.hcvlny.cv.net[/email]> for
[email]vinrin57@optonline.net[/email] (ORCPT [email]vinrin57@optonline.net[/email]); Mon,
12 Apr 2004 10:10:11 -0400 (EDT)
Date: Mon, 12 Apr 2004 10:10:11 -0400 (EDT)
Date-warning: Date header was inserted by mta25.srv.hcvlny.cv.net
From: [email]vinrin57@optonline.net[/email]
Message-id: <[email]0HW2000MMA0ZYN@mta25.srv.hcvlny.cv.net[/email]>
Content-transfer-encoding: 7BIT
Original-recipient: rfc822;[email]vinrin57@optonline.net[/email]
"Uncle Vinnie" <[email]vinrin57@nospam.optonline.net[/email]> wrote in message
news:z_Oec.26621$[email]467.4931377@news4.srv.hcvlny.cv[/email].n et...
思一克 回复于：2006-09-26 17:07:40
或者218.61.5.23
？
是源头？
abel 回复于：2006-09-26 17:09:33
[whois.apnic.net]
% [whois.apnic.net node-1]
% Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
inetnum: 218.60.0.0 - 218.61.255.255
netname: CNCGROUP-LN
country: CN
descr: CNCGROUP Liaoning province network
admin-c: CH455-AP
tech-c: GZ84-AP
status: ASSIGNED NON-PORTABLE
mnt-by: APNIC-HM
mnt-lower: MAINT-CNCGROUP-LN
mnt-routes: MAINT-CNCGROUP-RR
changed: [email]hm-changed@apnic.net[/email] 20040405
changed: [email]hm-changed@apnic.net[/email] 20040927
changed: [email]hm-changed@apnic.net[/email] 20060124
source: APNIC
route: 218.60.0.0/15
descr: CNC Group CHINA169 Liaoning Province Network
country: CN
origin: AS4837
mnt-by: MAINT-CNCGROUP-RR
changed: [email]abuse@cnc-noc.net[/email] 20060118
source: APNIC
role: CNCGroup Hostmaster
e-mail: [email]abuse@cnc-noc.net[/email]
address: No.156,Fu-Xing-Men-Nei Street,
address: Beijing,100031,P.R.China
nic-hdl: CH455-AP
phone: +86-10-82993155
fax-no: +86-10-82993102
country: CN
admin-c: CH444-AP
tech-c: CH444-AP
changed: [email]abuse@cnc-noc.net[/email] 20041119
mnt-by: MAINT-CNCGROUP
source: APNIC
person: Guangyu Zhan
nic-hdl: GZ84-AP
e-mail: [email]abuse@online.ln.cn[/email]
address: DATA Communication Bureau of Liaoning Province,China
address: 38 Lianhe Road,Dadong District Shenyang 110044,China
phone: +86-24-22800096
fax-no: +86-24-22800368
country: CN
changed: [email]zhangy@lntelecom.com[/email] 20030122
mnt-by: MAINT-CNCGROUP-LN
source: APNIC
還是大陸呀! 你 Search 那一條不是和 CN 有關的 ! 這問題就在 G - C - D 而以,
我認為這個推論很清楚,只是沒辨法證明而以 !
思一克 回复于：2006-09-26 17:21:31
To Abel,
如果是你说的那样，那可能是大陆的SMTP路径上什么东西引起的？如果是CLIENT端造成的，就不可能仅仅和大陆有关。
或是和WINDOWS XP的汉字版本有关？？
还有，非常容易知道是不是CLIENT发的。在SERVER上看一下就可以了。
我认为是CLIENT端发的。还有我7个月前遇到的是美国OFFICE的人发的。用的是EN WINDOW XP， MS OUTLOOK。SERVER 在美国
所以我不认为仅仅和大陆有关。
o00o 回复于：2006-09-26 21:13:49
我倾向于是CN的问题。
我遇到有说是客户端问题的，但是没有有力的证据。
关键是这个东西并不是每次都出现，而是不定期的出现，这个排查起来就比较困难。而且你还没有有力的证据来说明这个问题，也没有人站出来对此负责。ML的网管不好当啊～～！
醉卧水云间 回复于：2006-09-26 22:02:10
GFW过滤进出邮件，当发现敏感字后往两边各发送三个伪造的reset干掉连接，通常都发生在数据传输中间，所以会干扰到内容。思一克你可以测一下，服务端和客户端都屏蔽掉reset包，然后发送邮件，应该就不会有类似问题了。解决这个问题的方法也很简单，就是加密传输，类似于Gmail的pop和smtp，你想发什么都可以，让GFW成摆设吧。
台湾的往来邮件更严格。
避免此类麻烦就是学Gmail加密，让他们干瞪眼。
abel 回复于：2006-09-27 08:22:59
引用：原帖由 o00o 于 2006-9-26 21:13 发表
我倾向于是CN的问题。
我遇到有说是客户端问题的，但是没有有力的证据。
关键是这个东西并不是每次都出现，而是不定期的出现，这个排查起来就比较困难。而且你还没有有力的证据来说明这个问题，也没有人站出来 ...
是的 ! 深感同意
思兄的狀況也不過是7個月來偶發一次,那別人頻率又是如何我們不知道,
說是 Client 問題說不過去,那為什麼別人描述的狀況不同但問題都一樣,
client 問題早就該 fix 掉了,或是 google 會有一狗票了,結果什麼都沒有
所以動動大腦
思一克 回复于：2006-09-27 08:41:38
To Abel,
我的记录就是大约7，8个月前，美国同事发了300多个给一个BJ这里的人。
如果是RESET等由于过滤，那WHY她发那么多（是用不同的连接发的）。
这个在发这东西的SERVER上十分容易观察到是CLIENT发的。
也有这情况，一个病毒类的坏东西，去年在国外，今年主要在国内发作。
继续研究吧
abel 回复于：2006-09-27 08:50:11
引用：原帖由 思一克 于 2006-9-27 08:41 发表
To Abel,
我的记录就是大约7，8个月前，美国同事发了300多个给一个BJ这里的人。
如果是RESET等由于过滤，那WHY她发那么多（是用不同的连接发的）。
这个在发这东西的SERVER上十分容易观察到是CLIENT发的 ...
看來思兄還是轉不過來,
什麼去年在國外,今年在國內的 virus 都出來了,你 google 找到這個毒了嗎 ?
有這個毒嗎 ? 那麼多人都說不是病毒 (因為 anti-virus 都沒有 scan 到) 而且少於 300 bytes
的毒 (含 header 那毒是多小呀 !),一點說服力都沒有
前面的朋友也都講了, aaazzz 的信不具特定性 (或說還沒有歸納出來),我這個從未收過 aaazzz 的台灣人都
知道這是 CN 搞的鬼,他連 DNS,HTTP... 都搞鬼郵件實在也不算什麼了
思一克 回复于：2006-09-27 09:01:54
To Abel,
我知道不是病毒。原来我收到这东西时候详细研究过它。
我的措施就是在SERVER拒绝300字节以下的邮件，立刻就好了。
现在是探讨他的来源。
我不排除你说的可能，因为你那么肯定。
我建议发此东西的管理员在SERVER看，不就容易知道是否是CLIENT段发的了。
网上还有说可能：
一个垃圾广告邮件的木马在CLIENT机器上发作造成的。
还有说是POSTFIX的BUG。
。。。
等。
只是日本人（几个网站）说是中国特有的。还有解决方法。但不懂日本文字，看不懂。
fluke888 回复于：2006-09-27 09:11:34
o? 哪几个网站？有什么解决办法？
我在服务器上看了，客户端确实只发送了一遍，是我们的服务器在向对方服务器不停的发送。与客户端无关。
其实这在收件人的邮件头中也可以看到。收件人收到多封同样的邮件，发件时间都是一样的，但从网关出去的时间是不同的。
abel 回复于：2006-09-27 09:14:00
引用：原帖由 思一克 于 2006-9-27 09:01 发表
To Abel,
我知道不是病毒。原来我收到这东西时候详细研究过它。
我的措施就是在SERVER拒绝300字节以下的邮件，立刻就好了。
现在是探讨他的来源。
我不排除你说的可能，因为你那么肯定。
我建议发此东西的 ...
我的判斷只在於此事只發生在大陸或進出大陸的郵件 !
其他的部份從來沒見過如此而以
(從提問,及 Search Engine 上來判斷就知道了,所以即使我不在大陸,也可以判斷這樣的情況)
至於避免方法在於 MTA 要使用 SSL (STARTTLS) 或連外時使用 SSL Tunnel
這樣子做可以避免 CN 的過濾
思一克 回复于：2006-09-27 09:19:51
To flute888,
你在SERVER上可以看到CLIENT发了（1遍）aaazzzaaazzzaaazzzaaazzz 小MESSAGE?
思一克 回复于：2006-09-27 09:42:07
我的考虑--
这个和SERVER无关。是CLIENT端造成的。
即使是CLIENT端发一个，也就证明是client造成的了。
一个MAIL连接可以RESET 100次发成100个MSG。
CLIENT端乱了。
至于是否中国特有，我不认为是。我的经验是美国人用美国的SERVER也发了这个。
还有，如果在SERVER上可以看到一个aaazzzaaazzzaaazzz的垃圾从CLIENT端发了，就可以说不是过滤引起。因为CLIENT和SERVER之间没有过滤（有的C和S在一个内部网，无过滤，即使S在外部，应该也没有过滤。过滤都设在国际出口）
fluke888 回复于：2006-09-27 09:42:34
引用：原帖由 思一克 于 2006-9-27 09:19 发表
To flute888,
你在SERVER上可以看到CLIENT发了（1遍）aaazzzaaazzzaaazzzaaazzz 小MESSAGE?
是的，我的发件日志上确实如此。
思一克 回复于：2006-09-27 09:43:41
你将发垃圾的那么CLIENT WINDOWS重新安装
fluke888 回复于：2006-09-27 09:45:42
引用：原帖由 思一克 于 2006-9-27 09:42 发表
我的考虑--
这个和SERVER无关。是CLIENT端造成的。
即使是CLIENT端发一个，也就证明是client造成的了。
一个MAIL连接可以RESET 100次发成100个MSG。
CLIENT端乱了。
至于是否中国特有，我不认为是。我的 ...
哦，我弄混了。
我说的是另外一个现象。就是客户端只发了一遍邮件，但是用户那边却收到十几甚至几十封同样的邮件。
这中现象只是在最近几天才发现，而且很多例。
一直在查这个，所以弄混了，抱歉！
思一克 回复于：2006-09-27 09:54:28
CLIENT（C）只发一遍邮件，却可以发成100封。SMTP协议就是这样的，
RESET，
。。。
RESET，
。。。
只要你可以确定C发过了aaazzzaaazzz 一次就足说明是C的问题了。因为正常的CLIENT可能发aaazzzaaazzz吗？一定是病毒类（不是病毒，类）的东西造成的，或是WINDOWS某个功能，某个操作乱了。
abel 回复于：2006-09-27 10:00:12
引用：原帖由 思一克 于 2006-9-27 09:42 发表
我的考虑--
这个和SERVER无关。是CLIENT端造成的。
即使是CLIENT端发一个，也就证明是client造成的了。
一个MAIL连接可以RESET 100次发成100个MSG。
CLIENT端乱了。
至于是否中国特有，我不认为是。我的 ...
思兄對 TCP 熟不熟 ? CN 的 GW 不能做 Fake 處理嗎 ?
美國對美國的 Server 發也有這個問題,那就拿出證明不就很清楚, google 中我倒沒有看到那一條和中國無關的
你的經驗比的過 google 出來的總體經驗 ? 更何況只是一件 ?
大家也都明白的說了,這個狀況是突然的(時而很多時而很少),你怎知道就是 Client 造成的 ?
出口有過濾這個是大家都明白的,但你怎知中國內部就沒有過濾呢 ? 這個我從來都不敢說有或沒有
分明就是進出口造成的,你能說明一下為什麼台灣都沒有嗎 ? 大家用的軟體硬體, MTA/MUA 沒有什麼差別吧
為什麼 jp/uk..都沒有, google 也找不到一個 usa 的例子(就你說的那一個)?
就經驗法則來講說是 CN 的 Filter 造成的絕對站的住
abel 回复于：2006-09-27 10:04:34
引用：原帖由 思一克 于 2006-9-27 09:54 发表
CLIENT（C）只发一遍邮件，却可以发成100封。SMTP协议就是这样的，
RESET，
。。。
RESET，
。。。
只要你可以确定C发过了aaazzzaaazzz 一次就足说明是C的问题了。因为正常的CLIENT可能发aaazzzaaazzz吗 ...
你用的 Client 和我用的 Client 有什麼差別 ?
你會中的毒和全世界會中的毒有什麼差別 ?
你用的 MTA 和他人用的 MTA 有什麼差別 ?
只有你們的出口和全世界的出口不一樣
fluke888 回复于：2006-09-27 10:07:55
引用：原帖由 思一克 于 2006-9-27 09:54 发表
CLIENT（C）只发一遍邮件，却可以发成100封。SMTP协议就是这样的，
RESET，
。。。
RESET，
。。。
只要你可以确定C发过了aaazzzaaazzz 一次就足说明是C的问题了。因为正常的CLIENT可能发aaazzzaaazzz吗 ...
o ,我说的一遍是客户发送正常的邮件发送一遍，客户端却收到很多遍。不是aaazzz的邮件。我想也应当是reset的问题。大家的服务器每天的日志中大概能有多少reset记录呢？昨天我说了，5w封邮件时有2k个reset记录。不知大家是否正常。
至于aaazzz的邮件，我正在检查客户端的发送记录。
abel 回复于：2006-09-27 10:16:18
引用：原帖由 fluke888 于 2006-9-27 10:07 发表
o ,我说的一遍是客户发送正常的邮件发送一遍，客户端却收到很多遍。不是aaazzz的邮件。我想也应当是reset的问题。大家的服务器每天的日志中大概能有多少reset记录呢？昨天我说了，5w封邮件时有2k个reset记录。 ...
reset ? Client (MTA/MUA) 何必做這種事呢! 中毒也不可能
而是 CN GW 所送的 TCP flag RST , 因為在 DATA 後才送 RST,但 DATA 可能巳經出去了
所以 Source MTA 才可能再重送,而不是 SMTP 中的 reset !
fluke888 回复于：2006-09-27 10:21:50
引用：原帖由 abel 于 2006-9-27 10:16 发表
reset ? Client (MTA/MUA) 何必做這種事呢! 中毒也不可能
而是 CN GW 所送的 TCP flag RST , 因為在 DATA 後才送 RST,但 DATA 可能巳經出去了
所以 Source MTA 才可能再重送,而不是 SMTP 中的 reset !
呵呵，我说的就是MTA中的reset，我的MTA在与客户的MTA通讯时有很多reset记录。我想重复收到的原因就是data已经送出，而恰巧此时会触发GFW的规则，发送fake的RST信号，导致连接结束。so，source MTA不得不重传，再被reset，如此往复，导致用户收到多封。
fluke888 回复于：2006-09-27 10:25:19
我向客户要到了一个原始的邮件，邮件头很奇怪。估计是被修改后的结果。也请大家帮忙分析分析：用户名、源ip和域名部分做了修改。
Received: from McAfeeK.aig.co.jp ([170.105.205.142]) by svmalc01.clis.co.jp with Microsoft SMTPSVC(5.0.2195.6713);
Fri, 22 Sep 2006 10:27:57 +0900
Received: from (170.105.205.143) by McAfeeK.aig.co.jp via smtp
id 42be_7af89fba_49d9_11db_8aca_00304827c729;
Fri, 22 Sep 2006 10:27:15 +0900
Received: from nsk.aig.co.jp (unverified) by skmime11kj.r6-core.r6.aig.net
(Content Technologies SMTPRS 4.3.17) with SMTP id <T7ae1795844aa69cd8f4a0@skmime11kj.r6-core.r6.aig.net>;
Fri, 22 Sep 2006 10:27:16 +0900
Message-ID: <T7ae1795844aa69cd8f4a0@skmime11kj.r6-core.r6.aig.net>
Received: from mailgate1.domain.com ([ip.ip.ip.ip]) by nsk.aig.co.jp
with ESMTP id jp; Fri, 22 Sep 2006 10:14:54 +0900
From: user@domain.com
Bcc:
Return-Path: user@domain.com
X-OriginalArrivalTime: 22 Sep 2006 01:27:57.0209 (UTC) FILETIME=[556D7090:01C6DDE6]
Date: 22 Sep 2006 10:27:57 +0900
aaazzzaaazzzaaazzzaaazzzaaazzz
思一克 回复于：2006-09-27 10:25:29
To Abel,
我如何拿出来半年多以前的证明？我的亲身经历，我就说了。难道我还故意说假话不成。
现在问题不难判断，只要在SERVER上检查，CLIENT发过这短az垃圾,哪怕是一次，那就是client的问题。
flute888说过client的确发个这垃圾。
abel 回复于：2006-09-27 10:28:44
SMTP 中 DATA 後的 RESET 不會影響資料重傳,因為 DATA 後的東西若是 2xx 巳代表成功了
至於 DATA 後若收到 TCP flag 中的 RST (reset),因為 TCP 連線被重設,所以在 mail log 中就會
顯示 connection reset (smtp 的 reset 不會有這種訊息,更何況誰寄信會送 smtp reset)
這種 reset 訊息通常是被動式的 FW/IDS 所引起 , 這才是根本的原因,和 smtp protocol 中的 reset 根本無關
思一克 回复于：2006-09-27 10:29:41
还有：
CU上一个朋友说：
用windows explore的send to mail recipient就会产生这种邮件，我的postfix也发生过这个问题，开始也是以为是病毒或垃圾邮件，试验多次才知道原因。
你们也可以实验看可否重复
abel 回复于：2006-09-27 10:35:18
引用：原帖由 思一克 于 2006-9-27 10:25 发表
To Abel,
我如何拿出来半年多以前的证明？我的亲身经历，我就说了。难道我还故意说假话不成。
现在问题不难判断，只要在SERVER上检查，CLIENT发过这短az垃圾,哪怕是一次，那就是client的问题。
flute8 ...
我並沒有說你說假話, 但是你從不想想 google 上呈現的 Search 結果代表的意涵,那一個外對外有這種問題 ?
flute888 兄的 maillog 的 CN GW 欺騙他的結果,所以他以為真的是從該 Source IP 來的結果,實際上卻是假的(去查對方的 maillog 即可知),所以 maillog 故然重要,但是要知道這裏面所代表的 IP GW 都可以做掉的,
如果兩端的 maillog 可以 match 這封信,那才代表這個不是 GW 作假
思一克 回复于：2006-09-27 10:38:55
flute888,
你的SERVER和CLIENT是否在一个内部网？如果是那就可以否定了一个结论。
如果不是，比如SERVER在外IP，基本上也差不多。Abel说的那些过滤一般不会设在这之间。
abel 回复于：2006-09-27 10:39:04
引用：原帖由 fluke888 于 2006-9-27 10:25 发表
我向客户要到了一个原始的邮件，邮件头很奇怪。估计是被修改后的结果。也请大家帮忙分析分析：用户名、源ip和域名部分做了修改。
Received: from McAfeeK.aig.co.jp ([170.105.205.142]) by svmalc01.cl ...
]
信件不重要,你可以去問 Source MTA 的管理者,他的 maillog 有沒有這一筆
思一克 回复于：2006-09-27 10:39:26
flute888,
你的SERVER和CLIENT是否在一个内部网？如果是那就可以否定了一个结论。
如果不是，比如SERVER在外IP，基本上也差不多。Abel说的那些过滤一般不会设在这之间。
abel 回复于：2006-09-27 10:44:24
引用：原帖由 思一克 于 2006-9-27 10:29 发表
还有：
CU上一个朋友说：
用windows explore的send to mail recipient就会产生这种邮件，我的postfix也发生过这个问题，开始也是以为是病毒或垃圾邮件，试验多次才知道原因。
你们也可以实验看可否重复
思兄還是在個案上打轉呀 !
天底下多少人這樣用為什麼只有中國有呀 !
你在技術上打轉就不懂的推論結果 ?
smtp 中 reset 會影響 信件重送我就不想說什麼了
都講千百次, google 的結果就是答案 ,技術的深淺巳經無關了
abel 回复于：2006-09-27 10:46:32
引用：原帖由 思一克 于 2006-9-27 10:38 发表
flute888,
你的SERVER和CLIENT是否在一个内部网？如果是那就可以否定了一个结论。
如果不是，比如SERVER在外IP，基本上也差不多。Abel说的那些过滤一般不会设在这之间。
看看標題,想也知道這些都不可能在內網內 ! 內網內的東西網路上說法還會這麼多嗎 ?
fluke888 回复于：2006-09-27 10:46:59
引用：原帖由 思一克 于 2006-9-27 10:25 发表
To Abel,
我如何拿出来半年多以前的证明？我的亲身经历，我就说了。难道我还故意说假话不成。
现在问题不难判断，只要在SERVER上检查，CLIENT发过这短az垃圾,哪怕是一次，那就是client的问题。
flute8 ...
引用：原帖由 思一克 于 2006-9-27 10:39 发表
flute888,
你的SERVER和CLIENT是否在一个内部网？如果是那就可以否定了一个结论。
如果不是，比如SERVER在外IP，基本上也差不多。Abel说的那些过滤一般不会设在这之间。
唉，各位，怪我没解释清楚！
我不是说了嘛，我弄混了，我还没有查到客户端有发送aaazzz的日志。怪我，怪我，呵呵！
引用：原帖由 fluke888 于 2006-9-27 09:45 发表
哦，我弄混了。
我说的是另外一个现象。就是客户端只发了一遍邮件，但是用户那边却收到十几甚至几十封同样的邮件。
这中现象只是在最近几天才发现，而且很多例。
一直在查这个，所以弄混了，抱歉！
思一克 回复于：2006-09-27 10:50:40
To Abel,
165.21.103.142
209.86.89.70
看这两2 IP是那里的
abel 回复于：2006-09-27 10:53:39
引用：原帖由 思一克 于 2006-9-27 10:50 发表
To Abel,
165.21.103.142
209.86.89.70
看这两2 IP是那里的
自己用 whois 查不就知道了 ?
思一克 回复于：2006-09-27 11:01:19
To Abel,
你怎么那么相信google上人说的吗？
我为什么不相信你？因为我有过外国人发给我们的经历。
还有这中不正常的小邮件（内容未必一定是aaazzz, 也可以是其他的类似垃圾），不可能仅仅是和大陆有关。
这里我有昨天的LOG
smtpd 3531 queue-q 3532: too_small_msg 209.86.89.70 from [email]rongyao@earthlink.net[/email] size 188
smtpd 4198 queue-q 4201: too_small_msg 165.21.103.142 from [email]carolax7424@263.com[/email] size 178
smtpd 10775 queue-q 10778: too_small_msg 209.86.89.70 from [email]rongyao@earthlink.net[/email] size 188
smtpd 12667 queue-q 12669: too_small_msg 165.21.103.142 from [email]carolax7424@263.com[/email] size 178
smtpd 21972 queue-q 21973: too_small_msg 209.86.89.70 from [email]rongyao@earthlink.net[/email] size 188
smtpd 22563 queue-q 22564: too_small_msg 209.86.89.70 from [email]rongyao@earthlink.net[/email] size 188
smtpd 22607 queue-q 22610: too_small_msg 165.21.103.142 from [email]carolax7424@263.com[/email] size 178
你看这是来自哪里的？
一个技术问题，仅仅在google上找说法，就能当成最后结论？也太不认真了。
思一克 回复于：2006-09-27 11:02:35
To Abel,
我故意让你说，我怕我搞错了，你对IP分配比我更专业。
abel 回复于：2006-09-27 11:10:32
引用：原帖由 思一克 于 2006-9-27 11:01 发表
To Abel,
你怎么那么相信google上人说的吗？
我为什么不相信你？因为我有过外国人发给我们的经历。
还有这中不正常的小邮件（内容未必一定是aaazzz, 也可以是其他的类似垃圾），不可能仅仅是和大陆有关。
...
哈~我不認真,真是夠了,實在是你自己偏執,不認為是 CN GW 的問題,
回頭去看看 這帖中 "醉卧水云间 " 發的帖子吧 ! 人家可是有來歷的
從 google 的結果不能推論事實,那才奇怪吧,是你自己一開始就掉入是 Client 問題
那才真是問題呢 !
引用：
smtpd 3531 queue-q 3532: too_small_msg 209.86.89.70 from [email]rongyao@earthlink.net[/email] size 188
這樣的訊息能代表什麼 ?
思一克 回复于：2006-09-27 11:14:35
smtpd 3531 queue-q 3532: too_small_msg 209.86.89.70 from [email]rongyao@earthlink.net[/email] size 188
代表从209.86.89.70发过来类似于或就是az的小垃圾了。
思一克 回复于：2006-09-27 11:21:42
To Abel,
我也google了。你看这个发az垃圾的是中国的吗？
http://tech.groups.yahoo.com/group/postfix-users/message/186744
fluke888 回复于：2006-09-27 11:28:20
引用：原帖由 醉卧水云间 于 2006-9-26 22:02 发表
GFW过滤进出邮件，当发现敏感字后往两边各发送三个伪造的reset干掉连接，通常都发生在数据传输中间，所以会干扰到内容。思一克你可以测一下，服务端和客户端都屏蔽掉reset包，然后发送邮件，应该就不会有类似问题 ...
MTA间有何好方法？也使用加密传输么？目前大部分ICP、企业的邮件系统都开启加密支持？
我MTA中有如下日志：
Sep 24 05:55:43 mailgate sendmail[6534]: STARTTLS=client, relay=mail.domain.com., version=TLSv1/SSLv3, verify=FAIL, cipher=RC4-MD5, bits=128/128
verify FAIL是否意味着MTA尝试使用加密连接失败？
abel 回复于：2006-09-27 11:33:28
引用：原帖由 思一克 于 2006-9-27 11:21 发表
To Abel,
我也google了。你看这个发az垃圾的是中国的吗？
http://tech.groups.yahoo.com/group/postfix-users/message/186744
實在不想再看下去了,分明還是中國的 mail , 你以為這有什麼難的,反而是你自己沒把這個 Thread 看完
我巳經說了,有來歷的人巳經證明我的說法了,實在是你自己還在原地打轉,
你的說法都是有問題或站不住的,我的說法都站的住但沒法證明,那個 small_mail 也不能代表什麼事,就你一個人用的東西沒有什麼好說的
abel 回复于：2006-09-27 11:35:19
Sep 24 05:55:43 mailgate sendmail[6534]: STARTTLS=client, relay=mail.domain.com., version=TLSv1/SSLv3, verify=FAIL, cipher=RC4-MD5, bits=128/128
這個 Verify 只是確認 SSL 的有效性,但不影響 SSL 的加密傳輸
abel 回复于：2006-09-27 11:37:37
引用：原帖由 abel 于 2006-9-27 11:33 发表
實在不想再看下去了,分明還是中國的 mail , 你以為這有什麼難的,反而是你自己沒把這個 Thread 看完
我巳經說了,有來歷的人巳經證明我的說法了,實在是你自己還在原地打轉,
你的說法都是有問題或站不住的,我的說 ...
我就挑明講吧 ! 寫 GFW 都說是 tcp reset 問題了,你自己去查查人家過去的帖子 !
把目光放廣一些就能知道是什麼問題,不是 MTA 也不是 MUA !
就說從 google 就可以看出問題了 ! 就是 CN 才有而以
[ 本帖最后由 abel 于 2006-9-27 11:39 编辑 ]
zjzfb 回复于：2006-09-27 11:42:52
事件应该不是孤立的
看看cnbeta的电信ADSL拨号软件星空极速的相关问题应该有个答案
思一克 回复于：2006-09-27 12:22:02
再看这个，是来自中国的？
http://archives.neohapsis.com/archives/postfix/2004-08/2418.html
> Sep 1 22:25:52 beastie postfix/smtpd[497]: warning: Unable to look up NS host dnsauth3.sys.gtei.net for Helo command english-breakfast.cloud9.net: Host not found
> Sep 1 22:25:52 beastie postfix/smtpd[497]: 01265130E45: client=english-breakfast.cloud9.net[168.100.1.9]
> Sep 1 22:25:52 beastie postfix/cleanup[486]: 01265130E45: message-id=<20040901142345.01265130E45beastie.frontfree.net>
> Sep 1 22:25:52 beastie postfix/cleanup[486]: 01265130E45: discard: body aaazzzaaazzzaaazzzaaazzzaaazzz from english-breakfast.cloud9.net[168.100.1.9]; from=<owner-postfix-userspostfix.org> to=<delphijfrontfree.net> proto=ESMTP helo=<english-breakfast.cloud9.net>: "aaazzz Junk"
> Sep 1 22:29:05 beastie postfix/smtpd[497]: disconnect from english-breakfast.cloud9.net[168.100.1.9]
思一克 回复于：2006-09-27 12:35:43
SERVER在中国？
microchu 回复于：2006-09-27 13:04:47
哈哈，原文里有这样一句
> My own server is runninng postfix 2.1.4 with TLS configuration. My
> time zone is GMT+08:00.
如果Server的时区不是随便设置的，这个服务器还是在中国.
frontfree.net >> 219.239.99.7
* 查询结果1：北京市 电信通
* 查询结果2：北京市 电信通
[ 本帖最后由 microchu 于 2006-9-27 13:06 编辑 ]
fluke888 回复于：2006-09-27 14:09:07
请问一下：POP和smtp我现在都已经加密了，但MTA之间的传输加密....hmm...大部分MTA都可以响应加密的么？
醉卧水云间 回复于：2006-09-27 14:16:42
引用：原帖由 思一克 于 2006-9-27 09:42 发表
我的考虑--
这个和SERVER无关。是CLIENT端造成的。
即使是CLIENT端发一个，也就证明是client造成的了。
一个MAIL连接可以RESET 100次发成100个MSG。
CLIENT端乱了。
......
过滤都设在国际出口
过滤都设在国际出口???
思一克，过过脑子吧。广布中国的路由都有过滤，难道你以为现在是2000年？
思一克 回复于：2006-09-27 14:24:44
也可能你们说的正确，也就是abel的结论。
我认为有其他可能的原因很简单，就是我原来有过我的同事（在美国，通过US服务器发给BJ同事300个那垃圾）。
过滤的问题
1）如果你的SERVER在内网 --- 不可能。
2）如果你SERVER在外IP，有可能，但可能性不大。ISP还不至于设置的每个ROUTER按内容过滤。
尤其在一个IPS既提供托管，又提供专线的情况。
醉卧水云间 回复于：2006-09-27 14:30:57
引用：原帖由 思一克 于 2006-9-27 14:24 发表
也可能你们说的正确，也就是abel的结论。
我认为有其他可能的原因很简单，就是我原来有过我的同事（在美国，通过US服务器发给BJ同事300个那垃圾）。
过滤的问题
1）如果你的SERVER在内网 --- 不可能。
2） ...
ISP管过滤？没听说过，只听说国＊安往ISP上加过滤路由，ISP屁都不敢放一个。
再大的ISP邮件内容都可以过滤的来，因为是旁路过滤，不影响正常流量，一旦发现有意思的内容就伪造reset，当服务端接收完邮件发送确认时，它把你拿下，客户端没收到确认就重发，于是服务端就没完没了收邮件了。
我家老婆最美丽 回复于：2006-09-27 14:32:04
不要把上面想得太简单了。
你连接到美国只要不是卫星，都得走物理线路吧？海底光缆你要能自己铺，那绝对能搞清楚。
思一克 回复于：2006-09-27 14:39:31
我收的的奇怪邮件（尺寸小，有发件人，不符合RFC）不仅仅有那个aaazzz垃圾，还有类似的许多种。
尽管aaazzz有可能是中国特有过滤引起。
走专线就没有过滤了。因为所有用国内线路不能上的，用专线都可以了。
还有，我原来遇到的美国发过来的aaazzz垃圾不是通过专线。
思一克 回复于：2006-09-27 14:43:16
你看aaazzz垃圾比如100个是在多少时间内发的？
SERVER如果发不成功，需要过最少数分钟后再发一次（比如5分），所以不会出现短时间内发好几百的情况。
引用：原帖由 醉卧水云间 于 2006-9-27 14:30 发表
ISP管过滤？没听说过，只听说国＊安往ISP上加过滤路由，ISP屁都不敢放一个。
再大的ISP邮件内容都可以过滤的来，因为是旁路过滤，不影响正常流量，一旦发现有意思的内容就伪造reset，当服务端接收完邮件 ...
醉卧水云间 回复于：2006-09-27 15:02:01
引用：原帖由 思一克 于 2006-9-27 14:43 发表
你看aaazzz垃圾比如100个是在多少时间内发的？
SERVER如果发不成功，需要过最少数分钟后再发一次（比如5分），所以不会出现短时间内发好几百的情况。
server是会等一会再发，但client不会，会立即尝试再发，因为client不会长时间运行，他等不及的。于是server就可能反复收到client的重发，可惜每次确认都被阻挡。
思一克 回复于：2006-09-27 15:30:44
那美国那边的CLIENT和SERVER之间就不会有这问题了。
如果我收到美国SERVER发过来的而被过绿造成az垃圾，那一定是不会很多（是一封邮件被SERVER不断重新发的）
引用：原帖由 醉卧水云间 于 2006-9-27 15:02 发表
server是会等一会再发，但client不会，会立即尝试再发，因为client不会长时间运行，他等不及的。于是server就可能反复收到client的重发，可惜每次确认都被阻挡。
醉卧水云间 回复于：2006-09-27 15:42:19
引用：原帖由 思一克 于 2006-9-27 15:30 发表
那美国那边的CLIENT和SERVER之间就不会有这问题了。
如果我收到美国SERVER发过来的而被过绿造成az垃圾，那一定是不会很多（是一封邮件被SERVER不断重新发的）
SERVER在处理reset时可能有不当之处。但reset的干扰是主要问题，它不是1个是3个。
fluke888 回复于：2006-09-27 15:46:06
大家做个实验吧。
我用gmail向国内的邮箱发送了一封邮件，主题为：test，内容只有2行：
falungong
zhonggong
以上请用中文代替。
到现在为止，我已经收到2封同样内容的邮件了。
再反过来试试，看看这种内容能不能发到gmail去。
我都不知道怎么向用户解释。。。真tmd憋气！
思一克 回复于：2006-09-27 15:49:22
美国有些地方对邮件做法更可怕：
已经不是内容过滤了，而是将你的邮件“偷”走，然后他给你发。用户用OUTLOOK上时自己觉得和BJ的SERVER连上了，其实根本没有！
AOL就是这样的。你只要通过AOL上的INTERNET，邮件就被“偷”了。
我同事还发现在有的州的宾馆的BROADBAND也是如此。
但大部分地方不这样。
这个不是偷看一下内容了（基本不影响速度），而是相当于从邮局将所有信全用卡车拉到他们公司，研究后明天再给你发。
国内的ISP也有学美国这个的。
思一克 回复于：2006-09-27 16:03:43
to flute888,
好。你的测试已经说明了，是过滤直接引起的。
abel 回复于：2006-09-27 17:17:07
引用：原帖由 醉卧水云间 于 2006-9-27 14:30 发表
ISP管过滤？没听说过，只听说国＊安往ISP上加过滤路由，ISP屁都不敢放一个。
再大的ISP邮件内容都可以过滤的来，因为是旁路过滤，不影响正常流量，一旦发现有意思的内容就伪造reset，当服务端接收完邮件 ...
謝謝水兄~ 總算弄明白了 !
一個問題請教水兄, DNS 有沒有 Fake ?
我的實驗是有的,但是如果有一個正確的答案是最好不過的
fluke888 回复于：2006-09-27 17:23:44
唉，如何解决呢？众位兄弟～
我的mailsrv起了TLS，对方的没有启用，还是没有用啊。。。有多少企业的mailsrv启用了TLS呢？还有其他idea么？
另外，关键字也太敏感了吧？。。。全是正常的商务邮件也。。。
醉卧水云间 回复于：2006-09-27 18:34:18
引用：原帖由 abel 于 2006-9-27 17:17 发表
謝謝水兄~ 總算弄明白了 !
一個問題請教水兄, DNS 有沒有 Fake ?
我的實驗是有的,但是如果有一個正確的答案是最好不過的
大陆的DNS是靠不注的。
醉卧水云间 回复于：2006-09-27 18:37:29
引用：原帖由 思一克 于 2006-9-27 15:49 发表
美国有些地方对邮件做法更可怕：
已经不是内容过滤了，而是将你的邮件“偷”走，然后他给你发。用户用OUTLOOK上时自己觉得和BJ的SERVER连上了，其实根本没有！
AOL就是这样的。你只要通过AOL上的INTERNET， ...
美国是反恐需要，不过你同样可以安全地骂bush，FBI不会为此通缉你。
[ 本帖最后由 醉卧水云间 于 2006-9-27 18:41 编辑 ]
chris Lung 回复于：2006-09-27 19:52:34
Abel说的是，从上周开始我也遇到同样的问题了，发生这种乱码的原因一般maillog里都带有这种错误：
(lost connection with as2k02.hongfaith.com[203.194.207.136] while sending message body.)
(server dropped connection without sending the initial greeting.)
意思是说在smtp数据传输中中断了，Fake。
[ 本帖最后由 chris Lung 于 2006-9-28 08:33 编辑 ]
chris Lung 回复于：2006-09-27 20:04:00
Out: 250 Ok
In: DATA
Out: 503 <DATA>: Data command rejected: Improper use of SMTP command
pipelining
In: aaazzzaaazzzaaazzzaaazzzaaazzz
Out: 502 Error: command not implemented
In: .
Out: 502 Error: command not implemented
In:
Out: 500 Error: bad syntax
In: aazzz
Out: 502 Error: command not implemented
In: .
Out: 502 Error: command not implemented
In:
Out: 500 Error: bad syntax
Session aborted, reason: lost connection
思一克 回复于：2006-09-28 08:38:31
建议楼主将标题改个更好更贴切的（便于查找问题）。
谢谢将a-z垃圾问题搞清楚的各位。
还有邮件系统必须有能力阻止这类尺寸小的坏邮件，比如小于256。如果有，打开限制，这类小垃圾邮件将再也不会发进来了。
chris Lung 回复于：2006-09-28 09:06:31
引用：原帖由 思一克 于 2006-9-28 08:38 发表
建议楼主将标题改个更好更贴切的（便于查找问题）。
谢谢将a-z垃圾问题搞清楚的各位。
还有邮件系统必须有能力阻止这类尺寸小的坏邮件，比如小于256。如果有，打开限制，这类小垃圾邮件将再也不会发进来了。
楼主，发生这种情况是我在发了一些小的文本附件到对方，结果收到的就是这种东东。所以说这不是小垃圾邮件，也不是大规模的，是你手动发过去才会返回过来一封，仅此而已。
abel 回复于：2006-09-28 09:08:14
引用：原帖由 fluke888 于 2006-9-27 17:23 发表
唉，如何解决呢？众位兄弟～
我的mailsrv起了TLS，对方的没有启用，还是没有用啊。。。有多少企业的mailsrv启用了TLS呢？还有其他idea么？
另外，关键字也太敏感了吧？。。。全是正常的商务邮件也。。。
你可以用 PGP 也應可以
或是找個境外有支援 STARTTLS 的 Mail Server 幫你做 Relay
此外,謝謝水兄的解惑,讓許多人都能了解到此一問題的原因,
ISP 上做 filter 是非常有可能的,愈近 user 處就 filter 愈能減少敏銳訊息,也可減少必要出口的 loading
最後,見微知著的能力還是必要的, google 的結果巳經告訴大家可能的結果了
而 msg size 小於 256 即使可以檔掉 aaazzz 問題,但是也可能檔掉了正常信件,這種做法還是不能認同的,
還是根據內容特徵較實際
思一克 回复于：2006-09-28 09:56:22
To Abel,
正常的邮件尺寸大于256字节。这样阻挡是对的。对于a-z这类垃圾十分有效。
abel 回复于：2006-09-28 10:23:34
引用：原帖由 思一克 于 2006-9-28 09:56 发表
To Abel,
正常的邮件尺寸大于256字节。这样阻挡是对的。对于a-z这类垃圾十分有效。
你認為是對的就對的吧 ! 反正我又沒有這種問題
那一個人說這一定是對的呢 !
一封信光 Trace Field 就多少個 bytes 了 ?
各何況你前面舉的幾個 aaazzz mail 的 sample 那一個小於 256 ?
不是前後不一致嗎 ? 那些信你的 256 規則還不是照收了!
思一克 回复于：2006-09-28 10:35:00
不是我说对就对。
a-z垃圾尺寸好象是181（因为HEADER不全），拒绝256或300以下的小邮件非常有效。而不会误伤正常的邮件。
如果MAIL SERVER上边有20个DOMAIN，而且已经存在3年以上，用户数量在3000以上，那么各式各样的垃圾病毒会非常多。
r2007 回复于：2006-09-28 10:36:21
用尺寸来识别a-z的邮件的做法实在不敢恭维。
这个做法让我无法忍受！就像GFW的武断过滤一样，好端端的查询或访问竟然也被GFW给灭了:em12:
再有，如果阻挡了至少要给对方一个音，决不能一声不响地把小邮件直接咔嚓了。
醉卧水云间 回复于：2006-09-28 10:37:46
阻挡也许能解决问题，但这里的主要问题应该是服务器代码在应对reset的BUG，不过我没有太大兴趣去找它。
思一克 回复于：2006-09-28 10:46:40
TO R2007，
小邮件是由于坏的链路造成的。象a-z垃圾这样的（还有一些类似的），因为是不符合RFC的残缺邮件，根据尺寸阻挡非常有效。否则你的SERVER难道连残缺的邮件也接收不成？
所以阻挡残缺小尺寸邮件对一个功能好的SERVER是应该做的。否则就收垃圾把。
至于最好，那最好消除残缺的原因，或让过滤系统更智能，不会误伤好邮件而造成a-z垃圾。但这不是我们可以作到的。
我们能作到的仅仅是自己的MAIL SERVER在现有条件下更好，最好。
引用：原帖由 r2007 于 2006-9-28 10:36 发表
用尺寸来识别a-z的邮件的做法实在不敢恭维。
这个做法让我无法忍受！就像GFW的武断过滤一样，好端端的查询或访问竟然也被GFW给灭了:em12:
再有，如果阻挡了至少要给对方一个音，决不能一声不响地把小邮件直接咔 ...
[ 本帖最后由 思一克 于 2006-9-28 10:48 编辑 ]
abel 回复于：2006-09-28 10:54:10
思兄,那為什麼你舉的例子 Header 都是全的 ?你的就不全 ?
為什麼別人的 sample 就可以 !
用 size 再怎麼看都是有問題的,就是不夠嚴謹!
[ 本帖最后由 abel 于 2006-9-28 10:55 编辑 ]
思一克 回复于：2006-09-28 11:07:59
To Abel,
小于256的是残缺邮件（各种原因造成的），没有问题。
a-z垃圾很大部分是如此（如果不是全部）。具体尺寸你自己看把。反正我的SERVER 从第一次受到那垃圾拒绝之后再一个也没有了。
拒绝不会误伤正常邮件。
如果以上没有问题，那SERVER就可以做。WHY NOT。
abel 回复于：2006-09-28 11:11:50
引用：原帖由 思一克 于 2006-9-28 11:07 发表
To Abel,
小于256的是残缺邮件（各种原因造成的），没有问题。
a-z垃圾很大部分是如此（如果不是全部）。具体尺寸你自己看把。反正我的SERVER 从第一次受到那垃圾拒绝之后再一个也没有了。
拒绝不会误伤正常 ...
實在顧左右而這他,我只問為什麼別人沒有 "残缺" 只有你有 !?
大小問題我想沒幾人會想這麼做的,我寧可花點 CPU 把 pattern 對過較實際
思一克 回复于：2006-09-28 11:12:10
TO ABEL，
我举的哪个例子header是全的，超过256的？
abel 回复于：2006-09-28 11:19:14
你自己看一下 15 樓,19樓吧,至於其他的我就不提了
這兩個例子哪不全 ?
只有你的 aaazzz 會不全? 其他就沒有 ?
思一克 回复于：2006-09-28 11:29:23
To Abel,
你不要把SERVER接收后自己要DELIVER时加上的HEADER和邮件进来的时候的原来header搞混。如果你自己还有SA等还要加HEADER。X-SPAM等呢
在邮件刚进来的时候，检查尺寸，而不是DELIVER后。DELIVER后还再截获（maildrop?)本来也是不好的方法。
此贴我一开始就说了，拒绝小于300的可以有效的解决次垃圾。我的服务器都是这样做的，每个都有效。
至于是不是全部的，一切，我不保证，你自己研究。
查pattern, 此垃圾是一类，不仅仅aaazzz.
abel 回复于：2006-09-28 11:46:42
引用：原帖由 思一克 于 2006-9-28 11:29 发表
To Abel,
你不要把SERVER接收后自己要DELIVER时加上的HEADER和邮件进来的时候的原来header搞混。如果你自己还有SA等还要加HEADER。X-SPAM等呢
在邮件刚进来的时候，检查尺寸，而不是DELIVER后。DELIVER后还再 ...
你自己算算15/19樓有幾個 bytes , 去掉那些可還有至少還有 300 個bytes以上 ? 更何況人家哪裏破了 ?
只有你的破了而以 ?
r2007 回复于：2006-09-28 11:52:07
引用：原帖由 思一克 于 2006-9-28 11:29 发表
此贴我一开始就说了，拒绝小于300的可以有效的解决次垃圾。我的服务器都是这样做的，每个都有效。
有效地解决此垃圾可以有多种办法，包括上述方法，甚至关服务器也可以阻挡此类邮件。
但是怎么保证既能阻挡问题邮件又能确保正常邮件的收发？
拒绝size小于300的方法的支持论据好像是正常邮件的尺寸都大于256，请问这个结论是怎么计算出来的？
思一克 回复于：2006-09-28 11:54:30
To Abel,
没有必要说这个尺寸了。我只是说，如果你的SERVER可以拒绝256以下的小邮件，你做了对你肯定好的很。而这里面也包含了大部分的（如果不是全部）a-z垃圾。
还有其它的小的残缺不全的邮件。
vyouzhi 回复于：2006-09-28 12:02:23
我这里的客户也发生过这种问题
他们是这样发生的
A用outlook发一封正常的邮件mail
B会收到很多相同的mail
我在服务器上面看maillog
看到的是A产生了很多个连接
但都是正常的
[CODE]
2006-09-20 14:23:45.160438500 info msg 4670893: bytes 7725 from <purchase@asiateck.com> qp 14985 uid 510
2006-09-20 14:23:45.164696500 starting delivery 601: msg 4670893 to local 21deke.com-support@21deke.com
2006-09-20 14:23:48.049764500 delivery 601: success: did_0+0+1/
2006-09-20 14:23:48.079768500 end msg 4670893
[/CODE]
但这种日志在server上面出现很多次
而客户是确认了只发一次的
当然上面他是发给我
思一克 回复于：2006-09-28 12:05:32
你这个问题好象和以上说的没有关系。
abel 回复于：2006-09-28 12:08:37
To Abel,
看你这样说，有些话我也要说了。
这个问题你是说对了，但我必须要真实可重复的证明。否则仅仅凭google一下是不行的。所以我说要你拿出证明，最后其他朋友有了。
我7，8个月前遇到过此垃圾，因为SERVER上功能齐全，拒绝了300字节以下的，此垃圾再也没有了。而我的确一直认为是CLIENT端引起的。因为再没有了，所以没有再详细研究它。
这也正是在论坛上交换看法，辩论，来找真正原因，更正错误的想法。CU论坛就有这个好处。
我在10几楼的时候是比较相信你说的（有帖子证）可是你总是拿不出有力的可再现的证明来。既然被证明了，不就好了吗，帖子改名了可以用来方便别人查找。
Abel, 我觉得你说话的口气象吵架。你说对的，别人能不知道吗。
你知道如何做的好。未必。
请回忆，原来关于UNKNOWN USER当场拒绝的问题，你不一直和我在几个帖子中吵了很长时间，而且你有无数理由反驳我。可最后你还不是自己也利用了这个功能？如果如同你反驳的那样，你怎么不坚持自己了？
我知道你sendmail做的很好，但对于做一个完善的email server你却未必。WHY？ 不是你水平不行，而是你没有需求。你想，你一个30几个人的小SERVER能遇到过什么问题？和5000人遇到的问题可比？所以你的SERVER你自己说的无ANTI-VIRUS，无专门ANTI-SPAM，这个我们以前有帖子讨论为证明。幸亏sendmail的功能多。
还有，不要一说什么技术问题就“大陆，大陆”的，即使事情真是如此，你用这样的口气，如果不是有充分的证明，其他人是不愿相信的。技术问题就讨论技术。
我已经将此帖子叫LZ改成了容易google的名字。作为精华便于查找。
abel, 你在发一个回复我就锁贴了，现在锁我觉得对你不公平。
--------------------------------------------------------------------------------
我根本不需要做 ! 你怎知我做了很好 !
aaazzz 信很明顯超過你的 size ,更何況人家根本沒有破 !
從頭到尾就你說是 client 問題,是病毒,還舉了別人似是而非的 exploder 例子
根本不想想徹底的原因,我身在大陸之外,沒收過一封 aaazzz 的信看事情比那些收過的還清楚
打從 N 樓就說這也是中國特色 ! 你要舉例自己也不查清楚
[ 本帖最后由 思一克 于 2006-9-28 12:44 编辑 ]
r2007 回复于：2006-09-28 13:42:40
引用：原帖由 r2007 于 2006-9-28 11:52 发表
有效地解决此垃圾可以有多种办法，包括上述方法，甚至关服务器也可以阻挡此类邮件。
但是怎么保证既能阻挡问题邮件又能确保正常邮件的收发？
拒绝size小于300的方法的支持论据好像是正常邮件的尺寸都大于256， ...
阻挡小尺寸邮件的做法就是因噎废食，和国家颁布的<互联网上网服务营业场所管理条例>一样地武断和粗暴，虽然正面效果明显，但属于强权行为。
条例中规定网吧禁止接待未成年人，理由很简单，上网的都是在玩游戏、聊天、交友等等，会影响未成年人的正常成长并且容易滋生犯罪。事实也是如此99%甚至更多的人到网吧都是玩游戏，暂不讨论不让在网吧玩游戏对不对，单提未成年人不允许上网吧（不论上网的原因），就粗暴地侵害了作为一个公民应该享有的平等权利。同样我相信小于300的邮件未必就一定是不良邮件，没有刻意计算，一个新闻组订阅邮件，大概只需要一个特定的标题就可以了，加上必要的header应该不会超过300的。
[ 本帖最后由 r2007 于 2006-9-28 13:44 编辑 ]
chris Lung 回复于：2006-09-28 14:04:13
看来此贴还得继续下去啊。
思一克 回复于：2006-09-28 14:07:44
TO r2007,
如果你在smtpd入口处检查，尺寸小于一个数值（比如256）的邮件都不是一个好的完整的邮件，为什么不阻挡？所以没有因噎废食的问题。
你用比如outlook express写一个邮件无标题，内容仅仅一个a, 你看尺寸是多少？比256大。
一个SMTP连接，拒绝那些尺寸小的不符合RFC的邮件是很正常的，可以作为ANTI-SPAM的一部分。
不仅仅是因为小拒绝，更主要是因为邮件是不正常的。
引用：原帖由 r2007 于 2006-9-28 13:42 发表
阻挡小尺寸邮件的做法就是因噎废食，和国家颁布的<互联网上网服务营业场所管理条例>一样地武断和粗暴，虽然正面效果明显，但属于强权行为。
条例中规定网吧禁止接待未成年人，理由很简单，上网的都是在玩 ...
ghbspecial 回复于：2006-09-28 14:13:18
看了高手讨论很是受益，虽然有一点点的火药味，但讨论的很精彩，学习ing............
未成年人确实禁止进入网吧，但是没有禁止他们上网。。。。:mrgreen::mrgreen:
对于几位高手的水平，本人很是欣赏，向你们学习。。。。。。:mrgreen::mrgreen::mrgreen:
abel 回复于：2006-09-28 14:33:11
哈~你可以覆我的文,但請不要改我的文,這樣別人會搞不清楚 !
以前的事我都說過為什麼,請不要斷章取義 !
這樣的事其實我不認為 aaazzz 您的看法不好,而是認為 300 個 bytes (不論您說過幾個數字256,18x ??)及破碎的問題中,你跟本沒有深究 !
你認為我管30人的 Mail Server 經驗比不上 5000 人那是你的看法,
5000 人的 Server 經驗就一定比 30 人好 ? 不見得吧！ 技術的深淺和規模沒有絕對關係
我管 50000 人的 voip 系統,其變化性比郵件系統高得更多了 ! voip 中更是有 voice mail ,我可以說你的5000經驗比不上嗎 ?
google 中沒有一個答案是準得,因為跟本沒有任何證據可言! 但現象是早就可以知道了! 偏沒有幾個人想得到不是嗎 ?
這種東西是沒有證據的 ! 今天只是水雲兄間接的證實,我們站在相信的角度上認為他的話是可信的(水兄見諒),
本帖中有許多看法我不能認同,所以才會有這樣的結果不是嗎 ?
abel 回复于：2006-09-28 14:39:36
"如果你在smtpd入口处检查，尺寸小于一个数值（比如256）的邮件都不是一个好的完整的邮件，为什么不阻挡？所以没有因噎废食的问题。"
RFC 那裏規定 Size 的大小 ?
一封信需要那些必要 Header ? 為什麼不能小於 256 ?
經驗和標準是兩碼子事
busyant 回复于：2006-09-28 14:51:40
怎么Abel老大的帖，思老大可以修改的呢？
不应该这样吧？
思一克 回复于：2006-09-28 15:47:54
没有呀。我怎么能修改他写的？
ghbspecial 回复于：2006-09-28 16:11:08
上面情况真很奇怪，难道是系统问题。。。。
思一克 回复于：2006-09-28 16:56:48
TO 楼上，哪里有问题（拿一楼号？）我看看
ghbspecial 回复于：2006-09-28 16:59:14
107楼，，，大大没注意到吗？、、、
思一克 回复于：2006-09-28 17:01:24
啊。真有问题。107楼是我写的，为什么成Abel的了？
思一克 回复于：2006-09-28 17:03:06
估计是系统有问题。我进去改我的帖子，为何主人变为了Abel?
我又进去了，没有改动主人的地方。
ghbspecial 回复于：2006-09-28 17:07:57
我很喜欢看你们讨论的，二位我都很佩服，，看到107楼时，也有点晕了，不上面有个兄弟已经抓图了。
呵呵。。。确实比较离奇。。
思一克 回复于：2006-09-28 17:09:41
我已经向真正的老大（管理员）报告了。我进去（EDIT）没有看到哪里能改主人（按理说不应该能改）
醉卧水云间 回复于：2006-09-28 19:38:39
思一克想问题过于简单：
S: MAIL FROM:<[email]Green@Beta.ARPA[/email]>
R: 250 OK
S: RCPT TO:<[email]Jones@Beta.ARPA[/email]>
R: 250 OK
S: RCPT TO:<[email]Brown@Beta.ARPA[/email]>
R: 250 OK
S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: hello
S: <CRLF>.<CRLF>
R: 250 OK
你看看这个邮件的body有多大？ 你可能不大会数，我数给你看吧，5个字节。如果照你的阻挡方案，这个邮件就发不到smtpd，更不用relay了。
你举的outlook例子不能代表全部，它发了很多累赘的东西，符合协议的邮件body最短可以是空白，没有outlook我还用telnet 来发邮件呢。照你的过滤我不写满300个字看来别想用你的服务器了。
做服务要严谨，如果我发这个邮件而你把他过滤掉，我会投诉的：）
醉卧水云间 回复于：2006-09-28 19:49:06
107楼是思版主改过了？！
如果是思版主原帖怎么会是abel的署名？行走江湖这么多年，只碰到被人改贴，还没碰到过被人改名的。似乎不是系统错误吧。
langue 回复于：2006-09-28 21:58:13
禁止SMTP客户端，从Web Mail走
醉卧水云间 回复于：2006-09-28 23:03:58
引用：原帖由 langue 于 2006-9-28 21:58 发表
禁止SMTP客户端，从Web Mail走
还是你牛，呵呵。
zjzfb 回复于：2006-09-29 02:08:41
典型的MIME编码邮件，由Outlook发往163，再从163接收，内容：
主题：
Just for test !!!
正文：
Test line 1-1
Test line 1-2
用sniffer察看，还有163的包头，POP3接收之后脱掉一层
完成之后的邮件编码就变成了下面的，不知道300字节限制有什么作用
Received: from sc602 (unknown [60.177.61.135])
by smtp11 (Coremail) with SMTP id wKjADh4AZwMyygZFiIE5Aw==.22335S4;
Tue, 12 Sep 2006 22:54:46 +0800 (CST)
From: "=?gb2312?B?16O3yQ==?=" <[email]zjzfb@163.com[/email]>
To: <[email]zjzfb@163.com[/email]>
Subject: Just for test !!!
Date: Tue, 12 Sep 2006 22:54:37 +0800
Message-ID: <000301c6d67b$5e59c220$5801a8c0@sc602>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0004_01C6D6BE.6C7F7320"
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcbWe14Ly77Bc8DSSICxm2goTVmqcQ==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
This is a multi-part message in MIME format.
------=_NextPart_000_0004_01C6D6BE.6C7F7320
Content-Type: text/plain;
charset="gb2312"
Content-Transfer-Encoding: 7bit
Test line 1-1
Test line 1-2
------=_NextPart_000_0004_01C6D6BE.6C7F7320
Content-Type: text/html;
charset="gb2312"
Content-Transfer-Encoding: quoted-printable
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:=CB=CE=CC=E5;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"\@=CB=CE=CC=E5";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
text-align:justify;
text-justify:inter-ideograph;
font-size:10.5pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:Arial;
color:windowtext;}
/* Page Definitions */
@page Section1
{size:595.3pt 841.9pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;
layout-grid:15.6pt;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body lang=3DZH-CN link=3Dblue vlink=3Dpurple =
style=3D'text-justify-trim:punctuation'>
<div class=3DSection1 style=3D'layout-grid:15.6pt'>
<p class=3DMsoNormal><font size=3D1 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
9.0pt;font-family:Arial'>Test line 1-1<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D1 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
9.0pt;font-family:Arial'>Test line 1-2<o:p></o:p></span></font></p>
</div>
</body>
</html>
------=_NextPart_000_0004_01C6D6BE.6C7F7320--
.
[ 本帖最后由 zjzfb 于 2006-9-29 02:11 编辑 ]
zjzfb 回复于：2006-09-29 02:13:17
再来一个由163 Web Mail发送的
Received: from 60.177.61.135(60.177.61.135) ( 60.177.61.135(60.177.61.135)
[60.177.61.135(60.177.61.135)] ) by webmail-app92 (Coremail) ; Tue, 12 Sep
2006 22:48:16 +0800 (CST)
MIME-Version: 1.0
Message-ID: <[email]4506C8B0.000006.02986@bj163app92.163.com[/email]>
Date: Tue, 12 Sep 2006 22:48:16 +0800 (CST)
From: "=?gb2312?B?yP3O3sjL1LE=?=" <[email]zjzfb@163.com[/email]>
To: "祝飞" <[email]zjzfb@163.com[/email]>
Subject: Just for test
X-Priority: 3
X-Originating-IP: [60.177.61.135(60.177.61.135)]
X-Mailer: <!-- CoreMail Version 3.0.0 Copyright (c) 2002-2006 www.mailtech.cn --
>
163com
Content-Type: Multipart/Alternative; boundary="Boundary-=_buNvkTYlAyAqoOxZONDoMh
mlScuw"
--Boundary-=_buNvkTYlAyAqoOxZONDoMhmlScuw
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 7bit
test line 1
test line 2
--Boundary-=_buNvkTYlAyAqoOxZONDoMhmlScuw
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable
test line 1<br>test line 2<br><!-- footer --><br><br><br><br><br><div sty=
le=3D"border-bottom:1px solid #999"></div><br>=0A=0A=09<font color=3D"bla=
ck" style=3D"font-size:14.8px">=C2=F2 =D5=E2 =D0=A9 =C8=C3 =C5=AE =D3=D1 =
=BA=DC =D0=CB =B7=DC ( =CD=BC )</font> =0A=09<br>=0A=09 <a href=3D"http:/=
/adtaobao.allyes.com/main/adfclick?db=3Dadtaobao&bid=3D600,597,58&cid=3D2=
9985,198,1&sid=3D32501&show=3Dignore&url=3Dhttp://www.taobao.com/vertical=
/lady/pro.php" target=3D"_blank" style=3D"font-size:13px;line-height:160%=
;color:blue">=D5=E6 =BB=E1 =B9=FD =C8=D5 =D7=D3 ! =D2=BB =B8=F6 =D4=C2 =CA=
=D5 =C8=EB 5800 =C6=AF =C1=C1 MM =B5=C4 =B8=D0 =D0=D4 =C9=FA =BB=EE ( =D7=
=E9 =CD=BC )=0A</a>=0A=0A
--Boundary-=_buNvkTYlAyAqoOxZONDoMhmlScuw--
.
思一克 回复于：2006-09-29 08:44:01
关于aaazzz垃圾和阻挡小邮件（< 256字节的问题）更详细点说明。
我找到了这小的aaazzz垃圾，从朋友系统的用户的OE save出来的。
Return-Path: <[email]andrea.tenneriello@prysmian.com[/email]>
Delivered-To: [email]xxxx@yyyy.com[/email]
Received: (qmail 5275 invoked by uid 89); 26 Oct 2005 01:36:24 -0000
Received: from unknown (HELO mailer2.pirelli.com) (213.140.9.237)
by 0 with SMTP; 26 Oct 2005 01:36:24 -0000
aaazzzaaazzzaaazzzaaazzzaaazzz
这样的东西用户有的一收就有60多到200多。都是残缺不全的<300字节的。
现在知道了这个是网络引起的，在qmail系统接收就是这样的，所以可以一挡了之，在也没有了。
估计具体表现和mail系统有关，在其他系统中还要具体实验。
阻挡小邮件的问题。
邮件进入SMTPD服务器的过程是
OUTSIDE -----> SMTPD ------(A)------> QUEUE -----(B, LOCAL DELIVER AGENT)----->USERS
qmail系统的反病毒和垃圾检查都在A点，就是MSG还没进入队列前。在A点检查MSG尺寸（不包括信封），
你用OUTLOOK 写一个个无标题的内容只有一个a的邮件，在A点你看MSG大小，大约是400字节左右。不同系统会不同，但出入不大。那么，一个200字节的MSG是什么东西？想象是什么？该阻挡不？
我的MAPS反垃圾系统，阻止的尺寸原来是400多，基本没有任何误伤。后来发觉用palm pilot写的一个字节的邮件尺寸是300多，所以将阻挡大小变为300。
可以放心阻挡小于256的，我系统每天就这种真正的“垃圾”就挡掉近100个。
我说的这些到其它系统上会有不同。所以不需要一概而论。原理相似。
abel 回复于：2006-09-29 08:58:07
引用：
Return-Path: <[email]andrea.tenneriello@prysmian.com[/email]>
Delivered-To: [email]xxxx@yyyy.com[/email]
Received: (qmail 5275 invoked by uid 89); 26 Oct 2005 01:36:24 -0000
Received: from unknown (HELO mailer2.pirelli.com) (213.140.9.237)
by 0 with SMTP; 26 Oct 2005 01:36:24 -0000
aaazzzaaazzzaaazzzaaazzzaaazzz
思兄,這封信問題很多吧 !
沒有 Date ? 沒有 Message-ID ?
我不知道 qmail 怎處理 Message-ID , 你確定你朋友收到的沒有這兩個欄位 ?
還是你自己拿掉了
思一克 回复于：2006-09-29 09:06:30
Abel,
你说我自己将MSG拿掉了再贴出？我还没到那么龌龊的地步，永远也不会了。我如果不对了会立刻承认的，这有什么？本来研究问题也是学习的过程。不会死不认帐的。
我告你WHY这样子，因为网络RESET后并没有发MAILFROM RCPTTO等，而qmail-smtpd.c的mailfrom和rcptto并没有清空，就造成了这残缺不全的东西，而且一个RESET就会产生一个MSG。
加一句：你到网上查找，在其他系统（POSTFIX）也会产生不符合RFC的残缺邮件。比如有人研究了，发出的MSG在DATA 之前无HELO， 无RCPTTO。
[ 本帖最后由 思一克 于 2006-9-29 09:17 编辑 ]
abel 回复于：2006-09-29 09:27:53
引用：原帖由 思一克 于 2006-9-29 09:06 发表
Abel,
你说我自己将MSG拿掉了再贴出？我还没到那么龌龊的地步，永远也不会了。我如果不对了会立刻承认的，这有什么？本来研究问题也是学习的过程。不会死不认帐的。
我告你WHY这样子，因为网络RESET后并没有 ...
1. 你自己說從朋友的 OE 中取出來的,這就是 OE 中全部的訊息嗎 ? 如果不是你貼出來全部而不要主觀認為哪些是後來加的! 一封信不該有 Date 和 Message-ID 存在嗎 !!? 我用 sendmail 的經驗裏這兩個欄位若是不存在
它是會自動幫它補上的 ! qmail 難道不會這麼做 ? 而你朋友的 OE 中也沒有這兩個欄位嗎 ?
2. 我認為這可能不是 OE 中全部的訊息,基於上述完因我才這麼問你 ! 我並沒有懹疑你的人格 !
更何況基於你前面給的例子,那一個你檔得到?,那一個小於 300 ?!
思一克 回复于：2006-09-29 09:33:42
To Abel,
OE中将MSG 保存出来的。
这个问题不说了。基本没有什么意思了。
你到网上查找，在其他系统也有残缺不全的情况。因为网络上让过滤给RSET坏个，估计第一个RSET之前的是全的，以后的就不全了。而其他人研究的还不是QMAIL。
阻挡超小邮件，阻挡超大邮件，是ANTI-SPAM系统应该有的功能。
abel 回复于：2006-09-29 09:50:10
你就喜歡離題,?
就事論事不是很好嗎 ?
我如果不对了会立刻承认的，这有什么？本来研究问题也是学习的过程。不会死不认帐的。
aaazzz size 的事肯定你認知有問題,也沒回答 Message-ID/Date 問題 ,自己舉的例都遠超過 300 個 bytes,
關其他人,其他MTA 什麼事! 什麼 ISP 沒有 sensor (filter) ,
什麼不符合標準(RFC) 的郵件,問你什麼叫符合標準你也沒有說不是嗎 ?
有問題的郵件當然什麼 MTA 都有 ! 有問題的郵件就一定小於 300 ? 小於300就是有問題的郵件 ? 也太武斷了吧!
永遠都在跑題,東拉西扯,誰在跟你談 anti-spam 了,誰在跟你談什麼 broken mail
思一克 回复于：2006-09-29 09:57:15
ABEL，
你问其他用qmail的，如果收到那垃圾是什么样子。搞POSTFIX的说发出的邮件在DATA之前没有了HELO，RCPTTO等，你说那邮件不是残缺的？
我的系统就是这样做的，而且那东西一经发现立刻就搞定的。再也没有什么威胁了。
不要吵架了。实在没有意思。不要为了辩论而辩论，或为了中伤而辩论。
思一克 回复于：2006-09-29 09:58:58
TO ABEL，
我什么时候说有问题的一定<300? 我说<300的一定是有问题的，可以拒绝。这里有个充分必要的逻辑。
醉卧水云间 回复于：2006-09-29 10:10:23
引用：原帖由 思一克 于 2006-9-29 09:58 发表
TO ABEL，
我什么时候说有问题的一定<300? 我说<300的一定是有问题的，可以拒绝。这里有个充分必要的逻辑。
转发的邮件头一般都比较大，可能你的规则可以用，符合规范的一手邮件可以很小，<200一定会误杀。
r2007 回复于：2006-09-29 10:32:19
To Abel:
我测试了一下：
用telnet发给qmail server,内容如下：(仅仅把域名和ip做了改动）
Return-Path: <www>
Delivered-To: foo@bar.com.cn
Received: (qmail 2156 invoked from network); 29 Sep 2006 10:29:21 +0800
Received: from unknown (HELO ) (172.16.254.4)
by 172.16.0.2 with SMTP; 29 Sep 2006 10:29:21 +0800
123
给gamil，如下：
X-Gmail-Received: 00150dc439b11948b6d2502c18880287305a5e1a
Delivered-To: foo-bar@gmail.com
Received: by 10.35.135.1 with SMTP id m1cs85094pyn;
Thu, 28 Sep 2006 19:18:22 -0700 (PDT)
Received: by 10.35.8.1 with SMTP id l1mr1498557pyi;
Thu, 28 Sep 2006 19:18:22 -0700 (PDT)
Return-Path: <foo@bar.cn>
Received: from mail.bar.cn ([ip.ip.ip.ip])
by mx.gmail.com with ESMTP id m39si2438620pye.2006.09.28.19.17.25;
Thu, 28 Sep 2006 19:18:22 -0700 (PDT)
Received-SPF: pass (gmail.com: domain of foo@bar.cn designates xxx.xxx.xxx.xxx as permitted sender)
Date: Thu, 28 Sep 2006 19:18:22 -0700 (PDT)
Message-Id: <451c826e.12975220.622e.724dSMTPIN_ADDED@mx.gmail.com>
123
看来qmail的头可以没有date和msg-id
测试过程如下
telnet <mailhost> 25
helo www
mail from:<foo@bar.cn>
rcpt to:<myaccount@test.com>
data
123
.
quit
[ 本帖最后由 r2007 于 2006-9-29 10:35 编辑 ]
思一克 回复于：2006-09-29 10:34:36
水云间，你好
我的系统上设的是<300的就全部干掉，还有>40M的。
我用7，8种型号的PALM实验过，他们发的最小的也>300.
至于OUTLOOK等更大。
也可能有误伤的？我没有在意，2年来也没有任何抱怨的。
aaazzz垃圾在我的qmail系统中就是那样的小东西，缺手少脚的。所以挡掉了。
思一克 回复于：2006-09-29 10:38:08
直接用telnet发的最小。MAIL CLIENT, PALM上发的小，其他比如OE等大
醉卧水云间 回复于：2006-09-29 12:44:49
引用：原帖由 思一克 于 2006-9-29 10:34 发表
水云间，你好
我的系统上设的是<300的就全部干掉，还有>40M的。
我用7，8种型号的PALM实验过，他们发的最小的也>300.
至于OUTLOOK等更大。
也可能有误伤的？我没有在意，2年来也没有任何抱怨的。
...
SMTP RFC规范里的例子就会被你的规则干掉，用telnet写短信也会被你规则干掉。你说没人投诉也是有道理的，大约有十万分之一的正常邮件被你干掉，投诉比例很低是可以预料的到的。
你仔细想想，GFW每天干掉多少个连接？大概有1／100了吧，你听说过有人起诉政府GFW的问题吗？这和你的逻辑是一样的，没有投诉就是没有问题！
思一克 回复于：2006-09-29 12:56:18
TO 水云间，
那你实验看. 如果<256
OUTLOOK, OE, 等发的所有邮件不受任何影响。
PALM发的也不影响。
转发的任何邮件也不受影响（因为尺寸变大了）
LINUX上的邮件CLIENT也可以实验，不影响。
受影响的可能是某些不轨的广告？也不会，广告是垃圾邮件不是说技术上是垃圾，而是内容和情感上。
我观察，小的许多是CLIENT坏了，有的将DATA内容输入在该输入CMD的时候。或者网络有问题。总之，真的不影响。
有一个影响，就是TELNET进入实验你系统的时候。
思一克 回复于：2006-09-29 15:38:28
To Abel,
就107帖子问题向你道歉。
107楼帖子的问题，应该是我不小心改动的。昨天我刚开会回来，着急操作错误造成的。不是系统的问题。
abel 回复于：2006-09-29 16:41:47
引用：原帖由 思一克 于 2006-9-29 15:38 发表
To Abel,
就107帖子问题向你道歉。
107楼帖子的问题，应该是我不小心改动的。昨天我刚开会回来，着急操作错误造成的。不是系统的问题。
那沒關係,只是小事
這個帖中都只是小事,大家盡情討論才是最重要的 !
真理愈辨愈明,但沒有絕對的對錯,不是嗎
思一克 回复于：2006-09-29 17:14:45
To Abel,
同意你：沒有絕對的對錯. 但有些时候有些问题还是比较固定的好坏选择标准。
有时也有绝对的对错，比如我一开始认为的aaazzz垃圾不是网络FILTER造成的，就是绝对的错。
还有一些争论，是误解造成的。
还有一类问题，在不同系统下是不同的。不能一概而论。
我争论帖子中有得罪的地方，请你原谅。
引用：原帖由 abel 于 2006-9-29 16:41 发表
那沒關係,只是小事
這個帖中都只是小事,大家盡情討論才是最重要的 !
真理愈辨愈明,但沒有絕對的對錯,不是嗎
busyant 回复于：2006-09-30 09:00:28
我觉得可以结帖了 : )
han8xin8 回复于：2006-10-11 09:35:58
这样就结贴了.不是吧.
结论就是ISP的问题,解决就是过滤300字节内的小邮件吗!!!郁闷
abel 回复于：2006-10-11 10:46:59
引用：原帖由 han8xin8 于 2006-10-11 09:35 发表
这样就结贴了.不是吧.
结论就是ISP的问题,解决就是过滤300字节内的小邮件吗!!!郁闷
你若不要 aaazzz 又不想以 size 來判斷,那就用 關鍵字的方法吧
fluke888 回复于：2006-10-12 15:33:12
引用：原帖由 abel 于 2006-10-11 10:46 发表
你若不要 aaazzz 又不想以 size 來判斷,那就用 關鍵字的方法吧
没用，只能解决收信问题，依旧会发送aaazzz的邮件到客户那里。
另外，还有很多其他问题，比如重复收到同样的邮件、丢失附件、I/O error等问题～举不胜举～！！
刘五十三 回复于：2006-10-12 17:58:03
sendmail下怎么搞掉小邮件啊，我现在看到服务器每天一堆死连接，都在rcpt阶段不动了。搞得系统负荷动不动上20，有时候甚至有300多。简直吓人。
abel 回复于：2006-10-12 22:08:25
引用：原帖由 刘五十三 于 2006-10-12 17:58 发表
sendmail下怎么搞掉小邮件啊，我现在看到服务器每天一堆死连接，都在rcpt阶段不动了。搞得系统负荷动不动上20，有时候甚至有300多。简直吓人。
1. 搞掉小郵件你用 mimedefang 就可以搞定了,只要一行檢查 INPUTMSG size ,若小於某數就action_bounce 或 action_discare
2. sendmail 可以限制 smtp 每個階段允許的時間,實際設定請找 sendmail.cf 中觀於 O timeout.* 的部份
思一克 回复于：2006-10-14 15:12:30
aaazzz,你还可以按这个内容过滤掉不也可以吗
han8xin8 回复于：2006-10-17 09:50:25
问大家一个问题先.大家使用邮件服务器的域名都是属于那个域名服务商的.
新网 还是 万网
我的是万网的.怀疑可能是万网前段时间被攻击的原故.
ilovecr 回复于：2006-10-26 11:43:14
引用：原帖由 思一克 于 2006-9-27 11:01 发表
To Abel,
你怎么那么相信google上人说的吗？
我为什么不相信你？因为我有过外国人发给我们的经历。
还有这中不正常的小邮件（内容未必一定是aaazzz, 也可以是其他的类似垃圾），不可能仅仅是和大陆有关。
...
你这话说得有问题。google是全世界的人在用，怎么可凭借一个案来说明问题呢？
ilovecr 回复于：2006-10-26 11:53:31
引用：原帖由 思一克 于 2006-9-29 09:57 发表
ABEL，
你问其他用qmail的，如果收到那垃圾是什么样子。搞POSTFIX的说发出的邮件在DATA之前没有了HELO，RCPTTO等，你说那邮件不是残缺的？
我的系统就是这样做的，而且那东西一经发现立刻就搞定的。再也没有 ...
实在看不下去了。。拜托一下，“总是左右而言他”，这不是做学问，搞技术的态度。
态度若是不对，搞什么也白搭！
rushrush 回复于：2006-12-05 15:56:03
我现在看到reset 就想到GFW...
已经成习惯了
cdking 回复于：2007-01-08 12:00:13
我們用網通線路，隻有自己發給自己的時候才會，其他時間都不會
unix3er 回复于：2007-02-11 13:23:49
可否请LZ把结论一起放在一楼呢？？比较难找啊。
hongfengyue 回复于：2007-06-27 12:05:51
http://blog.5dmail.net/user1/1/20061018141237.html
|
