On 4/01/23 19:33, Hébergement Arbre Binaire wrote:
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 is that sendmail(1) cannot possibly know if the message gets
accepted by Postfix until after it runs, this is because postdrop (and
by extension sendmail(1) submits the message by dropping a file in a
queue directory and it's only later that postfix "picks up" the file
(via the pickup service) and attempts to process 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 <http://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.
msmtp (as others have mentioned) is probably a good solution here, but I
would encourage you to switch as much as possible to port 587 submission
or 465 submissions as possible. You can control these connections with
SASL login and give each script a separate login if you want which will
give you much better control if a PHP script goes haywire (or gets
compromised) and starts submitting a bunch of spam. It basically means
you can block mail from one script instead of having to block it from an
entire system user, or even the entire system which would affect
multiple sources of mail.
Peter
