# Send the file to mail from the console.



## bagas (Mar 19, 2021)

Hello.
How to send a file to mail from the console.
By regular means.
Do not install mutt or similar software.


----------



## zirias@ (Mar 19, 2021)

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.


----------



## SirDice (Mar 19, 2021)

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.


----------



## hruodr (Mar 19, 2021)

bagas said:


> 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.


----------



## zirias@ (Mar 19, 2021)

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.


----------



## hruodr (Mar 19, 2021)

Of course will not set content-type. For sending as attachment he will probably need to install or write
other program, like heirloom-mailx.


----------



## zirias@ (Mar 19, 2021)

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.


----------



## hruodr (Mar 19, 2021)

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.


----------



## zirias@ (Mar 19, 2021)

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.


----------



## hruodr (Mar 19, 2021)

Zirias said:


> *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.


----------



## diizzy (Mar 19, 2021)

https://github.com/muquit/mailsend-go or something similar?


----------



## zirias@ (Mar 19, 2021)

hruodr said:


> 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`.


----------



## hruodr (Mar 19, 2021)

Zirias said:


> You _might_ be able to save the email to an individual file, manually strip the headers and use `uudecode`.


Right, and hence it is not wrong what I said.

This was the old way to send binary files, without mime.


----------



## zirias@ (Mar 19, 2021)

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…


----------



## hruodr (Mar 19, 2021)

Zirias said:


> And if your mail software doesn't support saving an individual mail


This worked with `mail` and mbox format, and sure will continue working.


----------



## hruodr (Mar 19, 2021)

Zirias said:


> And if your mail software doesn't support saving an individual mail


That software is then rubbish.


----------



## wolffnx (Mar 19, 2021)

use `ssmtp`

and send your file with 
	
	



```
/usr/local/sbin/ssmtp  dst@address < /file
```

you have to configure ssmtp.conf


```
root=my_account@gmail.com
mailhub=smtp.gmail.com:465
FromLineOverride=YES
AuthUser=my_account@gmail.com
AuthPass=one-time-password
UseTLS=YES
```


----------



## hruodr (Mar 19, 2021)

He wanted it by regular means, wolffnx. If he needs to relay, then better so:









						mail, metamail, gpg, openssl, sendmail, fetchmail, etc AS MAIL CLIENT
					

This thread is dedicated to simple command line tools as mail client for normal desktop users, in order to show that FreeBSD has a past and a future as desktop system.  My contribution is to configure sendmail as smart host, in order that one can use normal mail to send mails. Perhaps someone...




					forums.freebsd.org


----------



## zirias@ (Mar 19, 2021)

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.


----------



## hruodr (Mar 19, 2021)

Zirias said:


> 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.


----------



## zirias@ (Mar 19, 2021)

No, it isn't. It's for the *transfer* encoding (of "anything"), e.g. 8bit, quoted-printable, base64. Please stop spreading nonsense.

edit:


hruodr said:


> 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.


----------



## hruodr (Mar 19, 2021)

Zirias said:


> 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).


----------



## zirias@ (Mar 19, 2021)

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.


----------



## hruodr (Mar 19, 2021)

Zirias said:


> Ever heard of mailcap(4)?


The mailcap file appeared with *metamail*, it associates a viewer for many content types of the 
*attachments*, and attachements are parts of the body and normally 7 bit sent, but base64 or 
quoted printable encoded.

As far as I know, email has still 7 bit transfer, metamail does not work with 8 bit. That was the reason I
had to write the following program:



			https://chiselapp.com/user/hruodr/repository/Mpart2tar/index


----------



## hruodr (Mar 22, 2021)

Zirias said:


> 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.


----------



## zirias@ (Mar 22, 2021)

I guess you didn't get the message from me not responding any more, so here it is very explicit:
What you're talking about is most definitely NOT what the OP wanted, and I personally don't care about it.


----------



## Mjölnir (Mar 22, 2021)

Proof:

```
root@t450s:~ # mail -s forward.conf paul < /etc/unbound/forward.conf
root@t450s:~ # sendmail -qf
root@t450s:~ # mailq
Mail queue is empty
```
switch konsole tab to user paul

```
paul@t450s:~ $ tail -30 /var/mail/paul 
Local system status:
 3:26AM  up 1 day,  8:16, 6 users, load averages: 0.38, 0.61, 0.49

-- End of daily output --

From root@t450s.local.lan Mon Mar 22 16:14:25 2021
Received: from root (uid 0)
        (envelope-from root@t450s.local.lan)
        id 180190
        by t450s.local.lan (DragonFly Mail Agent v0.11+);
        Mon, 22 Mar 2021 16:12:33 +0100
To: paul
Subject: forward.conf
Date: Mon, 22 Mar 2021 16:12:33 +0100
Message-Id: <6058b3e1.180190.32b3fff2@t450s.local.lan>
From: <root@t450s.local.lan>

# This file was generated by local-unbound-setup.
# Modifications will be overwritten.
forward-zone:
        name: .
#       forward-addr: 1.1.1.1
#       forward-addr: 1.1.1.2
# OpenNIC recursing nameservers:
# ns24.de.dns.opennic.glue
        forward-addr: 5.9.49.12
# ns1.any.dns.opennic.glue
        forward-addr: 185.121.177.177
# ns3.any.dns.opennic.glue
        forward-addr: 169.239.202.202
```


----------



## zirias@ (Mar 22, 2021)

Sure, a *text* file can just be a mail body, why not. And if it happens to be in US-ASCII encoding, you don't even need a `Content-Type:` header.


----------



## ShelLuser (Mar 22, 2021)

Talk about useless discussions... _Sjeesj_. Op wanted to sent a file, so.. uuencode, sure it'll be a (plain) text email but that's what uuencode is generating in the first place. 

It really helps if you really lived the 90's I guess.


----------



## Mjölnir (Mar 22, 2021)

Zirias said:


> Sure, a *text* file can just be a mail body, why not. And if it happens to be in US-ASCII encoding, you don't even need a `Content-Type:` header.




```
root@t450s:~ # uuencode /etc/sysctl.conf 'contains UTF-8'|mail -s sysctl.conf paul
root@t450s:~ # sendmail -qf
root@t450s:~ # mailq
Mail queue is empty
```
switch konsole to user paul

```
paul@t450s:~ $ view /var/mail/paul
From root@t450s.local.lan Mon Mar 22 16:33:01 2021
Received: from root (uid 0)

From root@t450s.local.lan Mon Mar 22 16:33:01 2021
Received: from root (uid 0)
        (envelope-from root@t450s.local.lan)
        id 18008e
        by t450s.local.lan (DragonFly Mail Agent v0.11+);
        Mon, 22 Mar 2021 16:32:54 +0100
To: paul
Subject: sysctl.conf
Date: Mon, 22 Mar 2021 16:32:54 +0100
Message-Id: <6058b8a6.18008e.78466120@t450s.local.lan>
From: <root@t450s.local.lan>

begin 644 contains UTF-8
M(R`D1G)E94)31#H@<F5L96YG+S$R+C(O<V)I;B]S>7-C=&PO<WES8W1L+F-O
M;F8@,S,W-C(T(#(P,3@M,#@M,3$@,3,Z,C@Z,#-:(&)R9"`D"B,*(R`@5&AI
[...]
M<&%T8V@I('=E(&1U;7`@=&\@+V1E=B]G<'0O25)35"P@=VAI8V@@97%U86QS
D('!H>7,N(&UE;2X@<VEZ90HC(&1E8G5G+FUI;FED=6UP/3`*
`
end
```


----------



## hruodr (Mar 22, 2021)

ShelLuser said:


> It really helps if you really lived the 90's I guess.


The purpose is: sending a file with email from the command line (and without installing anything).
Also a binary file.

As you see in my previous posting, it is simpler than using a heavy mail client to attach a file and to
extract the received attachment. It helps today for transferring files with email. It is as good or
perhaps better than mime. It depends if the receiver is prepared to deal with the mail.

Either with mime or with uuencode, the binary file will be encoded. Mail clients may offer a decoding
that many users are not aware of when using mime, but using `uudecode` is also not a tragedy.

heilroom-mailx will be equally easy for attachig, but not for extracting the attachment. Alpine is more
comfortable.


----------



## Mjölnir (Mar 22, 2021)

BTW I didn't use mail/heirloom-mailx, but the standard /usr/bin/mail from _base_.
EDIT hruodr gave the right answer to the Q in his 1st A right away, and all you did was nagging...


----------



## hruodr (Mar 22, 2021)

Mjölnir said:


> BTW I didn't use mail/heirloom-mailx, but the standard /usr/bin/mail from _base_.


I mentioned mail/heirloom-mailx only as a tool for making mime attachments. It seems there is inded
nothing in base for using mail with mime, but even uuencode.


----------



## zirias@ (Mar 22, 2021)

Mjölnir said:


> EDIT _*[FONT=monospace]hruodr[/FONT]*_ gave the right answer to the Q in his 1st A right away, and all you did was nagging...


I'd offer a bet he didn't, but that would require SOME feedback from the OP. Anything besides MIME for sending files by mail has been deprecated for SOOO long, I'd be very confident in that bet.


----------



## PMc (Mar 22, 2021)

Zirias said:


> I'd offer a bet he didn't, but that would require SOME feedback from the OP. Anything besides MIME for sending files by mail has been deprecated for SOOO long, I'd be very confident in that bet.


uuencoded mailbody with no content-type was never "deprecated" - it just didn't support macro-viruses.


----------



## zirias@ (Mar 23, 2021)

PMc said:


> uuencoded mailbody with no content-type was never "deprecated" - it just didn't support macro-viruses.


It's not explicitly deprecated because it was never in an IETF standard for mail in the first place. Some sources use the word "obsoleted" instead. And "macro-viruses" aren't a feature of MIME but a bug in MUAs handling MIME in an insecure way (which typically involves HTML/Javascript as well). That's really a straw here.

See RFC2045 for some background. `uuencode` has always been non-standard:

```
It is impossible to be certain that a non-MIME mail message is
   actually plain text in the US-ASCII character set since it might well
   be a message that, using some set of nonstandard local conventions
   that predate MIME, includes text in another character set or non-
   textual data presented in a manner that cannot be automatically
   recognized (e.g., a uuencoded compressed UNIX tar file).
```
This document also explains the reason to use base64 btw.

Another source explaining how to encode files for mail uses this wording:


> The first popular solution on Unix-type systems was _uuencoding_. That method is mostly obsolete now (though you'll still find it used sometimes); it's been replaced by MIME encoding. The next two sections cover both of those -- though we recommend avoiding _uuencode_ like the plague.





			https://www.nnc3.com/mags/unix3/upt/ch21_12.htm


----------



## PMc (Mar 23, 2021)

Zirias said:


> See RFC2045 for some background. `uuencode` has always been non-standard:
> 
> ```
> It is impossible to be certain that a non-MIME mail message is
> ...


So the problem is actually that software cannot always detect the content in a fully automated manner, and therefore cannot decode it as html, fetch your banking password and send it to the originating rogue website in an automated fashion.
Okay, got that.

Now there was a time when we did perfectly well with uuencode. I remember getting some emacs sourcecode in 23 mails of uuencoded compressed archive.
Even more, at that time we also did actually talk to each other via mail, and there was great communication. Nowadays we only send spam nobody wants to read. So probably this is just a form-over-content issue, where the latter doesn't happen anymore.
[if cynism is found included, it can be dispersed at the discretion of the reader.]


----------



## hruodr (Mar 23, 2021)

uuencode/decode belongs to Posix standard:



			uuencode


----------



## zirias@ (Mar 23, 2021)

The Internet (IETF), and therefore mail as well, is not POSIX. But this "discussion" is nonsense anyways…


----------



## hruodr (Mar 23, 2021)

From https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/



> POSIX.1-2017 is simultaneously IEEE Std 1003.1™-2017 and The Open Group Technical Standard Base Specifications, Issue 7.


----------



## PMc (Mar 23, 2021)

The Open Group basically did just put a price tag onto what Berkeley does.

Maybe that's slightly too fast-forward, but it's actually how it is: IEEE and OpenGroup make their living by pronouncing standards, but Berkeley made the Internet work (and all the big commercial bodies forming OpenGroup have copied it from there).

It's a bit difficult looking for standards when you're already at the source - or, in this case more precisely, you _are_ the source.


----------



## hruodr (Mar 24, 2021)

Zirias said:


> It's not explicitly deprecated because it was never in an IETF standard for mail in the first place. Some sources use the word "obsoleted" instead.


Once I spoke with a computer scientist, not a student, one with a good job, and he told me seriously
that also mathematical theorems and their proofs get obsolated.


----------

