Send the file to mail from the console.

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.
 
Proof:
Code: 
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
Code: 
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
 
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.
 
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.
 
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.
Click to expand...
Code: 
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
Code: 
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
 
ShelLuser said:
It really helps if you really lived the 90's I guess.
Click to expand...
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.
 
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.
Click to expand...
uuencoded mailbody with no content-type was never "deprecated" - it just didn't support macro-viruses.
 
PMc said:
uuencoded mailbody with no content-type was never "deprecated" - it just didn't support macro-viruses.
Click to expand...
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:
Code: 
   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.
Click to expand...
 
Zirias said:
See RFC2045 for some background. uuencode has always been non-standard:
Code: 
   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.
Click to expand...
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.]
 
The Internet (IETF), and therefore mail as well, is not POSIX. But this "discussion" is nonsense anyways…
 
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.
 
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.
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top