we have a recurrent problem where by emails sent from RT are bounced by some remote mail servers due to: Maximum line length exceeded (see RFC 5322 2.1.1).
I believe its the formatting becoming mangled when there are many emails in the message trail. Other than asking users not to include previous message bodies in their replies (not viable, people won’t reliably do this, we have tried) is there any other solution to avoid this issue? If not a fix to RT then possibly a custom Scrip?
Are the users using the RT web UI? If so maybe the easiest approach would be to add some custom JS that counts characters when on the update page and alerts them that their message is too large.
You could also try to write some code that automatically truncates the outgoing message at some size but I am not quite sure where that would go. You may potentially be able to change the default on transaction RT::Scrip template that uses:
{$Transaction->Content()}
And instead do some kind of size testing and truncating on the message if it is large.
Or if you’re using something like Postfix, does setting message_size_limit to a small value result in any warnings in the RT UI when an email is too large?
For the scrip something like this could work and you could add some smarts to remove quoting instead of just taking the first X characters. It isn’t perfect though since the user sending the email won’t know this truncation is happening:
RT-Attach-Message: yes
Content-Type: text/html
{
my $content =$Transaction->Content( Type => "text/html");
my $size_of_content = length( $content );
if ( $size_of_content > 20 ) {
$content = substr $content, 0, 20;
}
else {
$OUT = $content;
}
}
I have had this problem with my own outbound mail server rejecting long lines. I increased the limit, and I haven’t had any remote servers reject our messages.
I think RT should MIME+base64 encode any messages with long lines to solve this.
hello both, thanks for your replies.
In my case the issue occurs when sending emails to RT, not when using the web interface.
The option of truncating the transaction content is a possibility but, as you say knation, not ideal as its doing this silently without letting the user know. So that is a bit of a dirty fix.
I think you are being confused by my comment “the issue occurs when sending emails to RT”, this is in reply to the question “Are the users using the RT web UI?”. The answer is, no we are updating tickets via email not via the web UI, and it is when updating these tickets that RT generates emails that violate this line length RFC and are then bounced by the recipient. Its a massive problem if there is no proper solution.
Or to put it another way, I am not complaining about incoming emails violating any RFCs, as this wouldn’t be RTs fault,
OK, so I’m taking it from this that the emails from your users’ MUAs are coming in with really long lines, which RT is effectively reflecting out to remote remote mail servers when scrips send email to remote requestors, Ccs, etc? Do you know if these emails with long lines are mostly due to quoting, and if so how deep are they being quoted?
The reason for asking is I’m wondering if something fancy could be done with cutting out very deep quotes without just truncating a whole transaction’s email message. However if its just long line length coming in from MUAs with (say) less than 5 or 10 levels of quoting, that probably wouldn’t be much use.
no, I don´t understand that way, as I mentioned in my first post I suspect that RT is mangeling the formatting when recieving very long emails (but not emails that break any line length RFC). That is, the formatting is fine in the inbound emails, RT mangels the format and then sends out non RFC compliant emails. I assume this because, 1) we don’t have any issues with long lines when sending emails normally (not via RT) 2) there is no reason for there to be long lines in the RT messages, that is even if a mail is very long, at no point is there anything else that would normally create/add very long lines. RT on the other hand uses perl libraries for handling mail formatting AFAIU, so I suspect that RT is the culprit althought actually if Im being honest I haven’t double checked this which I could do by saving a copy of inbound mails before RT processes them and checking for long line issues,
This is my assessment also. We never have any problems with emails sent directly by users, only by RT. To be honest I am not sure if the problem emails are sent from RT via email or from the web interface.
I think this got a bit sidetracked. The problem here is not that a message is “too long”. It’s that a line is over 1000 characters! (998 characters + CRLF)
Such lines should be split/line-folded. That may even be done for you by the MTA near your RT install.
I find it hard that the original email had lines so long (or near enough to the limit to get pushed after that). The offending lines should be easy to find in the output transaction, though (an unfolded DKIM signature, perhaps?).
Sometimes, there is a preprocessing step (e.g. at a procmail recipe) before handing the mails to RT. Is it possible that you are unfolding the email lines, there? That would explain the long lines that later cause your trouble.
Erm, I think we have just been talking about line lenght, which part is sidetracked?The MTA should not be modifying the lines AFAIU, and as already mentioned emails not passing through RT have no issues. I believe the issue is created by RT, ie RT is creating message bodies and not spliting long lines. AFAIU the MTA will not normally modify/split lines, can you point me to any info on this?
Sorry to resurrect this old topic but this is causing us problems now.
The issue seems to be that certain mailers generate very long lines of HTML and hide it from the MTA using Base64 encoding. RT will decode the Base64 and then use the unencoded version in the emails it sends out which causes the mails to be rejected.
Is there any way to persuade RT to encode outgoing messages that have very long lines - preferably as quoted-printable but base64 at a push?