Today was a busy day! A rather expert user asks for my advice about emails being generated from his own Unix system, by his own processes, that occasionally come out with the encoding of the attachments showing up in the body of the message.
I am not a message formatting expert, or at least I wasn’t prior to this question today. Bbut if a sendmail expert can’t provide an answer, who will? So anyways, this user, let’s call him Rob forwards me this email:
Dear DrJohn, I was wondering if you have some idea as to why sometimes the attachment is getting included in the text of the email instead of being recognized as attachment, see example below. Any pointers would be helpful, as this makes it at the least cumbersome to open the attachment by cutting , pasting the text attachment part as file and uudecoding it into binary before it can be opened for content view. Regards, Rob Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_168946_477699193.1322837415283" X-Mailer: sendmsg ------=_Part_168946_477699193.1322837415283 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Dear Team; While executing the flow, In.process:RapidProductMovementReport_New, the following exception occurred. java.lang.Exception: java.sql.SQLException:ORA-12899: value too large for column "B2B_RAPID"."P_MOVEMENT_DETAIL"."UNIT_OF_MEASURE_TYP" (actual: 3, maximum: 2) Error Dump : com.wm.lang.flow.FlowException:java.lang.Exception: java.sql.SQLException:ORA-12899: value too large for column ... (actual: 3, maximum: 2) Pipeline values (see attachment) Caller: Rapid_In.process:RapidRouter Stack: %serviceStack% ------=_Part_168946_477699193.1322837415283 Content-Type: application/gzip; name=pipeline.xml.gz Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=pipeline.xml.gz H4sIAAAAAAAAAOy9bXPiSJr3+/rMp8hwbEzMHbFFKVOpp57umpVBBp0SkkcS5WHeVLhtutr32sbH dtV0f/uTEmDLIMBISErBf2O3to2SJJUP18PvujLz53/8cXdLfkwen26m97+c0I5yQib3V9Prm/tv v5yM4rMP5sk/Pv3l5y+Xt98nT68FmSj46S+E/PwjeUDuL+8mv5xcT6++303un+M/HyYnn84fp9ff r56H0x+T5MNw8jB9fP75Y/qFla/eX/72fOlNvzl3lze39vX14+Tp6eTTKTu1r+9u7v/n18un3zpX 07t1X7++eZxcPYuWnXxy/dNg5PfWlbydfvvt5naS/HHy6eP04fnjfya/3k2ef59eP328fHi4vbm6 TCoS5Z4.......
Hmm. So what do you think? I have often seen these Mime-type headers and paid absolutely no attention to them. When things work what does it matter? But now they’re not working and it does matter.
First I tried to reproduce the problem using a technique I had gleaned looking over the shoulders of some Unix admins. I knew they had an easy method to send attachments from the command line of their Unix systems so I walked over and asked them how they did it. Sure enough, it was dead easy. It goes something like this:
# uuencode file.txt file.txt|mailx -s “here is your attachment” recipient_address
I rolled up my sleeves, set recipient_address to a valid SMTP mail address. Sure enough. I got it as an attachment in Lotus Notes. But it’s an ugly attachment and doesn’t have any of the nice MIME formatting about it. so it’s probably a bit of luck that my MUA (mail user agent) understands that I mean to create an attachment. I don’t think all MUAs will do that, unless it’s following a more obscure RFC which I’m not aware of.
The original source of the message looks like this (my attachment is called cogstartup.xml.gz):
Date: Fri, 2 Dec 2011 14:54:34 -0500 From: ... Message-Id: ... To: ... Subject: test using uuencode X-MIMETrack: Itemize by SMTP Server on ... (Release 7.0.4|March 23, 2009) at 02/12/2011 20:54:36, Serialize by Notes Client ... (Release 8.5.1|September 28, 2009) at 12/02/2011 04:12:40 PM, Serialize complete at 12/02/2011 04:12:40 PM X-TNEFEvaluated: 1 begin 644 cogstartup.xml.gz M'XL(""57L4X``V-O9W-T87)T=7`N>&UL`.U]VW;;R+'H^WP%HA?-G$5)MN<2 MCW?&>].2/:/$NL24,\EY\0(!D$0,`@P`2N9\_:E+W]$@`(J2LG-&*QE+)-!= M755=MZZ...
Very different from what we saw above, right? None of those MIME-related headers seem to be present. So I decided that uuencode is too primitive to reproduce the problem.
I was next going to try to generate an email with the help of a PERL module, like MIME::Lite. But I decided that was too much trouble as I would need to download it and install it first!
So I ventured to see if I could get lucky and figure out the problem by educating myself on the standard, without wasting too much time. The relevant RFC seems to be 1341. I prefer the older RFCs because I suppose they’re shorter – easier to understand because life was simpler in those days! Once yuo parse through the verbiage and repitition, there wasn’t much to it. In particular, it mentioned that the Header
has to be included amongst the header fields. If it is not, the correct behaviour for a MUA is to interpret all the encodings and stuff as just part of a regular body text, which it will display to the user.
I ran a test using sendmail as my sending MUA from a Linux server. With the sendmail agent you can add headers, at least that’s how I remember it:
# sudo sendmail -v recipient< tst
where tst is a file I created that starts with the line
Yes, indeedy. I received it and my MUA interpreted the attachment as an attachment, displaying the attachment name and the appropriate icon type for it!
Now put just a blank line at the top of my tst file, pushing all the rest of the stuff down by a line, and the behaviour is completely different. Then my MUA treats everything as literal body text, just as the old RFC says it must, and it looks just the way it did when Rob forwarded it to me.
I explained to Rob that he must sometimes be introducing an extra line above the Mime-Verison header, which would cause this problem.
He thanked me.