How are SaaS/Mult-Tenancy apps implementing email notifications (sending and receving)?

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 notifications@VendorName.com or noreply@VendorName.com, this seems reasonable considering reply addresses and lilnks can be contained with开发者_开发百科in 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: notifications@AccountName.VendorName.com

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: noreply@AccountName1.VendorName.com or noreply@AccountName2.VendorName.com 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)

---

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. cases@mycompany.com). 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 :-)

---

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 support@company.com.

As you rightly said, you could also create *accountName_support@company.com* 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 support@company.com 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.