Problem CPANEL-39824 : message has lines too long for transport - Since January 21, 2022
-
In case anyone else is experiencing the same issue, after downgrading Exim I could no longer make changes to the Exim configuration via WHM as it was re-inserting the "message_linelength_limit" and therefore failing to save the configuration. To workaround this, I had to remove both "message_linelength_limit" entries from "/usr/local/cpanel/etc/exim/replacecf/dkim/remote_smtp" after which I could make changes to the Exim configuration via WHM. cPanel; how do I stop UPCP from upgrading Exim to the newer version and thus breaking things? Can I simply add "cpanel-exim*" to the "/etc/yum.conf" exclude or is there something else I need to do?
Manually edit config file according to: The cPanel & WHM Update Configuration File - cpupdate.conf | cPanel & WHM Documentation and put it on manual update.0 -
i noted that today a few of our servers started this issue yet again but this time its affecting delivery of mail to other cpanel accounts ad well as Microsoft 0 -
Any news for this error, I keep getting it and the customers are already going crazy with the workaround. 0 -
Update - we're adding the option to configure the message_linelength_limit value in WHM >> Exim Configuration Manager in 102.0.4 when that gets to a public tier. 0 -
So I put the maximum, I hope there will be no problem with 65536 instead of 2048000 : [QUOTE] Your changes have been saved. Restarting cPanel daemons...done. Updating your system to reflect any changes... Updating "Maximum line length for SMTP transports" from "" to "65536". "Maximum line length for SMTP transports" was updated. Done. Your configuration changes have been saved! Waiting for "exim" to restart "waiting for "exim" to initialize "finished. .... exim restarted successfully. 0 -
Here, the problem has returned yesterday, after cPanel night update - so i changed the message_linelength_limit to the maximum allowed value (65536) The problem still occurs. I'm going to the third ticket about this issue, this is extremely frustrating. 0 -
It would be necessary to remove the authorized limit (65536) to put no limit on it. [CODE=php]mail(....,message,...);
In this php function, for years the message could contain an unlimited number of characters but since January 2022 the limit number of characters has been restricted to 9xx then to 2048, which is not enough, even for 65536 it is not enough if there are a lot of texts or html codes. If for example I go to this wikipedia page and I do CTRL + A and I paste everything in the message variable of the mail() function of php, then the email will never send because the number of characters is 156,000 spaces included and cpanel have set a limit of 65,536 (characters?) which is not good. With 2048000 it was better... To tell the truth, putting the limit at 65536 is not a good idea, it would be necessary to make the number unlimited 2048000 or 2048000000000 at worst.0 -
@leandrokohler - I haven't heard any reports of this coming back after last night's update. Can you post the ticket number you created so I can follow along? 0 -
This issue started a couple of days ago for me. (v. 102.0.7) When I go to Exim Configuration Manager I cannot see any value to change, I only see blank content under any of the tabs there like basic editor, advanced editor. 0 -
[QUOTE]This issue started a couple of days ago for me. (v. 102.0.7) When I go to Exim Configuration Manager I cannot see any value to change, I only see blank content under any of the tabs there like basic editor, advanced editor.
This appears to be related to a new issue that our developers are actively investigating. You can read more about it in the following article: I apologize for the inconvenience. You may follow the article to receive an update when we have published a solution to the issue.0 -
This appears to be related to a new issue that our developers are actively investigating. You can read more about it in the following article: I apologize for the inconvenience. You may follow the article to receive an update when we have published a solution to the issue.
@cPanelWilliam as of cPanel & WHM v102.0.8 (STANDARD) we are not having any issues with Exim Configuration Editor showing the load 1 behavior. I have tried reloading it about 20 times now and it has not come back on our end. CPANEL-40174 is however still considered open and unresolved. Could you ask if it is indeed resolved? I am not seeing it mentioned in the change-log from 15th March 102 Change Log | cPanel & WHM Documentation0 -
CPANEL-40174 is also resolved in 102.0.8 according to what I see on my end. You're correct that it is not in the change log for some reason, but it was included and I'm having our team update the change log for that now. 0 -
Hi, I am using cPanel 102.0.8, and set message_linelength_limit to 65536, but I am still getting this error. Well the errors are reduced, but still lots, I know almost this issues are related with the outlook/office365, but I can not call Micrsoft Support, so I ask if we can downgrade the exim to old version ? 0 -
@chengkinhung - is it still the same error? If so, can you bump the value and see if that takes care of it? 0 -
Hi @cPRex, yes, exactly the same. But i am sorry, as I found my SMTP added custom SMTP ROUTE, and we must add message_linelength_limit into all this SMTP ROUTE manuly, after that, seems error gone. Thanks very much. 0 -
I have this issue too now. I didn't have it before, but since the update to 102.0.8 I'm getting these messages when Cpanel sends the logwatch email to me. I don't know anything about SMTP route, and I didn't change anything. In my case the logwatch message is send to root. Root is forwarded to my e-mail address on another server, which does support very long lines. 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: me@mycompany.com (generated from root@server.cpanelserver.nl) message has lines too long for transport him@otheradmin.nl (generated from root@server.cpanelserver.nl) message has lines too long for transport
The him@otheradmin.nl is an email addres to a domain residing locally on that cPanel server.0 -
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. 0 -
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. 0 -
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.0 -
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. ;)0 -
@rhm.geerts - were you able to bump that value in the configuration and see if that helped? 0 -
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 [font="courier new">message_linelength_limit variable in [font="courier new">/etc/exim.conf.localopts that [font="courier new">/scripts/buildeximconf reads to set the [font="courier new">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 [font="courier new">message_linelength_limit value will survive subsequent configuration updates. 0 -
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.0 -
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.0 -
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?0 -
At this point, users experiencing the issue will need to adjust that value manually. 0 -
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. 0 -
Thank you. That is a reasonable thought indeed. 0
Please sign in to leave a comment.
Comments
172 comments