![Sendmail MX 查找失败,dig 不成功](https://linux22.com/image/618268/Sendmail%20MX%20%E6%9F%A5%E6%89%BE%E5%A4%B1%E8%B4%A5%EF%BC%8Cdig%20%E4%B8%8D%E6%88%90%E5%8A%9F.png)
有人能解释一下这个问题吗?我可以在主机上执行 dig 或 nslookup 并获取 MX 服务器,但是当我通过 sendmail 检查时却失败了?
RHEL 5.6
发送邮件:
(root)> sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> /mx google.com
getmxrr(google.com) returns 0 value(s):
Sendmail 调试输出
(root)> echo '/mx google.com' | sendmail -bt -d8.20
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> getmxrr(google.com, droplocalhost=0)
getmxrr(google.com) returns 0 value(s):
挖:
(root)> dig mx google.com
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-14.P1.el5 <<>> mx google.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2247
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 4, ADDITIONAL: 9
;; QUESTION SECTION:
;google.com. IN MX
;; ANSWER SECTION:
google.com. 600 IN MX 10 aspmx.l.google.com.
google.com. 600 IN MX 20 alt1.aspmx.l.google.com.
google.com. 600 IN MX 30 alt2.aspmx.l.google.com.
google.com. 600 IN MX 40 alt3.aspmx.l.google.com.
google.com. 600 IN MX 50 alt4.aspmx.l.google.com.
;; AUTHORITY SECTION:
google.com. 33524 IN NS ns3.google.com.
google.com. 33524 IN NS ns4.google.com.
...
Sendmail 日志条目
Sep 20 00:42:26 myhost sendmail[26714]: r8K0gLUS026712: [email protected], [email protected] (500/500), delay=00:00:05, xdelay=00:00:05, mailer=example, pri=152798, relay=example.org, dsn=5.1.2, stat=Host unknown (Name server: example.org: host not found)
使用 -d17 发送邮件(超时)
sendmail -v -d17.20 [email protected]
Running /var/spool/mqueue/r8KFB1VF002503 (sequence 1 of 1)
hostsignature(gmail.com)
hostsignature(): getmxrr() returned 1, mxhosts[0]=gmail.com
hostsignature(gmail.com) = gmail.com
hostsignature(gmail.com)
hostsignature(): stab(gmail.com) found gmail.com
<[email protected]>... Connecting to gmail.com via esmtp...
答案1
我宁愿将其作为评论发布,但我不能。
您的 sendmail 日志条目一直在谈论“example.org”,这表明 sendmail 未完全配置。example.org 是一个典型的占位符域,[电子邮件保护]。
(这是假设你自己没有选择性地破坏/审查它——如果是这样的话,那么a)很难提取有意义的信息,并且b)至少应该始终如一地这样做)