Problem CPANEL-39824 : message has lines too long for transport - Since January 21, 2022
-
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 = 655360 -
Update - we have some more details on other tools, as even after the cPanel changes this is still affecting MailScanner and customer routers:
@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" ;-)0 -
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, LBJ0 -
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, 0 -
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? 0 -
@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. 0 -
@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.0 -
@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: xxxxxxxx@gmail.com message has lines too long for transport Reporting-MTA: dns; alpha.connectserver.org Action: failed Final-Recipient: rfc822;xxxxxxx@gmail.com Status: 5.0.0 Return-path: ='renovacao@trignosfera.pt'> Received: from foquimdental.com ([94.46.179.3]:38640 helo=my.trignosfera.pt) by alpha.connectserver.org with esmtpa (Exim 4.95) (envelope-from ='renovacao@trignosfera.pt'>) id 1nbXbQ-0004tf-Cz for xxxxxxxxxx@gmail.com; Tue, 05 Apr 2022 02:03:29 +0100 To: xxxxxx@gmail.com From: Trignosfera - Servicos de Internet ='renovacao@trignosfera.pt'> Reply-To: renovacao@trignosfera.pt 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 Eduardo0 -
@Just Retro - It's unfortunate that they referred you to a forums thread. They are correct, however, that the change has to be made globally on the root of the server and can't be adjusted for just one domain. I don't see why they wouldn't be able to make that change on their end for you as I wouldn't expect it to have a negative impact on other clients. @Paulus Cobris - you're still seeing that error even after setting the value to 65536? 0 -
@Just Retro - It's unfortunate that they referred you to a forums thread. They are correct, however, that the change has to be made globally on the root of the server and can't be adjusted for just one domain. I don't see why they wouldn't be able to make that change on their end for you as I wouldn't expect it to have a negative impact on other clients.
It is what it is I guess, reckon if I was to sent it via PHP -> SMTP for the same address instead of mail() it would bypass this error? Or does it affect that also?0 -
For our part, we modify the value to the maximum allowed 65536 and continue with the problem. 0 -
@Just Retro - It's unfortunate that they referred you to a forums thread. They are correct, however, that the change has to be made globally on the root of the server and can't be adjusted for just one domain. I don't see why they wouldn't be able to make that change on their end for you as I wouldn't expect it to have a negative impact on other clients. @Paulus Cobris - you're still seeing that error even after setting the value to 65536?
Hello, Yes, this was tested today with the 65536 value applied on the WHM -> Exim configuration, Running the latest current version of Cpanel. With my very best regards, Paulo Eduardo0 -
@Paulus Cobris - could you submit a ticket to our team so we can examine that system? 0 -
I would like to add, if you use Mailbaby, and probably any SMTP Relay, you would need to add message_linelength_limit = 65536 to the TRANSPORTSTART Section PS. it could be lower value i guess, but i would recommend maximum as exim basic editor. 0 -
Lower value will work fine. Microsoft Exchanges uses 8000 zo I set things to 8192 which should be more than enough. Unless one wants to write complete bookworks via e-mail. 0 -
Server just updated to 11.102.0.10 and started getting this issue for cron jobs trying to send mail. Per the fist post in this topic every site on every server I have that updates to this will start bouncing emails to EVERY CMS user creation or password change. (Edit 02: At least one site on this server can send password reset emails.) The related cPanel article: @Just Retro - It's unfortunate that they referred you to a forums thread. They are correct, however, that the change has to be made globally on the root of the server and can't be adjusted for just one domain. I don't see why they wouldn't be able to make that change on their end for you as I wouldn't expect it to have a negative impact on other clients.
If the above is accurate, why exactly can't cPanel just sed/cat/modify/replace that config file during an update?0 -
You really have to be able to differentiate between what cPanel is responsible for and what the server administrator is responsible for. And everything I see says there are very, very few actual server administrators out there. There are a lot of web hosting companies out there run by people waiting for someone else to fix their problems. For this particular case, I tend to side with cPanel. cPanel is following the RFC. The RFC says the max line length should be 998 characters. Is this RFC stupid? Yes. But what authority to does cPanel have to go out and police the rest of the Internet and tell everyone this RFC is stupid? What if another control panel does this? What if another mail server system does this? It's up to the server administrator to be responsible and adjust this value as they see fit. In a typical system, you'd just adjust the configuration file accordingly. But because cPanel has their hands on every application running on a cPanel server, you can't really do this and expect the changes to survive updates. This is why we have to depend on cPanel to provide "variables that can be changed" which they do through various Exim templates and /etc/exim.conf.localopts and the /scripts/buildeximconf script. And from what I've gathered, cPanel has provided all of this with the ability to adjust the max line length variables as administrators see fit. But it's still the server administrator's responsible to adjust this. cPanel can "recommend" that this value be set higher, but until the RFC changes the RFC value should be the default. (If you want to be mad at someone, be mad at Exim for blatantly ignoring this RFC for many, many years before finally adjusting their defaults to recognize the RFC imposed value.) 0 -
@Michael-Inet - can you update the value in WHM to the max and see if you still have issues? 0 -
cPanel is following the RFC. The RFC says the max line length should be 998 characters. Is this RFC stupid? Yes. But what authority to does cPanel have to go out and police the rest of the Internet and tell everyone this RFC is stupid? What if another control panel does this? What if another mail server system does this?
You"re missing the point. We PAY cPanel to maintain our servers in a state that makes them usable for all their clients. It matters not who made the change, and yes this is ultimately caused by Exim, it is cPanel"s responsibility (because we PAY them for it to be their responsibility!) to correct all upstream providers fubars.we have to depend on cPanel to provide "variables that can be changed"
Yes, cPanel has that responsibility as well, but that does not exempt them from the responsibility of leaving the user with a working system.but until the RFC changes the RFC value should be the default.
Absolutely not! cPanel"s duty to its customers is to test and verify that software changes do not adversely effect their customers. If an RFC value is "bad" then it is their duty and responsibility to correct the default to a real world usable value. # # # cPanel entirely dropped the ball on this. We pay them to both A) review up coming changes to the software installed on our systems and B) adjust those changes so that those changes will not negatively impact their clients. cPanel did not do their job. FFS allowing a mis-configuration through that completely trashes the functionality of almost every CMS and shopping cart system out there? That"s lasted over three months with no "official" fix from cPanel (see article link earlier). Why exactly are you defending that? Best Regards, Michael0 -
it is cPanel"s responsibility (because we PAY them for it to be their responsibility!) to correct all upstream providers fubars.
I'm going to disagree with this one. While there are times we have stepped in to create workarounds, you likely have also seen our "UP-####" cases, which indicates we've filed a case with the specific provider of the tool, whether that is Exim, CentOS, or wherever that needs to happen. The problem we run into is that if we customize every single thing from each provider, we have no guarantee if that is compatible with future updates. We'd literally have to spend all our time updating our custom updates to be compatible with future updates, so in fact more things would break. It's just not a sustainable practice. It's also important to note that everyone needs to follow the RFCs - not just cPanel. If not, the internet wouldn't function.0 -
@Michael-Inet - can you update the value in WHM to the max and see if you still have issues?
Hi Rex, Not to be an ass here, but please update an official cPanel document with the changes you"re requesting me to make. Please do include how to make the change(s) within the new Jupiter theme. Screenshots would be preferable. Thanks, Michael0 -
You"re missing the point. We PAY cPanel to maintain our servers in a state that makes them usable for all their clients.
This is a fundamental difference of opinion that you and I will have. I see cPanel as a product that a server administrator chooses to use on their servers. You see cPanel as an all-encompassing server administrator replacement. Perhaps the rest of the world agrees with you - I don't. Personally, if it were up to me, I'd tell cPanel to just give me the cPanel controlled parts (cPanel that runs on port 2083, WHM that runs on port 2087, Webmail (maybe?) that runs on port 2096). Everything else should ultimately be left up to the decision of the server administrator. cPanel can recommend that I use Apache, Exim, Dovecot, MariaDB, etc - and ship with pre/post event hook actions that adjust all of these configurations when an event happens in their cPanel, WHM, or Webmail. I'm also probably much older than most everyone else that uses cPanel and I can remember when knowledge and skill of solving your own server administration problems was important.0 -
@Michael-Inet - here's the screenshot, from v102 in Jupiter, under WHM >> Exim Configuration Manager: 0 -
@Michael-Inet - here's the screenshot, from v102 in Jupiter, under WHM >> Exim Configuration Manager: -04-07 at 2.45.17 PM.png">77197
Thank you. Yes, that allowed the mail to be sent.0 -
I'm going to disagree with this one. While there are times we have stepped in to create workarounds, you likely have also seen our "UP-####" cases, which indicates we've filed a case with the specific provider of the tool, whether that is Exim, CentOS, or wherever that needs to happen. The problem we run into is that if we customize every single thing from each provider, we have no guarantee if that is compatible with future updates. We'd literally have to spend all our time updating our custom updates to be compatible with future updates, so in fact more things would break. It's just not a sustainable practice. It's also important to note that everyone needs to follow the RFCs - not just cPanel. If not, the internet wouldn't function.
Yeah, that"s a corporate non-answer if I"ve ever seen one. [QUOTE] Michael wrote: it is cPanel"s responsibility (because we PAY them for it to be their responsibility!) to correct all upstream providers fubars.
Since I used the word "all" I guess I gave you that out. Lets not pick nits, you know what I mean. cPanel does customize things to make servers work like they should work. If you look at the screenshot you just sent me, cPanel has customized this issue itself by using a default value that is not the RFC value (snarky thought, unless whee! 998 = 2048). PS: And we both know that RFCs are not magically always correct. This issue itself invalidate your last sentence...This is a fundamental difference of opinion that you and I will have. I see cPanel as a product that a server administrator chooses to use on their servers. You see cPanel as an all-encompassing server administrator replacement. Perhaps the rest of the world agrees with you - I don't.
Hi Sparek, As you alluded to, cPanel is a cost/benefit analysis decision for most. I (you/consumers) have two basic choices; A) Hire someone, near full time, to handle all my servers. This leaves me with a single point of failure and only having the resources of one "brain." This also leaves the person I hire constantly looking for additional work and rarely/never being fully employed. B) Pay for a web hosting control panel system. This, arguable per Rex, should provide a vaster knowledge base (more "brains") that results in better solutions and significantly more functional servers. For the server admin themselves, they may make a lesser $/hr, but they are full time employed, so their total earnings per year are higher. Most consumers chose B) because the cost (US~100s to low 1,000s) is so significantly smaller than A) (US~10s of thousands).I'm also probably much older than most everyone else that uses cPanel and I can remember when knowledge and skill of solving your own server administration problems was important.
Based on your writings, we are not that different in age. Before you had to do it yourself because there wasn"t anyone to do it for you, so yes it was vitally important. There also wasn"t that much (total) demand for server administration/management, so there wasn"t any real profit to a firm like cPanel to exist. Besides which, if I never have to dig through the guts of a Solaris or BSD UNIX server again to fix something I"ll be extremely happy. # # # Have to go update a bunch of servers... Be well all, Michael Edit: PS: Rex, please!, get someone to update that article. It's one of the first search engine results.0 -
Has it not been updated? On it! 0 -
Well crap! Uhm, how do I update this for DNSONLY servers? Here's a Rewrite: Workaround The default message_linelength_limit was increased and an option to adjust this limit was added to the Exim Configuration Manager in cPanel version 102.0.2. To change this setting: Full WHM servers: Home / Service Configuration / Exim Configuration Manager The setting is called "Maximum line length for SMTP transports" For DNSONLY servers: {insert command line instructions needed}0 -
I confirmed I do have someone updating that article now. In general, DNSOnly shouldn't be sending any messages that would break the configured length limit. Messages leaving that server would be limited to notifications from the system itself. When the value is changed in the WHM interface we update /etc/exim.pl.local with the following value: our $O_DIRECTORY = 65536; Directly editing /etc/exim.pl.local isn't supported, but that is the only way I can see to make that change on a DNSOnly system. Can you get me more detail on why it would be necessary to make that change on a DNSOnly machine? If I can get a good use case, I can always make a case with our developers to get the functionality added. 0 -
When the value is changed in the WHM interface we update /etc/exim.pl.local with the following value: our $O_DIRECTORY = 65536;
It's not a value set in [font="courier new">/etc/exim.conf.localopts? You really need to be able to make every configuration change through a command-line process. Because logging into 50 different WHMs to make a change isn't feasible. But you can use something like Cluster SSH to log into 50 servers all at once and mirror the same command to all 50 servers.0
Please sign in to leave a comment.
Comments
172 comments