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

许多应用程序具有允许用户响应来自应用程序的通知电子邮件的便利功能.响应被重新回到应用程序中.

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

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

一些准则和考虑因素:

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

垃圾邮件:在应用程序外部进行垃圾邮件处理,并根据标头进行应用程序过滤.

排队失败的消息:在大多数情况下,请勿这样做.标准电子邮件行为是尝试最多3天来传递邮件.对于应用程序电子邮件服务器,所有这一切都是创建您很可能永远不会处理的邮件的巨型假脱机文件.如果失败原因超出您的控制范围,则仅排队消息(例如,服务器已关闭).

消息处理无效:消息可能有多种方式无效.一些是库的限制(它不能解析地址,即使它是一个有效的RFC).其他是因为客户端损坏(例如,省略某些标题周围的引号).其他可能太大,或者使用未知编码,缺少关键头,有多个值,只应该有一个,违反应用程序特定的某些语义等等,基本上,Java邮件API 可以在哪里抛出异常是一个错误处理案例,你必须确定如何正确处理.

错误响应:并非每个错误都应该得到响应.有些是由于垃圾邮件而生成的,您应该避免将邮件发送回这些地址.其他人来自自动化系统(你自己,一个度假应答者,另一个应用程序邮件系统等),如果你回复,它会向你发送另一条消息,重复循环.

特定于客户端的黑客攻击:如上所述,每个客户端都没有什么区别会使代码复杂化.遍历消息结构时,请记住这一点.

发件人,回复和循环:根据您的具体情况,您可能会收到以下某些来源的邮件:

真实的人,也许来自外部资源

邮件列表

你自己,或者你自己的一个收件人地址

其他邮件服务器(退回,失败等)

另一个系统中的实体(my-ldap-group@company.com,system-monitor @ localhost)

自动化系统

上述其中一个的别名

别名的别名

现在,你的第一直觉可能是"只接受来自正确来源的邮件!",但这会让你头疼不已,因为人们会将最大的东西发送给应用程序邮件服务器.我发现它更好地接受一切并明确否定例外.

调试:保存您收到的任何邮件的标题副本.只要您遇到问题,这将极大地帮助您.

- 编辑 -

我买了rossfabricant提到的"构建可扩展网站"这本书.它 - 有一个很好的电子邮件部分.它有两个重点,即处理来自无线运营商的电子邮件和电子邮件身份验证.