接受电子邮件作为应用程序输入的准则

Question

许多应用程序都有一个方便的功能，即允许用户回复来自应用程序的通知电子邮件。响应被返回到应用程序中。

例如，如果您正在构建客户支持系统，电子邮件可能会包含一些令牌，用于将响应链接回正确的服务票证。

实现这种类型的系统有哪些指导原则、提示和技巧？需要注意的潜在陷阱是什么？希望那些已经实现了这样的系统的人可以分享他们的智慧。

Answer 1

一些指导原则和注意事项：

地址问题:最好的做法是在电子邮件(myaddr**+custom**@gmail.com)地址中使用"+“扩展名部分。这使得路由更容易，但最重要的是，更容易跟踪到系统的地址路由。其他技术可能会在主题中使用标记

垃圾邮件：在应用程序之外处理垃圾邮件，并让应用程序根据标题进行过滤。

队列失败的消息：不，在大多数情况下。标准的电子邮件行为是尝试最多3天来传递一封邮件。对于应用程序电子邮件服务器，所有这一切都是创建巨大的邮件假脱机文件，您很可能永远不会处理这些文件。只有当失败原因不在您的控制范围内(例如，服务器关闭)时，才会对消息进行排队。

Invalid message handling：有多种方式可以使消息无效。一些是库的限制(它不能解析地址，即使它是RFC有效的地址)。其他原因是因为客户端损坏(例如，省略了某些标头周围的引号)。其他的可能太大，或者使用未知的编码，缺少关键的头部，有多个值而只有一个值，违反了一些特定于你的应用程序的语义，等等等等。基本上，Java mail API可能抛出异常的地方是错误处理情况，你的必须确定如何适当地处理。

错误响应：并不是每个错误都值得响应。有些邮件是由于垃圾邮件而生成的，您应该避免将邮件发送回这些地址。其他人来自自动化系统(您自己、假期应答者、另一个应用程序邮件系统等)，如果您回复，它将向您发送另一条消息，重复此过程。

客户端特定的黑客：与上面一样，每个客户端都有一些小的差异，这将使您的代码变得复杂。当您遍历消息的结构时，请记住这一点。

发件人、回复和循环：根据您的情况，您可能会收到来自以下来源的邮件：

自动系统管理员可能来自外部sources

• Mailing lists

• Yourself，或您自己的某个收件人addresses

• Other邮件服务器(退回、失败等)另一个系统中的别名实体(my-ldap-

@

• .com、addresses

• Other automated system

• an alias to a

• an alias to an alias

<>F231

现在，您的第一反应可能是“只接受来自正确来源的邮件！”，但这会让您非常头疼，因为人们会将最糟糕的东西发送到应用程序邮件服务器。我发现接受一切并明确否认例外会更好。

调试：保存您收到的任何消息的标头副本。这将在任何时候你遇到问题时提供极大的帮助。

-编辑--

我买了一本书，“构建可伸缩的Web站点”，这本书由rossfabricant提到。它--确实--有一个不错的电子邮件部分。它有几个要点是关于处理来自无线运营商的电子邮件和电子邮件的身份验证。

Answer 2

您可以设置发送电子邮件的地址，如果有人只按了“回复”，将在收件人地址中输入什么内容。让它变得独特，你就能知道它是从哪里来的，以及它必须返回到哪里。

当涉及到在它旁边放一个名字的时候，“这里的一些东西”--放一些有吸引力的东西，让他们直接回复邮件。我见过一个主要的网络应用程序，它的电子邮件捕获功能有“不回复”功能，这样人们就不会向它发送任何东西了。

Answer 3

编辑:我误解了你的问题。

您可以将您的电子邮件服务器配置为捕获所有邮件，并生成唯一的回复地址。例如，CST-2343434@example.com。

服务器上的轮询过程可以读取收件箱并从接收到的电子邮件中解析出相关部分，CS-2343434可能意味着客户支持票证ID为2343434。

我使用JavaMail API实现了类似这样的东西。

这只是个想法。