RT sending email that violates proper MIME RFC

Keith_Wessel · July 2, 2005, 6:14am

Hello,

Saw nothing in the archives or elsehwere about this, so I thought I’d
ask if anyone else had seen this issue.

Certain systems are having problems with the email that my RT 3.2.3
install is sending out. The problems started after upgrading from RT
3.2.2 a few weeks ago. There are two related symptoms:

Some systems that receive mail from RT (using Postfix) that have super
picky restrictions on mail meeting proper MIME RFC choak with the
message: “This box does not accept messages that violate MIME RFC” and
the mail is completely refused (554 service unavailable).
Any mail sent to a yahoo.com address is received, but the recipient
reports to me that they received a blank message from RT. If they
choose to download the message text, Yahoo then displays the raw message
in their browser and they can read the contents. But using the normal
facility in Yahoo’s web API to read mail, the message appears blank. I
have done an “rt show ticket/xxxxxx/History/id/yyyyyy” to copy the
message text into an email that I then resent from my personal email
address, and they receive the message fine. If I maintain the RT
subject line and set the reply-to to RT, the system handles their
response just fine.

So, anyone know why RT is breaking valid MIME rules? It’s RT 3.2.3 on a
RHEL3 system with the standard RedHat sendmail. Anyone seen this and
have any pointers on solving it? Sorry, but ceasing communications with
my customers at yahoo.com is not an option.

Thanks very much for any help anyone can provide!
-Keith

Jesse_Vincent · July 2, 2005, 6:41pm

Hello,

Saw nothing in the archives or elsehwere about this, so I thought I’d
ask if anyone else had seen this issue.

Certain systems are having problems with the email that my RT 3.2.3
install is sending out. The problems started after upgrading from RT
3.2.2 a few weeks ago. There are two related symptoms:

Can you try coming up to the current release, RT 3.4.2, to see if this
is resolved? Specifically, the issue is an extra ‘-’ in a mail header
“8-bit” should read “8bit” iirc. Or perhaps I have it backwards.

Keith_Wessel · July 2, 2005, 9:21pm

Thanks, Jesse, for the quick reply!

Unfortunately, I’d have to break all sorts of things on this RedHat
system to get a new enough version of Apache and Mod_perl running to run
3.4.2. (Sometimes, I miss the days before package managers!) But
thanks for the tip. I pulled the hyphen out of the 8-bit (you were
correct, it’s supposed to be 8bit) in Actions/SendEmail.pm for the
Content-Transfer-Encoding header. We’re all better!

Thanks for the awesome work on this product, and for being a developer
who’s still so plugged in with your user community! RT rocks!

Thanks,
-KeithOn Sat, Jul 02, 2005 at 02:41:25PM -0400, Jesse Vincent wrote:

On Sat, Jul 02, 2005 at 01:14:25AM -0500, Keith Wessel wrote:

Hello,

Saw nothing in the archives or elsehwere about this, so I thought I’d
ask if anyone else had seen this issue.

Certain systems are having problems with the email that my RT 3.2.3
install is sending out. The problems started after upgrading from RT
3.2.2 a few weeks ago. There are two related symptoms:

Can you try coming up to the current release, RT 3.4.2, to see if this
is resolved? Specifically, the issue is an extra ‘-’ in a mail header
“8-bit” should read “8bit” iirc. Or perhaps I have it backwards.

Filip_Jonckers · July 5, 2005, 9:38am

RT v3.4.2 action/sendmail.pm →

# fsck.com #5959: Since RT sends 8-bit mail, we should say so.
$self->SetHeader( 'Content-Transfer-Encoding','8-bit');

So if I understand correctly this should read:

# fsck.com #5959: Since RT sends 8-bit mail, we should say so.
$self->SetHeader( 'Content-Transfer-Encoding','8bit');

that could explain why some mails get bounced back
(receiving mail server is connected - sends its list of capabilities -
and sending server disconnects without sending the message!)
this results in a error message coming back (could not deliver message)
which in turn is added to the ticket and
results in a message being sent again … causing a loop and bringing
apache down on its knees
the anti-loop code does not detect this :-/

will do some tests to see if this helps…

thanks!
filip

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf
Of Keith Wessel
Sent: zaterdag 2 juli 2005 23:21
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] RT sending email that violates proper MIME RFC

Thanks, Jesse, for the quick reply!

Unfortunately, I’d have to break all sorts of things on this
RedHat system to get a new enough version of Apache and
Mod_perl running to run 3.4.2. (Sometimes, I miss the days
before package managers!) But thanks for the tip. I pulled
the hyphen out of the 8-bit (you were correct, it’s supposed
to be 8bit) in Actions/SendEmail.pm for the
Content-Transfer-Encoding header. We’re all better!

Thanks for the awesome work on this product, and for being a
developer who’s still so plugged in with your user community!
RT rocks!

Thanks,
-Keith

Hello,

Saw nothing in the archives or elsehwere about this, so I thought
I’d ask if anyone else had seen this issue.

Certain systems are having problems with the email that
my RT 3.2.3
install is sending out. The problems started after
upgrading from
RT
3.2.2 a few weeks ago. There are two related symptoms:

Can you try coming up to the current release, RT 3.4.2, to
see if this
is resolved? Specifically, the issue is an extra ‘-’ in a
mail header
“8-bit” should read “8bit” iirc. Or perhaps I have it backwards.

The rt-users Archives

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

CONFIDENTIALITY NOTICE
This E-mail message and any documents which accompany it are intended only for the use of the individual or entity to which addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If the reader is not the intended recipient, any disclosure, distribution or other use of this E-mail message is prohibited. If you have received this E-mail message in error, please delete and notify the sender immediately. Thank you.