This is very helpful, thank you.
On 12/9/23 8:26 AM, Tassilo Philipp wrote:
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
Is there any way to limit where this is implemented? Such as only
sessions from a specific server (via tag, action, match, etc.)?
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?
My current understanding is we could consider some different levels of
compromise:
1. Only the service is compromised (e.g., PHP) - this would limit
message sending to how the server is configured to send mail.
2. The root user is compromised - this would limit message sending with
the server, itself.
In scenario 1, only the mail relay server can be used for sending
messages. The service compromised does not have root privileges and
there are not other configured methods for sending mail (the firewall
does not allow destination port 25 on the external interface).
In scenario 2, the compromised server can be used for sending spam
because root has been compromised so the firewall rules can be
rewritten, but the separate mail relay server still can be used for
sending spam and likely has a decent reputation.
In both scenarios I would like to limit the damage done to the mail
relay server. Even if the above rule is only applied to client server,
at least in the event an attacker only compromises a service I can still
limit damage to the mail relay server IP address reputation.
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
