I have a ruby / rails application that integrates in and outgoing email directly into the app. The app is going to be running on multiple domains each with posible many users sending and recieving email.
I have looked into sendgrid, mailchimp and mad mimi as hosted services and also looked to create my own email server.
There are advantages and disadvantages of both solutions and i am not sure which one to go down and am hoping someone can give me advice ??
Any help will be great. I know email is a hassle to manage but once set up correctly cant be that bad ??
Thanks in advance
Rick
Hosting your own Mail Transfer Agent (MTA) has some benefits with easier mailbox creation and less latency but it requires significantly more maintenance. There's also the problem with spam filtering that would require some constant tweaking. An outside firm will likely have a more advanced filtering system in place that you can leverage the larger quantity of traffic passing through it.
Never underestimate the increased effort for uptime as more components are integrated.
I'd use Heroku, the have some mail add-ons
Related
I'm creating an e-mail client for iOS and before the start of working on it, I want to select the best architecture for it.
For example, at the first stage, I want to connect Gmail. I searched and found that Google has a ready library for doing that, so I can just connect the library and fetch my emails.
Another way of doing that is fetching emails from the API in my web server and later to take these emails from my server.
The main purpose is not just to fetch emails, but to be able later to add some new filtrations to it or some other functionalities, maybe machine learning technologies for better personalisation, etc.
Also, I want to support multiple email servers(Gmail, Yahoo, Hotmail, etc.)
What do you advise me to choose, to fetch from my own server or directly from the email servers? I also understand the security issues in the case of using my own servers.
Your feedbacks will help me a lot! Thanks in advance!
You shouldn't use your own server for this task. You just don't need it. It's less secure and I'm pretty sure, that some of your clients will dislike the fact, that you can store their mails on your own server.
If you want to support multiple email server providers, then you should use IMAP protocol for receiving mails and SMTP for sending. Also, in some cases, you can use OAuth2 as authentication method, so you don't need to ask user to enter his credentials in your application.
I recommend you to use some open source libraries for working with IMAP and SMTP, because implementing this protocols by self can be complicated.
Sounds very similar to what I was doing. I was recently building PickedMail where the backend is heavy AI. For Google, you'll want to use Oauth2 and use the server_token to pass in to your server.
I created an iOS framework for this, hope that helps you. https://github.com/Thywis/MultiAccountOauth
For others like outlook, yahoo, iCloud, I'd suggest using IMAP for now.
A client needs to send out eNewsletters.
We tried using their Sitefinity CMS, but it hangs for reasons that are hard to determine.
As a result, I am inclined to "roll my own".
However, various pitfalls yawn deep and dark along the imagined path.
For example:
Imagined Pitfalls
My client's domain gets blacklisted.
The emails get rejected as Spam.
Presumed ways of avoiding imagined pitfalls:
a. Send out emails with a delay of, say, 2 seconds between each one.
b. Send out emails individually, ie, no CC or BB.
Questions:
Are my imagined pitfalls and presumed
ways of avoiding them correct?
Can you think of other pitfalls?
Or better ways of avoiding them?
Do you know of reliable software that
just does this (ASP.NET, MVC by
preference, drawing form SQL Server
db).
It may be beneficial to use a third party like Constant Contact to handle sending your email campaigns. They expose an API that you can tap into via REST and it won't have any effect on your client's domain. Constant Contact is a reputable company and email campaigns they send out rarely get caught in Spam filters. My company currently uses the service, but not the API and its been very successful.
Constant Contact's Website
CC's API Web Site
Example of creating a Campaign
You should never do this. Your client's IP(s) and domain(s) will find themselves blacklisted to the point that even their legitimate, hand-crafted emails won't make it past spam filters at large mail services.
Use something like SendGrid if you want to stay closer to the metal than a service like MailChimp or Constant Contact.
There are other companies out there which do it, such as BriefYourMarket ... never roll your own :-)
I'm trying to create a ruby on rails ecommerce application, where potential customers will be able to place an order and the store owner will be able to receive the order in real-time.
The finalized order will be recorded into the database (at the moment SQLite), and the storeowner will have a browser window open, where the new orders will appear just after the order is finalized.
(Application info: I'm using the HOBO rails framework, and planning to host the app in Heroku)
I'm now considering the best technology to implement this, as the application is expected to have a lot of users sending in a lot of orders:
1) Each browser window refreshes the page every X minutes, polling the server continuously for new records (new orders). Of course, this puts a heavy load on the server.
2) As above, but poll the server with some kind of AJAX framework.
3) Use some kind of server push technology, like 'comet' asynchronous messaging. Found Juggernaut, only problem is that it is using Flash and custom ports, and this could be a problem as my app should be accessible behind corporate firewalls and NAT.
4) I'm also checking node.js framework, seems to be efficient for this kind of asynchronous messaging, though it is not supported in Heroku.
Which is the most efficient way to implement this kind of functionality? Is there perhaps another method that I have not thought of?
Thank you for your time and help!
Node.js would probably be a nice fit - it's fast, loves realtime and has great comet support. Only downside is that you are introducing another technology into your solution. It's pretty fun to program in tho and a lot of the libraries have been inspired by rails and sinatra.
I know heroku has been running a node.js beta for a while and people were using it as part of the recent nodeknockout competition. See this blog post. If that's not an option, you could definitely host it elsewhere. If you host it at heroku, you might be able to proxy requests. Otherwise, you could happily run it off a sub domain so you can share cookies.
Also checkout socket.io. It does a great job of choosing the best way to do comet based on the browser's capabilities.
To share data between node and rails, you could share cookies and then store the session data in your database where both applications can get to it. A more involved architecture might involve using Redis to publish messages between them. Or you might be able to get away with passing everything you need in the http requests.
In HTTP, requests can only come from the client. Thus the best options are what you already mentioned (polling and HTTP streaming).
Polling is the easier to implement option; it will use quite a bit of bandwidth though. That's why you should keep the requests and responses as small as possible, so you should definitely use XHR (Ajax) for this.
Your other option is HTTP streaming (Comet); it will require more work on the set up, but you might find it worth the effort. You can give Realtime on Rails a shot. For more information and tips on how to reduce bandwidth usage, see:
http://ajaxpatterns.org/Periodic_Refresh
http://ajaxpatterns.org/HTTP_Streaming
Actually, if you have your storeowner run Chrome (other browsers will follow soon), you can use WebSockets (just for the storeowner's notification though), which allows you to have a constant connection open, and you can send data to the browser without the browser requesting anything.
There are a few websocket libraries for node.js, but i believe you can do it easily yourself using just a regular tcp connection.
I have a rails app that just launched and I have over a thousand users signed up to the site. We are interested in keeping in contact with the community through email newsletters. We have been using a third party tool and migrating the email addresses from one database to another. Is there an easier way to do this from rails? I am open to suggestions.
http://github.com/adzap/ar_mailer
ar_mailer will allow you to queue up mail and send it out over time so you don't violate any mail rules put in place by your host.
If you really, absolutely, definitely need to send to these emails yourself, and you're dealing with a larger user base, you'd probably want to go through a distributed setup employing something like Starling, RabbitMQ, or the all-new Resque to distribute the task of sending these emails across a multitude of workers.
It's a topic far from trivial, so all in all I'd recommend using an external service provider for this.
Use ActionMailer to generate emails from templates (views) using Erb. I would do this unless you wish track clickthroughs back to your site from those mails, then you may be better of using a third party.
As an aside (I'm sure you know this but), be aware that you'll need to inform your ISP and demonstrate to them that you have permission from your users to send these emails, else they may block you from sending without warning.
You can simply loop through all the emails and send individual emails. It's pretty simple using rails and there are tutorials everywhere.
You could also use the third party API to add automatically your users emails to their database. If you could provide the third party you're using, I could maybe give you more information.
Some newsletter website give you the option to add emails directly in their system via a given form. Why not use this form? You would put it somewhere on the website and the system will add the new emails to the third party software and not to yours. Of course this only works if you have a "enter your email here to subscribe" kind of logic.
I'm looking for an alternative to Google Apps for sending email from my rails app. (Google limits the number of messages you can send).
Do most people roll their own, or is their a preferred provider?
I'd love to be able to dynamically create addresses for my customers: customer_name#myapp.com
We use AuthSMTP which does a quality job of informing you when you've been reported as SPAM and keeping you off of block lists.
It costs, but is very reasonable.
Just to give an update, it looks like the new hotness is SendGrid. Take a look if you're in the market for hosted email for your rails app.
If you're hosting on a Linux server and just looking for something to send emails from your rails application, rolling your own SMTP server really isn't rocket science. You'll find tons of manuals out there on how to deploy a SMTP server on your Linux distribution of choice.
Postfix would be the de-facto-standard and Qmail is my personal weapon of choice when it comes to security, reliability and speed.
If you want to provide your customers with mailboxes (POP and/or IMAP) for incoming emails, it wouldn't be rocket science either to deploy your own server, but the administration of this servers and the support calls from your customers could become a pain. :-) In this case I would go for Google Apps. The $50/year/customer for the business option probably would be the choice for your corporate customers.
I've had good success with Postfix with Rails and Linux in production. Once the site got beyond small, connecting to Google Apps for each email became impractical (it would fail or timeout somehow once every couple hundred emails). For doing a mass mail to all your users, very impractical.
There is a good series of articles for getting postfix set up on SliceHost's pages
http://articles.slicehost.com/2008/9/2/mail-server-overview