KumoMTA does not accept Content-ID

get-help
1

Below is just a snippet of the smtp-server tracer:

→
[194.223.63.122:50838->172.105.186.182:587] 291ms →
[194.223.63.122:50838->172.105.186.182:587] 291ms → --reXhCuc9
[194.223.63.122:50838->172.105.186.182:587] 291ms → Content-ID: ef1c86b51225aa75a861a4852f91e9dd@symfony
[194.223.63.122:50838->172.105.186.182:587] 291ms → Content-Type: image/png; name="ef1c86b51225aa75a861a4852f91e9dd@symfony"
[194.223.63.122:50838->172.105.186.182:587] 291ms → Content-Transfer-Encoding: base64
[194.223.63.122:50838->172.105.186.182:587] 291ms → Content-Disposition: inline;
[194.223.63.122:50838->172.105.186.182:587] 291ms → name="ef1c86b51225aa75a861a4852f91e9dd@symfony"; filename=Qyq9LftyW9\r
[194.223.63.122:50838->172.105.186.182:587] 295ms →
[194.223.63.122:50838->172.105.186.182:587] 295ms → iVBORw0KGgoAAAANSUhEUgAAAi4AAADeCAYAAAAaR4vvAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJ
[194.223.63.122:50838->172.105.186.182:587] 295ms → bWFnZVJlYWR5ccllPAAAMNxJREFUeNrsnQuUHHWd7/9V3TN5IGYi6q56lzQPXV2PZgb13Ku7h0zU

And teh error I get iss :

[194.223.63.122:50838->172.105.186.182:587] 300ms === smtp_server_message_received: Error: 552 5.6.0 invalid header: 0: at line 1:
ef1c86b51225aa75a861a4852f91e9dd@symfony
^________
expected ‘>’, found @

1: at line 1, in content_id:
ef1c86b51225aa75a861a4852f91e9dd@symfony
^_________________________________________

stack traceback:
[C]: in function ‘kumo.reject’
[string “/opt/kumomta/etc/policy/init.lua”]:270: in function <[string “/opt/kumomta/etc/policy/init.lua”]:234>

I know I am supposed to give miore info, but the initial question that I have is is there a known bug with Kumo not accepting this format of content id, i.e.: x@y. This is a standard content ID generated by Laravel.

I will gather all the required info if needed.

Here is the version: [root@mta ~]# /opt/kumomta/sbin/kumod --version
kumod 2024.08.18-84056ffb

Thanks in advance,
Stas

3

If looks like you are defining the content inside the html block. You need to define the content as an attachment and then refer to the content is inside the HTML block.

https://docs.kumomta.com/reference/http/api_inject_v1/#content

4

Yes, but this is not through the API this is one the of the ways Laravel generates embedded images in html, and they are sent over smtp, so I was curious if this is supposed to work, so whether this a bug, a conscious limitation or am I completely misunderstanding something.

5

Just confirming that we do have a fairly strict parser for the Content-ID header. However, it is only important when parsing and rewriting the message like you are doing in your policy. If you can ensure that the content coming into the system is valid, then you don’t need to use the check_fix_conformance method and won’t be blocked by this issue.

6

Resolved in mailparsing: relax Content-ID and Message-ID parsing · KumoCorp/kumomta@3d4a5d2 · GitHub

7

Thanks, @free-spirited-yorksh , @faithful-ostrich . You guys are awesome!!!