S/MIME Mail Causes RT EX_TEMPFAIL Errors
Jan 5th, 2006 by Alex
S/MIME message don’t interact well with RT. If you send an S/MIME email to the system, you will likely receive the nondescript “no value sent for required parameter 'message'” error. The mail administrator will see EX_TEMPFAIL errors (if using Sendmail). One solution is to remove MIME data from incoming messages destined for RT.
The following was discovered on a system running RT 3.4.2 on Red Hat Enterprise Linux 4. Your mileage may vary, but the CHANGELOG up to the current version (3.4.4 at the time of writing) didn’t suggest any major changes to rt-mailgate or other mail components. Jesse Vincent did mention that S/MIME signatures would “most likely” be worked on in the next year (as of a 29 April 2005 rt-users post), but that won’t help for now.
Disclaimer out of the way, RT is a stellar ticketing system. It handles most content with grace: MIME, text, attachments, etc. S/MIME seems to be one of the few exceptions. No one would expect RT to handle encrypted mail, but how about cleartext signed mail? It turns out that if you send a digitally signed message to RT, it will die in most cases.
If you’re running Sendmail and you look at the mailq or /var/log/maillog, you’ll see the EX_TEMPFAIL error code associated with the S/MIME messages. After some period, the sender will receive the following email back.
**********************************************
** THIS IS A WARNING MESSAGE ONLY **
** YOU DO NOT NEED TO RESEND YOUR MESSAGE **
**********************************************
The original message was received at Wed, 4 Jan 2006 17:54:42 -0500
from x.x.x [x.x.x.x]
----- Transcript of session follows -----
RT server error.
The RT server which handled your email did not behave as expected. It said:
At this point there will be a whole lot of properly formatted HTML. If your mail reader can handle HTML, you’ll probably be able to read it as is. Otherwise you’ll be forced to cut and paste the content into a file and load it up in a browser by hand. Either way, the next section will look somewhat like this:
error:value sent for required parameter 'message'context:
…
18: }
19:
20: foreach my $arg ( qw( message ) )
21: {
22: HTML::Mason::Exception::Params->throw
23: ( error => “no value set for required parameter ‘$arg’” )
24: unless exists $pos{$arg};
25: }
26: #line 50 /apps/rt-3.4.2/share/html/REST/1.0/NoAuth/mail-gateway
…code stack:
/apps/rt-3.4.2/var/mason_data/obj/standard/REST/1.0/NoAuth/mail-gateway:22
/usr/local/perl5/site_perl/5.8.5/HTML/Mason/Component.pm:136
/usr/local/perl5/site_perl/5.8.5/HTML/Mason/Request.pm:1069
/usr/local/perl5/site_perl/5.8.5/HTML/Mason/Request.pm:1068
/usr/local/perl5/site_perl/5.8.5/HTML/Mason/Request.pm:338
/usr/local/perl5/site_perl/5.8.5/HTML/Mason/Request.pm:338
/usr/local/perl5/site_perl/5.8.5/HTML/Mason/Request.pm:297
/usr/local/perl5/site_perl/5.8.5/HTML/Mason/ApacheHandler.pm:134
/usr/local/perl5/site_perl/5.8.5/HTML/Mason/ApacheHandler.pm:134
/usr/local/perl5/site_perl/5.8.5/HTML/Mason/ApacheHandler.pm:827
/apps/rt-3.4.2/bin/webmux.pl:124
/apps/rt-3.4.2/bin/webmux.pl:124
/dev/null:0
/dev/null:0
Below that will be a “raw error” section that will regurgitate the same information (although in a slightly more raw format). All of this doesn’t really tell us much even if you dig into it. Don’t bother, especially if you’ve been signing your messages or if your users have a tendency to check the “Add digital signature to outgoing messages” box on one of Outlook’s Security tabs (Tools, Options, Security). While you’re busy digging through volumes of perl code, your user’s request hasn’t made it to the system. Their attempts to re-send will be met with the same non-response until the mailer spits back the error, sometimes days later.
One solution is to strip MIME portion out of email entirely, thus removing the digital signatures that cause RT to balk. This will also effectively eliminate all those pesky HTML-only emails, hideous background attachments that some office people adore, viral attachments sent from infected machines, and rich text. All in all, a lot of garbage that shouldn’t be heading to most ticketing systems anyways. Our stance is that if an attachment needs to be sent, we’ll work with the requester to get it to us some other way. If this stance doesn’t work for you, you’ll have to find another way.
There’s a neat little perl script — written by Alex Wetmore — called stripmime that does exactly what is necessary and nothing more. No additional perl modules to be installed, no modifications to RT whatsoever. So long as you have Perl5, you’re good to go. All you have to do to use it is to modify your /etc/aliases file to pipe your message to stripmime before piping to RT.
Before stripmime:
rt: "|/etc/smrsh/rt-mailgate --queue general --action correspond --url http://your.host.name/" rt-comment: "|/etc/smrsh/rt-mailgate --queue general --action comment --url http://your.host.name/"
After stripmime:
rt: "|/etc/smrsh/stripmime|/etc/smrsh/rt-mailgate --queue general --action correspond --url http://your.host.name/" rt-comment: "|/etc/smrsh/stripmime|/etc/smrsh/rt-mailgate --queue general --action comment --url http://your.host.name/"
Aside from your particular path issues, that’s it. Rebuild your aliases and you’re done! On messages that stripmime modified, you’ll get a nice little summary at the bottom telling you what was stripped and what was left untouched.
By stripping down MIME data that comes to ticketing systems, we reduce the chance that a user’s request will be delayed and also the chance of them received a rather unpleasant (and unhelpful) error message. We feel that the trade-off of stripping the attachments and MIME data further enhance our ability to provide effective ticketing systems using RT.
Please let us know if you’ve had similar problems and have found this information helpful.
