Adding the final sending server to a header

get-help
1

Hey Peeps - sorry if this has already been asked or dealt with, i couldn’t find anything related.

Is it possible to append the details of the ip that finally sent the message to the final message headers, for example a custom header we use internally here to identify stuff?

I know there’s other ways to do this, so apologies, i just don’t understand how we can hook into the process at the point between ip being selected, and the message being sent.

Thanks!

4

By this do you mean the actual external IP after NAT?

5

yep so once its picked a pool, and then an ip in that pool, can we hook into that process there

6

guess its jus before it enters the queue

7

You’ll get all this:

"egress_pool": "pool0",

    // The name of the selected egress source (a member of the egress pool)
    // used for the delivery
    "egress_source": "source2",

    // For SMTP delivery, the source address (and port) that was used.
    // (*Since: Version 2024.09.02-c5476b89*)
    "source_address": {
        // The source address. The port number may be unknown and reported
        // as zero when using a proxy protocol.
        "address": "10.0.0.1:53210",
        // If a proxy protocol was used, this field will be
        // set to its name. It may be null/not set for no proxy,
        // "haproxy" or "socks5".
        "protocol": "socks5",
        // If a proxy protocol was used, this field will be
        // set to the proxy server address. It will be null/not set
        // when no proxy was used.
        "server": "192.168.1.1:5000"
    },

But if that is NAT mapped you’ll have to figure out the rest. I have external IP awareness on the roadmap but it hasn’t had a sponsor yet.

8

Yep we get all that back from hooks etc which is amazing, but what we really want to do is add a custom header to the mail headers before its sent

X-Sending-Server: xx or something similar

9

Told you its a weird request :grinning_face_with_smiling_eyes:

10

Aah. What do you do with that information after?

11

Weve traditionally just used it for tracking more obscure stuff further down the line

12

So if something goes wrong with a message and you get a bounce?

13

If so look at Configuring Feedback Loop Processing - KumoMTA Docs

14

Mike thanks, im an idiot. I have a related question, we also wonder if the return-path address can be adjusted at the point of send also. So we handle return-paths traditionally like useridentifier@mailx.domain.com

15

But now we are kind of stuck with useridentifier@domain.com as we wont know which server will be picked up front

16

What I’ll say is that’s not a typical request.

17

ordinarily would you expect the return path to just be top level domain

18

RFC doesn’t require that the EHLO host be part of the return path.

19

Ok thats ok - we just figured it would be best to seperate as much out as we could between hosts

20

In the meantime I’m looking for the right hook.

21

Thank you, i have scoured your docs believe me, i couldnt find it - that doesnt mean much tho :slightly_smiling_face:

22

If you look at orgs like Sendgrid and whatnot it’s typical that the EHLO hostname reflects the ESP, and the return path and friendly from reflect the tenant.