[rt-users] Problems with ! in html format emails
Kevin Curtis
Kevin.Curtis at farsite.com
Wed Jun 4 11:53:37 EDT 2014
Hi,
In case anyone else comes across this same problem (and I can't see why we should be the only users affected, I am sure that other RT installations must be processing emails from MS Office Outlook clients!), I have solved the issue for out particular case.
If this is a real problem it would be nice to have the fix in a future release of RT, so should I report it as a bug?
In the end I incorporated the solution into RescueOutlook as follows:
sub RescueOutlook {
my $self = shift;
my $mime = $self->Entity();
return unless $mime && $self->LooksLikeMSEmail($mime);
my $text_part;
my $html_part;
my $retval = 0;
my $tmp = $mime->head->get('Content-Type');
$RT::Logger->debug("Header content type $tmp");
if ( $mime->head->get('Content-Type') =~ m{multipart/related} ) {
$RT::Logger->debug("processing multipart/related");
my $first = $mime->parts(0);
$tmp = $first->head->get('Content-Type');
$RT::Logger->debug($tmp);
if ( $first->head->get('Content-Type') =~ m{multipart/alternative} )
{
$RT::Logger->debug("processing related/alternative");
my $inner_first = $first->parts(0);
if ( $inner_first->head->get('Content-Type') =~ m{text/plain} )
{
$RT::Logger->debug("releated/alternative/plain");
$text_part = $inner_first;
}
$inner_first = $first->parts(1);
if ( $inner_first->head->get('Content-Type') =~ m{text/html} )
{
$RT::Logger->debug("releated/alternative/html");
$html_part = $inner_first;
}
}
}
elsif ( $mime->head->get('Content-Type') =~ m{multipart/mixed} ) {
$RT::Logger->debug("processing multipart/mixed");
my $first = $mime->parts(0);
if ( $first->head->get('Content-Type') =~ m{multipart/alternative} )
{
$RT::Logger->debug("processing multipart/alternative");
my $inner_first = $first->parts(0);
if ( $inner_first->head->get('Content-Type') =~ m{text/plain} )
{
$RT::Logger->debug("mixex/alternative/plain");
$text_part = $inner_first;
}
$inner_first = $first->parts(1);
if ( $inner_first->head->get('Content-Type') =~ m{text/html} )
{
$RT::Logger->debug("multipart/alternative/html");
$html_part = $inner_first;
}
}
}
elsif ( $mime->head->get('Content-Type') =~ m{multipart/alternative} ) {
my $first = $mime->parts(0);
if ( $first->head->get('Content-Type') =~ m{text/plain} ) {
$RT::Logger->debug("alternative/plain");
$text_part = $first;
}
$first = $mime->parts(1);
if ( $first->head->get('Content-Type') =~ m{text/html} )
{
$RT::Logger->debug("alternative/html");
$html_part = $first;
}
}
# Add base64 since we've seen examples of double newlines with
# this type too. Need an example of a multi-part base64 to
# handle that permutation if it exists.
elsif ( $mime->head->get('Content-Transfer-Encoding') =~ m{base64} ) {
$text_part = $mime; # Assuming single part, already decoded.
}
if ($text_part) {
# use the unencoded string
my $content = $text_part->bodyhandle->as_string;
if ( $content =~ s/\n\n/\n/g ) {
# Outlook puts a space on extra newlines, remove it
$content =~ s/\ +$//mg;
# only write only if we did change the content
if ( my $io = $text_part->open("w") ) {
$io->print($content);
$io->close;
$RT::Logger->debug(
"Removed extra newlines from MS Outlook message.");
$retval = 1;
}
else {
$RT::Logger->error("Can't write to body to fix newlines");
}
}
}
else
{
$RT::Logger->debug("No text_part to fix newlines");
}
if ($html_part) {
# use the unencoded string
my $html_content = $html_part->bodyhandle->as_string;
if ( $html_content =~ s/<o:p>/<o:p>\n/g ) {
# only write only if we did change the content
if ( my $io = $html_part->open("w") ) {
$io->print($html_content);
$io->close;
$RT::Logger->debug(
"Added linebreaks to Outlook message.");
$retval = 1;
}
else {
$RT::Logger->error("Can't write to html body to add linebreaks");
}
}
}
else
{
$RT::Logger->debug("No html_part to add line breaks");
}
return $retval;
}
Regards
Kevin
From: rt-users [mailto:rt-users-bounces at lists.bestpractical.com] On Behalf Of Kevin Curtis
Sent: 30 May 2014 17:18
To: rt-users at lists.bestpractical.com
Subject: Re: [rt-users] Problems with ! in html format emails
Hi,
I am sorry I just noticed that this question didn't have a proper Subject, which I have now added.
Regards
Kevin Curtis
FarSite Communications
From: rt-users [mailto:rt-users-bounces at lists.bestpractical.com] On Behalf Of Kevin Curtis
Sent: 29 May 2014 15:05
To: rt-users at lists.bestpractical.com<mailto:rt-users at lists.bestpractical.com>
Subject: [rt-users] (no subject)
Hi,
I have searched hard for the answer to this one, but haven't seen it yet, maybe someone can point me in the right direction.
We have RT version 4.2.1 installed on Ubuntu 12.04. The main mailbox is on a Windows Exchange server, and we use fetchmail to get the mail every minute or so. Mail sent by RT goes through sendmail.
We use RT as a Ticket handling tool for customer problems. Our inhouse support staff use Office Outlook version 12. The email client composes html formatted email.
The problem that I have spent the last week trying to solve is that the emails sent out have an exclamation marks "!" inserted into them at various places.
Now I have tracked down that the sendmail tool is doing this because some of the lines are longer than the maximum line length supported by SMTP (990 characters).
And I have also tracked down that the Office Outlook email client is creating the long lines when html is chosen as the message format. (It doesn't appear to be a problem with rtf or plain text).
I know the problem isn't in RT itself, but our configuration must so typical of many RT installations that I can't believe that we are the first to see this problem, and that there isn't a solution already out there somewhere. If someone knows what it is then I'd be pleased to hear it.
I am not an expert in any of the component parts (fetchmail, sendmail or RT), but it seemed to me the best place to try and solve the issue was in the fetchmail/mailgate interface. So I have added a new method to EmailParser.pm.
I have used the RescueOutlook method as a template and I have tried to break lines (using the perl Text::Wrap) but this doesn't seem to be doing the job. It looks like what I really need to do is process just the text/html section of the email and be a bit more intelligent about where the line breaks are placed. At the moment it's just if the line is greater than 132 characters.
It's been quite a steep learning curve this week! And it looks like it will take me a long time to get this fixed using the method I have chosen. I hope that there is already a fix.
Thanks in Advance
Kevin Curtis
Farsite Communications.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20140604/7c2fd4c6/attachment.htm>
More information about the rt-users
mailing list