Re: [rt-users] HTML email with inline images.

[Kevin Curtis]

Hi Derek,
We had a similar problem as well, and we submitted a simple change to 
Transaction.pm that solved the problem for us.

See In Line Images in Emails.
The change was submitted on 2nd June 2014


Regards

Kevin

From: rt-users [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of 
Derek keith
Sent: 16 July 2014 12:16
To: rt-users@lists.bestpractical.com
Subject: [rt-users] HTML email with inline images.

Hello List
Have just installed a clean RT4.2.5 system running on centos.
I'm testing at the moment and have run into issues with HTML formatted email.
Scenario1
I'm using fetchmail to pull email form google via imap
Google appears to be creating a plain text version of all html formatted email.
when the email reaches the ticket in RT the plain text email is listed but not 
displays anything and the HTML formatted email is displayed correctly. then the 
inline images are listed below as in screenshot. 
http://static.bestpractical.com/blog/whats-new-in-4.2/ticket-history-inline-image.png
 OK
Problem1
The Autoreply in HTML is replying with only the first plaintext part of the 
email inside pre html tags.ithttp://tags.it completely ignores the html 
part.
Think this may be what 
http://lists.bestpractical.com/pipermail/rt-users/2014-June/083637.html may be 
experiencing.

Scenario 2
I'm using fetchmail to pull email form exchange via imap
when the email reaches the ticket in RT the HTML formatted email is displayed 
correctly. Then the inline images are listed.  Good
Problem2
The Autoreply in HTML is replying, however the inline images have not been 
added to the email so are displayed as empty boxes with red crosses. :(
Have I missed something?
This at the moment is a bit of a show stopper as our customer user base mostly 
use html formatted emails from outlook clients.
Improvements.
It would be nice if there was an option for inline pictures not to be listed as 
attachments. only list files that have been attached such as pdf's 
spreadsheets, photos, documents etc. similar to how outlook works at present.
Hopefully someone can help with pointer in the right direction.
Derek
-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training

Re: [rt-users] HTML email with inline images.

[Kevin Curtis]

Hi Derek,
Just tried a quick test, and now I see that in the first response from RT 
the images seem to get mislaid, but in all subsequent correspondence, any 
further images added are ok.

I guess I didn’t notice this here because we manage the creation of tickets on 
behalf of the customer, and then after that everything is ok.

If you come up with the answer we would be interested in implementing it here.

Another annoying features was the placement of “!” characters in the emails, 
which we also solved with another update that we submitted, see

Problems with ! in html format emails   dated  June 5th.

Regards

Kevin

From: rt-users [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of 
Derek keith
Sent: 16 July 2014 15:22
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] HTML email with inline images.

Thanks Kevin

That appears to have fixed Problem1.
Now just need to get inline pictures to show on the email.
derek


On 16 July 2014 12:24, Kevin Curtis 
kevin.cur...@farsite.commailto:kevin.cur...@farsite.com wrote:
Hi Derek,
We had a similar problem as well, and we submitted a simple change to 
Transaction.pm that solved the problem for us.

See In Line Images in Emails.
The change was submitted on 2nd June 2014


Regards

Kevin

From: rt-users 
[mailto:rt-users-boun...@lists.bestpractical.commailto:rt-users-boun...@lists.bestpractical.com]
 On Behalf Of Derek keith
Sent: 16 July 2014 12:16
To: rt-users@lists.bestpractical.commailto:rt-users@lists.bestpractical.com
Subject: [rt-users] HTML email with inline images.

Hello List
Have just installed a clean RT4.2.5 system running on centos.
I'm testing at the moment and have run into issues with HTML formatted email.
Scenario1
I'm using fetchmail to pull email form google via imap
Google appears to be creating a plain text version of all html formatted email.
when the email reaches the ticket in RT the plain text email is listed but not 
displays anything and the HTML formatted email is displayed correctly. then the 
inline images are listed below as in screenshot. 
http://static.bestpractical.com/blog/whats-new-in-4.2/ticket-history-inline-image.png
 OK
Problem1
The Autoreply in HTML is replying with only the first plaintext part of the 
email inside pre html tags.ithttp://tags.it completely ignores the html 
part.
Think this may be what 
http://lists.bestpractical.com/pipermail/rt-users/2014-June/083637.html may be 
experiencing.

Scenario 2
I'm using fetchmail to pull email form exchange via imap
when the email reaches the ticket in RT the HTML formatted email is displayed 
correctly. Then the inline images are listed.  Good
Problem2
The Autoreply in HTML is replying, however the inline images have not been 
added to the email so are displayed as empty boxes with red crosses. :(
Have I missed something?
This at the moment is a bit of a show stopper as our customer user base mostly 
use html formatted emails from outlook clients.
Improvements.
It would be nice if there was an option for inline pictures not to be listed as 
attachments. only list files that have been attached such as pdf's 
spreadsheets, photos, documents etc. similar to how outlook works at present.
Hopefully someone can help with pointer in the right direction.
Derek

-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training

Re: [rt-users] Problems with ! in html format emails

[Kevin Curtis]

Hi Jason,
Thanks for the response.  The ! characters are being inserted (with a 
space as well) by sendmail.  Is that the MTA that you are using?

I kind of agree that that it could be a configuration issue somewhere, but the 
where is difficult to track down.  Everything looks ok.

We have two other problems that I haven't seen any reference to either in the 
mailing list:

1)  Inline images not displayed in emails sent out by rt, because they had 
been converted to text

2)  Not being able to make an attachment when replying to correspondence 
through the GUI

All of these things are pretty noticeable, so it must be something unique with 
our installation.

It has been quite a frustrating few weeks.


Regards

Kevin

From: Hubbard, Jason [mailto:jason.hubb...@circles.com]
Sent: 04 June 2014 19:38
To: Kevin Curtis; rt-users@lists.bestpractical.com
Subject: RE: [rt-users] Problems with ! in html format emails

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-boun...@lists.bestpractical.com] On Behalf Of 
Kevin Curtis
Sent: Wednesday, June 04, 2014 11:54 AM
To: rt-users@lists.bestpractical.commailto:rt-users@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

Re: [rt-users] Problems with ! in html format emails

[Kevin Curtis]

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-boun...@lists.bestpractical.com] On Behalf Of 
Kevin Curtis
Sent: 30 May 2014 17:18
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Problems with ! in html

Re: [rt-users] In Line Images in Emails

[Kevin Curtis]

Hi Emmanuel,

Thanks for your reply.



The test case for us was quite simple.  We use Miscrosoft Office Outlook as the 
email client.

1) Create a ticket

2) The Ticket owner updates the ticket by sending an email to RT that has

   an inline image

3) RT sends an email to the Requestor and CC's that has been converted to 
plain text





We believe that the plain text conversion was taking place in Transaction.pm 
here (highlighted):



my $content;

if ( my $content_obj =

$self-ContentObj( $args{Type} ? ( Type = $args{Type} ) : () ) )

{

$content = $content_obj-Content ||'';



$RT::Logger-debug( From Transaction.pm args{type} is .$args{Type} );

$RT::Logger-debug( but the detected object type of the content is 
.$content_obj-ContentType );



if ( lc $content_obj-ContentType eq 'text/html' ) {

#if ( 1  ) {

$content =~ s/p--\s+br \/.*?$//s if $args{'Quote'};



if ($args{Type} ne 'text/html') {

$RT::Logger-error( In content type is html .$args{Type} );

$content = RT::Interface::Email::ConvertHTMLToText($content);

}

}

else {

$content =~ s/\n-- \n.*?$//s if $args{'Quote'};

if ($args{Type} eq 'text/html') {

# Extremely simple text-html converter

$content =~ s//#38;/g;

$content =~ s//lt;/g;

$content =~ s//gt;/g;

$content = pre$content/pre;

}

}

}



We also think that we have solved the issue with a modification as follows:



my $all_parts = $self-Attachments;



+while ( my $part = $all_parts-Next ) {

+#$RT::Logger-debug(Detected a part in the multipart of type 
.$part-ContentType);

+if ( lc $part-ContentType eq 'text/html' ) {

+return $part;

+}

+next;

+}



while ( my $part = $all_parts-Next ) {

next unless RT::I18N::IsTextualContentType($part-ContentType)

 $part-Content;

#$RT::Logger-debug(Figured this part of type 
.$part-ContentType. would do you);

return $part;

}



Could you confirm that this code change is appropriate.





Regards



Kevin Curtis

FarSite Communications.





-Original Message-
From: rt-users [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of 
Emmanuel Lacour
Sent: 30 May 2014 17:32
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] In Line Images in Emails



On Fri, May 30, 2014 at 11:57:22AM +0100, Kevin Curtis wrote:



We have found that whenever RT receives an email that contains an inline

image (internally or externally), any emails that get sent out by RT (for

example to the CC list or the requestor or the owner) the email that gets

sent out has the text/html section stripped of any html formatting and the

text is encased in a pre .. /pre block.



html/body is stripped in RT::Transaction-Content, but not wrapped in pre ...



can you send more information (test case) for this problem?





There is not an image either.





The problem appears when the image is referenced as src=cid: There is a 
bug caused by the fact that RT changes multipart/related to multipart/mixed 
that breaks displaying of inline images.





I worked a bit on this but did not found a beautiful fix (as a template may 
makes reference to another Transaction content than the current one ...).



A quick fix is to hack RT::Transaction::Content so it looks for CIDs, then try 
to find corresponding images attachments in RT::Tickets-Attachments, then 
replaced the CID by src=data:image





--

Easter-eggs  Spécialiste GNU/Linux

44-46 rue de l'Ouest  -  75014 Paris  -  France -  Métro Gaité

Phone: +33 (0) 1 43 35 00 37-   Fax: +33 (0) 1 43 35 00 76

mailto:elac...@easter-eggs.com  -   http://www.easter-eggs.com

--

RT Training - Boston, September 9-10

http://bestpractical.com/training
-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training

Re: [rt-users] In Line Images in Emails

[Kevin Curtis]

Hi,
The Template for Correspondence is as you show below, as does the one for 
Transaction.  Is there another that I should check?


Regards

Kevin

-Original Message-
From: Emmanuel Lacour [mailto:elac...@easter-eggs.com] 
Sent: 02 June 2014 10:07
To: Kevin Curtis
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] In Line Images in Emails

On Mon, Jun 02, 2014 at 09:48:03AM +0100, Kevin Curtis wrote:
Hi Emmanuel,
 
The test case for us was quite simple.  We use Miscrosoft Office Outlook
as the email client.
 
    1) Create a ticket
 
    2) The Ticket owner updates the ticket by sending an email to RT that
has
 
   an inline image
 
    3) RT sends an email to the Requestor and CC’s that has been converted
to plain text
 


So it looks that your Template that is used to send this email is not using 
something like:


RT-Attach-Message: yes
Content-Type: text/html


[...]

{$Transaction-Content( Type = text/html)}


-- 
Easter-eggs  Spécialiste GNU/Linux
44-46 rue de l'Ouest  -  75014 Paris  -  France -  Métro Gaité
Phone: +33 (0) 1 43 35 00 37-   Fax: +33 (0) 1 43 35 00 76
mailto:elac...@easter-eggs.com  -   http://www.easter-eggs.com
-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training

Re: [rt-users] In Line Images in Emails

[Kevin Curtis]

Yes I believe so.
For example, scrip 12 references the Template Correspondence.  And that 
template is using text/html.

I note that there is a Correspondence and a Correspondence in HTML template 
and both appear to be the same.  I did read that there is a script to convert 
text/pain templates to text/html templates, does it do anything else that might 
be significant?  I am not sure if that script has been run or if the Templates 
were changes manually.  Does the Global/Templates list normally show the 
Template and the Template in HTML entries?


Regards

Kevin


-Original Message-
From: Emmanuel Lacour [mailto:elac...@easter-eggs.com] 
Sent: 02 June 2014 11:03
To: Kevin Curtis
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] In Line Images in Emails

On Mon, Jun 02, 2014 at 10:27:07AM +0100, Kevin Curtis wrote:
 Hi,
 The Template for Correspondence is as you show below, as does the one for 
 Transaction.  Is there another that I should check?
 


and your scrip is really using this template or the non-html one?

-- 
Easter-eggs  Spécialiste GNU/Linux
44-46 rue de l'Ouest  -  75014 Paris  -  France -  Métro Gaité
Phone: +33 (0) 1 43 35 00 37-   Fax: +33 (0) 1 43 35 00 76
mailto:elac...@easter-eggs.com  -   http://www.easter-eggs.com
-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training

[rt-users] In Line Images in Emails

[Kevin Curtis]

Hi,
I have searched hard for the answer to this one, but there seems to be some 
confusion.  I am hoping that someone can provide some definitive answers.

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.

We have found that whenever RT receives an email that contains an inline image 
(internally or externally), any emails that get sent out by RT (for example to 
the CC list or the requestor or the owner) the email that gets sent out has the 
text/html section stripped of any html formatting and the text is encased in a 
pre .. /pre block.
There is not an image either.

The email can be viewed in the Web GUI as it was sent by the originator.  The 
reformatting is performed by RT when generating the outgoing mail.

If the email had contained a url to an image instead of an embedded image, then 
all seems to work fine.  In this case the outgoing emails are not converted to 
plain text in a text/html wrapper.

So my questions are as follows:


1)  Is there any documentation anywhere about the limitations of using the 
email interface?

2)  Should the email with an embedded image in it have not had the html 
formatting stripped out?

3)  Have I misconfigured something?


The questions
Thanks in Advance

Kevin Curtis
Farsite Communications.


-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training

Re: [rt-users] Problems with ! in html format emails

[Kevin Curtis]

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-boun...@lists.bestpractical.com] On Behalf Of 
Kevin Curtis
Sent: 29 May 2014 15:05
To: rt-users@lists.bestpractical.commailto:rt-users@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.

-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training

[rt-users] (no subject)

[Kevin Curtis]

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.

-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training