Mail delivery notices are correctly delivered, actual mail isn't
I have configured the Debian workstations at our department to use Exim 4 for mail delivery. Also I have created an alias such that I receive all the root
emails. The Exim 4 configuration (via Ansible and debconf) has those settings:
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'
On each of the machines, I can use mailx
to send an email to root
and it will show up in my inbox just fine. Also some executions of the cron jobs are properly sent to me.
However, most cron jobs fail to deliver their emails and instead I get the following email:
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 git@github.com:…/….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
I really do not understand why this is happening. Either all email delivery fails, or almost all succeed. How can the email from cron fail on most workstations but succeed on others, while the delivery failure emails always get through?
The system log regarding exim on the machine, echo, is really sparse:
# 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.
Looking into /var/log/exim4/mainlog
serves the explanation on a silver platter:
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
The error likely is “message is too big (transport limit = 1)”. But that still does not make so much sense since I have 30 identically configured workstations and for some of them the messages get through several days in a row. The length of the message should be the same for each machine (except the length of the hostname), and the two machines which currently get their emails through have longer names.
email exim
add a comment |
I have configured the Debian workstations at our department to use Exim 4 for mail delivery. Also I have created an alias such that I receive all the root
emails. The Exim 4 configuration (via Ansible and debconf) has those settings:
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'
On each of the machines, I can use mailx
to send an email to root
and it will show up in my inbox just fine. Also some executions of the cron jobs are properly sent to me.
However, most cron jobs fail to deliver their emails and instead I get the following email:
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 git@github.com:…/….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
I really do not understand why this is happening. Either all email delivery fails, or almost all succeed. How can the email from cron fail on most workstations but succeed on others, while the delivery failure emails always get through?
The system log regarding exim on the machine, echo, is really sparse:
# 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.
Looking into /var/log/exim4/mainlog
serves the explanation on a silver platter:
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
The error likely is “message is too big (transport limit = 1)”. But that still does not make so much sense since I have 30 identically configured workstations and for some of them the messages get through several days in a row. The length of the message should be the same for each machine (except the length of the hostname), and the two machines which currently get their emails through have longer names.
email exim
2
This is a delivery failure message. What do the Exim mail log files tell you on the system that fails to send the original message?
– roaima
Apr 14 '18 at 15:09
How could I not have looked into the logs‽ I now made up for this lapse. The issue seems to be a size issue. But since it is just a few page text log and other machines get their stuff through, it still seems unclear.
– Martin Ueding
Apr 14 '18 at 15:22
add a comment |
I have configured the Debian workstations at our department to use Exim 4 for mail delivery. Also I have created an alias such that I receive all the root
emails. The Exim 4 configuration (via Ansible and debconf) has those settings:
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'
On each of the machines, I can use mailx
to send an email to root
and it will show up in my inbox just fine. Also some executions of the cron jobs are properly sent to me.
However, most cron jobs fail to deliver their emails and instead I get the following email:
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 git@github.com:…/….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
I really do not understand why this is happening. Either all email delivery fails, or almost all succeed. How can the email from cron fail on most workstations but succeed on others, while the delivery failure emails always get through?
The system log regarding exim on the machine, echo, is really sparse:
# 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.
Looking into /var/log/exim4/mainlog
serves the explanation on a silver platter:
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
The error likely is “message is too big (transport limit = 1)”. But that still does not make so much sense since I have 30 identically configured workstations and for some of them the messages get through several days in a row. The length of the message should be the same for each machine (except the length of the hostname), and the two machines which currently get their emails through have longer names.
email exim
I have configured the Debian workstations at our department to use Exim 4 for mail delivery. Also I have created an alias such that I receive all the root
emails. The Exim 4 configuration (via Ansible and debconf) has those settings:
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'
On each of the machines, I can use mailx
to send an email to root
and it will show up in my inbox just fine. Also some executions of the cron jobs are properly sent to me.
However, most cron jobs fail to deliver their emails and instead I get the following email:
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 git@github.com:…/….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
I really do not understand why this is happening. Either all email delivery fails, or almost all succeed. How can the email from cron fail on most workstations but succeed on others, while the delivery failure emails always get through?
The system log regarding exim on the machine, echo, is really sparse:
# 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.
Looking into /var/log/exim4/mainlog
serves the explanation on a silver platter:
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
The error likely is “message is too big (transport limit = 1)”. But that still does not make so much sense since I have 30 identically configured workstations and for some of them the messages get through several days in a row. The length of the message should be the same for each machine (except the length of the hostname), and the two machines which currently get their emails through have longer names.
email exim
email exim
edited Apr 14 '18 at 15:21
Martin Ueding
asked Apr 14 '18 at 15:05
Martin UedingMartin Ueding
1,28811227
1,28811227
2
This is a delivery failure message. What do the Exim mail log files tell you on the system that fails to send the original message?
– roaima
Apr 14 '18 at 15:09
How could I not have looked into the logs‽ I now made up for this lapse. The issue seems to be a size issue. But since it is just a few page text log and other machines get their stuff through, it still seems unclear.
– Martin Ueding
Apr 14 '18 at 15:22
add a comment |
2
This is a delivery failure message. What do the Exim mail log files tell you on the system that fails to send the original message?
– roaima
Apr 14 '18 at 15:09
How could I not have looked into the logs‽ I now made up for this lapse. The issue seems to be a size issue. But since it is just a few page text log and other machines get their stuff through, it still seems unclear.
– Martin Ueding
Apr 14 '18 at 15:22
2
2
This is a delivery failure message. What do the Exim mail log files tell you on the system that fails to send the original message?
– roaima
Apr 14 '18 at 15:09
This is a delivery failure message. What do the Exim mail log files tell you on the system that fails to send the original message?
– roaima
Apr 14 '18 at 15:09
How could I not have looked into the logs‽ I now made up for this lapse. The issue seems to be a size issue. But since it is just a few page text log and other machines get their stuff through, it still seems unclear.
– Martin Ueding
Apr 14 '18 at 15:22
How could I not have looked into the logs‽ I now made up for this lapse. The issue seems to be a size issue. But since it is just a few page text log and other machines get their stuff through, it still seems unclear.
– Martin Ueding
Apr 14 '18 at 15:22
add a comment |
2 Answers
2
active
oldest
votes
I think you've hit this reported bug, exim4: bogus reject response on overlong lines.
It actually refers to lines that are too long, not the message itself. Try piping your message through fmt -s
before passing it to exim4
.
This very much looks like it! Theansible-playbook
command sometimes creates insanely long lines because it has the full failure output fromapt-get
in one line. I have updated two failing hosts with this, it should be fixed. I will come back here after the next run of cron and describe how it went.
– Martin Ueding
Apr 15 '18 at 8:41
add a comment |
example in log:
email@domain.tld R=smarthost T=remote_smtp_smarthost: message is too big (transport limit = 1)
this means a max LINE limit of 998 chars has been hit
solution:
in "/etc/exim4/exim4.conf.localmacros" add the following line:
IGNORE_SMTP_LINE_LENGTH_LIMIT = 1
and then restart exim4.
New contributor
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f437761%2fmail-delivery-notices-are-correctly-delivered-actual-mail-isnt%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
I think you've hit this reported bug, exim4: bogus reject response on overlong lines.
It actually refers to lines that are too long, not the message itself. Try piping your message through fmt -s
before passing it to exim4
.
This very much looks like it! Theansible-playbook
command sometimes creates insanely long lines because it has the full failure output fromapt-get
in one line. I have updated two failing hosts with this, it should be fixed. I will come back here after the next run of cron and describe how it went.
– Martin Ueding
Apr 15 '18 at 8:41
add a comment |
I think you've hit this reported bug, exim4: bogus reject response on overlong lines.
It actually refers to lines that are too long, not the message itself. Try piping your message through fmt -s
before passing it to exim4
.
This very much looks like it! Theansible-playbook
command sometimes creates insanely long lines because it has the full failure output fromapt-get
in one line. I have updated two failing hosts with this, it should be fixed. I will come back here after the next run of cron and describe how it went.
– Martin Ueding
Apr 15 '18 at 8:41
add a comment |
I think you've hit this reported bug, exim4: bogus reject response on overlong lines.
It actually refers to lines that are too long, not the message itself. Try piping your message through fmt -s
before passing it to exim4
.
I think you've hit this reported bug, exim4: bogus reject response on overlong lines.
It actually refers to lines that are too long, not the message itself. Try piping your message through fmt -s
before passing it to exim4
.
edited Apr 15 '18 at 13:24
answered Apr 14 '18 at 16:39
roaimaroaima
43.3k553116
43.3k553116
This very much looks like it! Theansible-playbook
command sometimes creates insanely long lines because it has the full failure output fromapt-get
in one line. I have updated two failing hosts with this, it should be fixed. I will come back here after the next run of cron and describe how it went.
– Martin Ueding
Apr 15 '18 at 8:41
add a comment |
This very much looks like it! Theansible-playbook
command sometimes creates insanely long lines because it has the full failure output fromapt-get
in one line. I have updated two failing hosts with this, it should be fixed. I will come back here after the next run of cron and describe how it went.
– Martin Ueding
Apr 15 '18 at 8:41
This very much looks like it! The
ansible-playbook
command sometimes creates insanely long lines because it has the full failure output from apt-get
in one line. I have updated two failing hosts with this, it should be fixed. I will come back here after the next run of cron and describe how it went.– Martin Ueding
Apr 15 '18 at 8:41
This very much looks like it! The
ansible-playbook
command sometimes creates insanely long lines because it has the full failure output from apt-get
in one line. I have updated two failing hosts with this, it should be fixed. I will come back here after the next run of cron and describe how it went.– Martin Ueding
Apr 15 '18 at 8:41
add a comment |
example in log:
email@domain.tld R=smarthost T=remote_smtp_smarthost: message is too big (transport limit = 1)
this means a max LINE limit of 998 chars has been hit
solution:
in "/etc/exim4/exim4.conf.localmacros" add the following line:
IGNORE_SMTP_LINE_LENGTH_LIMIT = 1
and then restart exim4.
New contributor
add a comment |
example in log:
email@domain.tld R=smarthost T=remote_smtp_smarthost: message is too big (transport limit = 1)
this means a max LINE limit of 998 chars has been hit
solution:
in "/etc/exim4/exim4.conf.localmacros" add the following line:
IGNORE_SMTP_LINE_LENGTH_LIMIT = 1
and then restart exim4.
New contributor
add a comment |
example in log:
email@domain.tld R=smarthost T=remote_smtp_smarthost: message is too big (transport limit = 1)
this means a max LINE limit of 998 chars has been hit
solution:
in "/etc/exim4/exim4.conf.localmacros" add the following line:
IGNORE_SMTP_LINE_LENGTH_LIMIT = 1
and then restart exim4.
New contributor
example in log:
email@domain.tld R=smarthost T=remote_smtp_smarthost: message is too big (transport limit = 1)
this means a max LINE limit of 998 chars has been hit
solution:
in "/etc/exim4/exim4.conf.localmacros" add the following line:
IGNORE_SMTP_LINE_LENGTH_LIMIT = 1
and then restart exim4.
New contributor
edited 5 hours ago
Jeff Schaller
39.4k1054126
39.4k1054126
New contributor
answered 6 hours ago
dev_nulldev_null
1
1
New contributor
New contributor
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f437761%2fmail-delivery-notices-are-correctly-delivered-actual-mail-isnt%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
This is a delivery failure message. What do the Exim mail log files tell you on the system that fails to send the original message?
– roaima
Apr 14 '18 at 15:09
How could I not have looked into the logs‽ I now made up for this lapse. The issue seems to be a size issue. But since it is just a few page text log and other machines get their stuff through, it still seems unclear.
– Martin Ueding
Apr 14 '18 at 15:22