root@t450s:~ # mail -s forward.conf paul < /etc/unbound/forward.conf
root@t450s:~ # sendmail -qf
root@t450s:~ # mailq
Mail queue is empty
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 aContent-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
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
The purpose is: sending a file with email from the command line (and without installing anything).It really helps if you really lived the 90's I guess.
uudecode
is also not a tragedy.I mentioned mail/heirloom-mailx only as a tool for making mime attachments. It seems there is indedBTW I didn't use mail/heirloom-mailx, but the standard /usr/bin/mail from base.
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.EDIT [FONT=monospace]hruodr[/FONT] gave the right answer to the Q in his 1st A right away, and all you did was nagging...
uuencoded mailbody with no content-type was never "deprecated" - it just didn't support macro-viruses.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.
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.uuencoded mailbody with no content-type was never "deprecated" - it just didn't support macro-viruses.
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).
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.
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.See RFC2045 for some background.uuencode
has always been non-standard:
This document also explains the reason to use base64 btw.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).
POSIX.1-2017 is simultaneously IEEE Std 1003.1™-2017 and The Open Group Technical Standard Base Specifications, Issue 7.
Once I spoke with a computer scientist, not a student, one with a good job, and he told me seriouslyIt'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.