Reducing I/O load for log disposition messages

KumoMTA Administration
1

I was wondering if it’s possible to somehow configure a separate spool for those messages? Currently their meta&data are spooled together with emails, and since every email gets at least 2 disposition events (Reception & Delivery or Bounce), this adds quite a lot of writes.

On another note, it looks like all the log disposition messages have the exact same content in data and in meta.log_record? If so, logging I/O load could be halved by not writing data files for them and just using meta.

3

I think if you’re willing to write some Lua, you might be able to set a filter event in https://docs.kumomta.com/reference/kumo/configure_local_logs/ that checks for the log record reception protocol and returns false if it finds it. also consider if you want some form of log-delivery logs (something on delivery failure say). also: i’m not a kumo expert or even using it in prod, check things for yourself, can’t do much followup. good luck!

4

log_hooks add some filter like this

 per_record = {
      -- SMTP and HTTP Incoming Monitoring, use for debugging only
      Reception = { enable = false },
      -- Rejected Incoming SMTP Command
      Rejection = { enable = true },
      -- Internal Delayed messages, use for debugging only
      Delayed = { enable = false },
      Any = { enable = true },
    },
5

I am writing quite a bit of lua :slightly_smiling_face: fwiw, we currently use deferred_spool = true with configure_log_hook, but that has some drawbacks regarding durability.

Idea was roughly something like

        name = 'logs',
        path = '/path/to/log/spool',
    }```
So that it would be possible to spread IO across multiple devices, like it's currently possible to do with configure_local_logs.
6

Oh I see! Somehow I read this as “can I suppress log-delivery events from local logs” but was totally wrong. My bad!

7

Getting it now–you might want much different perf/durability tradeoffs for the queue of mail you’re sending vs. the queue of disposition events to deliver.

8

Sorry for going down a blind alley there, resolving to learn to read in '26

9

(As part of my “learn to read” project, also now recognizing you wanted to tweak the location not the durability tradeoff.)

10

You could use a filter event and a second logging location. In the main logging location filter OUT any logs created by Lua and int the other only filer IN the ones generated by Lua.

11