Re: Limit messages sent per unit time?
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.)? From my limited understanding of the few bits of code I read, around this and other mta options, those "limit" options seems to be global. There are other (global) knobs that maybe do something to the scheduling per domain or host, but I haven't tried any of those and I think they rather apply to retries. Check out ./usr.sbin/smtpd/limit.c, function limit_mta_set(). I ran a few rough grep(1)s through the sources, by guessing related strings, but I didn't find anything related to action or match. 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. [...] at least in the event an attacker only compromises a service I can still limit damage to the mail relay server IP address reputation. Mh... good thinking, I agree. I appreciate you sharing your reasoning :)
Re: Limit messages sent per unit time?
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
Re: smtpd.conf questions
Not sure if this applies to you, but I just gave an answer to Paul Pace's "Limit messages sent per unit time?" question on this mailing list, which might also help you. On Tue, Dec 05, 2023 at 10:32:20PM -0800, Sean Kamath wrote: Hi. I have a couple of (hopefully quick) questions about some max settings in smtpd.conf Recently, I tried to email 13 email addresses on Google, and they throttled me. I found that scheduling each envelop in the “mass mailing” individually went through just fine. So I’m wondering if I can make opensmtpd send at most N messages to google (but allowing the other mails to be sent at a “safe and sane” rate of the defaults). I found these three options, none of which I think will do what I’m hoping to do, namely set a max number of envelopes to be sent to a given MX at one time (I’ve had other MXes say “You’re sending too many recipients in one go” before, so it’s not just The Goog.) mta max-deferred number When delivery to a given host is suspended due to temporary failures, cache at most number envelopes for that host such that they can be delivered as soon as another delivery succeeds to that host. The default is 100. I’m unclear on what happens to messages over the number? Does it attempt to batch, at most, “number” envelopes at a time? This kinda sounds like what I want, except I was limited at the very beginning, so there were no successful deliveries to later try. smtp limit max-mails count Limit the number of messages to count for each session. The default is 100. It sounds like this is an incoming limit, where opensmtpd will accept at most count messages on one session, so no help here. smtp limit max-rcpt count Limit the number of recipients to count for each transaction. The default is 1000. This also sounds like an incoming limit, allowing up to “count” recipients to a single message. Again, no help here. Thus the only settings with “max” in them don’t appear to do what I need. Either I’m missing something, or some code would need to be written. Sean
Re: Limit messages sent per unit time?
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
Re: Limit messages sent per unit time?
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
