只看一个新项目的需求，我想确保这个用例是合理的：
SQL Server 是否能够以这种方式解析邮件附件？这种方法有什么注意事项吗？
使用 Outlook 作为提交技术的吸引力在于，如果用户处于脱机状态，则其处理过程是相同的。然后，Outlook 将在它们重新联机时自动同步。用户必须通过某种方式离线填写表格，“提交”它们，然后在下次上线时自动与服务器同步。
编辑：澄清一下，我不是在寻找一种从服务器->客户端缓存表单数据的方法。我正在寻找缓存完成的表格。构建单独的应用程序以在客户端缓存已完成的报告不是一种选择。
我不会使用您上面概述的方法。在我看来，有几种方法比让 SQL Server 查看 Exchange 邮箱更可取。您提出的要点和重要要求是允许 InfoPath 表单在脱机模式下工作。我会将项目的“离线模式”和“数据传输”部分视为两个不同且独立的部分：1）表单和数据应存储在客户端上，直到可以连接到 Internet 和 2）一旦连接可用，表单和数据应传输到服务器。
您可以将 InfoPath 表单设置为直接提交到 SQL Server 并完全绕过 Exchange“中间人”。设计表单时 InfoPath 中的设置非常简单：1) 为连接启用“提交数据”，2) 配置提交选项。本文详细介绍了如何执行此操作。此外，您与 SQL Server 的连接可以设置为离线使用，如本文所述。这种方法唯一需要注意的是，您可能需要更改数据库模式以支持它。
另一种方法是让您的 InfoPath 表单提交到 SQL Server 2005 HTTP 端点。InfoPath 客户端只是一个美化的 XML 编辑器，而 HTTP 端点基本上是 Web 服务的不同名称。您在 HTTP 端点将表单数据接收到临时表中，其中数据存储为 XML，然后您可以从该临时区域解析该数据。您仍然必须设置 InfoPath 连接以供离线使用。这种方法的主要警告是微软将在 SQL Server 2008 中弃用 HTTP 端点，转而支持 WCF。
我想建议的另一种方法是使用 WCF 本身从 InfoPath 客户端接收 XML 表单数据。这种方法需要您在设计时将表单的数据源连接到您的 WCF Web 服务，然后还要设置表单以供离线使用。
我希望这对您有用，至少可以为您指明正确的方向。
更高版本的 SQL Server 能够在其中运行 .NET 代码，因此您可以从 SQL Server 轮询邮箱并处理 InfoPath 表单。但是，我不确定我会这样做。
考虑编写一个可以完成这项工作的 Windows 服务可能会更好。Windows 服务将启动，检查“服务帐户”的邮箱，阅读邮件，提取附件，处理 xml，并最终将数据写入 SQL。如果发生业务规则或验证错误，它还可以用确认或错误来响应该邮件。
我不确定我是否会将上述所有逻辑都放入 SQL 中 - 一方面，我怀疑您的帐户有问题（必须让帐户 SQL 在能够访问 Exchange 邮箱帐户下运行）。
您的里程可能会有所不同，您应该对此进行原型设计以确定最适合您的方式，但我会尝试将使用 Exchange 的代码作为“工作队列”与 SQL 分开，并且只将处理写入数据的代码放入SQL 中的表。
我见过类似的项目，它们在客户端使用 Express 版本，将信息路径（或应用程序数据）保存在 Express 中并使用 Service Broker 传递到中心，因为 SSB 与邮件的保证传递语义。这为您提供了一个更容易向 IT 销售的全 SQL 解决方案，并且您不需要在服务器上进行轮询。此外，您不必处理 MIME 解析，所有这些都是直接的 XML 处理。但这并不适合胆小的人，让 SSB 启动并运行是一项挑战。如果您决定使用邮件传递，可以说外部服务将更容易构建、调试和故障排除。您应该回答一些更精细的问题：- 您将如何保持邮件出列操作和表写入操作的一致性？您的组件必须将 Exchange 读取/删除和 SQL 插入到一个分布式事务中。- 您的逻辑是否准备好处理出现故障的 infopath 文档？邮件传输绝对不能保证交付顺序，因此您可能会在“订单创建”文档之前看到“订单删除”文档 - 您将如何检测丢失的文档（不是通过邮件交付）？您是否要实现发送者序列号并最终在邮件之上重新发明 TCP？- 您的处理是否允许并行处理相关文档？如果线程 1 接收到 doc 1，线程 2 从同一个发送者那里接收到 doc 2，并且 doc 2 与 doc 1 相关联（即指同一个业务交易），数据库写入会发生什么？它会死锁，它会失去更新，会回滚吗？
前面桥下有很多龙……