Voters 15
-
-
-
J
-
-
P
-
A
-
Z
- + 9 voters
-
-
-
H
-
R
-
J
-
J
-
-
Increase message_linelength_limit default
- Live
 |
Jarland Donnell |
In version 4.95, the exim developers added a new transport variable message_linelength_limit. This defaults to 998 as per an old RFC. This should be increased by the DirectAdmin team in their default exim.conf deployment, and I will explain why.
The addition of message_linelength_limit was not in response to the industry suddenly enforcing a 998 character per line limit. It was simply another point of control for admins. There is not some big push to suddenly conform to the old RFC. In fact, because the rest of the world is happily going on about it's business and not enforcing this limit at 998, it is unlikely that software developers will be rushing to pick up some new change sweeping across the industry (because it isn't).
If DirectAdmin does not define this in it's transports at a higher number, DA users will begin receiving support tickets from their customers, describing a problem that they will see as unique to their product (your product, DA). They will not accept the idea that they need to go ask Microsoft to update Outlook, or the Roundcube team to do the same, etc. Rather, they'll ask the provider to fix it or they'll move to a new provider that isn't enforcing this limit that no one else is.
The provider, running DirectAdmin, will be limited in options. They can:
1. Define their own transport in an include and set a higher limit there.
2. Edit exim.conf and then do it again every time DA updates exim.
3. Edit it in exim.conf and set exim.conf to immutable.
#1 is not reasonable if they are not using an external relay.
#2 requires new overhead to override DA's defaults on updates.
#3 will eventually one day lead to exim failures on their servers, when an update changes some syntax.
Some might pop up and say "just use a custom exim.conf with custombuild" but no, custombuild will not deploy a custom exim.conf like it will some others. It will ignore it. Even if it didn't, that would eventually find the same problem as mentioned in #3 above.
The only logical answer is that DA should simply define message_linelength_limit in their transports with a number that is unlikely to interfere with customer activity.
Activity Newest / Oldest
fln
Status changed to: Live
Richard G
IMHO normally I think DA should not add this by default as it's normal to obey the RFC's. And in spite of the fact that Exim adjusted this only after many years, it's still an RFC.
However due to incompatibility of many programs and clients, just because this was not implemented on time it should be configurable some way.
Edit: I changed my mind about this. Since Postfix is using a 2048 limit and Exchange even 8000, by default in DA Exim should have a higher limit than the RFC provides.
So change to better value by default, since otherwise due to this late change lots of applications and clients would run into issues, which would also might lead to too many customer support work for a lot of company's.
It's up to the MTA's to agree upon a standard limit in the RFC which is compatible now in modern times. So update the RFC to remove that 988 limit.