Re: [rt-users] Base64 encoded emails unreadable
I installed RT-3.8.8 and am still seeing the same problem. I am using the RHEL4 sendmail-8.13.1-3.2.el4 RPM on an RHEL4 server. When I installed RT-3.8.8 I opted not to update the smrsh (rt-mailgate) from the 3.6.3 version that is currently running because there are two RT-3.6.3 running in Production mode on this server. Is it possible that the problem lies partially, or wholly, in the mailgate application? --phess -Original Message- From: Jesse Vincent [mailto:je...@bestpractical.com] Sent: Friday, January 21, 2011 10:55 AM To: Patrick Hess Cc: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Base64 encoded emails unreadable I believe that this works in more recent RTs. Can you try sending a test message from a blackberry to rt-b...@bestpractical.com, cced to me? Best, Jesse On Fri, Jan 21, 2011 at 10:52:56AM -0800, Patrick Hess wrote: The entire content of emails, not just attachments, from BlackBerry devices appears to be Base64 encoded. The issue that we're having is that RT-3.6.3 is unable to detect that the message is encoded -- even though the Content-Transfer-Encoding header is set to base64 -- and therefore any message from a BlackBerry is unreadable. I'm fairly certain that someone else has seen this problem and fixed it; I'm hoping someone can give a recommendation to help with this. I am running RT-3.6.3 on a RHEL4u5 x64 server with perl-5.8.5 using the perl-5.8.5-36.RHEL4 RPM. --phess --
Re: [rt-users] Base64 encoded emails unreadable
Final update: this issue is fixed. At the site in question, the procmail-related formail application is being used to remail messages to RT. During the remailing process, formail was stripping off the Content-Transfer-Encoding and Content-Type headers from the incoming message before remailing to RT. Now that formail is configured to no longer strip those important headers, RT is correctly able to discern that the message is Base64 encoded used and RT-3.6.3 is correctly decoding the message. --phess -Original Message- From: Patrick Hess [mailto:ph...@cataphora.com] Sent: Friday, January 21, 2011 10:53 AM To: 'rt-users@lists.bestpractical.com' Subject: Base64 encoded emails unreadable The entire content of emails, not just attachments, from BlackBerry devices appears to be Base64 encoded. The issue that we're having is that RT-3.6.3 is unable to detect that the message is encoded -- even though the Content-Transfer-Encoding header is set to base64 -- and therefore any message from a BlackBerry is unreadable. I'm fairly certain that someone else has seen this problem and fixed it; I'm hoping someone can give a recommendation to help with this. I am running RT-3.6.3 on a RHEL4u5 x64 server with perl-5.8.5 using the perl-5.8.5-36.RHEL4 RPM. --phess
Re: [rt-users] Base64 encoded emails unreadable
I know that when I reply to RT tickets from a BlackBerry it sends with the header set. I also know that my replies, in RT-3.6.3, look identical to the other BlackBerry users (the ASCII characters of base64 encoded). If you'd like, I'll create a test ticket in my system and divert an email so you can see. --phess -Original Message- From: Jesse Vincent [mailto:je...@bestpractical.com] Sent: Monday, January 24, 2011 6:40 AM To: Patrick Hess Cc: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Base64 encoded emails unreadable On Fri 21.Jan'11 at 13:18:05 -0800, Patrick Hess wrote: On Fri, Jan 21, 2011 at 11:15:52AM -0800, Patrick Hess wrote: Thanks for replying, Jesse. I can and will send a test from a blackberry. However, upgrading my version of RT is not practical. :( As a heads up, I didn't see any of the messages you sent as coming throught with a base64 content-transfer-encoding. Best, Jesse Understood. Unfortunately, helping with bugs in older versions that we've already fixed in current versions is something we can only really do in the context of a support contract. (But let's make sure that's the case first) Best, Jesse
[rt-users] Base64 encoded emails unreadable
The entire content of emails, not just attachments, from BlackBerry devices appears to be Base64 encoded. The issue that we're having is that RT-3.6.3 is unable to detect that the message is encoded -- even though the Content-Transfer-Encoding header is set to base64 -- and therefore any message from a BlackBerry is unreadable. I'm fairly certain that someone else has seen this problem and fixed it; I'm hoping someone can give a recommendation to help with this. I am running RT-3.6.3 on a RHEL4u5 x64 server with perl-5.8.5 using the perl-5.8.5-36.RHEL4 RPM. --phess
Re: [rt-users] Base64 encoded emails unreadable
Thanks for replying, Jesse. I can and will send a test from a blackberry. However, upgrading my version of RT is not practical. :( --phess -Original Message- From: Jesse Vincent [mailto:je...@bestpractical.com] Sent: Friday, January 21, 2011 10:55 AM To: Patrick Hess Cc: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Base64 encoded emails unreadable I believe that this works in more recent RTs. Can you try sending a test message from a blackberry to rt-b...@bestpractical.com, cced to me? Best, Jesse On Fri, Jan 21, 2011 at 10:52:56AM -0800, Patrick Hess wrote: The entire content of emails, not just attachments, from BlackBerry devices appears to be Base64 encoded. The issue that we're having is that RT-3.6.3 is unable to detect that the message is encoded -- even though the Content-Transfer-Encoding header is set to base64 -- and therefore any message from a BlackBerry is unreadable. I'm fairly certain that someone else has seen this problem and fixed it; I'm hoping someone can give a recommendation to help with this. I am running RT-3.6.3 on a RHEL4u5 x64 server with perl-5.8.5 using the perl-5.8.5-36.RHEL4 RPM. --phess --
Re: [rt-users] Base64 encoded emails unreadable
This one is from my BlackBerry --phess -Original Message- From: Jesse Vincent je...@bestpractical.com Date: Fri, 21 Jan 2011 14:19:50 To: Patrick Hessph...@cataphora.com Cc: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Base64 encoded emails unreadable On Fri, Jan 21, 2011 at 11:15:52AM -0800, Patrick Hess wrote: Thanks for replying, Jesse. I can and will send a test from a blackberry. However, upgrading my version of RT is not practical. :( Understood. Unfortunately, helping with bugs in older versions that we've already fixed in current versions is something we can only really do in the context of a support contract. (But let's make sure that's the case first) Best, Jesse
Re: [rt-users] Base64 encoded emails unreadable
When you say current versions are you referring to 3.6.10 or 3.8.x? --phess -Original Message- From: Jesse Vincent [mailto:je...@bestpractical.com] Sent: Friday, January 21, 2011 11:20 AM To: Patrick Hess Cc: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Base64 encoded emails unreadable On Fri, Jan 21, 2011 at 11:15:52AM -0800, Patrick Hess wrote: Thanks for replying, Jesse. I can and will send a test from a blackberry. However, upgrading my version of RT is not practical. :( Understood. Unfortunately, helping with bugs in older versions that we've already fixed in current versions is something we can only really do in the context of a support contract. (But let's make sure that's the case first) Best, Jesse
Re: [rt-users] apache httpd segfaults
I don't have any RHEL5.x servers at my disposal but, based on what I know
about perl and RHEL4, from your strace output it looks like your perl
installation may be questionable or at fault here.I recommend verifying
your perl-5.8.8 RPM. Don't be surprised if files show up as missing.
When you install updated perl modules, the install may choose to uninstall
the old versions. If there are missing files from the RPM, check in
vendor_perl and site_perl to make sure they're installed elsewhere.
I have experienced similar segfaults from Apache-2.0 when a server is short
on memory because I have set vm.overcommit_memory=2 and
vm.overcommit_ratio=100 on my RHEL4 servers. This essentially puts a limit
on how much memory the kernel can claim to have and thereby forces malloc()
to return NULL if the server doesn't have enough free memory to allocate.
It seems that Apache-2.0 doesn't know how to deal with the inability to
allocate memory; it's possible that this bug is still present in Apache-2.2.
Have you attempted to allow Apache to leave coredumps? In Apache-2.0 this
was done by setting the CoreDumpDirectory to some directory with write
permissions for the appropriate User in the httpd.conf and also setting the
DAEMON_COREFILE_LIMIT environment variable to unlimited in the
/etc/sysconfig/httpd file. I assume it's not too different with Apache-2.2
and RHEL5. If you can get Apache to dump core, you can backtrace with gdb.
I'm sorry I cannot be of more assistance, but I hope this helps somewhat.
--phess
-Original Message-
From: rt-users-boun...@lists.bestpractical.com
[mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Aleksey
Tsalolikhin
Sent: Friday, January 21, 2011 4:26 PM
To: rt-users
Subject: Re: [rt-users] apache httpd segfaults
On Fri, Jan 21, 2011 at 4:12 PM, Aleksey Tsalolikhin
atsaloli.t...@gmail.com wrote:
My RT 3.8.8 has lost its prettiness. It's text-based now, no colors
or graphics, only text. It does work, but it isn't pretty. No
buttons, only links.
The only errors I can find are in the Apache httpd log, and it seems
each time I click on a link within RT, I get a message like this in my
httpd error log:
[Fri Jan 21 16:05:06 2011] [notice] child pid 32708 exit signal
Segmentation fault (11)
I use postgres 8.4 on the backend.
Would appreciate any suggestions for troubleshooting this.
This is on CentOS 5.5 and Apache httpd 2.2
strace of the apache httpd process shows the following:
open(/usr/lib/perl5/5.8.8/PerlIO.pm, O_RDONLY) = 60
ioctl(60, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff0aee6850) = -1 ENOTTY
(Inappropriate ioctl for device)
lseek(60, 0, SEEK_CUR) = 0
read(60, package PerlIO;\n\nour $VERSION = ..., 4096) = 4096
lseek(60, 382, SEEK_SET)= 382
lseek(60, 0, SEEK_CUR) = 382
close(60) = 0
stat(/opt/rt3/bin/../local/lib/PerlIO/scalar.pmc, 0x7fff0aee6c00) =
-1 ENOENT (No such file or directory)
stat(/opt/rt3/bin/../local/lib/PerlIO/scalar.pm, 0x7fff0aee6ac0) =
-1 ENOENT (No such file or directory)
stat(/opt/rt3/bin/../lib/PerlIO/scalar.pmc, 0x7fff0aee6c00) = -1
ENOENT (No such file or directory)
stat(/opt/rt3/bin/../lib/PerlIO/scalar.pm, 0x7fff0aee6ac0) = -1
ENOENT (No such file or directory)
stat(/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/PerlIO/scal
ar.pmc,
0x7fff0aee6c00) = -1 ENOENT (No such file or directory)
stat(/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/PerlIO/scal
ar.pm,
0x7fff0aee6ac0) = -1 ENOENT (No such file or directory)
stat(/usr/lib/perl5/site_perl/5.8.8/PerlIO/scalar.pmc,
0x7fff0aee6c00) = -1 ENOENT (No such file or directory)
stat(/usr/lib/perl5/site_perl/5.8.8/PerlIO/scalar.pm,
0x7fff0aee6ac0) = -1 ENOENT (No such file or directory)
stat(/usr/lib/perl5/site_perl/PerlIO/scalar.pmc, 0x7fff0aee6c00) =
-1 ENOENT (No such file or directory)
stat(/usr/lib/perl5/site_perl/PerlIO/scalar.pm, 0x7fff0aee6ac0) = -1
ENOENT (No such file or directory)
stat(/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/PerlIO/sc
alar.pmc,
0x7fff0aee6c00) = -1 ENOENT (No such file or directory)
stat(/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/PerlIO/sc
alar.pm,
0x7fff0aee6ac0) = -1 ENOENT (No such file or directory)
stat(/usr/lib/perl5/vendor_perl/5.8.8/PerlIO/scalar.pmc,
0x7fff0aee6c00) = -1 ENOENT (No such file or directory)
stat(/usr/lib/perl5/vendor_perl/5.8.8/PerlIO/scalar.pm,
0x7fff0aee6ac0) = -1 ENOENT (No such file or directory)
stat(/usr/lib/perl5/vendor_perl/PerlIO/scalar.pmc, 0x7fff0aee6c00) =
-1 ENOENT (No such file or directory)
stat(/usr/lib/perl5/vendor_perl/PerlIO/scalar.pm, 0x7fff0aee6ac0) =
-1 ENOENT (No such file or directory)
stat(/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/PerlIO/scalar.pmc,
0x7fff0aee6c00) = -1 ENOENT (No such file or directory)
stat(/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/PerlIO/scalar.pm,
{st_mode=S_IFREG|0644, st_size=979, ...}) = 0
[rt-users] Sendmail and multiple RT instances
I am trying to create a second RT-3.6.3 instance on an RHEL4 server. The server is fully into production mode for the original instance (which has been working fine for quite some time). I have a separate installation for the second RT-3.6.3 instance and it seems to be working fine in all respects, except one. I would like mail from the second RT instance to appear to come from a different server name. However, the Reply-To address is being overridden by the Masquerade from Sendmail and therefore appears to come from the same server as the original instance. I had to configure Sendmail to Masquerade the envelope and the entire domain as a fixed name in order to compensate for some poor legacy decisions. However, this level of rigidity is now a problem for me. Can someone here recommend another way to configure RT or Sendmail to achieve my end goal? --phess RT Training in Washington DC, USA on Oct 25 26 2010 Last one this year -- Learn how to get the most out of RT!
