[rt-users] Problems with ! in html format emails
Hubbard, Jason
Jason.Hubbard at circles.com
Wed Jun 4 14:38:09 EDT 2014
Hi Kevin, it sounds like you have an issue with your Outlook client
configuration, maybe a standard signature your company uses or some
configuration pushed by GP or your build is causing it. We use Outlook
as our mail client and HTML is our standard format. We have never seen
any issues like this.
From: rt-users [mailto:rt-users-bounces at lists.bestpractical.com] On
Behalf Of Kevin Curtis
Sent: Wednesday, June 04, 2014 11:54 AM
To: rt-users at lists.bestpractical.com
Subject: Re: [rt-users] Problems with ! in html format emails
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
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.
------------------------------------------------------------------------------This message contains information that may be confidential and proprietary. Unless you are the intended recipient (or authorized to receive this message for the intended recipient), you may not use, copy, disseminate or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply e-mail, and delete the message immediately.
==============================================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20140604/7e2934c2/attachment.htm>
More information about the rt-users
mailing list