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 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: 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.
Related
I'd like to send emails programmatically via SendGrid (from admin#mydomain.example.com), but have replies to that email come to my Google Workspaces inbox for admin#mydomain.example.com). I would then like to reply to the customer from Google Workspaces.
The closest question related to this I could find is Setup | G Suite + Sendgrid for transactional email, but that was a fairly different use-case.
So in my usecase, emails to the customer would come from admin#mydomain.example.com via EITHER SendGrid or Google Workspaces.
Here's a article from MailGun that talks about a similiar pattern
My questions:
Will this result in deliverability issues, having emails sometimes come with different signing keys/domains? I don't understand email signing particularly well.
Is there anyway to have replies to the email address go to BOTH SendGrid and Google Workspaces, so I'll have it in my inbox but can also get it posted to a webhook by SendGrid? I think the answer is no, but figured I'd ask.
Any other considerations I should keep in mind for this strategy? Is this a poor idea for some reason?
Thanks!
Yes, this will result in deliverability issues. You should use the same domain for both sending and receiving.
No, you can't have replies go to both. You can have replies go to a webhook, but you can't have them go to both a webhook and a mailbox.
Final consideration: This is a poor idea. You should use the same domain for both sending and receiving. If you want to use SendGrid, you should use SendGrid for both sending and receiving. If you want to use Google Workspaces, you should use Google Workspaces for both sending and receiving. You can't use both at the same time.
Another consideration: If you're sending a lot of emails, you might get flagged as a spammer if you're sending from multiple domains.
The company I work for does something similar that might be helpful for your scenario.
We have a number of systems that send emails via SendGrid e.g. Auth0, Salesforce, various bespoke systems, etc. Some of these use native integrations to SendGrid, some use SMTP relaying, and others send emails programatically via the SendGrid API.
We've implemented sender auth (i.e. DKIM) in SendGrid for our domain e.g. mydomain.example.com, but we don't handle replies in SendGrid as we want replies to go to a different system - specifically our contact center system (which is the main systems our help desk staff use). Help desk staff would then reply to emails from within the contact center system. Note: we needed to configure DKIM for both SendGrid as well as the contact center system (as both currently send emails from mydomain.example.com), but in the future the intent was to implement a SMTP relay in the contact center system (to SendGrid) so that all sending goes through SendGrid.
I'm a bit fuzzy on the fine-grained implementation details of how we handle replies, but essentially we point the (single) MX record for mydomain.example.com to a third-party email protection system which scans the emails and forwards them to Office 365 mailboxes which subsequently forwards them to our contact centre system. I believe Office 365 is really only there for email posterity. AFAIK you should be able to point the MX record to anything that can handle SMTP.
In your scenario you should be able to configure the MX record for the mydomain.example.com domain to point at your Google Workspaces. This will allow you to send emails from SendGrid and use Google Workspaces to handle the sending and receiving of replies.
Not sure if you can configure SMTP relaying in Google Workspaces (i.e. to relay through SendGrid), but this would mean you'd only need to configure DKIM for SendGrid. All emails would be sent by SendGrid and replies would be go to Google Workspaces.
I have a web application that will be used by committee chairs to communicate with committee members over email. All these users will have e-mail accounts external to the web application and domain the web application is hosted on. Any replies from members need to be directed to the e-mail of the committee chair user, not an account on the domain of the web application. The only two methods of accomplishing this that I've come up with are
In the from of the e-mail, use the e-mail of the sending user. E-mail applications for many of the committee members block this as spam.
Use an account such as no-reply#applicationdomain.com, and then include instructions in the e-mail of the correct address that replies should be sent to. Users often get confused and don't send replies to the correct address.
Are there any alternatives I am missing?
Traditionally, this was the purpose of the Sender email header. If you want an email to be From the user, but sent by you, you would just set the Sender header to an email address on your domain but have From be the user. Also, the SMTP envelope sender should also be on your domain. Then, you would be properly declaring that you're the sender of the message for anti-spam purposes, you'll receive any bounce messages, but email clients will know that the email is reportedly from the "real" user, and will direct replies accordingly. Generally, email clients would report both Sender and From, saying something like "From my-server#website.example.net on behalf of real-user#example.com", though obviously the details depend on the email client being used.
Refer to What's the difference between Sender, From and Return-Path? and OpenSPF Web Generated Email Best Practices for more information.
However, now DMARC has come along. It has made the decision that verification should be based only on the From header. The theory is that there's no way for an end-user to know whether a particular Sender is in fact authorized to send mail "on behalf of" the user listed in the From header. While it probably isn't the decision I would have made due to how it ignores the traditional Sender, it's something that needs to be dealt with now, as if the domain of the user listed in the From has a DMARC record that is set to q=reject, then nobody else, including your web form that's trying to send mail with the complete approval of the user, can send mail that's From that domain. More and more domains are turning on DMARC, and as they do so your form won't be able to send email From them, regardless of what other headers are set.
The only other alternative, then, is to have email be From your application entirely, but set the Reply-To header to where the email program should send replies to. Also, the SMTP envelope sender should be your application, and ideally be set to an address that can handle bounce messages or other errors. You shouldn't need to include any instructions, as the Reply-To header is very well supported among email clients as indicating where replies should be directed.
Refer to the DMARC FAQ entry "Why are messages I send on behalf of visitors to my website being blocked?".
My company is developing a cloud contact management service and on our iOS app we're having some problems launching a particular enterprise email client app when the user presses the "Email" button on one of their contacts.
One member of our team came up with an idea to get around the problems with this enterprise app:
We let the user specify their email address in the app's settings and create our own email composing screen. Tapping the email button on a contact would open the composing screen, they would write their message and then we would send it on their behalf from our servers (or via service like mailchimp).
Basically, this would mean we would have to create an endpoint on our api that would accept a POST request with 'from', 'to', 'subject', and 'body' fields which would send the appropriate email.
This seems like a very bad idea as it's essentially creating a free, anonymous email service that could easily be abused send spam.
A few extra notes about our setup:
We don't verify an accounts email when they sign up
Even if we did verify the account's email, the user would need to be able to specify any email, as they may have signed up with personal email, but want to email someone from their work email.
Our API doesn't currently have any kind of rate limiting
Instead of having a from field in the request, we could instead send the id of the contact they want to email. This doesn't really change anything because if someone wants to abuse the send email endpoint they can also abuse the create contact endpoint.
So exactly how much of a bad idea is this, and how can I convince my team not to do this?
A few thoughts against doing it:
This is the perfect spamming service, which could damage the reputation of your company (reputational risk).
Your email servers would very quickly make it into blacklists (RBLs), making your outgoing emails land in spam folders in very many recipients' mailboxes.
Even if your servers are not yet in RBLs, if you send a forged email like that and proper email security is set up at the recipient end, your emails will still have a good chance to get classified as spam. Have a look at things like SPF and DKIM.
This could even have legal implications. Imagine the scenario when one of your users uses this service for something like blackmail. Would you be able to prove it was not you? Probably yes with the right controls, but would you want the hassle?
Still on the legal side, many countries (the EU, mainly) have data protection regulations which strictly control how personal data like email addresses can be used, especially for commercial advertisement. You probably want to adhere to that, but that would be hard with such a service (note that I'm not a lawyer, in such a case it's probably the abuser of your service that would offend these regulations and not you, I don't know, but it's something to consider).
If anyone can just send emails, it will be fairly easy to perform a denial of service attack against your services.
A few controls you could implement to mitigate some risks:
When adding a sender (from) address, you should validate that by for example sending a (cryptographically random) token and checking if the user can send it back (eg. by clicking a link in the email). If he can, that proves to some extent that he controls the email address and is probably a valid sender.
Limit the possible recipient addresses if you can. The best would be if recipients had to opt in to receive emails. If this is not possible, at least let recipients opt out from further emails. For this, you would have to add something like a footer to emails with "never again" links, and implement a facility to maintain recipients to which you must not send anymore.
Implement rate limiting. Depending on your exact scenario and use case, only allow to send the least number of emails acceptable for your application.
Implement proper logging so that you have an audit log of who exactly sent what email to whom. For this, log metadata like IP addresses as well. For this, you will likely have to authenticate your users.
On an operational level, have monitoring in place, and be prepared to ban offending users, based on a clear ToS shared with your users.
For a project I need to setup either a mail server (like Open X-change, Kolab) or I can use email service as Saas from providers like Mailgun, Sendgrid etc. But my prime requirements are:
Create new email addresses using (Rest) API or any other API programmatically.
Ability to create huge number of email ids (more than 10,000)
I have researched and found some like mailgun provides facility of sending / receiving messages through APIs. But nothing was mentioned about creating new email ids using APIs.
Does anyone know any mail server / SaaS which provides the aforementioned facilities?
To have a mail id, you need to be able to accept messages at that location, which would be a full mail service such as Gmail.
If you just need to send "as" addresses, you can use an SMTP service such as SendGrid. You'd just need to make sure the domain is legitimate and can receive mail, and that you set the Reply-To value to something that you can accept mail at.
I have a PHP web app that is going to send out about 1,000 emails. I would love to test the performance beforehand. Is there any kind of service that provides dummy email addresses to send to, for this kind of testing? I can't find anything that's not just a general bulk-email service. The key here is I just want dummy addresses to send to.
If you have the ability to just purchase a domain name from a hosting service, I know at least 1&1 gives you like 2500 email addresses per domain so you could literally spam yourself to death and not worry about any other 3rd party. You can pick up a domain name for like
When you say "test the performance", do you mean you want to know about your deliverability rates, or how your emails look?
Deliverability Rates
This is entirely dependent on your SMTP server and the reputation of the IP that it will be sending from along with your domain's SPF records and the content of your email. To maximize this, I would recommend using a marketing email service such as MailChimp or MadMimi.
Appearance of Emails
You could always just send yourself a test email to see how it looks. An alternative is to use a service like PostageApp that has a built in template designer that has both an easy email preview function and a test send email function.
(Full Disclosure: I am the Product Manager of PostageApp.)
If you use "Post Hoc" you can send email to an unlimited number of email addresses. Post Hoc acts like an SMTP server, and receives the email messages that you are sending, but it does not forward them on anywhere. You do not need to set up any email inboxes ahead of time, so there is no problem if you have 1000 different unique email addresses. They do not need to be from a single domain -- you can use any email address you want. It stores the email messages received so that you can inspect them if necessary. You would run it locally so that there is no concern about network problems, and it is very low overhead since it does almost no processing of the email. This way, the performance measure will be mostly the sending side processing. Best of all, it is open source and freely available:
Find it on GitHub: GitHub for Post Hoc
Also see the blog post: PostHoc: Testing Apps that Send Email