So your question made me curious to read more of the source... and there
are actually multiple undocumented knobs, and there might be this one
that maybe works for you, e.g. put this in you smtpd.conf for a minimum
of 10s delay between MTA transactions:
mta limit session-transaction-delay 10
This would not start any new transaction before 10s passed since the
last one. I just gave it a try - submit n mails, observe that the first
one goes out right away, watch via smtpctl show queue that the other
ones are delayed (or use the tracing and debug flags when running
smtpd). If nothing was scheduled for longer than that, any new one gets
sent right away.
There are quite a few more knobs, unsure why they aren't documented but
this might be intentional, as you can probably seriously shoot yourself
in the foot changing some of those.
Hope this helps, but no guarantees there are no side effects.
PS: can't help but point out that if I understand your use case
correctly, this won't really prevent abuse, b/c if your system is
compromised, the attacker might also just modify the config, no?
On Sat, Dec 09, 2023 at 07:09:16AM -0800, Paul Pace wrote:
On 2023-12-06 19:47, Paul Pace wrote:
Is there a way to limit messages sent per unit time?
Maybe it's just not possible in OpenSMTPD?
My use case is I have a small cluster of servers that use a single
server as an SMTP relay. One of the servers hosts stuffs that have a
somewhat higher probability of being compromised, so one method I
would like to use to limit the potential damage done by a compromised
server is to rate limit messages sent, ideally by some number of
messages per unit time (probably 1 per 10 seconds, since it isn't
expected to send much mail).
Thank you,
Paul
