i just ran into an issue where forwarding a ticket fails with a " T=remote_smtp: message has lines too long for transport" other mail seems to work fine
the forwarded message is added to the ticket history but fails to send via exim4.
an internet search suggests its related to exim4.95 but since its only in forwarded tickets i’m wondering if there is an RT fix.
I think it’s just that the generated email is too large for your mail service. Can that max value be configured?
It looks like a default was changed in Exim 4.95 such that it now enforces the RFC line length limit.
RFC 5322 maximum line length:
new default message_linelength_limit = 998
Some clients just seem to be broken though, and violate this limit. I am not sure if this is caused by RT, or if RT is simply forwarding broken messages from other broken clients.
Probably the client (or RT) should have a mechanism to ensure line folding complies with the RFC.
Some others implement line folding in the MTA, but IMHO, modifying the body of messages in transit with the MTA introduces a whole new world of pain. (i.e., when messages are signed, multi-part MIME, encrypted, DKIM etc.). Getting the MTA to modify the message body introduces complexity and can cause more problems.
Exim’s philosophy since the very early days is to NEVER modify the message body, and it is not the job of the MTA to tamper with the message contents.
Before he retired, Exim’s original author Philip Hazel held workshops at Cambridge University during the late-1990s/early 2000s. I remember the question being asked if there was any plan for Exim to do things like insert those pointless legal disclaimers at the bottom of emails. “Absolutely not!” came the reply as he recoiled in horror! (Although if you really want to, you can write your own scripts etc. to do this, though it’s really quite complicated because of MIME, HTML etc.)
Probably the quickest fix for this is to tweak Exim’s settings for the remote_smtp: transport to set message_linelength_limit = 8000 or some such, then figure out what’s causing it.
I found a good tip here to add an ACL condition so you can log a warning when this happens and work out which client etc. is causing it. This goes in your acl_smtp_data section, usually called acl_check_data:
# Message line length exceeds maximum RFC 5322 value
warn
set acl_m_linelength_limit = 998
condition = ${if >{$max_received_linelength}{$acl_m_linelength_limit}}
logwrite = Warning: Message from <${sender_address}> to <${recipients}> exceeds RFC 5322 maximum line length ($max_received_linelength > $acl_m_linelength_limit)