SaaS/多租户应用程序如何实现电子邮件通知（发送和接收）？
给定多租户应用程序，供应商如何从电子邮件帐户设置和编程角度实现电子邮件通知：
发送电子邮件可以来自通用帐户：例如[电子邮件受保护] 或 [电子邮件受保护]，考虑到电子邮件内容中可以包含回复地址和链接，这似乎是合理的。
接收电子邮件：例如，应用程序如何接收电子邮件；生成支持票证或在电子邮件中将评论分配给项目/任务。我在主题中看到了 ID，并且对包含帐户名称的地址进行了一些回复，例如： [电子邮件] protected]
我意识到可以通过编程方式连接到 pop3 服务器并接收电子邮件并查找带有主题的 ID，但是有没有一种方法可以设置和接收电子邮件到单个 pop3来自多个子主机名称电子邮件地址的帐户（不确定那里的术语）例如： [电子邮件] protected] 或[电子邮件受保护] 并检查帐户名称从地址？ （类似于检查 URL 上的子域）
有什么做法、经验、意见或建议吗？
（不确定它是否相关，但使用 C# asp.net-mvc 和服务等）
Given multi-tenant application, How are vendors implementing email notifications from an email account setup and programming perspective:
Sending emails could come from a generic account: eg [email protected] or [email protected], this seems reasonable considering reply addresses and lilnks can be contained within the email contents.
Receiving Emails: How would an application receive email, for instance; to generate support tickets or assign comments in an email to a project/task. I have seen ID's within the subject and some reply to addresses containing the account name eg: [email protected]
I realise one can programatically connect to a pop3 server and receive emails and look for the IDs with the subject, but is there a way of setting up and receiving email to a single pop3 account from multiple sub-host name email addresses (not sure on terminology there) eg: [email protected] or [email protected] and check the Account Name from the address? (similar to checking subdomains on a URL)
Any practices, experience, comments or sughestions?
(not sure its relevant, but using C# asp.net-mvc and services etc)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对于发送通知电子邮件，我们有一个通知发送到与每个帐户关联的地址，并且只需从我们的域发送到该地址即可。我们的发件人地址受到监控，回复最终会进入 CSR 工作队列。
对于入站电子邮件，我们使用 FogBugz（来自 Stack Overflow 的制造商）进行案例跟踪。通过电子邮件接受新案例（例如[电子邮件受保护]）。票证是根据电子邮件自动创建的。我唯一的抱怨是客户需要检查一个不起眼的链接以获取案例更新（没有“我的案例”门户网站，但也许会在即将推出的 FogBugz 版本中出现）。
我们在 FogBugz 中有一个自定义字段来指示票证来自哪个客户。理论上我们可以为 FogBugz 编写一个插件，使用发件人域自动分配该插件，但我想 CSR 还没有大声抱怨:-)
For sending notification emails, we have a notification send to address associated with each account and simply send from our domain to that address. Our from address is monitored and replies end up in the CSR work queue.
For inbound emails, we use FogBugz (from the makers of Stack Overflow) for case tracking. That accepts new cases via email (e.g. [email protected]). Tickets are auto-created from the email. My only complaint there is that the customer needs to check an obscure link for case updates (no "my cases" web portal, but maybe that will come out in an upcoming version of FogBugz).
We have a custom field in FogBugz to indicate the customer the ticket is from. We could theoretically write a plugin to FogBugz that auto-assigns that using the senders domain, but I guess the CSR's haven't complained loudly enough yet :-)
我们（muHive）是一款入站电子邮件/社交对话管理产品。如果您正在考虑处理来自客户的入站电子邮件或社交媒体对话，我们有一个令人印象深刻的工具集。
对于我们自己的出站需求，最简单的方法是使用电子邮件发送API。不用费心自己去SMTP发送。我们使用 Amazon SES 并尝试过 Sendgrid 为我们带来了额外的好处，例如传递状态和电子邮件解析。
您可以通过两种方式处理多个帐户以获取所有电子邮件地址。如果您的目标系统可以区分不同的客户并根据内容/发件人将任务分配给正确的代表，请要求所有客户发送电子邮件至 [电子邮件受保护]。
正如您所说，您还可以创建 *[email protected]* 电子邮件在任何 CRM/支持解决方案上使用不同的帐户来管理这些电子邮件。
另一种方法是让您的客户向您发送电子邮件至[电子邮件受保护]< /a> 并且您使用基于规则的系统（如 muHive）根据发送邮件的客户/帐户将这些邮件转发给适当的客户主管。
We (at muHive) are an inbound email/social conversations management product. If you are looking at a handling inbound email or social media conversations from customers, we have an impressive toolset.
For our own outbound needs, the simplest way is to use an Email sending API. Don't bother with SMTP sending by yourself. We use Amazon SES and have also tried Sendgrid which gave us additional benefits like delivery status and email parsing.
There are two ways in which you can handle multiple accounts to a catch all email address. If your target system can differentiate between different customers and assign tasks to the correct representatives based on either the content/sender, ask all your customers to send an email to [email protected].
As you rightly said, you could also create *[email protected]* email addresses and use different accounts on whatever CRM/Support solution use to manage these emails.
Another approach is to have your customers send you an email to [email protected] and you use a rule based system (like muHive) to forward these mails to the appropriate account executives based on the customer/account who sent the mail.