MailScanner v5.3.3
WHM v102.0.8 (STANDARD)
Exim v4.95
Hi, all, am having an intermittent issue with messages sent via an Azure client to external accounts.
The issue started after a recent WHM upgrade, but cPanel support is pointing to ConfigServer as possibly being the culprit.
The Azure client has an email account on the server, sending out messages on behalf of the domain with the email account (this gets around them having to spoof the "from" address).
Here's part of a line from Exim logs (sender and recipient removed for security):
2022-03-23 15:02:28.075 R=dkim_lookuphost T=dkim_remote_smtp: message has lines too long for transport DT=0.000s
cPanel suggested I temporarily disable MailScanner - which I did - but the problem persists, so it's obviously not on CSF's side.
Still, am curious: Is anyone else seeing this issue?
Please advise. Thanks!
Exim bouncing: "Message too long for transport"
Re: Exim bouncing: "Message too long for transport"
Heard back from cPanel - they had me bump up the maximum line length to 4096 from 2048 (their current default in Exim Config Manager).
Messages seem to be going out OK from the Azure provider now. (If only M$'s SMTP server had been RFC compliant to start with, this problem wouldn't have presented. Oh, well...)
Have also re-enabled MailScanner, and everything still seems to be good.
Hopefully cPanel will come up with a permanent fix and allow the max length to go back down (not sure what additional overhead - if any - results from leaving it that high).
Before opening a ticket with them, had found a cPanel article mentioning the problem:
https://support.cpanel.net/hc/en-us/art ... port-Error
and a followup:
https://support.cpanel.net/hc/en-us/art ... r-v102-0-2
but the former (from around 3 weeks ago) merely says that as of v102.0.2, the issue should be fixed, and the latter (from just today) says there's currently no workaround.
Wish they had pointed that setting out earlier, but at least things are working again.
Exim is big, so it can be difficult to keep track of every setting, but now knowing what to look for, a little more rooting through the inter-tubes brought up line 189 in
https://github.com/Exim/exim/blob/e3e28 ... rts/smtp.c
(from exim.org's github copy of the source) where the default seems to be quite a bit lower:
.message_linelength_limit = 998,
Messages seem to be going out OK from the Azure provider now. (If only M$'s SMTP server had been RFC compliant to start with, this problem wouldn't have presented. Oh, well...)
Have also re-enabled MailScanner, and everything still seems to be good.
Hopefully cPanel will come up with a permanent fix and allow the max length to go back down (not sure what additional overhead - if any - results from leaving it that high).
Before opening a ticket with them, had found a cPanel article mentioning the problem:
https://support.cpanel.net/hc/en-us/art ... port-Error
and a followup:
https://support.cpanel.net/hc/en-us/art ... r-v102-0-2
but the former (from around 3 weeks ago) merely says that as of v102.0.2, the issue should be fixed, and the latter (from just today) says there's currently no workaround.
Wish they had pointed that setting out earlier, but at least things are working again.
Exim is big, so it can be difficult to keep track of every setting, but now knowing what to look for, a little more rooting through the inter-tubes brought up line 189 in
https://github.com/Exim/exim/blob/e3e28 ... rts/smtp.c
(from exim.org's github copy of the source) where the default seems to be quite a bit lower:
.message_linelength_limit = 998,
-
- Junior Member
- Posts: 11
- Joined: 28 Sep 2011, 14:49
Re: Exim bouncing: "Message too long for transport"
ive repeatedly had to keep updating the setting on our servers in both exim.conf and exim_outgoing.conf to a really big value to get it to work. currently changing them to 20480000 ! ... yeah i know insane but not taking any risks....
for whatever reason after certain cpanel update events it resets them both back to 2048 which then causes the errors, cPanel supports solution was to tell me to disable MailScanner and MSFE! as they claimed that was the cause of the ongoing issue...
of course i didn't but is there a way to permanently fix this yet?
for whatever reason after certain cpanel update events it resets them both back to 2048 which then causes the errors, cPanel supports solution was to tell me to disable MailScanner and MSFE! as they claimed that was the cause of the ongoing issue...
of course i didn't but is there a way to permanently fix this yet?
Re: Exim bouncing: "Message too long for transport"
Reached out to cPanel and they say they only introduced a way to modify the setting in their Exim config manager about a month ago now, with v102.0.2 of WHM.
Prior to that one would have needed to manually edit /etc/exim.conf.
Going forward, any customer-set values in the config manager should be retained following cPanel updates.
The current default max SMTP line length values are: 998 for Exim (per section 2.1.1 of RFC 2822 ( https://www.rfc-editor.org/rfc/rfc2822 ), and 2048 for cPanel.
Following the update to WHM v102.0.2, with cPanel's default, messages were bouncing from certain MTA's. Having bumped it up to 4096, there fortunately haven't been any further issues.
Prior to that one would have needed to manually edit /etc/exim.conf.
Going forward, any customer-set values in the config manager should be retained following cPanel updates.
The current default max SMTP line length values are: 998 for Exim (per section 2.1.1 of RFC 2822 ( https://www.rfc-editor.org/rfc/rfc2822 ), and 2048 for cPanel.
Following the update to WHM v102.0.2, with cPanel's default, messages were bouncing from certain MTA's. Having bumped it up to 4096, there fortunately haven't been any further issues.
-
- Junior Member
- Posts: 11
- Joined: 28 Sep 2011, 14:49
Re: Exim bouncing: "Message too long for transport"
the issue im seeing however is that while the setting may hold in exim.conf its not being kept or updated in exim_outgoing.conf
Re: Exim bouncing: "Message too long for transport"
I don't believe this is a cPanel issue, as exim_outgoing.conf is used by MailScanner.
I also don't believe this is a MailScanner issue; more likely a problem with a sender's mail client.
(Try a recursive grep of "exim_outgoing.conf" in /var/cpanel and see what it shows you. Most results are calls to the log daemon. Pipe that into another grep excluding "log_rotation" and there are only a couple of entries.)
So far as the value
(You should also see the value in /etc/exim.conf.localopts, as cPanel stores customized values there and uses it to build the actual exim.conf.)
exim_outgoing.conf is a slightly modified copy of exim.conf used by MailScanner. Yes, there are a couple of minor differences between the two - such as exim.conf's router section deferring action to MailScanner; having the same commands in MailScanner's copy would just cause an endless loop) - but the smtp transport section should be identical, so your customized number should be the same in both files.
The relevant config line is "message_linelegth_limit", which should be shown in two sections of both exim.conf and exim_outgoing.conf:
FWIW, I do note that in the GUI, the tooltip for that setting indicates a range from 1 to 1,000,000, so if you're setting a value larger than the high end, it's possible cPanel is resetting your "out of bounds" number back to its default value of 2048. However, that still shouldn't cause it to be different between exim.conf and exim_outgoing.conf
In any event, besides the fact that cPanel doesn't seem to allow such a large value, setting the max line length to more than a million seems way more than you'd actually need. That would imply an attachment is being sent, and the sender's email client is not properly MIME-encoding the message, as lines longer than 76 characters are supposed to have "soft breaks" inserted.
See RFC 2045 ( https://www.ietf.org/rfc/rfc2045.txt ) for more info on encoding in general, and 6.7(5) for detail on quoted-printable encoding.
Good luck getting your issue sorted out!
I also don't believe this is a MailScanner issue; more likely a problem with a sender's mail client.
(Try a recursive grep of "exim_outgoing.conf" in /var/cpanel and see what it shows you. Most results are calls to the log daemon. Pipe that into another grep excluding "log_rotation" and there are only a couple of entries.)
So far as the value
I'd check WHM's Exim config manager GUI and verify your customized value is retained after saving changes.not being kept or updated in exim_outgoing.conf
(You should also see the value in /etc/exim.conf.localopts, as cPanel stores customized values there and uses it to build the actual exim.conf.)
exim_outgoing.conf is a slightly modified copy of exim.conf used by MailScanner. Yes, there are a couple of minor differences between the two - such as exim.conf's router section deferring action to MailScanner; having the same commands in MailScanner's copy would just cause an endless loop) - but the smtp transport section should be identical, so your customized number should be the same in both files.
The relevant config line is "message_linelegth_limit", which should be shown in two sections of both exim.conf and exim_outgoing.conf:
- remote_smtp
- dkim_remote_smtp
FWIW, I do note that in the GUI, the tooltip for that setting indicates a range from 1 to 1,000,000, so if you're setting a value larger than the high end, it's possible cPanel is resetting your "out of bounds" number back to its default value of 2048. However, that still shouldn't cause it to be different between exim.conf and exim_outgoing.conf
In any event, besides the fact that cPanel doesn't seem to allow such a large value, setting the max line length to more than a million seems way more than you'd actually need. That would imply an attachment is being sent, and the sender's email client is not properly MIME-encoding the message, as lines longer than 76 characters are supposed to have "soft breaks" inserted.
See RFC 2045 ( https://www.ietf.org/rfc/rfc2045.txt ) for more info on encoding in general, and 6.7(5) for detail on quoted-printable encoding.
Good luck getting your issue sorted out!