mjl-
Feature Request: add X-Original-To header to messages
In certain cases like group emails or BCC (Blind Carbon Copy), the destination address may not appear in the email headers visible to the recipient. In the case of BCC, the email server removes the BCC addresses before delivering the email, so recipients can't see them. For group emails, a single email may be sent to a group address, and the individual members of the group may not be listed in the headers.
The actual delivery addresses for these emails are communicated during the SMTP transaction between email servers, and they don't appear in the headers of the individual email messages stored in the recipients' inboxes.
It would be nice to have mox get the delivery address at the SMTP level and add it as X-Original-To header.
Proton Mail has these 3 headers alway present on top:
Return-Path: [email protected] X-Original-To: [email protected] Delivered-To: [email protected]
This feature is invaluable, especially when using catchall addresses. With other solutions, I've had to painstakingly sift through all headers, sometimes finding no clues at all.
Return-Path: [email protected] X-Original-To: [email protected] Delivered-To: [email protected]
Would the X-Original-To different from the Delivered-To address in some circumstances?
The Delivered-To header has recently been added with the SMTP "RCPT TO" address during delivery. That's this commit: https://github.com/mjl-/mox/commit/0fc59af9a82dd5f240032934ac7522efe0328a5a.
If I understand correctly, Delivered-To is a valid address configured for an account.
X-Original-To would be the address the message was sent to.
Example:
-
[email protected]send a message to[email protected] -
domain.comhas catchall enabled and delivered to[email protected]
Return-Path: <[email protected]>
X-Original-To: [email protected]
Delivered-To: [email protected]
Another example, one sets up email forwarding from a Gmail account to an address on mox, the headers would indicate this transition. The Delivered-To field would identify the ultimate mox recipient, whereas X-Original-To would display the Gmail address that initially received the email.
I looked into X-Original-To a bit more just now. I couldn't find any place that specifies its behaviour. I did find a mention in the postfix documentation about how they treat it, although it is light on details, see https://www.postfix.org/local.8.html:
prepends an X-Original-To: header with the recipient address as given to Postfix, prepends an optional Delivered-To: header with the final envelope recipient address
I'm interpreting that as if X-Original-To is the SMTP MAIL TO, and Delivered-To is the address found after resolving internal rewrites/forwards (so Delivered-To would be the same as X-Original-To if there are no rewrites).
Then we have relatively new experimental RFC 9228, https://datatracker.ietf.org/doc/html/rfc9228. It seems to say local/internal rewrites should also be give their own Delivered-To header for recording, see point 2 in https://datatracker.ietf.org/doc/html/rfc9228#section-4.
In mox, we don't do internal rewrites. And the Delivered-To field must be a valid address, so we cannot have the mox-internal catchall address there. Mox always sets it to the SMTP RCPT TO address.
I don't think the [email protected] from your example exists for a mox account. Accounts can have multiple addresses, but there is no primary address for an account. Hypothetically, there could also be one specific address in domainA.example, and a catchall in domainB.example, so it would be weird if an smtp transaction to [email protected] would result in a header "Delivered-To: [email protected]". Currently, mox will add just one "Delivered-To: [email protected]". So that's the address from the SMTP RCPT TO. If mox were to add an X-Original-To, it would currently be the same as Delivered-To.
So unless X-Original-To is required by someone/something (e.g. software that cannot be configured to look at Delivered-To), I currently think it would be better to not add an X-Original-To, especially since there is no specification for its behaviour.