I just don't understand the process: if a local client uses sendmail to enqueue an email, that client is not expecting much more than a zero or non-zero response code. If the shim is set up to communicate using SMTP and Postfix responds that it will not enqueue mail from localhost because of "Too many mails" like it does to remote clients, then that shim just issues a non-zero code and that's it.
The problem for me is not well behaved SMTP scripts (PHP or other). At the moment I know that if a PHP script uses SMTP and I have those 3 lines in main.cf, that script will be rate limited (I hope I'm right): anvil_rate_time_unit = 60s smtpd_client_message_rate_limit = 1 smtpd_client_event_limit_exceptions = Legacy or rogue scripts using sendmail directly are the ones concerning me. I could selectively disable the mail() function but it's not always possible. I was trying to find a single centralized solution for mail throttling with proper reporting of abuse. Le mer. 4 janv. 2023, à 00 h 37, Viktor Dukhovni <postfix-us...@dukhovni.org> a écrit : > 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. >
