如何“回复此电子邮件发表评论”像脸书一样？
我正在开发的一个类似论坛的应用程序会在收到新回复时向线程发起者发送电子邮件通知。如果所有者可以回复电子邮件以向线程添加新回复，那就太好了。
我怎样才能像Facebook一样实现“回复此电子邮件发表评论”功能？
选项 A：扫描主题行/正文？我不喜欢它，因为如果用户错误地修改了主题行怎么办？
选项 B：使用链接到线程 ID 的唯一回复电子邮件地址。这是邮件服务器的常用功能吗？比如设置一个 *@addComment.domain.com ？或者应用程序服务器是否需要在发送带有回复的电子邮件之前设置一个新的电子邮件帐户？
还有其他选择吗？
谢谢！
A forum-like app I'm working on will send an email notification to the thread starter when a new replied is received. It would be nice if the owner can just reply the email to add a new reply to the thread.
How can I implement the feature, i.e. "reply to this email to comment" like Facebook?
Option A: scan the subject line/body? I don't like it 'cause what if the user modified the subject line by mistake?
Option B: use a unique reply-to e-mail address that links to the thread ID. Is this a common function for mail server? like set up a *@addComment.domain.com ? Or does the app server needs to setup a new email account before sending the email with reply-to?
Any other options?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
系统用户可以轻松删除主题和正文中的字符串。
使用加号寻址（[电子邮件受保护]) 作为回复地址邮件消息。使用 CFIMAP，您可以检索消息并解析 TO。
通配符域（[电子邮件受保护]) 也是一个选项，但如果您电子邮件服务器支持加上寻址我会走那条路。
Using strings in the subject and body can be easily erased by a user of the system.
Use plus addressing ([email protected]) as the REPLY-TO address in the mail message. With CFIMAP you can retrieve the messages and parse the TO.
Wildcard domain ([email protected]) is also an option, but if your email server supports plus addressing I would go that route.
您可以将线程 ID 或父消息 ID（正在回复的消息）填充到电子邮件的 Msgessage-ID: 标头或自定义电子邮件标头中，并在接受消息后进行处理。
但是，使用自定义 Reply-To: 地址非常常见。
You could stuff the thread ID or the parent message ID (the message that is being replied to) in the Msgessage-ID: header of the email, or a custom email header, and put the processing after accepting the message.
However, using custom Reply-To: addresses is quite common.
一个选项是在原始电子邮件的主题和正文中嵌入标识符。一些小的东西，比如 bit.ly 的 6-8 个字符代码。这样，他们就不太可能把事情搞砸，并且您可以保证电子邮件正文的安全，而大多数人无论如何都会保留电子邮件正文。
an option is to embed an identifier in both the subject and the body of the original email. something small, like bit.ly's 6-8 character code. that way, they're less likely to mess it up, and you have the safety of the email body, which most people leave in anyway.
不建议使用自定义电子邮件标头，因为不能保证沿途的任何服务器不会将其剥离（或根本无法将其传递）。一位曾在 AT&T 大型电子邮件数据中心工作的朋友表示，那里的技术人员警告他不要有这个想法。
这也可能适用于 Message-ID： -- 不知道。
Using a custom email header is not advised as there is no guarantee that any server along the route would not strip it off (or simply fail to pass it on). A friend who worked at a huge email data center for AT&T said the techs there warned him off that idea.
This may also be true of the Message-ID: -- don't know.