mail转发看起来是个简单任务，其实不然，变复杂的原因是为了邮件系统的安全
最让我费神的经历是：
发出去的邮件被当成垃圾邮件
sendmail很容易安装和运行，起先，向我的gmail邮箱发送邮件时，总是要到垃圾邮件中找，检查发现发件人的地址是 xxx@localhost.localdomain。显然是邮件服务器的主机名配置不合理。经过研究，结论是sendmail启动时会从多个地方获得本机名和别名，他们是：
RedHat操作系统的/etc/hosts文件 RedHat操作系统的/etc/sysconfig/network sendmail的配置文件/etc/mail/sendmail.cf中Cw的值 sendmail的配置文件/etc/mail/local-host-names（如果在sendmail.cf中声明使用该文件）
这些名字既用在发送过程，也用在接收过程。接收过程后面说明。
如果，使用sendmail命令向外发送一个邮件，例如：
/usr/sbin/sendmail who@domain.com < message-in-file
服务器要决定在发送的邮件中的From头应该怎样填写，它的格式是account@hostname，account就是当前Linux用户的帐号，容易确定，hostname部分我感觉到它是这样确定的：系统判断这是本地用户发起的邮件，所以在/etc/hosts中将127.0.0.1行中的第一个名字选定为hostname。如果第一个名字是localhost或者localhost.localdomain，对方一般会认为这是垃圾邮件。
于是有个办法，将真是的邮件服务器名字放在127.0.0.1这行的第一个位置，这个方法有效解决了From头的地址问题。
但是，这种解决方法仍然是不正确的，将会在http://cbl.abuseat.org的CBL上有个很不好的评级，后来，我根据http://cbl.abuseat.org/hostname.html的建议，将127.0.0.1这行恢复成只有localhost和localhost.localdomain两个名字，而另加一行，说明实际地址和实际主机名字的对应关系。参见http://cbl.abuseat.org/hostname.html。同时在sendmail.cf中声明Dj的值为真正的主机名。
使用以下方法检验主机名配置是否合理：
/usr/sbin/sendmail helocheck@cbl.abuseat.org < message-in-file
即给上述地址发个邮件，看它返回的信息里面是否包含了真正的IP地址或者真正的主机名，不应该是127.0.0.1或者localhost之类。
无法接收外部邮件的问题
系统已经能够向外发送邮件了，但是接不到外来邮件，这个问题困扰了我整整一天，后来体会到sendmail为了提高安全性，做了很多判断，收不到邮件会有多种原因：
上节讲sendmail启动时获取了很多名字，这些名字用来过滤对方发的邮件，如果发来的邮件的目的地址的主机名部分不能被识别，将拒绝这个邮件，所以，在上节所将的配置主机名的地方一定要将所有可能的名字包含在内。
SMTP使用25号端口，要看绑定在哪个IP上，那么只有向这个IP发送的邮件才被接收，查看的命令是netstat -na | grep 25。一开始，在sendmail.cf中，有下面一行
DaemonPortOptions=Port=smtp,Addr=127.0.0.1, Name=MTA
那么，sendmail启动时就帮定到127.0.0.1上了，结果只能在同一台机器的不同用户间发邮件。如果改成
DaemonPortOptions=Port=smtp,Addr=实际IP, Name=MTA
那么，只能接收发向此IP的消息了，结果同机器上用户将的信息不能转发了。
解决办法是两个都加上。还有更好的方法就是两条配置命令都删除，这样25号端口就不绑定IP地址了。
部分邮件服务器拒绝接收
由于IP地址都是租来的，可能该IP被人用过而且有不好的声誉，现在很多邮件服务器都加入了一个反垃圾邮件和病毒的联盟，很有可能你拿到的IP正在别人的黑名单上。不幸的是，这就发生在我的身上。为了解决这个问题，需要到这些服务器上声明自己是清白的。主要作了下面的声明：
到http://www.spamhaus.org上检查自己的IP是否有污点，有就需要清除
到http://cbl.abuseat.org上检查CBL的状态，必要的化需要清除
差不多过30分钟，到http://www.senderbase.org上看IP地址的评级，我的邮件评级已经是netural了，但是web仍然是poor，回头再考虑怎样解决。
设置reverse DNS
关于reverse dns
Reverse DNS is the process of using DNS to translate IP addresses to hostnames.
It is the opposite of forward DNS, which is used to translate hostnames to IP addresses.
Internet names are those used to refer to hosts on the Internet, such as www.tech-faq.com and www.freebsd.org.
IP addresses are the numbers that Internet routers use to move traffic across the Internet, such as 216.17.138.115 and 216.136.204.117.
Reverse DNS Lookups
One of the best ways to understand reverse DNS is to use the DNS testing tool, `nslookup` to do a sample reverse DNS lookup.
Here is an example of using `nslookup` to do a reverse DNS lookup on the IP address 216.136.204.117:
bash-2.05a$ nslookup 216.136.204.117
Server: localhost.net
Address: 127.0.0.1
Name: www.freebsd.org
Address: 216.136.204.117
Reverse DNS PTR Records
Reverse DNS is setup by configuring PTR records (Pointer Records) in the DNS server.
This is in contrast to Forward DNS, which uses A records (Address Records).
Reverse DNS Delegation
When someone registers a domain name with a domain registrar, he/she usually becomes responsible for that Forward DNS domain. In DNS terms, the domain is delegated to the person who registers the domain name.
However, this person is not responsible for his/her reverse records. His/her Reverse DNS records are still most likely the responsibility of your hosting facility or ISP.
To change the Reverse DNS PTR records, contact the company where the IP address came from, usually a hosting facility or an ISP.
Alternatively, the ISP or hosting company may delegate a range of IP addresses to the user, in which case the user must configure Reverse DNS and PTR records in his/her DNS server.
Is Reverse DNS Necessary?
Some junior DNS administrators configure forward DNS and forget to configure reverse DNS.
When they do this, some things work fine. Internet web browsing, for example, works great. However, not everything works.
Reverse DNS is required by some Internet protocols and by extensions to some other Internet protocols. Without reverse DNS, users will experience trouble with r-commands, IRC, some SMTP servers, most enterprise management systems, and many network backup systems.
Troubleshooting problems that faulty or non-existent reverse DNS cause can take considerable time and effort. It is much better to ensure that reverse DNS is configured correctly from the beginning.
参考与引用 本文搜集自互联网 仅供学习和交流 所用
Naming issues with Linux and xBSD
Responsive Email Developer’s Guide for Magento EE 1.14.1 and Magento CE 1.9.1