mirror of
https://github.com/axllent/mailpit.git
synced 2026-04-26 00:35:51 +03:00
[GH-ISSUE #463] Suggestion: Don't change Message-ID to Message-Id #298
Labels
No labels
awaiting feedback
bug
docker
documentation
enhancement
github_actions
invalid
pull-request
question
stale
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/mailpit#298
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ThomasLandauer on GitHub (Mar 12, 2025).
Original GitHub issue: https://github.com/axllent/mailpit/issues/463
Am I right that you're converting the
Message-ID:header's name toMessage-Id:?According to RFC 5322, the name is
Message-ID, so I'm suggesting that you don't change it.@axllent commented on GitHub (Mar 12, 2025):
Hi @ThomasLandauer - can you please be a bit more specific where exactly you are meaning? Mailpit adds a
Message-Id(I note your point below) if there is none, and it overwrites theMessage-Idwhen releasing mail, however other than that it doesn't convert any of them as far as I can recall.Yes, you are correct, I will look into this. Before I do though, could you please provide more info to my question above? Thanks.
@ThomasLandauer commented on GitHub (Mar 12, 2025):
When an incoming message contains this header:
In Mailpit's web interface, when I click the "Headers" tab, I see
Message-Id. And when requesting this info via an API call, I think it has to be requested asMessage-Id.@axllent commented on GitHub (Mar 13, 2025):
Oh I see what you mean. Hmm, this is a tough one because those headers are extracted & grouped via another package. Given that there can easily be inconsistency in the header casing (even within the same message), these header keys are programmatically Pascal-cased (ie:
mesSaGe-iDbecomesMessage-Id). You'd be surprised how manyMessage-Idinstead ofMessage-ID,CCinstead ofCc,BCCinstead ofBccheaders there are, so strict parsing (which no system does) would break many, many messages.Whilst I'm sure I could potentially modify some of these before returning the information via the API, changing this type of behavior would also potentially break other existing integrations which test for
Message-Idin headers response. So, whilst I totally get your point (and you're not wrong), I can't change do that.I can however ensure better consistency when overwriting or adding a
Message-IDheader (viamailpit sendmail& releasing messages) which your point made me realise.@ThomasLandauer commented on GitHub (Mar 13, 2025):
I'm not surprised - that's why I don't suggest strict parsing ;-)
But you have to be aware: If you parse a message with
Message-IDand present it asMessage-Id, you're kind of telling people that this would be the correct/recommended casing.As far as I see,
Message-IDis the only affected header. So what you could do is just relabel this one (from the other package's output).If possible, keep
Message-Idas alias (for backwards compatibility), but raise some deprecation note somewhere.@axllent commented on GitHub (Mar 13, 2025):
Absolutely, I understand exactly what you are saying, although I wouldn't fully agree on this being used as a source of truth. The message(s) API returns the
Message-IDasMessageID, and that doesn't tell people it should actually be called that.As it currently stands, these headers are currently a 1:1 output of the default (built-in) mail parsing package within Go.
To further my point, headers such as
List-ID=>List-Id,ARC-Message-Signature=>Arc-Message-Signature,DKIM-Signature=>Dkim-Signature,X-TUID=>X-Tuid- they all are rewritten in the exact same (but consistent) manner asMessage-IDI honestly do not feel I can (or should) do something special to change (or duplicate)
Message-Id. I do agree with you, it's not what the RFC says, but there is a consistency between all these headers, and if I was to change one, then I should change them all (except I'll never get them all), and adding a duplicate header field will also appear like theMessage-IdandMessage-IDis duplicated in the header (which is even more misleading).Do you understand my point?
@ThomasLandauer commented on GitHub (Mar 13, 2025):
Yeah, sure I understand.
Maybe you could open an issue at Go - maybe they have an idea? (I would open it myself if I had any knowledge of Go...)
@axllent commented on GitHub (Mar 14, 2025):
I believe that anyone requesting a change to the default behavior would likely be denied. As I mentioned earlier, Go consistently returns all headers, regardless of their nature. While the casing of the
Message-IDfield may not comply with RFC standards, it’s important to note that it was never claimed to be RFC-compliant. The same applies to Mailpit's header responses; these are simply JSON object keys used to reference their values. If you need theMessage-ID, you should useMessage-Idin your automation. Altering the casing in the web UI could also create confusion for developers looking to integrate with the API and using the web UI as a reference.Additionally,
Message-Idis actually very commonly used (and thus supported), regardless of RFC specifications. I checked my personal emails and found that 35,502 out of 132,393 (27%) use Message-Id instead of Message-ID.I appreciate your input, but I won’t be pursuing this further, as the drawbacks of making this change far outweigh any potential benefits.