I'm currently running a SAAS application and mails are being sent from our application using Mailjet.
Some of the larger customers have been asking to allow the emails to be sent from their domain (e.g. info#largehotel.com) instead of our system (notifications#saasapp.com).
Are there any initial pointers I will need to look at? I'm guessing they will need to add our SPF records to their SPF records too and that they will need add a DKIM key that we generate for them to add to their records too? Then do some validation on them on the DNS level and mark them as validated?
I have some understanding to have customers run their own domain against our SAAS domain but a bit lost on the sending from their email domain requirement.
First, for the record, my SaaS platform does this (vía option 2b). It’s an e-commerce marketplace and I need the receipts to be sent from the email address of the product seller, not from me (the marketplace)
You have two(ish) options
Send email through your client’s mail servers (instead of mailjet)
Verify the client’s domain on your Mailjet (or similar email) service
option 1
With option 1, you’ll need to ask your client’s IT team to setup a username and password for you to access their SMTP server. This is essentially just like them creating an email account for you to use. This may seem like the easiest path available for you, but there are potential pitfalls and disadvantages:
Doing this, you will lose the mail open/click/bounce tracking functionality you get with mailjet; because you’ll be using the company’s SMTP server instead.
If you’re sending out as a fairly common email address (eg info#your-client.com) the client may already have that account active on their mail servers. That would allow them to receive replies into the existing infrastructure but make them wary of the security issues with sharing a password to their mail server with you.
You might find that they don’t even have the ability to give you a username and password. Modern mail services don’t allow for SMTP access (which is what your web app will need); and security conscious companies require 2 factor authentication on mail accounts (which your web app can’t answer)
Option 2
For this, you will need to ask their IT team to configure some DNS records to prove to mailjet, and to the email recipient, that you’re allowed to send on behalf of your client.
You did this for your own domain when you first setup mailjet. See https://app.mailjet.com/support/how-to-add-a-sender-address,96.htm for what this involves, but it’s a case of asking the client to configure a DNS record.
That tells mailjet that you’re allowed to send on behalf of that domain; but you’ll also want the client to adjust their SPF and DKIM records so as the recipient of the emails knows to trust Mailjet’s servers with emails sent from your client’s domain name. Normally, recipients only trust email sent from your client’s mail server (which you have as option 1) and distrust email sent from SAAS providers.
You will (or should) have done this on mailjet for your own domain already as well. https://app.mailjet.com/docs/spf-dkim-guide
So for this, you’ll need your client to setup 3 DNS records.
If you go this way, you could setup a separate Mailjet account which they and you have access to. That way they ca see their dashboard directly and feel a sense of ownership and security around it. But you won’t be able to markup the price of it 😜
Conclusion
How important is the tracking? If you can’t lose that you need to go with option 2.
How technically savvy is the client? Are they going to be able to have those DNS records changed? Are they going to be (rightly) security conscious around giving you an account on their main mail sever.
Option 2 would be my preference. You might need to hold their hand through the DNS setup so get it configured on Mailjet (And ask about SPF in here to make sure you get it right) so you can provide them with clear instructions of the specific 3 DNS records to create/update.
Whatever approach you take make sure you’re talking to the right people at your clients side soon. Their marketing team may be keen to do this with you, but if their IT feels left out of the conversation they will be difficult to get on board when you need them to make the changes. Us IT folk can be grumpy and obstinate 😀
your web app
This is going to need some adjustment. You probably already store your Mailjet credentials in a file or environment variables; these might need to move these to a dB table so you can relate credentials with specific accounts. But we’d need more info on the web app to be able to speak more to that side of the challenge.
option 2b
just as a note instead of a real suggestion. Be aware that some email service provers allow the sending verification part to be done by sending an email to someone on that domain (eg admin#yourclient.com) and then allowing sending vía the API if the recipient clicks on the approve link on that email. But, even with that setup you still need the client to configure SPF and DKIM on their DNS, so the extra one record isn’t a big ask. AWS’s SES allows for this. This works for me; but I have different requirements around deliver ability, and a large number of non-tech users (as opposed to your one or two big clients)
you can ask your client to generate programmatic(app key/password) user for email need to use for example info#largehotel.com and some other info like (host:gmail, protocol: smtp,...) all basic info needed then in your saas retrieve all this info to create object with client info that you stored before to send email for the target (from developer prospective non network engineering )
The SPF is the most important think to do. In most cases you have to be very careful about the IP reputation, but since you are using Mailjet it's up to them to manage this part.
Be attentive to the overall quality of the email, text/image ratio... Also offers a text body version of the content and dont forget the unsubscribe link. Since you already send emails with your service, I guess it's points are already correct.
Related
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.
We are hosting customer data on behalf of companies/clients, and one of our tasks is to send out a very specific transactional email from us (with our email address as sender and reply-to) to clients customers.
We are trying to move away from storing the personal part of a customers data, including his email address. Of course, in order to be able to send out an email to a customer we need to at some point have access to the email address, but in our view it's a step in the right direction to retrieve the email address from the client during a session instead of retreiving it from our own database.
The problem now is that our unwillingness to have email addresses stored anywhere rules out using email service providers like Sendgrid. Instead we need to send out lots of emails through our own server, and this might hurt deliverability. I've been looking for a kind of "self hosted Sendgrid". One who will enable us to send bulks of emails, and one we can tweak to not store the sent emails.
One solution I've found is sendy.co who defines themselves as:
Sendy is a self hosted application that runs on your web server.
This sound promising, but then I read that emails are sent through Amazon's cloud:
Sendy uses multi-threading to send emails via Amazon SES.
I suppose this leads us back where we started, because then Amazon is storing the email addresses.
As I understand, the high deliverability that ESPs achieve is not only caused by state-of-the-art email headers, but also by their servers being recognized by Google/Gmail, Microsoft and other email hosts. So maybe a high deliverability just isn't possible without an ESP. But is there an alternative approach that lets us acheive relativly high deliverability without needing to involve a 3rd party server to do the sending?
The reason that people tend to pay for this service is because it is reasonably difficult/complicated/time consuming. If sending this email is a core part of your business, you'll want to hire a deliverability engineer to handle this. If it's not, I'd start by contacting the various transactional ESPs and see if you can find one that has an enterprise offering they're willing to tailor to this use case.
I think that I'm a little late to this. I hope that you figured out your question by now.
If you haven't then:
One alternative that you can try is to host your own server with an on-premise option. I would check out SocketLabs Hurricane MTA.
SocketLabs is a cloud ESP, like Sendgrid. But they also have a powerful on-premise option.
https://www.socketlabs.com/blog/introducing-hurricane-mta-3-0/
I'm trying to understand a few concepts around sendgrid, whitelabeling and different servers that I plan to deploy the same sendgrid account in.
So my questions are:
1) Is whitelabelling purely for masking the via sendgrid.me and will I have any issues if I dont use it with my current setup(i.e. same account on several domains)
2) How does sendgrid deal with messages that have a "From" email that doesnt match the domain the email is sent from? Cause I read that it would silently drop them but instead I see that emails do get delivered however the statistics in sendgrid's dashboard are not being updated.
3) Upon creating a demo account I was asked to provide the domain from which the emails will be triggered but since I want to deploy this in several different domains will I need multiple accounts or is there an alternative option when you go for a paid plan?
Mike
Yes - whitelabelling will replace the sendgrid.me with your own domain.
You can also setup multiple domains inside SendGrid and assign each to a subuser. That will get you one SendGrid account, with multiple whitelabelled domains and separate sender reputation for each.
SendGrid will attempt delivery of whatever you ask it to send -- if you send an email with a different from domain than the signed sending domain, it's up to the receiving mail server to decide whether to block, flag as spam, or allow the email. Different receiving domains will behave differently.
It's generally best practice to always have your from domain match your signed sender domain.
Once you have one domain setup, you can setup additional domains using SendGrid subusers -- more info here.
If you have a complicated multi-domain setup, you might want to check out a templating API, like sendwithus, for making things easier to manage. They'll integrate directly with your SendGrid subusers on your behalf.
We are building a system that is, effectively, an email/calendar/contact client.
Users will provide us with their email address password (or other auth, eg oauth) and we will connect to their underlying email system.
"underlying systems" include:
Microsoft Exchange / Office365
GMail
Yahoo Mail
Apple email
Generic IMAP
Each of these systems have subtle (and not so subtle) differences in their APIs, especially to access calendar & contact data. Thus we need to know what provider the user is using.
But we would rather not ASK the user. We would like to figure it out (and at, least reduce the choices) automatically.
I've looked around for something that already implements this but have not found anything. I know it's mostly possible because Windows Phone does it pretty well (just enter username/pw and it does the right thing).
Before I dive in and start writing my own I want to ensure I'm not wasting my time if someone's already done it in an excellent way.
Know of anything like this? For this project prefer C#/.NET.
[EDIT: Adding potential algo]
Potential Algorithm:
Given email address & password
Extract domain name from email address
Try Exchange autodiscover. If successful done.
Use DNS MX records to find smtp host.
Do SMTP EHLO
Gmail responds with "250-mx.google.com at your service"
So if we see a "google.com" we are done.
Yahoo responds with 250-mta1257.mail.sk1.yahoo.com
So if we see a "yahoo.com" in the response we are done.
Apple responds with 250-xxxxxx-mac.com
So if we see a "mac.com" in the response we are done.
If none of the above
IMAP?
...
[EDIT: 5/18]
I built a prototype that uses methods that don't require auth (e.g. just MX/SMTP sluthing). Give it a try: http://bit.ly/KLZKxD
Algorithm seems reasonable. You will get best results running from unfiltered server (meaning it has direct SMTP outbound / doesn't run through a proxy). If running from client (mobile/tablet/desktop), then no guarantees as some ISP's pass SMTP through a proxy relay hence EHLO response is only for proxy.
You may want to do a port check for servers to verify expected protocol support (just a TCP connect may be sufficient but protocol handshake is preferable). Additionally, best to build up a database of verified SMTP and IMAP server mappings as there can be split names (e.g. smtp.domain.com and mail.domain.com) - discovering SMTP is easy, discovering outbound server(s) which usually also means calendar/contacts server, not so much (except for Exchange but only if autodiscovery is configured correctly).
If you can get your users to approve and assuming you have their username/password, you could try connecting to SMTP via MX record and sending an email back to your own address then checking through headers for useful info about the server (needs to be authenticated to relay). Users could alternatively reply to an email you generate in order to get the same server info.
Also ensure that you do your own DNS query and try each MX record or all primaries -- if the principal MX is down or DNS is poorly configured for equal weighting, you could end up hitting a smarthost / backup which may just be a dumb SMTP relay / store-and-forward and not give you the correct response.
TL;DR: No quick solution but a cascaded algorithm that trys and fails different solutions until one works / gives an expected result should work.
Most devices can auto detect the service by parsing the Whole e-mail address. Xyz#gmail.com would obviously be a gmail account. So for Apple, Gmail, Yahoo, Live, Hotmail etc you can easily program for.
For other domains, including custom, you can try this: http://www.exclamationsoft.com/exclamationsoft/netmailbot/help/website/HowToFindTheSMTPMailServerForAnEmailAddress.html
You can detect Google Apps For Your Domain accounts by examining the domain's MX records. If the primary MX record is ASPMX.L.GOOGLE.com, then it's GMail.
I created an implementation of this that has been used widely with some success: https://github.com/tig/Email2Calendar
This is used by both milelogr.com and freebusy.io.
For an application we are building, it is required to give certain registered accounts the ability to send emails to other registered accounts.
As part of the registration, we obviously collect the real email address of every user.
I do not want to expose any of my users' email addresses so I would like to have the ability to proxy them through fake email address that basically forward to the real email address.
For example, if someone want's to email John Doe, they would send an email to abcdefg12345#mysite.com which would then forward the email to john#johndoe.com.
In case its not obvious, the purpose of this is to protect the end user from spam and keeps their real email address private. Since my application acts as the proxy, I could easily block certain email's from going through.
The most famous example of this is Facebook's email proxy for Facebook Apps.
My Question: Are there any patterns, servers, 3rd party services, or libraries that provide such a feature? Does anyone have any suggestions for how this could be built?
I've never seen a service that offers this directly. The hardest part here is the receiving of the emails and wiring things up to your app for the authentication. You could use a service like http://cloudmailin.com in order to receive the email and then forward it on or even use some sort of custom install. Another option would be to create a script that modifies a server such as postfix's configuration.
Finally although I wouldn't recommend it you could try and create your own mail server to do this. I would read up a little more on SMTP/IMAP and see what options you have.
It looks like there is no 3rd party service or tool\library to accomplish this. It is going to be a bigger task than I was hoping for so I will be putting it off until I have the time to implement it.
I think the solution is to use a mail daemon that has an API or at least allows you to manipulate the users\emails\aliases in it such that you can create new mailboxes on demand and set them to forward from someuser#proxy.mysite.com to user#theirdomain.com
I found out that there are services that provide this type of functionality as part of their offerings:
http://mailgun.net/
http://www.sendgrid.com
Both of these services are very cool and offer quite a bit for sending and analyzing emails including the ability to create forwarding\proxy emails.