------------ Original Message ------------
> Date: Friday, July 17, 2015 01:23:46 PM -0400
> From: Bill Cole <postfixlists-070...@billmail.scconsult.com>
>
> On 17 Jul 2015, at 9:17, Tony Stocker wrote:
>
>> Quick background, we recently shifted from a very old mail server
>> running Postfix (~2.2.10) to a newer, though not cutting edge,
>> one also running Postfix (~2.6.6). As much as practical the
>> configuration files from the old server were used to provision
>> the new server. For the most part everything seems to be
>> working normally.
>>
>> However we have one oddity that we've noticed so far. We have
>> several systems that use 'uuencode' and 'mailx' to send reports
>> through the mail server, the basic format of the cron job that
>> does these is like so:
>>
>> /usr/bin/uuencode
>> "/logs/system/reports/${system}/ftpreport.${yesterday}"
>> "${system}.ftpreport.${yesterday}" | /bin/mailx -s "FTP Report
>> ${yesterday}
>> ${system}" astocker
>>
>> These worked fine with the old server, the emails would arrive
>> and have a file attachment, appropriately named
>> '"${system}.ftpreport.${yesterday}"'.
>>
>> However the new server does not appear to be "attaching" the file
>> to the email, but instead outputting the uuencode directly to
>> the mail body.
>
> You seem to be unfamiliar with how "attachments" in email work.
>
> All "attachments" in email are blobs of text directly in the body
> of messages, formatted and encoded in ways that are understood by
> MUAs (Mail User Agents, i.e. mail clients) to be "attached" files
> distinct from the parts of the message that are human-readable
> with less complex interpretation. Normal MTAs (Mail Transport
> Agents, i.e. mail servers) know nothing of attachments and do
> nothing with them other than transport the blobs of text without
> reformatting except in a few edge cases, and then in ways that
> don't damage standard types of attachment encoding.
>
> The uuencode/uudecode pair of programs is the oldest means of
> encoding files for mail transport and decoding mail to extract
> "attached" files. They predate any carefully-crafted standards for
> email attachments and the 3 (at least) entirely independent
> implementations on Unix-like systems mostly interoperate well. The
> cron job you run literally just dumps the output of uuencode into
> the body of a mail message sent by mailx. The last thing to modify
> the message is mailx. On the other end, you apparently use a MUA
> that recognizes some flavors of uuencode-piped-to-mail messages as
> having an "attached" file. That's not simple to do reliably, and
> in fact many users of Outlook have been mystified over the years
> by it's overeager interpretation of lines like 'begin [digits]
> [characters]' as the start of an attachment: mystified and
> occasionally pranked. Because the uuencode-piped-to-mail format is
> not really very consistent (due to varying behaviors of various
> uuencode's and mail/Mail/nail/mailx's) many MUAs wisely don't try
> to interpret it, instead only supporting the well-specified
> standard mechanisms under the "MIME" umbrella for attaching files
> to mail and recognizing attached files in mail.
>
> So your best solution is to stop using the best of the 80's mail
> software for sending files via mail and move into the 90's by
> using something that generates MIME attachments instead of relying
> on some fuzzy heuristics in a particular MUA to recognize uucode
> blobs as attached files.
>
In addition to what's been said already, if the attachments work
correctly with mutt, but not with mailx, that alone would cause me
to suspect the application the messages are being generated with,
rather than the MTA.
You don't indicate your OS, but the postfix versions you mention
correlate with rhel/centos 5 and 6 respectively. Whether my guess is
correct or not, look closely at what "mailx" really is on your
systems. In the case of rhel/centos, with 5, "mailx" is a symlink to
"mail", while on 6 it's "mailx" proper. A review of the the man
pages shows that the two programs need to be handled differently in
many respects, including attachments.
