什么是解析带有错误描述的电子邮件的最佳方法。一位客户最近决定，如果用户能够向已知邮箱发送电子邮件并且错误将在错误跟踪器中注册（不完全关闭），这将是一件好事。
问题是错误描述有很多字段，如日期、时间、描述、评论、丢失、附件等。依靠用户使用某些特定的邮件格式并不是最明智的做法。
问题是如何解析电子邮件以获取所有需要的信息。格式不应该太严格，但足以猜测哪些字段是什么意思。我也有兴趣听到正确和最简单的解决方案。
PS 实际上这个功能是银行要求的。他们有一个公共邮箱，客户可以在其中发送发现的问题。问题是在银行员工真正看到之前从这些信件中获取尽可能多的信息。
FogBugz能够监控电子邮件地址并将发送到该地址的电子邮件添加为新的 FogBugz 案例。
还有一个称为ScoutSubmit的功能，它接受 HTTP GET 参数并使用这些参数提交新案例。让应用程序自动从现场提交错误报告非常方便。
我们用 RT 做类似的事情，但是电子邮件并没有真正被解析。所有电子邮件都进入一个队列，由我们的 IT 人员进行评估。基本上，解析是由人工完成的——他们修改票证以获取尽可能多的信息，因为他们可以从电子邮件中收集到。
您不太可能让用户（正确地）遵守您提出的任何特殊语法或格式 - 除非他们是员工、训练有素或有一定的动机遵守您的规则。
另一种选择是让初始电子邮件回复格式为问卷的电子邮件。换句话说，用户写了一份初始的错误报告，并立即（或在您的电子邮件服务器可以响应时）收到一条“谢谢您-您能提供更多信息”的消息，并提示您提供更多信息。然后，您可以解析该电子邮件并让它在您的错误跟踪系统中填充更准确的信息，
祝你好运！听起来是个很酷的主意！
根据自由格式文本对错误进行分类是一个困难的提议。除了缺陷提交者的姓名和报告错误的日期外，几乎没有什么可以从电子邮件中轻松收集到。您是否有理由限制自己使用电子邮件？如果您提供通过网页提交错误的表单，您可以根据您提供给用户的下拉菜单项对缺陷/错误进行分类。此外，您可以在页面的动态信息部分将它们指向常见答案。查看Apple iTunes 支持请求页面，了解一种稍微烦人但有效的方法来强制用户向您提供体面的信息。银行应用程序不是允许歧义的好领域，也不是进行多轮通信的好领域。