5

I understand uuencode is for encoding files, and mailx sends mail. However, I'm not exactly understanding...

  1. Why uuencode file file | mailx -s "subject" email_adress keeps sending messages with the encoded content inside the email instead of as an attachment. (And how to go about fixing it...)
  2. I have tried echo | mailx -s "subject" -a <file> <email_address> and seemed to get my files just fine. But does this mean I am without the protection of encoding or does -a give you that?
  3. I've skimmed there may be better alternatives. Is this really the way to go? I am not particular fluent on the *nix side of things.... Is mutt a good place to start? Are there other suggestions?

This is on RHEL 6.4, uuencode (GNU sharutils) 4.14

Update

Does it matter that mailx version is Heirloom Mail version 12.4 7/29/08? Could the issue be a difference in behavior how mailx treats the uuencode output? Could it be a mailrc setting or some environment variable?

Well, I found another post that seems to have more details on mail headers... I found it helps me understand this issue more, so I'm keeping a link here.

Community
  • 1
user1766760
  • 555
  • 2
    mailx takes the piped message as message body, you could use mime construct to make an attachment mime construct –  Feb 19 '14 at 19:54
  • If the uuencoded data is in the email body instead of an attachment, you can save the entire received message to a file, and you should then be able to run uudecode on it just fine. uudecode was designed to ignore email headers. – Mark Plotnick Feb 19 '14 at 19:56
  • Have the sasme issue... this combination "uuencode </path/to/file> | mailx -s "some thing" my.mail@here.com" worked fine for years and attached the file as a MIME coded attachment before we upgraded to CentOS 7... not it's broken and send the hole things as "garbage", as stated before... grrrr.... –  Nov 26 '14 at 14:06

4 Answers4

3

Uuencode converts binary data into text it was the first method used to send binary files by email (it is just one of the usage of uuencode). Uuencode will not protect your email.

Then MIME was invented who defined mail body and attachments.

To send MIME emails I use mpack 

mpack -s "subject" -d description_file file address1 address2...

description_file is the email text (optional)
file is the attached file

Emmanuel
  • 4,187
1

The pipe sends the stream to stdin, as such it's the content of the message. -a creates an attachment which will be base64 encoded -- basically the same thing as uuencode.

Ricky
  • 1,377
  • I tried looking at the man page, and -a only mentions attaching a file. After your comment, I looked again. Are you referring to the encoding option? I don't really understand what Binary Option is about. – user1766760 Feb 19 '14 at 22:31
  • There are multiple different mailx implementations, some have an -a or -A option which does this and others don't, or have an option by that name which does something else entirely. – tripleee Nov 03 '22 at 12:14
  • Sending proper MIME is vastly superior to uuencode; they are very much not "basically the same thing". – tripleee Nov 03 '22 at 12:38
  • I'm referring to base64 being basically the same thing as uuencode. (One is way older than the other. Both turn a binary stream into an ASCII text representation. As I recall, uuencode was designed to avoid characters that can't be translated to EBCDIC [from the days of mainframes].) Both accomplish the same thing with the tools of their era. – Ricky Nov 04 '22 at 18:58
1

To complement and slightly unpack the information in the other answers here, let me answer in reverse order.

  1. Yes, mutt is a good place to start. It is reasonably ubiquitous and well-supported, and has good support for MIME attachments. The command-line interface isn't terribly versatile, but it can quickly get a message with a few attachments submitted to your mail server.

(If you don't have a mail server configured, that complicates matters for all of these discussions. Let's assume you do. Some beginners are stymied by this, so I thought I should mention this as a basic sanity check before we proceed. Do you have something responding on port 25 locally? Or, do you have your mail client configured to connect to a remote server for message submission? If not, solve that first.)

  1. If you have mailx with an -a option which accepts the name of a file to attach, that does exactly the right thing, and sends the file as a (usually base64-encoded) MIME attachment.

Matters are complicated somewhat by the fact that there are multiple mailx implementations. See here for details.

  1. uuencode far predates MIME or the concept of "attachments". What it does is precisely what you describe, and the usability problems with that was no doubt one of the motivations for replacing it with MIME. There should be no reason to use uuencode in this millennium.

Apart from the usability improvement of having the email divided into an inline "body" with zero or more "attachments", MIME vastly improves over uuencode by way of identifying the file type and file name of each attachment unambiguously and robustly. It is also the prerequisite for any sort of multimedia and/or multilingual content. (Email before MIME was fundamentally text only, and English only. There were local hacks to override that in many regions but ... you'd be appalled.)

tripleee
  • 7,699
0

As Emmanual quite correctly stated, the only same way to get a MIME attachement sent in most morden Unices is by using mpack. Using mpack does have a massive down-side, though, in that it is limited to a single file as attachment.

Should you wish to send multiple files, the best solution, I have found, is to write a Python wrapper to do the mailing for you using its built-in email module.

I have used the one I've uploaded to the following Gist for a good couple of years on Solaris and Linux and it has been rock-solid for me.

Eugéne
  • 1,119