我正在编写一个编写电子邮件回复的程序。原始电子邮件可能已经是回复。我应该如何处理主题?
我已经看到了使用冒号之前的一切方法。这可能会影响一种情况re[2]:
。如果使用冒号方法。回复会变成Re:
,对方的电脑会失去计数。
如果不是,则回复将变为Re: re[2]
那么下一个回复可以re[4]
按预期进行。
Resending:
但是冒号方法对于您说并且下一个回复将变为的情况很有用Re:
。
你对此有意见吗?有没有标准或通用的方法来做到这一点?
我正在编写一个编写电子邮件回复的程序。原始电子邮件可能已经是回复。我应该如何处理主题?
我已经看到了使用冒号之前的一切方法。这可能会影响一种情况re[2]:
。如果使用冒号方法。回复会变成Re:
,对方的电脑会失去计数。
如果不是,则回复将变为Re: re[2]
那么下一个回复可以re[4]
按预期进行。
Resending:
但是冒号方法对于您说并且下一个回复将变为的情况很有用Re:
。
你对此有意见吗?有没有标准或通用的方法来做到这一点?
(完全没有上下文,很难提供一个具体的答案——您可能想在您的问题中提供更多信息)
大多数体面的邮件用户代理 (MUA)使用In-Reply-To:
标头来指示消息线程,而不使用诸如解析Subject:
标头之类的不安全操作。大多数此类客户端还具有适当的线程模式,其中不寻常的东西Re[2]:
充其量是不必要的。事实上的使用标准Re:
是简洁和内容之间的良好折衷,但在适当的线程支持下,它最终归结为美学。
只需Re:
在您自己创建的消息中使用 - 其他任何内容都必然会导致混乱。In-Reply-To:
确保为任何回复消息正确生成标题。
请不要从标题中删除内容。Subject:
例如,当适当的子字符串已经存在时,您可能会避免添加它Re:
,但如果您实际上是在删除字符串,您肯定会弄错,从而导致混乱的情况。
这不是一个严格的技术问题——不同的人有不同的偏好。在特定社区中,例如邮件列表,社交自动化 (sic) 将处理任何使用奇怪或令人困惑的约定的屡犯者。
试图自动处理这个问题必然会导致比它解决的问题更多的问题。此类问题也不是承运人(即邮寄系统)的责任。让您的系统保持简单并专注于真正的技术问题。
编辑:
损坏客户端(或用户 - 我一直不清楚)的常见案例是Re:
雪崩案例:
Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: What about that thing we were talking about?
是不是很诱人 MTA中的简单过滤规则,或回复 MUA 中的几行代码,雪崩会自动替换为漂亮的单行 Re:
!
在我看来,这是一种应该抵制诱惑的情况:
不能保证 MTA 是特定邮件使用的唯一路径。例如,当一些用户回复邮件列表消息时,他们会同时回复邮件列表和直接回复发帖人。自然,发帖人会收到两条消息,很可能是通过完全不同的路径。
您知道接收具有两个不同主题行的同一条消息是多么令人困惑吗?即使是基本的按主题排序也会失败。在我看来,即使是在主题上添加 、[SPAM]
或其他内容的垃圾邮件检测系统也在推动它。**SPAM**
$P@M
你能想象一个图书馆根据某种当地政策有选择地改变他们的书籍副本的标题吗?
即使您的 MUA “修复”了问题,其他人仍将使用旧主题,除非在回复您时。此外,您刚刚单方面创建了似乎是新线程的内容。正确的邮件客户端仍将正确显示线程,但视觉效果令人困惑。毕竟,您确实从您的回复帖子中删除了该主题的一个非常独特的功能,不是吗?
实际上,我记得一些有趣的话题,其中主题中的Re:
雪崩是开玩笑的讨论的一部分。你为什么要错过它?
当然,人们使用损坏的客户端。或者他们自己坏了。如果有人真的不合时宜,可以单独处理。只是不要使问题复杂化,不要理会我们的Subject:
标题。请?请问好看吗?