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,


Reply via email to