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.