Parsing logs to get count of emails sent per source?

get-help
1

Is it possible to parse the KumoMTA logs so that I can see how many emails were sent based on what source IP address?

4

yes, the egress_source name and local-to-kumod source address are logged in the log record. See Log Record - KumoMTA Docs

5

do I need to use Tailer to access that log? or maybe I am misremembering?

6

tailer is more for operator ad-hoc inspection. You can either write code to open the logs and zstd decompress it, or what most customers do, is setup a webhook to catch and receive the events

7

unfortunately this is retroactive, I’m trying to analyze something that occured over the weekend. so it sounds like I will have to zstd decompress it on order to do that

8

maybe not an especially helpful comment, you can probably do that with zstdcat file | jq SOMETHING :slightly_smiling_face:

9

perfect, that’s what I found for trying as well :slightly_smiling_face:

10

if you do come up with something helpful for that as a one-liner with jq, please share it and we can get that added as an example for the docs

11

will do. simply knowing to used zstdcat was mostly what I needed, everything else is just piping to jq sort and unic -q

12

hmmm if my egress_source and source_address are always null… I must be missing something?

13

are you filtering to Delivery records?

14

uhhh at this point I’m just trying to pull out ANYTHING from my logs to help me identify how an email got into my Kumo

15

someone open-relayed through my system, and I am doing damage control

16

based on the sender I have an idea of how much the sent and to whom, but I am kind of at a loss for the “how”. I’m sure it’s a mistaken firewall or auth entry, but I’d like to know what IP address connected inbound to cause it

17

this worked:
zstdcat 2025042* | jq -cr 'select(.type =="Reception") | .peer_address.addr' | sort | uniq -c | sort -nr | head -n 20

I was just looking at the wrong log before

18

There’s no way for me to see the current queue while kumod is stopped right? is there any way to pause it without starting it?

basically my concern is there’s a bunch of bad emails about to go out, and I’d like to analyze them without them continuing to send

19

we don’t have a super great way to stop all mail for this sort of situation. You could deliberately break DNS to prevent SMTP from working, doing something like this inside your init event.

kumo.dns.configure_resolver {
    name_servers = {
       '127.0.0.1:1234' -- bogus dns server on loopback port that doesn't exist
    }
}
20

that’s a clever way of doing it, thank you :slightly_smiling_face:

21

alright, I think I must be missing something.

I did this command:
/opt/kumomta/sbin/kcli bounce --everything --reason "maintenance"

but things are still piling up in the queue

22

these are not new, inbound requests (I firewalled off the server completely for that)