Re: [TUHS] off-topic list

[Grant Taylor via TUHS <tuhs@minnie.tuhs.org>]

On 06/24/2018 08:53 PM, Dave Horsfall wrote:
> Anyone with any concept of security will not be running Procmail;

I'm going to have to throw a flag and cry foul on that play.

1)  "Anyone (with)" is a rather large group.
2)  "any concept of security" is a rather large (sub)group.
3)  "will not" is rather absolute.

I do believe that I have a better concept of security than many (but not 
all) of my colleagues.

  - I've got leading (if not bleeding) edge email security.
  - I've got full disk encryption on multiple server and workstations.
  - I use encrypted email when ever I can.
  - I play with 802.1ae MACsec (encrypted Ethernet frames).
  - I use salted hashes in proof of concepts.
  - I advocate for proper use of sudo...
  - ...and go out of my way to educate others on how to use sudo properly.

I could go on, but you probably don't care.  In short, I believe I fall 
squarely in categories #1 and #2.

Seeing as how I run procmail I invalidate #3.

So, I ask that you retract or amend your statement.  Or at least admit 
it's (partial) inaccuracies.

> it's not even supported by its author any more,

Many of the software packages that TUHS subscribers run on physical and 
/ or virtual systems are not supported by their authors any more.  Some 
of them are directly connected to the Internet too.

How many copies if (Open)VMS are running on (virtual) VAX (emulators)? 
Don't like (Open)VMS, then how about ancient versions of BSD or AT&T SYS 
V?  How many people are running wide array ancient BBSs on as many 
platforms?

How many people in corporate offices are running software that went End 
of Support 18 months ago?

Lack of support does not make something useless.

> due to its opaque syntax

I'm not aware of Procmail ever having claimed to have simple syntax.  I 
also believe that Procmail is not alone in this.

m4 is known for being obtuse, as is Sendmail, both of which are still 
used too.  SQL is notorious for being finicky.  I think there's a lot of 
C and C++ code that can fall in the same category.  (LISP … enough said)

> and likely vulnerabilities

Everything has vulnerabilities.  It's about how risky the (known) 
vulnerabilities are, and how likely they are to be exploited.  It's a 
balancing act.  Every administrator (or company directing said 
administrator) performs a risk assessment and makes a decision.

> (it believes user-supplied headers

Does the latest and greatest SMTP server from Google believe the 
information that the user supplies to it?  What about the Nginx web 
server that seems to be in vogue, does it believe the verb, URL, HTTP 
version and Host: header that users supply?

Does Mailman that hosts the TUHS mailing list believe the information 
that minnie provides that was originally user supplied?

Does your web browser believe and act on the information that the web 
server you are connecting to provided?

Applications are designed to trust the information that is provided to 
them.  Sure, run some sanity checks on it.  But ultimately it's the job 
of software to act on the user supplied information.

> and runs shell commands based upon them).

I've seen exceedingly few procmail recipes that actually run shell 
commands.  Almost all of the procmail recipes that I've seen and use do 
a very simple match for fixed text and file the message away in a 
folder.  These are functions built into procmail and NOT shell commands.

The very few procmail recipes that I've seen that do run shell commands 
are passing the message into STDIN of another utility that is itself 
designed to accept user supplied data, ideally in a safe way.

So, I believe your statement, "Anyone with any concept of security will 
not be running Procmail", is false, literally from word one.

If you want to poke fun at something, take a look at SpamAssassin and 
it's Perl.  Both of which are still actively supported.  Or how about 
all the NPM stuff that people are using in web page that are being 
pulled from places that God only knows.



-- 
Grant. . . .
unix || die