sending email through unix by using cat with uuencode - email

Question

here I'm working on sun Solaris 10, I have tried before to send a normal email with and without attach and its worked fine with me , but now I'm trying to cat-file element and send attach in the same email but it does not work
this is my result.txt file body :
Total Number of Files = 8
Total Number of Fixed Files = 4
Total Number of Notification Files = 4
Total Number of Courrpted Files = 0
Total Execution Time = 3 Seconds.
this is my data.txt file body :
Notification Files :
file number 1
file number 2
unix command :
RECEIPIENTS="mm#gmail.com"
SUBJECT="!! testtt !!"
(cat Results.txt ; uuencode Data.txt Data.txt) | mailx -s "$SUBJECT" -c mm#gmail.com,dd#gmail.com -r zz#gmail.com $RECEIPIENTS
this is what i got after sending the email :
Total Number of Files = 8
Total Number of Fixed Files = 4
Total Number of Notification Files = 4
Total Number of Courrpted Files = 0
Total Execution Time = 3 Seconds.
begin 777 Data
M#0I.;W1I9FEC871I;VX#1FEL97,#.B -"#T*,2U#1$M(34LU2D]21DPP,#0R
M,#T*,BU#1$Q454]-2D]21DPP-S$Q- T*,RU#1$Q454]-2D]21DPP-S$Q-#T* M-"U#1$Q604Q-2D]21DPP-#0U, T*#0I&:7AE9"!&:6QE<R Z( T*#0HQ+4-$ M051'2SE*3U)&3# P,3$T#0HR+4-$051'2SE*3U)&3# P,3$U#0HS+4-$0TA.
C0U5*3U)&3#,Q.3DT#0HT+4-$0TA.0U5*3U)&3#,Q.3DU#0HU
end
note: if I use echo or echo -e or attach the file with uuencode without cat its worked fine, the problem only when I use cat with uuencode

Answer 1

There was a time in the last millennium when uuencode made sense, but you really should be using MIME instead in this day and age.
Here is a simple Python 3 script which combines a message from standard input with an attachment into a valid RFC822 message which you can send with sendmail or similar. It is rather closely based on the Python documentation's examples.
#!/usr/bin/env python3
from email.message import EmailMessage
import sys
msg = EmailMessage()
msg['From'] = sys.argv[1]
msg['To'] = sys.argv[2]
msg['Subject'] = sys.argv[3]
# Don't mess with the preamble, the documentation is wrong to suggest you do
msg.set_content(''.join([line for line in sys.stdin]))
with open(sys.argv[4], 'r') as attachment:
msg.add_attachment(attachment.read(), maintype='text', subtype='plain')
print(msg.as_string())
To use this in your example,
# If `sendmail` is not in your `PATH`, maybe add it.
# For example, if you have it in `/usr/lib/sendmail`
# and `/usr/lib´ is not in your `PATH`, you can add it with
#PATH=$PATH:/usr/lib
# Don't use upper case for private variables; check spelling of "recipients"
# To demo an example of sending to multiple addresses, adds a second recipient
recipients="mm#gmail.com,another#example.com"
subject="!! testtt !!"
python3 path/to/script.py "zz#gmail.com" "$recipients" "$subject" Data.txt <Results.txt |
sendmail -oi -t
You can leave out the pipe to sendmail to see what the message looks like. Instead of uuencode smack dab in the message body, it creates a multipart MIME message with two parts, one of which is inline and contains the text from standard input, and another which is properly tagged as an attachment. It's slightly bulky, but I'm including an example here just to show you.
From: zz#gmail.com
To: mm#gmail.com,another#example.com
Subject: !! testtt !!
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2189027902917283968=="
--===============2189027902917283968==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Total Number of Files = 8
Total Number of Fixed Files = 4
Total Number of Notification Files = 4
Total Number of Courrpted Files = 0
Total Execution Time = 3 Seconds.
--===============2189027902917283968==
Content-Type: text/plain
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Content-Disposition: attachment
Tm90aWZpY2F0aW9uIEZpbGVzIDogCmZpbGUgbnVtYmVyIDEKZmlsZSBudW1iZXIgMgo=
--===============2189027902917283968==--
The attachment is rather needlessly base64-encoded in this particular example; you can tweak the Python code if you absolutely need it to be human-readable (but then neither was the uuencode).
(Also, no idea why the body part has a separate MIME-Version: header -- that seems like a bug.)