To header with HTTP injection

KumoMTA Policy
1

Hello,

We use single transactions for VERP, but noticed that when an email has e.g. To and Cc, the final generated email to for example the Cc recipient, overwrites the To header as it seems that KumoMTA generates this based on the envelope recipient. Is that correct?

I believe this isn’t the case when using the “content” property in the HTTP injection endpoint.

Is there a way to prevent overwriting the To header?

3

For now I think this Lua script in http_message_generated works:

    local to_values = msg:get_all_named_header_values('To')
    if #to_values > 1 then
        local our_to = to_values[#to_values]
        msg:remove_all_named_headers('To')
        msg:prepend_header('To', our_to)
    end

The one we added is always the “last” one, which is why this works.

4

We had another user mention something simlar recently. How do you think the interface should change to accommodate this?

Perhaps the simplest thing we could do is to not generate a To header for a recipient if it is was already set in the message.

5

I think that would be easiest as well, or if you want it to be more explicit, allow to either provide it as envelope object (maybe with other envelope properties?) or separate properties for to/cc

6

fix generating multiple To headers with http injection API · KumoCorp/kumomta@d0e8e1e · GitHub is what I went with for this

7

That’s awesome, thanks!

8

if I provide the header via the content, it gets pushed to new_unstructured, this triggers qp_encode here and that encodes the entire address in RFC 2047 instead of correctly RFC 5322 like the auto-generated To does when I don’t provide my own header

9

not sure if my understanding is correct

10

basically, in this case I am providing a structured header to the HTTP injection API but it is treated as unstructured