[RndTbl] "washing" a fork/exec to force all groups

[Trevor Cordes]

On 2023-04-18 Adam Thompson wrote:
> (SMTP email
> address validation, anyone?  Did you know you can legally put spaces
> in the middle of an address, for example?)

:-)

$REemail='(?:[\\x21\\x23-\\x27\\x2A-\\x2B\\x2D\\x2F-\\x39\\x3F\\x41-\\x5A\\x5E-\\x60\\x61-\\x7A\\x7B-\\x7E\\x{0080}-\\x{FFFF}]+(?:\\x2E[\\x21\\x23-\\x27\\x2A-\\x2B\\x2D\\x2F-\\x39\\x3F\\x41-\\x5A\\x5E-\\x60\\x61-\\x7A\\x7B-\\x7E\\x{0080}-\\x{FFFF}]+)*|\\x22(?:[\\x21\\x23-\\x5B\\x5D-\\x7E\\x{0080}-\\x{FFFF}]|\\x5C[\\x20\\x09\\x21-\\x7E\\x{0080}-\\x{FFFF}])*\\x22)@[\\x2Da-zA-Z0-9\\x{0080}-\\x{FFFF}]+(?:\\.[\\x2Da-zA-Z0-9\\x{0080}-\\x{FFFF}]+)+';

Captures most email possibilities, including spaces (in double quotes
is the rule).  However, currently won't allow plane 3+ UTF8 codes,
assuming those are even allowed in emails(?).  (Always looking to
improve this regex.)

> I'm far too old and tired to jump on the "latest hotness" bandwagon.
> But in this case, I've seen multiple MTA maintainers (I think I'm now
> up to... 5?) explicitly say "don't use procmail, it's unsafe".  I'm
> assuming this many specialists from this many different origins know
> something I don't.

Meh, I guess it has to be your "personal" group of specialists before
one really pays attention?  I'm pretty sure for 80% of the daemons,
languages, idioms, etc, I use you could easily find 5 specialists to
say it's "unsafe".

And if they think procmail is unsafe, then they should expound on
precisely why it is so and post bugzillas about it so someone can make
the CVEs!  Procmail (at least on my RHEL box) is still included as part
of the core supported product meaning we all have an obligation to
report sec flaws.

In a similar vein, is vim unsafe?  It gets dozens of CVEs every couple
of months.  emacs has had less than a handful in a decade.  Is emacs
unsafe?  It's still in the core repo of every distro.  Just because
less people use emacs, and the dev work is much slower, does that mean
"don't use emacs"?  How about this: maybe emacs and procmail were
written properly by far better programmers than vim.  Maybe dev has
slowed/stopped because they literally "did it all".  I have no idea if
this is true, but it's a possibility.  (I can't think of a single thing
I'd need that procmail doesn't already do.)  At least CVE count is more
of a measurable, objective measurement of "unsafe" than "I know 5 guys".

To be sure, I'm not saying your 5 guys are wrong, or that any one of
these things is better than the other, I'm just saying one might want
more to go on than anecdotal hearsay.  If I listened to that, I'd have
written everything in Java for the last 25 years (the horror!).

> In the modern era, I sadly agree.  Enter OpenSMTPd, which is rapidly
> growing enough features and corner cases to make it just as bad.

Yes, it is clear to me that is what happened with postfix.  They said
"oh it's easy to write a SMTP daemon that doesn't have insane m4
nuttiness and replaces sendmail", then they built the guts of it, and
then realized there's 800 corner cases and little niggling features
they have to support.

The funny thing is, the crazy stuff required for a real MTA these days
that was tacked on to sendmail is easier to deal with and almost seems
more elegant than postfix.  Once you find the magic documentation and
the magic letter you have to put in the magic macro, it tends to be
easier with less overall config changes than postfix requires.

At the very end of setting up postfix I was definitely left wondering
in about 5 obscure config cases "will this really do what I think and
not open-relay me?".  In sendmail I know for a fact an option is doing
what I want.  The postfix docs on the obscure options are also very
poor, written ambiguously (and maybe by a EASL which really doesn't
help when you need precision).

Maybe I sound bitter (moi?!), but I really thought by the hype that
postfix was utopia and infinitely superior.  Got disenchanted real fast.
Wasted a whole day replicating a very complex sendmail config in
postfix.  On the bright side, it was possible to do, rather than
reaching the all-too-common "it can't do XYZ that you absolutely need"
3/4's of the way through the job.

> think this just proves that SMTP should be taken out back and put out
> of its misery, but I don't expect to see that happen in my lifetime.

It's an interesting thought.  I think what really should have happened
was the sender should have been 100% separated from the receiver in
SMTP daemons.  Not just a separate process, but a separate config, or
even program.  And maybe the MTA-MTA comms completely broken out from
the MTA-MUA comms.  And maybe the private-MTA-public-MTA comms broken
out from the all-public MTA comms (by private I mean one controlled by
you basically acting like a MUA).  I have no idea how this could be
architected properly.  Maybe that's why it is what it is.

> Another option could be running your own (e.g.) Perl single-purpose
> MTA on another port; you already alluded to Postfix being the 2nd MTA
> on the system, do you need all of it, or it is just to support a
> single userid-to-pipe?

Ya, but in this case nope.  I need a full-blown MTA to do all the wacky
stuff in every direction with every option.  Only have so many static
IPs we can assign to MTA-like programs, gotta make them count.

I'll tell you something funny, and why I had to use a postfix
instance... You can run 2 sendmails on 1 system, and use 2 different
IPs.  BUT (and I only hit this at the very end of setting up the 2nd
sendmail) sendmail cannot set the *outgoing* (source) IP on a
per-daemon basis.  The 2nd daemon will always send from the first
available (i.e. main) system IP.  Apparently this might be fixed in a
future version.  Luckily postfix had an option for this.  (Yes, a VM
may have helped me here, but I don't virtualize, deal with it.  ;-)

I also found a way to simultaneously run sendmail and postfix on the
same box, which RHEL really really doesn't want you to do.  Haha,
that was the fun part.  Ya, I could have just run 2 postfixes, but I
trust sendmail more for the "more important" IP that must never break.

> What about just checking out the git repo, then?  Not to mention: how
> the heck are you getting git to reliably deal with userids and
> groups?  That's very explicitly *not* something git cares about.

Haha, *you* probably know the answer to that.  I wrote my own git hooks
/ system for dealing with perms in a git repo.  Definitely not for
linux-kernel type dev situations, but perfect for my project with a
limited number of devs and a mostly-moves-forward few-branches dev
strategy. It really has been perfect for several years now.  Yes, that
means git is also my deployment tool.  git push Live and the new
version is live in 3s.

It was MUUG guys on this list that gave me all the ideas a few years
back when I didn't know squat about git.  P.S. Switching to git was the
best move I ever made.  Recommended, though there will be some
wall-head-bashing, guaranteed.

> It's designed to do all the filtering things that a normal procmail
> user would be using it for.  Probably not going to help you much.  Ofc
> I still don't understand why you need procmail at all, when aliases(5)
> supports pipes directly.

Yes, the more I think about it, the more your alises idea seems the way
to go.  I simply didn't know about that feature, though I guess I
should have as a mm admin for 20 years.  Doh.  The key will be if
postfix really does have that option you mentioned that really will
make it not drop the supplementary groups.  I will try that next!  Love
the idea of cutting out the "middleman" programs where possible.

TBH after my sudo fix my interest became more in grokking the
fundamental issues regarding this group behavior.  Postfix ticked me
off; and I love a good unix-y problem to boot.  If you ever find the
rationale for the "feature", post it to the list!  Till then, it's as
good a feature as PHP 8's "warning: use of uninitialized array index"
feature.  Hahaha.