About max_message_rate

get-help
1

Hi Teams
Thanks in advance

Currently I’m starting to use KUMOMTA in production environment, and I’m now setting the maximum send based on tenant .
I set it in queue.toml

[tenant.'tenant1']
egress_pool = 'egresspool1'


[queue.'qq.com'.'tenant1']
max_message_rate = '15/m'

have a few questions to confirm

  1. Currently I am not using redis, and I have deployed 4 kumo instances. qq.com can send 60 messages per hour, so I have set up 15-m per node. Is this OK?

  2. According to the document, when making_egress_path, max_message_rate can also be set. Can I ignore this and only limit it based on max_message_rate set in queue.toml? limit only for every tennat.

  3. For emails that are already in the channel (not sent yet, all due to the error: ‘bulk delay of ready queue: too many successful connection failures where there was no answer from any hosts listed in MX’) the sending is paused. After I set queue.toml, will it still work, or do I need to clear the queue and resend it?

3

deepwiki’s answer:
https://gist.github.com/smsvip/2d77c75031972a30d912d3b3bb5daf82
https://gist.github.com/smsvip/c8e0274bbb2741b46d4d34b19d974d6a

4
  1. sure. doing the math manually is usually ok.
  2. yes. If you are using queues.toml, that is the same thing as configuromg make_egress_path
  3. Bulk failing happens when you have an extremely hi failure rate ( like 100%) typically due to network connectivity issues,
5
  1. It may be that the ISP temporarily restricted our ip because the same proxy is sent normally.
6

note that the queue-helper level only throttles the rate at which things move from the scheduled queue to the ready queue. It does not limit the rate at which messages move from the ready queue to the destination. Only the shaping helper controls that rate of egress.

So if you don’t use the shaping helper, and you have a lot of messages in your scheduled queues ready to go at once, you will likely be sending faster than you thought.

7

Hi Wez, if we use shaping helper, it can be based on tenant? I think each tenant is limited to 50/m, but if the entire system is limited to 50/m, it is too small.

8

most large scale senders will assign one source per tenant for this sort of use case and use the shaping helper to manage the egress that way. If you are using shared sources between multiple tenants you will need to set the per-tenant rate for entering the ready queue, and the shaping helper to manage the rate at which the associated source ip sends to the destination

9

I’m very interested in one source per tenant, is there any documentation? If it causes trouble, I’m very sorry.

Currently, my usage method is as described in the kumo documentation.

one tennat one egress_pool , egress_pool several ips

Multiple tennats expand downwards in turn.

Is the one source per tenant you mentioned another architecture?

10

There isn’t much to document, you simply set up “one source per tenant”.
To make that more clear, create a source called “XYZ” and put it in a pool called “XYZ-POOL”
Then assign XYZ-POOL to the Tenant in the queues helper.
That is only one way to do it, but is probably the easiest.

I’ll mention again that we could probably save you a lot of pain and time and effort with a PS arrangement :slightly_smiling_face:

11

Yes, we just do what you said , one tennat one egress_pool , egress_pool config several ips(source) .

“the shaping helper to manage the rate at which the associated source ip sends to the destination” I think it is important for me .

12

The format is in the shaping inheritance section:

The format is DOMAIN.sources.SOURCE so if you want to limit the deliveries per connection from “IP-1” to gmail.com, you would use ["gmail.com".sources."IP-1"]