Sorry about my english - if some thing is not clear please ask me in comments - i will clarify this.
I build system in microservice architecture. I have one service with user information, one service for "offers", and one service for "ideas". Services "offers" and "ideas" comunicate (by Restful API) with "User" service on login and other operations. And i wonder - how to deal with emails? Each service have it separate frontend and send emails after some actions (eg. when some third person open link with some offer the user who create this offer will get email, or when some user create idea the manager will get email). Moreover, on each service frontend, manager can create "periodic" mailing with season statistical data or just some other information. Each service email looks differently and have different content.
I have many choices and don't know which will be better. This are some propositions:
Each service has his own separate emailing system and send all kinds
of email (after action, and periodic) independent.
The "user service" have "engine" to send action and periodic emails and other services give the task. Inside task there is link to service who give task and that link will generate email content (for example witch statistical data in periodic email). This solution is complicated...
The "user service" has only engine to periodic emails (tasks have link to generate email body...) but email after actions are send from each microservice indepenndent
Create new microservice only for sending email (periodic and "after action") with proper API. Ofcourse each service like "offers" should send also link (to themself) in mailing task - this link will be call when the periodic email will be send and the response of this link will be generated body of email....
Which one will be better? Or may be there is some better alternative?
Sending emails it's like making request to another service (via SMTP). So, that's a good approach when every service will be able to send emails.
But, of course there's some common logic for sending emails like rendering templates, sending code, configurations and so on. This logic should be shared between services via common code (dll, package and so on).
So, in this way:
Every service doesn't depend on another service when it needs to send an email
Common code for sending email is shared between services
You don't have development, deployment and network overheads in the case of having dedicated email sending serviced
One drawback of this approach is that every service should have the same email configuration (SMTP address, login, password and so on). But if you share configurations between all services it's not a problem.
Related
I am setting up technical services in Pagerduty for a team and want all of them to use the same email integration, specifically, the same email address.
I see that I am allowed to associate the same email address to multiple technical services.
Is this the right thing to do? If not, what are the drawbacks?
A drawback to this is that you'll get an incident for all of those services that share the email. Depending on the size of your setup, this will cause a lot of noise for oncall.
If you want a single email, I'd suggest a global event rule or event orchestration. This products a single routing key and email but still allows you to use rules to route the incoming event to a specific service.
https://support.pagerduty.com/docs/rulesets#global-rulesets
https://support.pagerduty.com/docs/event-orchestration
This question is a follow-up question to this one.
The problem is that my current E-Mail provider does not natively support DKIM-signing, but I need that DKIM feature to make certain API integrations regarding my emails (like sending emails from my payment service provider through my own domain).
The solution I'm starting to see, as long as my host does not DKIM-sign their outgoing emails, is to watch out for an email providing service that allows you to send emails in the name of your own domain including the DKIM-signature feature. Does such a service exist, via API call? I've no experience whatsoever in this area, and would be happy to know if such a setup potentially has a bad influence on delivery rates / other problems.
If the mail server signs using your domain and not theirs, and you post the matching public key in your DNS, it will all work fine. You do need to find a provider that lets you do that though, which they may do via CNAME records. Such services will often allow you to configure what the mail server does with your messages using additional params in an HTTP API, or via custom headers over SMTP, e.g. it might allow you to set a header like:
Sign-with-selector: myselector
Recommendations for services are off-limits for SO though.
In our SaaS application each company (tenant) is given their custom domain like companyName.ourapp.com
We would like to provide some email services like:
Ability to send and receive email notifications from info#companyName.ourapp.com and similar addresses
Ability to create new email accounts in clients' subdamains at runtime, programmatically, when needed. For example we would have separate emails created for each "opening" so that emails sent to this address would be parsed info would be extracted
Similar tasks
For now I just don't even know on where to look and how this could possibly work.
As far as I understand email it should be some kind of custom mail server (SMTP) serving all sub-domains and having API we can use to send emails, list and retrieve messages etc.
Please suggest how it may work and is there any components out there we can use to implement this.
There are three options for this.
Create an email server and programatically configure it to accept or deny the specific accounts. Then use cron to poll via pop3 or imap and download the messages for the account. You can then send them on for the customer or handle them in your web app.
Create a script that is fired by the email server as it receives each email. The script can then handle what to do with the email as it's received.
Use a third party to receive the email via HTTP Post at your app. Using CloudMailin for example would allow you to create a custom authorization filter that would call your app in realtime and determine if the given account exists and messages should be accepted for it.
I wrote a blog post for Rails about receiving incoming email, however the principals would apply to any programming language and framework.
With regards an OMS, what is the best method to send a confirmation email? The 2 options I have so far are;
A script on the order page sends an email once the record is written to the database.
A scheduled task on the server, send the email, polling the database every-so-often to find new entries.
Which method do systems currently use?
For e-commerce websites, it might be better to think about the best user experience.
Given that, you would want to send the email as soon as the order is received so the user knows that they have purchased the item. The sooner it gets into their inbox, the sooner they will be happy that they have made their purchase.
I agree with Digbyswift that sending the confirmation email once the record is written to the database is the least scalable. But I would argue that if your system has gotten to the point that you are taking so many orders that your system cannot keep up, you have a wonderful problem on your hands that you now probably have resources to handle.
At PostageApp, we handle the emails of a few e-commerce websites, so perhaps you would benefit from an arrangement with an email service provider to off-load this task so that all of your resources can be spent on keeping your site up and your databases running.
Here are some great alternatives if PostageApp is not your style:
Sendgrid
Postmark
Mailjet
This is a question of scalability. Sending a confirmation email once the record is written to the database is the least scalable. The more orders that are taken , the more emails are sent potentially tying up resources.
A scheduled task is certainly better as emails can be queued up and can be sent in a separate process.
A further option which you could consider is using neither and delegating the responsibility of sending emails to a 3rd party dedicated emailing service, i.e. via an API. This is much better since your hosting does not have to consider the load and you can utilise any reporting offered by the 3rd party. Plus many services offer a free quota up to a certain threshold. This will allow you OMS and business to scale appropriately.
If you apply a message based architecture; you could just publish an order created message and have any number of subscribers respond to that event. You could create a listener that sends the email in house (bespoke option) or another listener that called the API of a 3rd party emailer to send the email on your behalf (as per #Digbyswift)
What I've always liked about this approach is
You can have any number of listeners live at any one time.
You can create a new listener and change how you send the email without needing to change/redeploy the OMS application itself.
You can take the listener(s) off line and stop / delay the sending of the email without losing any notifications or affecting the OMS itself.
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.