On Wed, Jan 04, 2023 at 12:25:47AM -0500, Hébergement Arbre Binaire wrote:
> I don't know if this could be put to consideration by your dev team (or
> not, because of technical considerations above my knowledge), but a single
> door to a barn makes a more secure barn.
My "dev" team is just me, and ditto with Wietse.
> If external and internal clients could be treated as equally at risk
> of abuse, security would be much improved and a single set of
> parameters could then be used to regulate mail flow from any source.
As already explained, the local submission interface via sendmail(1) is
not sufficiently expressive to admit fine-grained access control. The
feedback channel is too crude, and clients are too minimal to sensibly
handle selective rejects.
Again, if you want filtering, have the clients use SMTP, either because
they are using some abstract API (in PHP or whatever), where that API
can be configured to use SMTP, deal with rejection, ...
Or deploy a sendmail(1) shim, to also cover submission by any and all
command-line programs outside managed code bases. What the shim should
do when submission is rejected, is a mystery to me. Sure it would return
a non-zero exit code to the client (ideally compatible with sendmail's
<sysexits.h>), but this leaves most clients entirely unprepared to do
anything other than just silently lose the message (some might syslog
the loss).
--
Viktor.
