接受电子邮件作为输入到应用程序的指南 [英] Guidelines for accepting email messages as input to application

问题描述

许多应用程序具有允许用户响应应用程序的通知电子邮件的便利功能。回复将被退回到应用程序中。

A number of applications have the handy feature of allowing users to respond to notification emails from the application. The responses are slurped back into the application.

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

For example, if you were building a customer support system the email would likely contain some token to link the response back to the correct service ticket.

实现这种类型的系统有哪些指导方针，提示和提示？有什么潜在的陷阱要注意？希望那些实现这样系统的人可以分享他们的智慧。

What are some guidelines, hints and tips for implementing this type of system? What are some potential pitfalls to be aware of? Hopefully those who have implemented systems like this can share their wisdom.

推荐答案

一些准则和注意事项：

地址问题：最好的办法是使用电子邮件的+部分（myaddr**[e-mail]）地址。这使得路由更容易，但最重要的是更容易跟踪到系统的地址路由。其他技术可能会在主题中使用令牌

The address question: The best thing to do is to use the "+" extension part of an email (myaddr**+custom**@gmail.com) address. This makes it easier to route, but most of all, easier to keep track of the address routing to your system. Other techniques might use a token in the subject

垃圾邮件：在应用程序之外进行垃圾邮件处理，并根据标题使用应用过滤器。排队失败的邮件

Spam: Do spam processing outside the app, and have the app filter based on a header.

绝大多数情况下不排队。标准电子邮件行为是尝试最多3天来传递消息。对于应用程序电子邮件服务器，所有这一切都是创建您很可能永远不会处理的邮件的巨型假脱机文件。如果失败原因无法控制（例如，服务器关闭），则只排队消息。

Queuing failed messages: Don't, for the most part. The standard email behavior is to try for up to 3 days to deliver a message. For an application email server, all this does is create giant spool files of mail you'll most likely never process. Only queue messages if the failure reasons are out of your control (e.g., server is down).

无效的消息处理：有多个消息无效的方式。有些是库的局限性（即使RFC有效）也不能解析该地址。其他的是因为客户端（例如，省略某些标题的引号）。其他人可能太大，或使用未知编码，缺少关键标题，多个值应该只有一个，违反某些特定于您的应用程序的语义等等。基本上，Java邮件API 可以抛出异常是一个错误处理案例，你必须确定如何正确处理。

Invalid message handling: There are a multiple of ways a message can be invalid. Some are limitations of the library (it can't parse the address, even though its an RFC valid one). Others are because of broken clients (e.g., omitting quotes around certain headers). Other's might be too large, or use an unknown encoding, be missing critical headers, have multiple values where there should only be one, violate some semantic specific to your application, etc, etc, etc. Basically, where ever the Java mail API could throw an exception is an error handling case you must determine how to appropriately handle.

错误响应：并不是每个错误值得回应。有些是由于垃圾邮件而生成的，您应该避免将邮件发送回这些地址。其他来自自动化系统（您自己，休假回复者，另一个应用程序邮件系统等），如果您回复，则会向您发送另一条消息，重复此循环。

Error responses: Not every error deserves a response. Some are generated because of spam, and you should avoid sending messages back to those addresses. Others are from automated systems (yourself, a vacation responder, another application mail system, etc), and if you reply, it'll send you another message, repeating the cycle.

客户端特定的黑客：如上所述，每个客户端几乎没有区别，这将使您的代码复杂化。

Client-specific hacks: like above, each client has little differences that'll complicate your code. Keep this in mind anytime you traverse the structure of a message.

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

Senders, replies, and loops: Depending on your situation, you might receive mail from some of the following sources:

• 真实的人，也许来自外部来源


• 邮件列表


• 您自己或您自己的收件人地址


• 其他邮件服务器（退回，失败等）


• 另一个系统中的实体（[e-mail]，system-monitor @ localhost）


• 自动化系统


• 别名以上之一


• 别名的别名

• Real people, maybe from external sources
• Mailing lists
• Yourself, or one of your own recipient addresses
• Other mail servers (bounces, failures, etc)
• Entity in another system ([e-mail], system-monitor@localhost)
• An automated system
• An alias to one of the above
• An alias to an alias

现在，你的第一本能是可能只接收来自正确来源的邮件，但是这样会导致你头痛，因为人们会将最坏的东西发送到应用程序邮件服务器。我发现更好地接受一切并明确否认例外情况。

Now, your first instinct is probably "Only accept mail from correct sources!", but that'll cause you lots of headaches down the line because people will send the damnedest things to an application mail server. I find its better to accept everything and explicitly deny the exceptions.

调试：保存您收到的任何邮件的标题副本。这将有助于您有任何问题。

Debugging: Save a copy of the headers of any message you receive. This will help out tremendously anytime you have a problem.

- 编辑 -

我买了这本书，构建可扩展网站，由rossfabricant提到。它 - 有一个很好的电子邮件部分。关于处理来自无线运营商的电子邮件和电子邮件身份验证的几点要点。

I bought the book, Building Scalable Web Sites, mentioned by rossfabricant. It -does- have a good email section. A couple of important points it has are about handling email from wireless carriers and authentication of emails.

这篇关于接受电子邮件作为输入到应用程序的指南的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！