We know how sender restrictions work. But, it’s not something I think is generally worth the effort to make more restrictive. Or, at least, I haven’t considered it worth the trade off in the past.
Adding restrictions makes it harder for local users and applications to send mail. Sending mail is already one of our biggest support burdens (search the forum for “can’t send mail”).
Our assumption is that your users are generally somewhat trustworthy and you’re keeping an eye out to make sure they aren’t doing something dumb and/or nefarious. You have their billing information (name, address, whatever), at the very least. You know who they are. And, for people doing mass-hosting, they probably handle mail in a different way (something centralized for efficiency).
And, this thread is also full of a lot of misunderstandings.
Mail to other users on the system is supposed to be accepted, whether from other local users or remote! It’s the mail server for those users, it is supposed to receive mail addressed to them. (Incoming mail should be checked for SPF and DKIM and whatever other spam filtering tools you’re using, of course!)
Even authenticated users can do tricky things with the From: address, and it’s kind of complicated to avoid that. The From: address does not come from the username used to log in to the mail server. From: comes from an email header added by the mail client or the script sending the mail. A user sending mail is not necessarily sending mail with their username. It is merely convention in a Virtualmin system that your email address and username match, and you can change it in mail you send. Again, it’s a bit more complexity than I like to prevent that.
All that said, it may be time to consider adding more restrictions on sending. I hate to think of how many more support requests about sending mail, especially from applications, we’ll get. But, when people’s expectations and mental model of how things work isn’t how things actually work, it gets ugly. (We can’t always fix the mental model, because nobody reads documentation, but maybe we can make things work a little more closely to how people expect.)
In short: No one should be surprised by the current behavior. It’s how mail has worked on Linux/UNIX systems forever. It is only vaguely a security issue; if you have malicious users, they can send mail from the system, and any mail from the system for domains hosted on the system will have an SPF record that looks legit (which is one a few reasons SPF isn’t sufficient, though it is helpful).
Nothing is stopping anyone from making it more restrictive, and there are several ways to do it, though I think some of the threat models being discussed here are kinda off-target and maybe wasting time fixing things that aren’t likely to be a problem. If you do have a user that is abusing the trust local users have to send mail, I would argue you should get rid of the user ASAP and with prejudice. It’s a good litmus test for a good citizen on a shared system.
