电子邮件线程中自定义标头的持久性
我这可能是一个奇怪的问题，但我想我应该继续问。假设我通过特殊客户端使用 IMAP SMTP 发送电子邮件。该客户端在发送电子邮件之前会在电子邮件中添加一些自定义标头。收件人收到这封邮件并直接回复我（也许还有抄送的几个人）。
我的问题是：鉴于上面的示例，这些 X 标头是否会在线程内的所有新消息中持续存在？
我能想到的一件事是客户会知道它发送的原始电子邮件。此电子邮件的所有后续回复都将具有“Reply-To”标头，其值等于上一封电子邮件的“Message-Id”。我不明白为什么我无法爬行这些回复线程，直到我到达客户端发送的原始消息，从而派生出原始的自定义标头。
也许我想太多了。有什么建议吗？ :)
I this is probably a strange question, but I thought I'd go ahead and ask. Say, I send an email, using IMAP SMTP, through a special client. This client adds a few custom headers to the email message before sending it on its way. The recipient receives this email and responds to me directly (and maybe CC's a few people as well).
My question is this: Given the above example, would these X-headers persist throughout all the new messages within the thread?
One thing I can think of is the client would be aware of the original email message it sent. All subsequent responses to this email would have a "Reply-To" header whose value equals the "Message-Id" of the previous email. I don't see why I couldn't crawl up these thread of replies until I get to the original message sent by the client, thereby deriving the original custom headers.
Maybe I'm over-thinking this. Any suggestions? :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
消息回复不一定包含原始消息的任何内容。 MUA 可能会建议原始主题的修改版本（例如，前缀为“Re:”），并且显然这些地址也用于适当的默认值。消息的其他内容均不构成回复的一部分（除非发件人故意包含它，如引用或转发）。您消息中的任何 X- 标头肯定不会包含在回复中（除非您可以控制该 MUA）。
但是，您跟踪原始消息的计划当然是可行的：请参阅 RFC 5322< 的第 3.6.4 节/a>.每条消息都应该（不是必须）有一个 Message-ID 标头，并且在适当的时候应该有 In-Reply-To 和 References 标头。
In-Reply-To 被提及来标识正在回复的消息（或多个消息），而引用则标识整个对话线程。 References 标头旨在包含正在回复的消息的 References 标头的全部内容，因此您只需要最后一条消息即可识别整个线程。
请注意，In-Reply-To 和 Reply-To 不是同一件事（后者指定发件人希望将回复发送到的地址）。
假设您有原始消息，那么您应该能够使用任何回复的引用标头来识别原始消息。并非每个 MUA 都能正确处理引用或回复，但大多数都会。
A message reply does not necessarily contain anything of the original message. The MUA is likely to suggest a modified (e.g. prepended with "Re:") version of the original subject, and obviously the addresses are utilised for appropriate defaults as well. None of the other content of the message forms part of the reply (unless the sender deliberately includes it, as with quoting or forwarding). Any X- headers that you have in your message will certainly not be included in the reply (unless you have control over that MUA).
However, your plan of tracking the original message is certainly feasible: see Section 3.6.4 of RFC 5322. Every message should (not must) have a Message-ID header, and should have In-Reply-To and References headers when appropriate.
In-Reply-To is mention to identify the message (or messages) that is (are) being replied to, while References identifies the entire thread of conversation. The References header is meant to contain the entire contents of the References header of the message being replied to, so you only need the last message to identify the entire thread.
Note that In-Reply-To and Reply-To are not the same thing (the latter specifies the address that the sender wishes replies to be sent to).
Assuming that you have the original message, then you should be able to use the References header of any reply to identify the original message. Not every MUA will handle References or In-Reply-To correctly, but most will.
据我所知，没有理由认为任何电子邮件客户端都会传播它不理解的任何标题行。大多数人会保留主题（通常在必要时添加“回复：”）并从上一条消息的标题中派生出“收件人：”和“抄送：”行，但仅此而已。我想有些（但不是全部）会生成“In-Reply-To”行，但仅此而已。
您让客户端爬回线程寻找特定标头的想法听起来似乎是可行的，但如果您想要该功能，您必须编写自己的电子邮件客户端，并且您仍然会被阻止事实上，并非所有电子邮件客户端都以任何方式保留消息线程。
As far as I know, there's no reason to think any email client would propagate any header lines it doesn't understand. Most will preserve the subject (usually adding "Re: " if necessary) and derive their "To: " and "Cc: " lines from the previous message's headers, but that's about it. I suppose some (but not all) will generate an "In-Reply-To" line, but that's as far as it goes.
Your idea of having a client crawl back through the thread looking for specific headers sounds like it might be do-able, but you'd have to write your own email client if you want that feature, and you'd still be blocked by the fact that not all email clients preserve message threading in any way.