分类目录归档：EMOS邮件服务

错误表现为能发不能收，同域下也不行。

日志：

Sep 10 09:05:24 mail postfix/qmgr[9788]: C4351101654: to=<nq@networkquestions.org>, relay=none, delay=0.33, delays=0.25/0.08/0/0, dsn=4.3.0, status=deferred (unknown mail transport error)
解决方法：编辑/etc/postfix/master.cf，屏蔽红色部分。

# maildrop. See the Postfix MAILDROP_README file for details.
# Also specify in main.cf: maildrop_destination_recipient_limit=1
#
maildrop  unix  –       n       n       –       –       pipe
#  flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
  flags=DRhu user=vuser argv=maildrop -w 90 -d ${user}@${nexthop} ${recipient} ${user} ${extension} {nexthop}
#

重启postfix

     收取qq发送来的邮件正文为乱码，在 编码 手动选择GB2312没问题。截取部分邮件原结构发现qq的编码为gb18030，extmail会自动判别编码格式来显示。

$VAR1 = {
   ‘body’ => {
      ‘list’ => [
         {
         ‘pos_end’ => ‘1596’,
         ‘pos_start’ => 1490,
         ‘phead’ => {
             ‘Content-Type’ => ‘text/plain’,
             ‘charset’ => ‘gb18030’,
             ‘Content-Transfer-Encoding’ => ‘base64’
            },
         ‘idflag’ => ‘alternative-0’,
         ‘size’ => ‘106’
         },
         {
         ‘pos_end’ => ‘1757’,
         ‘pos_start’ => 1640,
         ‘phead’ => {
             ‘Content-Type’ => ‘text/html’,
             ‘charset’ => ‘gb18030’,
             ‘Content-Transfer-Encoding’ => ‘base64’

EMOS官网解释：

关于GB18030
       由thunderbird或某些客户端软件发出的中文邮件编码是GB18030，部分内容甚至全部乱码。经过仔细检查发现是Perl 目前版本（5.8.8或以下）缺少了GB18030码表，因此增加了Encode::HanExtra码表模块的支持，解决了此问题。

解决方法如下：

[root@emos ~]# wget -c http://search.cpan.org/CPAN/authors/id/A/AU/AUDREYT/Encode-HanExtra-0.23.tar.gz
[root@emos ~]# cd Encode-HanExtra-0.23
[root@emos Encode-HanExtra-0.23]# perl Makefile
[root@emos Encode-HanExtra-0.23]# make install

直至完成，刷新页面即可。

另一种方法就是在用QQ邮箱写信时，设置编码为Unicode

勾选始终使用Unicode编码发信。后面也给出了解释。

PS:

EMOS1.5中perl版本就是5.8.8，在新版本的emos1.6中版本为5.10.1。

        首先，我们先简单说一下RBL的原理。目前用于垃圾邮件过滤的RBL服务，应该称之为基于DNS的实时黑名单查询，也就是说，这个服务是通过DNS协议来完成的。

         (什么是RBL : http://tt.networkquestions.org/thread-125-1-1.html)

　　具体而言，当一个客户端希望查询某个IP地址（如11.22.33.44）是否在某个RBL（如cbl.anti-spam.org.cn）中时，其实际上是查询如下地址是否存在解析： 44.33.22.11.cbl.anti-spam.org.cn. （IP地址逆转附加在RBL地址后）。DNS的解析分为几种类型，对于RBL查询，通常是查询这个地址是否存在A记录、TXT记录或者任意（ANY）记录。

　　如果该地址被列入了这个RBL，那么查询会返回一个具体的解析结果，根据RBL和查询的不同，可以返回一段文本，也可以返回一个或几个IP地址，也可以同时返回文本和IP。返回的文本通常是一个说明，用来说明这个IP地址被列入了哪个RBL，具体信息去哪里查询等。返回的IP地址并不具有实际意义，只是标识该查询有结果，通常这个IP地址是一个保留IP段的地址，如127.0.0.1、127.0.0.2等。

　　如果该地址没有被列入这个RBL，那么该查询会返回一个查询错误（NXDOMAIN），表示该地址未列入。DNS劫持就发生在这里，具体情况我们下面再详细解释。

　　举例说明这个查询过程：

　　当查询的IP地址不在RBL中时，返回状态为MXDOMAIN。
# dig 44.33.22.11.cbl.anti-spam.org.cn.

; <<>> DiG 9.3.3rc2 <<>> 44.33.22.11.cbl.anti-spam.org.cn.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 58553
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;44.33.22.11.cbl.anti-spam.org.cn. IN   A

;; AUTHORITY SECTION:
cbl.anti-spam.org.cn.   3600    IN      SOA     cbl.anti-spam.org.cn. wxy.anti-spam.org.cn. 2008061006 14400 3600 14400 3600

;; Query time: 8 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jun 10 09:28:55 2008
;; MSG SIZE  rcvd: 90

当查询的IP地址在RBL中时，返回状态为NOERRO，并给出具体的结果：127.0.x.x（这和RBL用的server有关，具体可以参考有关RBL的说明。）。例如：
dig 198.150.70.75.bl.spamcop.net  

; <<>> DiG 9.3.4-P1 <<>> 198.150.70.75.bl.spamcop.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25768
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;198.150.70.75.bl.spamcop.net.  IN      A

;; ANSWER SECTION:
198.150.70.75.bl.spamcop.net. 760 IN    A       127.0.0.2

;; Query time: 0 msec
;; SERVER: 206.251.73.9#53(206.251.73.9)
;; WHEN: Sat Mar 28 12:53:58 2009
;; MSG SIZE  rcvd: 62
在明白了RBL查询的原理后，我们来看一下RBL劫持的发生原因。

　　由于国内很多用户在使用电信企业的线路连接互联网时，都会使用接入的ISP所提供的DNS，有的是明确设置使用的，有的是通过PPPoE或DHCP分配使用的。最近一些年来，电信企业为了引导用户访问其增值站点或合作站点，通过会对其DNS做一些修改，在接收到一个不存在结果的DNS查询时，总是返回一些特定的IP地址，使用户访问到这些增值站点。比如你在使用ADSL上网时，如果随便在浏览器的地址栏中任意敲入一个无效的域名，通常都会给你重定向到电信企业自己的门户站点。

　　一般而言，这种行为对于用户没有多大的损害，最多只是扭曲了用户意志，强制其访问另外一个站点而已。但是，对于使用RBL来防范垃圾邮件的用户，这种DNS劫持就会带来较大的麻烦。在这种情况下，所有的DNS查询都会返回一个有效的结果，换言之，无论任何发来邮件的IP地址，都会被认为列入到了RBL中，用户将接收不到任何外部邮件。

　　那么如何应对这种情况呢？有两种办法：

　　一是使用一个可信的，没有被DNS劫持的DNS服务器。国内电信企业的DNS被劫持的情形比较多，尤其是做接入的ISP的DNS服务器，很多都存在劫持问题。可以考虑使用国外的公开DNS、或者一些未劫持的DNS服务器。但是要注意的是，不能使用不支持公开解析请求的DNS，即那种只解析特定域名的DNS服务器是不能用来解析其他域名的；类似的，根域服务器（*.ROOT-SERVERS.NET）也是不提供这种公开解析请求的功能的。可以通过nslookup或dig以及其它工具来测试一个DNS服务器是否可以提供公开解析功能，以及是否被劫持。

    如何确定一个DNS是否有劫持？

    首先查询1个不存在的域名或主机名，例如：
dig aaaaa-extmail.org

; <<>> DiG 9.3.4-P1 <<>> aaaaa-extmail.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 44066
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;aaaaa-extmail.org.             IN      A

;; AUTHORITY SECTION:
org.                    0       IN      SOA     a0.org.afilias-nst.info. noc.afilias-nst.info. 2008589985 1800 900 604800 86400

;; Query time: 14 msec
;; SERVER: 206.251.73.9#53(206.251.73.9)
;; WHEN: Sat Mar 28 12:56:33 2009
;; MSG SIZE  rcvd: 98
这里返回了NXDOMAIN结果，表明该服务器没有被DNS劫持。

而当我们使用了一个被劫持的DNS来查询一个不存在的域名：aaa-extmail.org ，查询返回结果是一个特定的IP ： 61.140.3.66（这是一个电信地址），实际指向了电信的网站！
dig aaa-extmail.org. @202.96.128.86     

; <<>> DiG 9.2.4 <<>> aaa-extmail.org. @202.96.128.86
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21176
;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;aaa-extmail.org.               IN      A

;; ANSWER SECTION:
aaa-extmail.org.        128     IN      A       61.140.3.66

;; Query time: 97 msec
;; SERVER: 202.96.128.86#53(202.96.128.86)
;; WHEN: Sat Mar 28 02:17:35 2009
;; MSG SIZE  rcvd: 49
　当使用该DNS查询一个存在的域名是能正确返回其IP地址。这种针对不存在的域名强制劫持到一个特定的IP的行为导致了RBL的查询返回错误。

　　二是对RBL查询结果进行验证。基本上所有的RBL服务都会返回特定的查询结果，即每次都返回同样的一个或几个IP地址，而且这种IP地址通常都是特定的保留IP，不会出现在正常的DNS查询中，如127.0.0.2、127.0.8.2等。目前绝大多数支持RBL查询的邮件服务器都支持对查询结果进行验证，你可以根据RBL服务所公示的查询结果来设置你的RBL查询。

以下是我服务器用ISP所在地区的dns测试，及谷歌dns测试结果：
[root@mail ~]# dig 35.209.167.119.cbl.anti-spam.org.cn

; <<>> DiG 9.7.3-P3-RedHat-9.7.3-2.el6_1.P3.3 <<>> 119.167.209.35.cbl.anti-spam                                                                                        .org.cn
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46879
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;119.167.209.35.cbl.anti-spam.org.c. IN A

;; ANSWER SECTION:
119.167.209.35.cbl.anti-spam.org.c. 3600 IN A   123.129.254.15

;; AUTHORITY SECTION:
.                       10800   IN      SOA     a.root-servers.net. nstld.veris                                                                                        ign-grs.com. 2011121200 1800 900 604800 86400

;; Query time: 38 msec
;; SERVER: 202.102.134.68#53(202.102.134.68)
;; WHEN: Mon Dec 12 15:56:04 2011
;; MSG SIZE  rcvd: 143

[root@mail ~]# dig 35.209.167.119.cbl.anti-spam.org.cn

; <<>> DiG 9.7.3-P3-RedHat-9.7.3-2.el6_1.P3.3 <<>> 119.167.209.35.cbl.anti-spam                                                                                        .org.cn
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19596
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;119.167.209.35.cbl.anti-spam.org.c. IN A

;; AUTHORITY SECTION:
.                       1800    IN      SOA     a.root-servers.net. nstld.veris                                                                                        ign-grs.com. 2011121200 1800 900 604800 86400

;; Query time: 57 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Dec 12 15:56:37 2011
;; MSG SIZE  rcvd: 127

以上说明我服务器所使用的dns存在劫持，换谷歌~

原文来自：http://www.extmail.org/forum/thread-10198-1-1.html 在原有基础加以增删。

        Dec 12 15:00:12 mail postfix/smtpd[17103]: NOQUEUE: reject: RCPT from unknown[116.254.202.98]: 554 5.7.1 <root@xxx.org>: Recipient address rejected: blocked using cblplus.anti-spam.org.cn, see http://bl.extmail.org/cgi/rbl?116.254.202.98; from=<support@***.com> to=<root@xxx.org> proto=ESMTP helo=<mail.***.com>

        解决方法：

(先更改服务器dns为8.8.8.8 谷歌的dns试试，如果不行再按照下面操作)

[root@mail ~]# vi /usr/local/slockd/config/plugin.cf

dnsbl_plugin = no      //改为no

保存退出：

[root@mail ~]# /usr/local/slockd/slockd-init restart
Stopping spam locker daemon: slockd
Starting spam locker daemon: slockd
[root@mail ~]#
再次收发测试！

       案例摘自网络：

       公司用的是EMOS 邮件服务器（内网IP:192.168.10.5,端口25、110映射到外网） postfix+extmail 公司使用邮件的员工在80人左右，都是用foxmail收发邮件，之前系统一切正常，最近出现一个很奇怪的问题：foxmail会突然连接不上邮件服务器，连接超时，发送邮件正常。

所有foxmail客户端的POP3、SMTP地址用的都是公司外网地址，出现问题后，我把foxmial的POP3地址该为内网地址192.168.10.5，收取正常。之后，我通过telnet命令分别连接邮件服务器的25 110端口，telent+内网IP+端口 一切正常
telnet+外网IP+端口 25端口正常 110端口连接不上。

路由映射正常，邮件服务器出现这个问题后，重启路由解决不了，只能重启邮件服务器，然后一切恢复正常，但是过一段时间（大约6小时不等，时间或短或长），又会重复出现无法接收邮件的情况 。个人设想是邮件服务器POP3端口的问题！

     分析一下：

      在EMOS服务器中，有一个组件为fail2ban，其在服务器中起到了屏蔽ip的作用，当来自于同一个ip经过多次身份验证错误的时候，fail2ban会自动将其加入到iptables，过滤掉，在配置文件中指定的时间之后可以自动解封。经过fail2ban的过滤，那么我们的ssh、pop3 服务会更安全，它防止了一定程度的暴力破解。

参考下：https://www.rootop.org/?p=603

     以上故障可以看出，telnet emos服务器内网IP的25  110 端口没有任何问题，说明端口、服务运行正常。

telnet emos 服务器外网IP的25 端口没问题，110出现无法连接。众所周知110端口用来接收邮件，在此期间还用于传递身份验证信息。到此我们应该想到，传递身份验证信息的时候，如果遇到有密码错误呢？对，fail2ban开始起作用了，当达到fail2ban中定义的错误次数时，此ip就被加入到iptables中直接拒绝掉，记住，fail2ban是对服务进行过滤，所以不会对其它端口造成影响。

     因为案例中公司员工都是通过外网来访问网络边缘设备的外网ip所映射到的服务器，只要公司员工邮箱有身份认证错误，那么公司网络出口设备上的外网ip会被fail2ban封掉，导致全部不能上，重启网络设备无效是正确的，重启服务器，等于重启fail2ban服务，解除封锁的ip，即可恢复正常。

最有效的方法为，在fail2ban中添加公司出口ip，忽略掉此ip即可。

编辑fail2ban的配置文件/etc/fail2ban/jail.conf

在 [DEFAULT] 全局配置中的ignoreip选项中添加被放行的ip地址：
ignoreip = 127.0.0.1 172.17.1.218

参考  fail2ban添加ip地址白名单 ：

https://www.rootop.org/?p=880

      还有一种情况需要注意下，如果在服务器前端有其它的网络设备，会转换源ip地址为网络设备的内网ip地址的话，那么需要添加网络设备内网ip到白名单。

比如深信服的AD5500（Ver3.0版本）负载均衡器，就会转换客户端源ip地址为AD设备的内网ip，在服务器中看到的来源ip都是来源于AD的内网ip。或者是配置AD，传送源ip到服务器。