message has lines too long for transport

D

DA-User-8173

New member
Joined
Aug 7, 2024
Messages
4
On my server (Almalinux) I see the error message in /var/log/exim/mainlog: “message has lines too long for transport”

This concerns exim 4.98

Apparently the content of the email needs to be adjusted by adding Linefeeds \n.



But the problem is that the email is created by Cron Daemon: From: "(Cron Daemon)"

Also I can't see which cron it concerns because the Subject line in the mainlog is truncated at the end: “Cron <submomain@vps12> /usr/local/php/bin/php /home/ submomain /domains/ submomain.domain.nl/public"


It seems that the current limit is not a problem:

/etc/exim.conf:1022: message_linelength_limit = 52428800
/etc/exim.conf:1032: message_linelength_limit = 52428800

I also tried this from another post:

/etc/exim.transports.pre.conf:

auth_relay:
driver = smtp
message_linelength_limit = 52428800

Unfortunately, that doesn't work (I don't think it's about smtp)

How can I (temporarily) override this error message so that I still receive the email and can see which cron it is?
 
What transport did the failure go through? Your exim.conf should have the value defined for remote_smtp and remote_smtp_forward_transport, and your exim.transports.pre.conf has it for auth_relay. I'm guessing this email is going through a different transport. That should be the "T=" on the log line containing the error. My suspicion is that message_linelength_limit isn't defined for the transport in question and is therefore going to the default value, which is a stupid value and the exim devs really stepped in that for no defensible reason (an old RFC is not justification for breaking functionality that users have been using without complaint).
 
Thanks for your answer.

I can't imagine that this message is sent via another transport. We have dozens of crons running and they send emails with content without any problems. It's a fresh vps.

The T=“Cron <submomain@vps12> /usr/local/php/bin/php /home/ submomain /domains/ submomain.domain.nl/public.....???????????..."

That T-content is the same as all other crons that do arrive. But the problem is that the T-value is truncated at the end and therefore we can't see the program in question.

Since the update to Exim 4.98 we have had several HTML emails that gave an error because lines were too long. That was solved by replacing "<BR>" with "<BR>\n" .

The question is whether we can temporarily disable that check for length so that we can find out which program is sending the problem email.
 
There is a T= for the email subject, but there should also be one on another line that refers to the exim transport.
 
DA-User-8173 said:
Here are all the T-lines:

T="Cron <subdomain@vps10> /usr/local/php/bin/php /home/subdomain/domains/subdomain.domain.nl/publi" from <[email protected]> for [email protected]

T=auth_relay: message has lines too long for transport

T="Mail delivery failed: returning message to sender" from <> for [email protected]

T=local_delivery S=2663
Click to expand...

Ok so you need to make sure message_linelength_limit is defined in the auth_relay transport. Do you happen to have that set up in /etc/exim.transports.pre.conf?
 
No, that file doesn't exists. Should I create it and fill it with "message_linelength_limit = 52428800" ?
 
You must log in or register to reply here.
Back
Top