SOLVED Problem CPANEL-39824 : message has lines too long for transport - Since January 21, 2022

[sparek-3]

Maybe the current limit of 2048 is still too small or it's not used for some reason by php forms. Exchanges uses a limit of 8000. However, it's odd that the issue did not occur before and suddenly start appearing after upgrading to this new version.

This all stems from a change Exim made from Exim 4.94 to Exim 4.95.

Prior to Exim 4.95 - Exim did not enforce RFC 5322 2.1.1 - and really, no MTA enforces RFC 5322 2.1.1 (or at least none that I'm aware of).

Now, who is right and who is wrong? This is a prime example of what happens when you start bending the rules - the rules start to not matter and you're left with a proprietary mess of nonconformity.

Ideally, all MTAs would have strictly follow all of the RFCs for SMTP from the start - meaning that the 998 character limit per line would have always been enforced, and none of us would be any wiser. On the flipside of it... since seemingly nobody has ever enforced this limit... does this prove that the need for the limit really doesn't affect anything, so why have it?

For me, the real-real answer to this, is for the RFC to be rewritten so that RFC 5322 2.1.1 is not needed. Unless someone can point out an issue with having SMTP lines that are longer than 998 characters.

 

[rhm.geerts]

This all stems from a change Exim made from Exim 4.94 to Exim 4.95.

Yes I'm aware of that, but I had 4.95 already running in my previous version of cPanel. I just updated 2 days ago and only the last 2 days I get these notices of the logwatch mails which are send from the cPanel server. So I'm clueless as to why this happens.

It might be I created a workaround which was overwritten someway, I'm not sure anymore. Except for the fact that it's happening for 2 days now, since the upgrade.

I'm also aware of that particular RFC which Exim did not enforce before. But indeed, nobody cares about it anymore. As I already stated even Microsoft Exchange uses a way higher limit. I can understand because that low limit is not of this time.

Who is right? Well.. normally the RFC's are right, but since nobody clearly cares about this RFC except suddenly Exim, it seems to me the party's deciding about RFC's should discuss things and either update or remove that particulier RFC. That's not up to use hosters, neither Panel creators like cPanel.
So for this part, we agree.

However, suddenly we as hosters get stuck with this problem. And cPanel stated they should fix it, and it's not fixed. DA did fix it.

Unless someone can point out an issue with having SMTP lines that are longer than 998 characters.

Like I already stated... my daily logwatch messages from cPanel.

However, if the workaround mentioned by Metro2 will work too and will not be overwritten, it's fine by me too, but in that case cPanel should not communicate that they will fix it in version 102.0.8 but should communicate it's an RFC thing and we have to use workarounds.

 

[cPRex]

@rhm.geerts - were you able to bump that value in the configuration and see if that helped?

 

[sparek-3]

I'm not running cPanel 102 or whatever version of cPanel updates to Exim 4.95 - so I can't really see what cPanel has done or is in the process of doing to resolve this.

But my proposal would be to add a message_linelength_limit variable in /etc/exim.conf.localopts that /scripts/buildeximconf reads to set the message_linelength_limit in the necessary Exim transports. Set the limit to 998 by default if you wish, since that's the RFC, but system administrators are able to change this value to whatever they might wish.

This way a change to the message_linelength_limit value will survive subsequent configuration updates.

 

[rhm.geerts]

were you able to bump that value

I didn't had the time for it yet, had to go some place else, but I will do that now as the logwatch mails will be send later tonight anyway.
So I'll let you know tomorrow.

 

[muwicaksono]

Same issue "message has lines too long for transport" just started for several of my customer's PHP forms and certain e-commerce site automated responses to their customers, only after updating to 102.0.8 (Release tier) just a few days ago.

I'm going to try the WHM >> Exim Configuration Manager > message_linelength_limit value 65536 workaround and ask users to test today, and will report back here with results tonight or tomorrow in case it's anything useful.

I've changed the message length limit several times and it's still popping up a notification like that, it doesn't work.

 

[rhm.geerts]

and see if that helped?

Hello cPRex.
I can confirm that the bump of the value in the configuration fixed the issue so that is a good workaround.
Today I got the logwatch e-mail again without any issues, so that is change is working fine.

Will this be all or will cPanel still provide a definate fix for everybody? Or does everybody experiencing this problem has to use this workaround?

 

[cPRex]

At this point, users experiencing the issue will need to adjust that value manually.

 

[rhm.geerts]

At this point,

But will this be fixed by CP in the near future? Because of this statement CP made:

A fix has been published to cPanel version 102.0.2.

https://support.cpanel.net/hc/en-us/articles/4420121088919-Exim-4-95-message-has-lines-too-long-for-transport-Error

which creates a certain expectation about a real fix.

 

[cPRex]

At this point the fix is to add that option in the interface. For most users, that takes care of the issue, but having the option to adjust that configuration makes it much easier to adjust for users that need additional configuration options.

 

[rhm.geerts]

Thank you. That is a reasonable thought indeed.

 

[wintech2003]

For servers that use a smarthost (ie MailChannels, MailBaby etc) and have a custom POSTMAILCOUNT and TRANSPORTSTART entries via the Advanced Editor, is it required to add the message_linelength_limit = 2048 line in those sections too?
If so, does it go to the route or the transport section?

Nvm, indeed, it needs to be added to the custom TRANSPORTSTART entry. Otherwise by default the limit will be 998.

Without adding the entry to the custom router:

# exim -bP transport_list | while read list ; do echo "$list" ; exim -bP transport $list | grep line ; done
mailchannels_smtp
message_linelength_limit = 998
remote_smtp
message_linelength_limit = 65536
dkim_remote_smtp
message_linelength_limit = 65536

After adding message_linelength_limit = 65536 into TRANSPORTSTART

# exim -bP transport_list | while read list ; do echo "$list" ; exim -bP transport $list | grep line ; done
mailchannels_smtp
message_linelength_limit = 65536
remote_smtp
message_linelength_limit = 65536
dkim_remote_smtp
message_linelength_limit = 65536

 

[cPRex]

Update - we have some more details on other tools, as even after the cPanel changes this is still affecting MailScanner and customer routers:

https://support.cpanel.net/hc/en-us/articles/4422687370519--Message-has-lines-too-long-for-transport-while-MailScanner-is-in-use

https://support.cpanel.net/hc/en-us/articles/4984208965015--Message-has-lines-too-long-for-transport-with-custom-routers-in-v102-

 

[Metro2]

Update - we have some more details on other tools, as even after the cPanel changes this is still affecting MailScanner and customer routers:

https://support.cpanel.net/hc/en-us/articles/4422687370519--Message-has-lines-too-long-for-transport-while-MailScanner-is-in-use

https://support.cpanel.net/hc/en-us/articles/4984208965015--Message-has-lines-too-long-for-transport-with-custom-routers-in-v102-

@cPRex thanks for the additional double-check reference.

In my particular case so far, it appears that using the WHM >> Exim Configuration Manager > message_linelength_limit value 65536 workaround seems to have done the trick, since:

A.) I run Mailscanner and...
B.) I never had to manually modify /etc/exim_outgoing.conf after implementing the workaround - it automatically set it to message_linelength_limit = 65536 in /etc/exim_outgoing.conf and all I had to do was restart Exim.

But I'm running CloudLinux 6 ELS along with CSF/LFD/Mailscanner on cPanel Release Tier, so others might not have the same results.

I've asked customers to "try again" a couple days ago and have not had any responses, which as we know basically means "hmmm seems solved, moving on, no need to reply to the person I ticketed" ;-)

 

[LBJ]

have not had any responses, which as we know basically means "hmmm seems solved, moving on, no need to reply to the person I ticketed"

Love it!

Best regards,

LBJ

 

[Paulus Cobris]

Hello,
I can confirm this situation is not RESOLVED and the latest WHM version.
Im expecting some update and final fix on this situation on next wave of updates...

The problem is happening "Less" times, but i have been contacted with costumers having this issue even on this latest version...

Best Regards,

 

[Just Retro]

Can confirm this bug is affecting my online shop too. I'm using OpenCart 3.0.3.8 and it seems whenever anyone purchases a gift certificate or when I update the a customer order I get the dreaded message has lines too long for transport error.
OpenCart is just using PHP's Mail() function as far as I'm aware

The host I'm using (Host Sailor) uses cPanel 102.0.8
Unfortunately I don't see any "exim" related entries whatsoever in my cPanel or on FTP when I check out the /etc folder. So I guess I have no way of fixing the message_linelength_limit right? I'm assuming I'm stuck with it?

 

[cPRex]

@Just Retro - do you have root access to the machine? If not, you'd need to speak with your host to have them fix the issue as you can't do that at the user level.

 

[Just Retro]

@Just Retro - do you have root access to the machine? If not, you'd need to speak with your host to have them fix the issue as you can't do that at the user level.

I don't no, and speaking to them directly about the issue just sent me to this thread. When I suggested the workaround used in this thread of editing that entry they just basically said we can't change individual options for only 1 customer lol.

 

[Paulus Cobris]

@Just Retro - do you have root access to the machine? If not, you'd need to speak with your host to have them fix the issue as you can't do that at the user level.

Hello,
When this issue is fixed?

In WHM i have altered to the max permited numbers and STILL the problems happens...


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:

[email protected]
message has lines too long for transport


Reporting-MTA: dns; alpha.connectserver.org

Action: failed
Final-Recipient: rfc822;[email protected]
Status: 5.0.0


Return-path: <[email protected]>
Received: from foquimdental.com ([94.46.179.3]:38640 helo=my.trignosfera.pt)
by alpha.connectserver.org with esmtpa (Exim 4.95)
(envelope-from <[email protected]>)
id 1nbXbQ-0004tf-Cz
for [email protected];
Tue, 05 Apr 2022 02:03:29 +0100
To: [email protected]
From: Trignosfera - Servicos de Internet <[email protected]>
Reply-To: [email protected]
Subject: =?UTF-8?B?UmVub3Zhw6fDo28gZG9zIFNlcnZpw6dvcyBjb20gYSBUcmlnbm9zZmVyYSAt?=
=?UTF-8?B?IEFsb2phbWVudG8gLSA0NzI=?=
Date: Tue, 05 Apr 2022 01:03:24 +0000
X-Mailer: CakePHP Email Component
Content-Type: multipart/alternative; boundary="alt-"
Content-Transfer-Encoding: 7bit
X-Exim-DSN-Information: Due to administrative limits only headers are returned


This is starting to become very annoying...

I need an ETA for some kind of fix... just go back to older EXIM.

Best Regards.

Paulo Eduardo