HTTP injection with long From display names

KumoMTA Policy
1

Hello,

I might have stumbled on an issue with header folding. We noticed these issues to happen with a customer who submits a very long display name.

In the JSON that we submit, it’s just a string in the from object:

"from":{"email":"redacted@redacted.com","name":"Redacted Redacted Redacted Redacted Redacted | Redacted Redacted Redacteddd"}```

Is this something that should be encoded before passing to the HTTP injection endpoint or possibly a bug in Kumo?

Thanks!
3

I’ll have this looked at, but of course will point out that if they needed folding to make it work then it’s not going to be very good UX when the recipient sees it in their MUA.

4

True!

5

Does that error reproduce with literally the json you provided? I cannot reproduce this using this construct in our lua test harness:

local ok, msg_or_err = pcall(kumo.api.inject.build_v1, {
  envelope_sender = 'no-reply@example.com',
  recipients = {
    { email = 'user@example.com', name = 'John Smith' },
  },
  content = {
    text_body = 'Hello',
    from = {
      email = 'from@example.com',
      name = 'Redacted Redacted Redacted Redacted Redacted | Redacted Redacted Redacted Redacted Redacted Redacted Woot Redacted Redacted Redacted Redacted Redacted Redacted Redacted Redacted Redacted Redacted Redacted',
    },
  },
})

print(msg_or_err[1]:parse_mime())
assert(not ok)

It generates a message that does successfully parse.

Please share more information, including the version of kumod that you are running.

6

Yep, well, except for it being something else than redacted, but I passed the exact amounf of characters.

However, upon looking closer at the error message, it is happening on this function:

    [C]: in local 'poll'
    [string "?"]:3: in method 'from_header'
    [string "/opt/kumomta/etc/policy/init.lua"]:504: in function 'prepare_message'
    [string "/opt/kumomta/etc/policy/init.lua"]:429: in function <[string "/opt/kumomta/etc/policy/init.lua"]:417>```

Which is:
```function prepare_message(msg)
    queue_helper:apply(msg)
    local signer = kumo.dkim.rsa_sha256_signer {
        domain = msg:from_header().domain,
        selector = 'lettermint',
        headers = { "From", "Reply-To", "Subject", "Date", "To", "Cc",
  "Resent-Date", "Resent-From", "Resent-To", "Resent-Cc",
  "In-Reply-To", "References", "List-Id", "List-Help",
  "List-Unsubscribe", "List-Subscribe", "List-Post",
  "List-Unsubscribe-Post", "List-Owner", "List-Archive" },
        key = {
            key_data = cached_get_key(msg:from_header().domain),
        },
    }```

We are on `2025.12.02-67ee9e96`.

Not sure if it is useful; but before when we used SMTP injection, this did not cause issues.
7

which are lines 417 and 429?

8

417 is http_message_generated:

-- Processing of incoming messages via HTTP
kumo.on("http_message_generated", function(msg)
    -- TM:1 Aug 2024 - added this to ensure Massage ID is added:
    local failed = msg:check_fix_conformance(
        -- check for and reject messages with these issues:
        "MISSING_COLON_VALUE",
        -- fix messages with these issues:
        "LINE_TOO_LONG|NAME_ENDS_WITH_SPACE|NEEDS_TRANSFER_ENCODING|NON_CANONICAL_LINE_ENDINGS|MISSING_DATE_HEADER|MISSING_MESSAGE_ID_HEADER|MISSING_MIME_VERSION"
    )
    if failed then
        kumo.reject(552, string.format("5.6.0 %s", failed))
    end

    prepare_message(msg)
end)

and 429 is the prepare_message there

9

I just implemented a change that pre-encodes the display name in RFC 2047 and that seems to have fixed this issue

10

FWIW, Fix an issue when rebuilding mailbox list headers with wrapped contents · KumoCorp/kumomta@213fb6f · GitHub should address this

11

The generated header is fine, but the issue was that the check_fix_conformance operation causes a rebuild to occur, and it would re-encode the header incorrectly

12

Aahhhh!

13

I think that this might be the same issue?

Failed to deserialize the JSON body into the target type: content: data did not match any variant of untagged enum Content at line 1 column 22971

14

I think it’s because there are some headers with special chars, e.g. brackets like {}

15

Ah, that one is possibly an error on my side

16

Might have found some more details:

Kumo uses BTreeMap<String, String> for the headers. In our case, this error happens when the same header key gets used multiple twice (same or different values doesn’t matter).

Not sure if this limitation is by design. Couldn’t really find if custom headers like this are limited in the RFC, they’re not restricted at least.

17

Most (all?) repeated headers are typically trace headers, so it is unusual to want to assign multiple headers with the same name at the point of injection

18

Ah check, it’s the case here as well indeed, in this case the values are also the same so deduping fixes it

19

Thanks for the help! I’ll try the new dev version locally asap

20

Hi Wez! Was going to try and test the dev build, but noticed this during http injection:
Error: task 131 panicked with message "set_meta_spool has not been called

was about to test if the long from name issue is fixed with the fix you mentioned earlier

21

sounds like you didn’t configure the spool?