Exim 4.95

[Richard G]

It doesn't make sense at all to have standards ore even RULES LAWS whatever if not all related and stakeholders are compliant,

Correct, that is what I stated too. Except for this specific case, because it's so old and maybe except some smaller applications, all bigger MTA's (Exchanges, Postfix, Gmail) are not confirming to this RFC.
If Exim things they should suddenly apply this rule after so many years, they should have thought of this and first have contacted the others so the RFC can be updated to a new standard.

Now it's on our backs and indeed it shouldn't. But we have to deal with it, unless Exim will change their mind again. However... will that be the case? And if yes, how long will that take. Most people here need a solution now.

 

[sparek]

I'm wondering if these limitations are really relevant today? Which kind of application/device today is unable to handle more than 998 characters.

I think the real problem is not Exim but the legacy rfc5322 rule (from 2008), which needs to be updated or removed.

That's kind of the issue here.

The IETF and the ones responsible for the RFCs don't really react quickly to changing things up. And they're mostly unaware of the real world applications of the rules they set out.

But, not to put all the blame on IETF and the RFC writers, most things on the Internet are governed by a system that doesn't actually use the systems they govern. It's the left hand not knowing what the right hand is doing.

 

[sparek]

Now it's on our backs and indeed it shouldn't. But we have to deal with it, unless Exim will change their mind again. However... will that be the case? And if yes, how long will that take. Most people here need a solution now.

Not really pointing the finger at DirectAdmin or any of the other control panels - because they do what they have to do - but this is kind of the problem with using control panel maintained packages like this.

The answer to all of this is to modify your Exim transports and add your own message_linelength_limit value.

But when you're using a control panel or something else that maintains Exim, it's not that simple. Upgrades to Exim and exim_conf are going to overwrite this. Because there's a lot of administrators out there that don't understand how to configure all of this for themselves and have to depend on the control panel to provide this configuration.

That's why there are so many include files in the exim.conf - because the control panel has to weigh giving administrators a proper configuration versus allowing those administrators to customize the configuration as they would want.

In terms of DirectAdmin - the answer would be to either put additional include statements in each of the transports to allow administrators to add configuration options to the transports, or make the transports section completely an include file (does the default transports configurations ever change or require an update?). Or just explicitly add a message_linelength_limit to the transports and allow administrators to create a post exim_conf update hook in which they can modify the message_linelength_limit directive.

It sucks that you have to depend on DirectAdmin (or any other control panel) to offer this level of customization. But such is the burden of having to depend on control panel system to maintain these packages.

 

[Richard G]

but this is kind of the problem with using control panel maintained packages like this.

That I don't understand. I don't see any difference if you upgrade yourself to Exim 4.95 or a control panel is doing it for you.
You run into the same issue and have to fix it.

The answer to all of this is to modify your Exim transports and add your own message_linelength_limit value.

Would be an answer if every MTA and mail client would comply to the RFC. Which is not the case.
As this is a nice notice to the customers, there is still the issue that all kinds of other things, amongst which are CSF/LFD messages are having messages too long and also other MTA's and email clients don't respect this limit.
So the only answer is the option to adjust the limit setting itself or at least have an option to do that.

Because there's a lot of administrators out there that don't understand how to configure all of this for themselves and have to depend on the control panel to provide this configuration.

Which is why I always state that admins should be admins and not click and play wannabe's, we got enough of those. And the customers will see that too on a certain point and choose decent hosting company's with admins with knowledge or starting admins which are eager to learn.
I will be very blunt about this but for the rest I don't care. You don't get to call yourself an admin if you don't even at the very least know how to fix the easiest things via SSH, panel or no panel. Some are even scared to login via SSH. Come on, then you're a hobbyist, not an admin worth of a lot of customers imho. Sorry.
Panels are out there to make live easier for admins, not to do take over the job for them. In spite of the fact that CP is doing that more or less, but you pay for that.... and learn nothing. If something goes really wrong, you have to wait until they have time for you. Good luck.

But such is the burden of having to depend on control panel system to maintain these packages.

You can also do it yourself, without control panel. But it will be a lot more work to maintain your server and keep it updates, create packages etc. etc. etc.
There is an easy workaround to downgrade to Exim 4.94.2. But if you want to use 4.94 and not have this long line issue for the customers, indeed you have to wait until the used control panel (whatever one) is coming with some include statement.
However it's also possible to temporarily create one yourself. There ware already some solutions mentioned. It's also possible to for the time being, after making that change to chattr the exim.conf so you're not all that dependend from the control panel.
At least nog here at DA imho.

 

[sparek]

but this is kind of the problem with using control panel maintained packages like this.

That I don't understand. I don't see any difference if you upgrade yourself to Exim 4.95 or a control panel is doing it for you.
You run into the same issue and have to fix it.

We're going to get off-topic if we're not careful here.

I simply mean that if every server administrator was an actual server administrator - then there would be no reason at all for all of the includes in the exim.conf file. An administrator would just write their own straight exim.conf. And at that point the fix for this is simple: just add message_linelength_limit directive to your transports.

If a server administrator is maintaining their own Exim, then they have a bit more freedom to write their exim.conf file any way they see fit.

Now, I'm not really complaining about DirectAdmin managing the Exim package - they add a lot of stuff and a lot of configuration that I probably wouldn't have thought of. And some of those configuration settings may need to be changed from time to time and it's nice to depend on them to update them as necessary.

But because DirectAdmin has their hands in the exim configuration, they have to play both sides: Provide an exim.conf configuration file that works for most AND the ability to heavily customize Exim.

This is why we can't make direct edits to the exim.conf file (not with out immuting the file and that's a dangerous proposition). If we could make direct edits to the exim.conf then this particular issue is a very, very easy fix ... add a message_linelength_limit to the transports as we each see fit. But as it stands we can't do that because when we do and exim_conf is updated those changes are lost.

Don't misunderstand me. I'm not saying what DirectAdmin is doing is wrong. The ... *ahem* ... other popular control panel ... does the same thing (albeit a little differently). I'm not upset that DirectAdmin is controlling the exim.conf like this. This was not meant to be a complaint of any degree. Just stating a fact.

In order for us to maintain an exim.conf with our desired message_linelength_limit - one that won't get overwritten when we upgrade exim or exim_conf through custombuild, then DirectAdmin will have to allow for or create a way for us to customize this - either through an additional include file in each of the transports, or explicitly setting the message_linelength_limit in the transports so we can use a post exim_conf update hook to update it to our desired limit. We're at the mercy of DirectAdmin for this. (and we'll be at the mercy of the other control panel when they do this update).

 

[sparek]

I suppose you could accomplish this by adding a post exim_conf hook:

mkdir -p /usr/local/directadmin/custombuild/custom/hooks/exim_conf/post
touch /usr/local/directadmin/custombuild/custom/hooks/exim_conf/post/fix_message_linelength_limit.sh
chmod 700 /usr/local/directadmin/custombuild/custom/hooks/exim_conf/post/fix_message_linelength_limit.sh

Then edit the /usr/local/directadmin/custombuild/custom/hooks/exim_conf/post/fix_message_linelength_limit.sh file and add:

#!/bin/bash sed -i -r -e '/remote_smtp:/,/helo_data = .*/ s/(helo_data = .*)/\1\n message_linelength_limit = 4096/g' /etc/exim.conf sed -i -r -e '/remote_smtp_forward_transport:/,/helo_data = .*/ s/(helo_data = .*)/\1\n message_linelength_limit = 4096/g' /etc/exim.conf systemctl reload exim

This would essentially add a message_linelength_limit = 4096 after the helo_data line in the remote_smtp and remote_smtp_forward_transport transports.

(Change 4096 to whatever you desire for your message_linelength_limit)

(This would be easier if a message_linelength_limit = 998 were already present in the remote_smtp and remote_smtp_forward_transport transports - it would be an easier sed line command)

 

[Richard G]

But because DirectAdmin has their hands in the exim configuration, they have to play both sides: Provide an exim.conf configuration file that works for most AND the ability to heavily customize Exim.

I see more clearly now what you mean. But they can't help it either if Exim suddenly decides to implement an RFC option they didn't use for many years, or am I mistaken?
I think they were just as surprised as us to see this happening on 4.95.

DirectAdmin will have to allow for or create a way for us to customize this

Correct. That is true.
But that is why I was wondering if it was possible to do this in the exim.variables.conf.custom or exim.strings.conf.custom or if they needed to create a new custom file option for this.

 

[Nickske00]

Looks like work on this was done back in 2020

smtp transport: message_linelength_limit option. Bug 1684 · Exim/exim@0de9945

Exim Mail Transport Agent - source, testsuite and documentation - smtp transport: message_linelength_limit option. Bug 1684 · Exim/exim@0de9945

github.com

They point to bug 1684 ( https://bugs.exim.org/show_bug.cgi?id=1684 )

I see one bug reported, but no answer yet

Bug 2827 – bounce generated by exim gets too long lines breaching message_linelength_limit limit

bugs.exim.org

 

[ikkeben]

ON/OFFtopic:
FOUR the BIG FOUR or so email service providers. yes no folow RFC and own policies because of POWER BIG

They are most worse in not protecting SCAM abuse done from those accounts using that services as you can see only one example here:

Gmail accounts are used in 91% of all baiting email attacks

Bait attacks are on the rise, and it appears that actors who distribute this special kind of phishing emails prefer to use Gmail accounts to conduct their attacks.

www.bleepingcomputer.com

So why they block or get smaller EMAIL .. in spam , where there own services are doing the worst of all and not highly reputable , but in practic very very low reputable

 

[cjd]

Hopefully DA implement either an include or an option in custombuild for this line length issue. Been going though my logs and it's only been a small number of messages running into this, but I have had some system messages from LFD being blocked also. Sooner or later this is going to become a problem without a proper solution of being able to adjust it.

 

[sysdev]

Hopefully DA implement either an include or an option in custombuild for this line length issue. Been going though my logs and it's only been a small number of messages running into this, but I have had some system messages from LFD being blocked also. Sooner or later this is going to become a problem without a proper solution of being able to adjust it.

Yups, I've seen it on LFD too.

 

[hostfast]

Hello,

When compiling exim version 4.95 on Centos8 with DMARC enabled, I get errors:

dmarc.c: In function 'dmarc_process':
dmarc.c:464:13: warning: passing argument 3 of 'opendmarc_policy_store_dkim' makes pointer from integer without a cast [-Wint-conversion]
dkim_result, US"");
^~~~~~~~~~~
In file included from dmarc.h:14,
from exim.h:555,
from dmarc.c:14:
/usr/include/opendmarc/dmarc.h:125:94: note: expected 'u_char *' {aka 'unsigned char *'} but argument is of type 'int'
OPENDMARC_STATUS_T opendmarc_policy_store_dkim(DMARC_POLICY_T *pctx, u_char *domain, u_char *selector, int result, u_char *human_result);
~~~~~~~~^~~~~~~~
In file included from local_scan.h:31,
from exim.h:531,
from dmarc.c:14:
mytypes.h:84:14: warning: passing argument 4 of 'opendmarc_policy_store_dkim' makes integer from pointer without a cast [-Wint-conversion]
#define US (unsigned char *)
dmarc.c:464:26: note: in expansion of macro 'US'
dkim_result, US"");
^~
In file included from dmarc.h:14,
from exim.h:555,
from dmarc.c:14:
/usr/include/opendmarc/dmarc.h:125:108: note: expected 'int' but argument is of type 'unsigned char *'
OPENDMARC_STATUS_T opendmarc_policy_store_dkim(DMARC_POLICY_T *pctx, u_char *domain, u_char *selector, int result, u_char *human_result);
~~~~^~~~~~
dmarc.c:463:20: error: too few arguments to function 'opendmarc_policy_store_dkim'
libdm_status = opendmarc_policy_store_dkim(dmarc_pctx, US sig->domain,
^~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from dmarc.h:14,
from exim.h:555,
from dmarc.c:14:
/usr/include/opendmarc/dmarc.h:125:20: note: declared here
OPENDMARC_STATUS_T opendmarc_policy_store_dkim(DMARC_POLICY_T *pctx, u_char *domain, u_char *selector, int result, u_char *human_result);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
make[1]: *** [Makefile:805: dmarc.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/usr/local/directadmin/custombuild/exim-4.95/build-Linux-x86_64'
make: *** [Makefile:35: all] Error 2


My Makefile:

USE_OPENSSL=yes
SUPPORT_SPF=yes
CFLAGS += -DSPF -I/usr/local/include
LDFLAGS += -lspf2
CFLAGS += -O2 -march=native -mtune=generic -m64 -pipe -fstack-protector --param ssp-buffer-size=4
EXPERIMENTAL_SRS_ALT=yes
EXPERIMENTAL_SRS=yes
LDFLAGS += -lsrs_alt
SUPPORT_DMARC=yes
LDFLAGS += -lopendmarc

 

[sirwiz]

After update to 4.95 SMTP stop working, from log I got:
failed to open /etc/virtual/whitelist_hosts_ip when checking "/etc/virtual/whitelist_hosts_ip": Permission denied (euid=8 egid=12)
And also few other files.
Sure, I fix it, now it working but strange is that until update it works without any problems.
(to fix it just go to /etc/virtual, and chown mail:mail nesesery files)

 

[TestUser]

So... how can i fix this persistent problem "message has lines too long for transport" ?

 

[Richard G]

how can i fix this

?? Too lazy to read the thread?
Either temp change exim.conf or revert to 4.94.2 or use another solution mentioned in the thread.

 

[TestUser]

Workaround: downgrading to Exim 4.94.2:

echo "exim:4.94.2:" >> /usr/local/directadmin/custombuild/custom_versions.txt
/usr/local/directadmin/custombuild/build update
/usr/local/directadmin/custombuild/build exim

This actually worked for me!

 

[Yoshua]

"message has lines too long for transport"

And 19 days after this problem was reported and several pages of discussion in this thread, here we still have no solution or response from DirectAdmin.

For this service and support did they raise the prices of the licenses?

?

 

[mxroute]

And 19 days after this problem was reported and several pages of discussion in this thread, here we still have no solution or response from DirectAdmin.

For this service and support did they raise the prices of the licenses?

?

They've responded to the issue in tickets. They believe that this is an old standard that should be enforced. I've explained why I disagree, and they disagree with my disagreement.

 

[sparek]

They've responded to the issue in tickets. They believe that this is an old standard that should be enforced. I've explained why I disagree, and they disagree with my disagreement.

Ah! Many thanks for this.

I'll probably try to go ahead and deploy my post exim_conf hook to better resolve this.

I was kind of waiting around thinking (hoping) that DirectAdmin would provide some guidance on this (i.e explicitly adding a message_linelength_limit to the transports) so that this could be more easily fixed.

But seeing as how that doesn't appear to be the case, I'll forge ahead with my own "fix".

Can't wait for this to all hit the fan when the other control panel upgrades to Exim 4.95.

 

[Richard G]

For this service and support did they raise the prices of the licenses?

As a fact....No they didn't raise the prices.
They are obligated to help and report in tickets, which has priority. The forum is (as with others) mostly not a place for priority support.

@mxroute I can understand their point of view. It's an RFC and it's up to exim to fix this. Creating a workaround by DA would be nice, but it's not a task of a panel to break RFC's.
However, they would be showing a nice service, if they would allow us to create a custom message_line_length somewhere.

Can't wait for this to all hit the fan when the other control panel upgrades to Exim 4.95.

As am I... checked several times at CP but that isn't at 4.95 yet.... I'm very curious what they will do...