![邮件送达通知已正确送达,但实际邮件未正确送达](https://linux22.com/image/131462/%E9%82%AE%E4%BB%B6%E9%80%81%E8%BE%BE%E9%80%9A%E7%9F%A5%E5%B7%B2%E6%AD%A3%E7%A1%AE%E9%80%81%E8%BE%BE%EF%BC%8C%E4%BD%86%E5%AE%9E%E9%99%85%E9%82%AE%E4%BB%B6%E6%9C%AA%E6%AD%A3%E7%A1%AE%E9%80%81%E8%BE%BE.png)
我已将我们部门的 Debian 工作站配置为使用 Exim 4 进行邮件传递。我还创建了一个别名,以便我收到所有root
电子邮件。 Exim 4 配置(通过 Ansible 和 debconf)具有以下设置:
exim4_dc_eximconfig_configtype: internet
exim4_dc_readhost: …
exim4_dc_smarthost: …
exim4_dc_use_split_config: 'true'
exim4_dc_hide_mailname: 'true'
exim4_dc_mailname_in_oh: 'true'
在每台机器上,我都可以用来mailx
发送电子邮件root
,它会很好地显示在我的收件箱中。还一些cron 作业的执行已正确发送给我。
但是,大多数 cron 作业无法发送电子邮件,而是收到以下电子邮件:
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
ueding@…
(generated from root@echo)
Reporting-MTA: dns; echo
Action: failed
Final-Recipient: rfc822;ueding@…
Status: 5.0.0
Return-path: <root@echo>
Received: from root by echo with local (Exim 4.89)
(envelope-from <root@echo>)
id 1f7Jqz-0007jU-7y
for root@echo; Sat, 14 Apr 2018 14:00:25 +0200
From: root@echo (Cron Daemon)
To: root@echo
Subject: Cron <root@echo> ansible-pull -U [email protected]:…/….git --private-key /root/.ssh/ansible_pull localhost.yml
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>
Message-Id: <E1f7Jqz-0007jU-7y@echo>
Date: Sat, 14 Apr 2018 14:00:25 +0200
X-Exim-DSN-Information: Due to administrative limits only headers are returned
我真的不明白为什么会发生这种情况。要么所有电子邮件发送失败,要么几乎全部成功。来自 cron 的电子邮件怎么会失败最多工作站但在其他工作站上成功,而发送失败的电子邮件总是能通过?
机器上有关 exim 的系统日志 echo 非常稀疏:
# journalctl -u exim4.service
-- Logs begin at Tue 2018-03-06 18:35:11 CET, end at Sat 2018-04-14 17:13:08 CEST. --
Apr 02 18:00:30 echo systemd[1]: Starting LSB: exim Mail Transport Agent...
Apr 02 18:01:23 echo exim4[27433]: Starting MTA: exim4.
Apr 02 18:01:23 echo systemd[1]: Started LSB: exim Mail Transport Agent.
调查一下/var/log/exim4/mainlog
就可以得到银盘上的解释:
2018-04-14 14:00:25 1f7Jqz-0007jU-7y <= root@echo U=root P=local S=7948
2018-04-14 14:00:25 1f7Jqz-0007jU-7y ** ueding@… <root@echo> R=dnslookup T=remote_smtp: message is too big (transport limit = 1)
2018-04-14 14:00:25 1f7Jqz-0007jW-BM <= <> R=1f7Jqz-0007jU-7y U=Debian-exim P=local S=1856
2018-04-14 14:00:25 1f7Jqz-0007jU-7y Completed
2018-04-14 14:00:26 1f7Jqz-0007jW-BM => ueding@… <root@echo> R=dnslookup T=remote_smtp H=… […] X=TLS1.0:RSA_AES_256_CBC_SHA1:256 CV=yes DN="C=DE,ST=…,L=…,O=…,OU=…,CN=…" C="250 2.0.0 Ok: queued as 6FCA1155FC32"
2018-04-14 14:00:26 1f7Jqz-0007jW-BM Completed
错误可能是“消息太大(传输限制 = 1)”。但这仍然没有多大意义,因为我有 30 个配置相同的工作站,其中一些工作站的消息连续几天传递。每台机器的消息长度应该相同(主机名的长度除外),并且当前获取电子邮件的两台机器具有更长的名称。
答案1
日志中的示例:
[电子邮件受保护] R=smarthost T=remote_smtp_smarthost:消息太大(传输限制 = 1)
这意味着已达到 998 个字符的最大 LINE 限制
解决方案:
在“/etc/exim4/exim4.conf.localmacros”中添加以下行:
IGNORE_SMTP_LINE_LENGTH_LIMIT = 1
然后重新启动exim4。
答案2
我认为您已经遇到了这个报告的错误,exim4:超长线路上的虚假拒绝响应。
它实际上指的是太长的行,而不是消息本身。fmt -s
在将消息传递到 之前尝试通过管道传输消息exim4
。