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

[cPRex]

@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?

 

[Just Retro]

@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?

 

[SoporteNTX]

For our part, we modify the value to the maximum allowed 65536 and continue with the problem.

 

[Paulus Cobris]

@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 Eduardo

 

[cPRex]

@Paulus Cobris - could you submit a ticket to our team so we can examine that system?

 

[JoseDieguez]

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.

 

[rhm.geerts]

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.

 

[Michael-Inet]

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: https://support.cpanel.net/hc/en-us...essage-has-lines-too-long-for-transport-Error
gives ZERO fixes. And even claims the issue is "fixed." And, surprise, surprise, the comments are closed so the user base can't even inform the next victim the article is bogus.

Reading 6 pages of forum pages to sift out some possible (who knows if it actually works) temporary fix on an issue known for at least 3 months seems a bit unprofessional for cPanel.

Where is an officially published by cPanel fix for this issue?

If there is none, say so, so I can open a ticket.

Regards,
Michael

Edit 01:

@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?

 

[sparek-3]

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.)

 

[cPRex]

@Michael-Inet - can you update the value in WHM to the max and see if you still have issues?

 

[Michael-Inet]

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,
Michael

 

[cPRex]

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.

 

[Michael-Inet]

@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,
Michael

 

[sparek-3]

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.

 

[cPRex]

@Michael-Inet - here's the screenshot, from v102 in Jupiter, under WHM >> Exim Configuration Manager:

 

[Michael-Inet]

@Michael-Inet - here's the screenshot, from v102 in Jupiter, under WHM >> Exim Configuration Manager:

View attachment 77197

Thank you.

Yes, that allowed the mail to be sent.

 

[Michael-Inet]

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.

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.

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

 

[cPRex]

Has it not been updated? On it!

 

[Michael-Inet]

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}

 

[cPRex]

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.