Send the file to mail from the console.

Hello.
How to send a file to mail from the console.
By regular means.
Do not install mutt or similar software.
 
Not at all. Implementation of attachments works with the MIME type multipart/mixed, and as the name MIME tells (Multipurpose Internet Mail Extensions), it's a set of *extensions* to email.

I don't know any base tool supporting the creation of a multipart/mixed email body.

Bottom line, just install mutt.
 
You'll need to use uuencode(1) on the file, provide the right MIME types and then you can feed all that to the mail(1) command as content. Not easy but not impossible to do either.
 
How to send a file to mail from the console.
mail mailadress < file

You can also use some options like -s for setting the subject header.

uuencode if the file is not ascii. You can also use a pipe.

If you use heirloom-mailx, then with -a you can send file attachements.
 
Sure, but this will create a mail containing ONLY the file as the body. I'd have to test, but I doubt it would set an appropriate Content-Type header either, so the receiving end might have troubles.

If this is for scripting, there are for example perl modules (like Email::Stuffer) allowing easy creation of MIME Emails.
 
Of course will not set content-type. For sending as attachment he will probably need to install or write
other program, like heirloom-mailx.
 
Setting the correct Content-Type and sending as an attachment (implicating Content-Type: multipart/mixed) are two different things. But without any Content-Type, software at the receiving side might just attempt to display the file as text.
 
To set content-type is very easy, sendmail, in opposite to mail, allows you to put the headers you want.
But that is not a solution, because content-type is a header of the mime-format, not of normal mail, and
then you will not be able to use normal programs to extract the file sent.

To write a program or script should not be very difficult, it is only concatenating some strings. The opposite,
extracting the file, is a little more difficult, you need to parse the string.
 
Yes, it's specified by MIME. But sure that's a "solution" if you just want to send a file (NOT as an attachment). You might need Content-Transfer-Encoding: base64 as well.

Anyways, bottom line still is: There is no base tool supporting creation of MIME Emails. The simple case of sending *just* a file might be possible with uuencode(1) *if* you also find a way to set the required headers.
 
*if* you also find a way to set the required headers
As said, sendmail as command, that is also called by mail, allows that.

But if the receiver knows that he received something uuencoded, then special headers are not necessary.
That was the old way to send binary files with mail.
 
if the receiver knows that he received something uuencoded, then the header is not necessary.
Wrong. The original email specification (RFC 822) is about text messages. In absence of any Content-Type header, any email software should consider the body as plain text and display it as such.

You might be able to save the email to an individual file, manually strip the headers and use uudecode.
 
Oh, sure. And if your mail software doesn't support saving an individual mail and your storage is good old mbox, you just attempt to copy the uuencoded blob out from there.

Give me a break… :rolleyes:
 
use ssmtp

and send your file with
Code:
/usr/local/sbin/ssmtp  dst@address < /file

you have to configure ssmtp.conf

Code:
root=my_account@gmail.com
mailhub=smtp.gmail.com:465
FromLineOverride=YES
AuthUser=my_account@gmail.com
AuthPass=one-time-password
UseTLS=YES
 
Could you stop writing all that fluff? An email without using at least a Content-Type header as specified in MIME is, by definition (rfc 822), plain text.

Sure you can do some trickery to extract a base64-encoded body manually and decode it, but this is most certainly not what the OP had in mind.
 
Sure you can do some trickery to extract a base64-encoded body manually
That is not necessary, because the base64 encoded file has markers at the beginning and end telling that
it is such an encoded binary file. markers play the role of the content-type header.

In any case, here is "content-transfer-encoding" the header that could help, but do not. I wrote once a
C pragram that inserts a mail in a sqlite3 db, and there were fields for the content of some headers like
this one. Then some MUAs can decode the contents, but it will show it as text, this header is for encoding
things like utf-8 as 7-bit ascii. It does not really help.
 
No, it isn't. It's for the transfer encoding (of "anything"), e.g. 8bit, quoted-printable, base64. Please stop spreading nonsense.

edit:
That is not necessary, because the base64 encoded file has markers at the beginning and end telling that
it is such an encoded binary file.
base64 is just the encoding. Only uuencode will add these markers. Then the mail is only intended for machines also using uuencode. (UU = Unix-to-Unix). There's a reason MIME was specified a LONG time ago.
 
No, it isn't. It's for the transfer encoding (of "anything"), e.g. 8bit, quoted-printable, base64. Please stop spreading nonsense.
If that field is base64, then the body will have a base64 encoded content. It is up to the MUA to decode it.
mail -f will not do it. Other MUAs yes, but show the decoded content as text. If a content-type
header with other content is there, perhaps it offer to download the file, I never tested it. But this is sure
not a reliable way, beginning with the problem that deppends on the MUA what is done with the content.
More reliable is to use uuencode and uudecode, if one knows something uuencoded was sendt.

BTW. The transfer of mail is always ascii 7 bit. Always. (unless something changed in last time).
 
Ever heard of mailcap(4)? What's unreliable (and cumbersome) is uuencode. There's a reason sending binaries THAT way has LONG been superseeded.

And, "BTW", no. mail nowadays is 8bit clean, Content-Transfer-Encoding: 8bit is a valid choice. It's not widely used because there's always the (very tiny) risk to have a transport somewhere on the way that isn't 8bit clean.
 
What's unreliable (and cumbersome) is uuencode.
BTW, it is not. Did you ever try it?

cat filename | uuencode name | mail address

Using a non-rubish mail client, you can pipe the mail to uudecode or save it
as file and apply:

uudecode file or uudecode -o newname file

You get the file as name or newname respectively.

No need to delete headers. As said, that was the way before mime. It worked and continues working.
 
Back
Top