이메일 전달 알림은 제대로 전달되었으나 실제 이메일은 제대로 전달되지 않았습니다.

이메일 전달 알림은 제대로 전달되었으나 실제 이메일은 제대로 전달되지 않았습니다.

나는 메일 전달을 위해 Exim 4를 사용하도록 우리 부서의 Debian 워크스테이션을 구성했습니다. 또한 모든 이메일을 받을 수 있도록 별칭을 만들었습니다 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받은 편지함에는 문제 없이 표시됩니다. 반품일부크론 작업 실행이 나에게 올바르게 전송되었습니다.

그러나 대부분의 크론 작업은 이메일 전송에 실패하고 대신 다음 이메일을 받습니다.

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과 관련된 시스템 로그 에코는 매우 드물습니다.

# 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)

이는 최대 LINE 제한인 998자에 도달했음을 의미합니다.

해결책:

"/etc/exim4/exim4.conf.localmacros"에 다음 줄을 추가합니다:

IGNORE_SMTP_LINE_LENGTH_LIMIT = 1

그런 다음 exim4를 다시 시작하십시오.

답변2

이 보고된 버그를 겪으신 것 같습니다.exim4: 매우 긴 줄에 대한 가짜 거부 응답.

이는 실제로 메시지 자체가 아니라 너무 긴 줄을 의미합니다. fmt -s메시지를 전달하기 전에 메시지를 파이프해 보십시오 exim4.

관련 정보