I have a Rails 3.1 app deployed to Heroku. This app makes heavy use of mailers. I'm looking for a way to run a sort of integration-stress test. In other words, I would like to automate integration tests that cover from user action to email receipt (not simply delivery), and I want to use these test to stress-test the app. As Heroku runs everything in production mode, I'm can't run this server-side.
(I'm happy enough to script the actual user interaction, though I'm interested in suggestions. What's really tripping me up is actual email receipt. What would I use to monitor incoming emails? I'd like to not use a separate tool, and I'd prefer not to check that emails were received after testing, as I would like my stress test to also calculate elapsed time between user interaction and email receipt, etc.)
I don't think you can avoid using a separate tool if you actually want to check the messages were received at the end point. I wrote a blog post on a number of options for receiving emails.
Since you're running things locally and don't nessesarily need to be performant it might actually be enough for your tool to connect via pop3 or imap and download the email to check it was delivered.
Related
I have problems sending mail from a ruby production app on heroku by a gmail smtp account.
Here i found the solution
When i apply the solution all works wel, but after a while the problems comes back.
Do i have to set something in my google account to make it permanent ?
I think it has to do with the fact that i am using a free heroku account.
The servers stops after a while an perhaps has to login in gmail when it starts up again.
There's no way to make it permanent because Gmail doesn't want its service to be used to send out automated e-mails(*).
There are some providers that will make it much easier for you:
https://sendgrid.com/pricing/ has a free plan (up to 100 emails/day)
https://postmarkapp.com/pricing gives you 10k emails for 10$)
or take your pick, because the market seem to be pretty saturated: https://duckduckgo.com/?q=e-mail+delivery+service&ia=web
(*) What I suspect they do (though I could not find info about it) is that they can see if "same e-mails" are sent within short intervals.
You might try your luck (if it makes sens, when for example it's a toy project) to alter each e-mail contents to make it seem like different e-mail each time. But it will be just easier to go with free option in any other providers that actually want you to use it in your app.
I want an E-Mail to be sent using a background process whenever an Invite was generated.
What I currently have is this approach: The Invite model has the method send_mail, which sends an E-Mail using the Mandrill API and gem. It also has the method queue_mail adds InviteMailer with the invite's ID to the queue using Resque.
However… Since I'm having sort of a really hard time writing specs for this, I assume this might not be the best approach to send mails.
What I mainly want and need to test:
was the mail added to the queue?
is InviteMailer working properly?
does the mail contain the correct vital information?
Vital informations are: sent to the correct person, contains a link to a specific site and some specific data/text; also I'm not sure how to get the current host to the link.
I don't think this is a rare thing to do, so I wonder what the best practices are.
My testing environment: rspec, capybara, factory girl. I already added VCR, to cache the API-request.
You can use Mailcatcher to fake your mail server, and check received mail via web API:
Features
Catches all mail and stores it for display.
Shows HTML, Plain Text and Source version of messages, as applicable.
Rewrites HTML enabling display of embedded, inline images/etc and open links in a new window. (currently very basic)
Can send HTML for analysis by Fractal.
Lists attachments and allows separate downloading of parts.
Download original email to view in your native mail client(s).
Command line options to override the default SMTP/HTTP IP and port settings.
Mail appears instantly if your browser supports WebSockets, otherwise updates every thirty seconds.
Growl notifications when you receive a new message.
Runs as a daemon run in the background.
Sendmail-analogue command, catchmail, makes using mailcatcher from PHP a lot easier.
Written super-simply in EventMachine, easy to dig in and change.
How
gem install mailcatcher
mailcatcher
Go to http://localhost:1080/
Send mail through smtp://localhost:1025
API
A fairly RESTful URL schema means you can download a list of messages
in JSON from /messages, each message's metadata with
/messages/:id.json, and then the pertinent parts with
/messages/:id.html and /messages/:id.plain for the default HTML
and plain text version, /messages/:id/:cid for individual
attachments by CID, or the whole message with /messages/:id.source.
I've read most of the other answers on this topic, but a lot of them related to either third-party services like MailChimp (which I'm not necessarily opposed to) or how not to upset the host's email server.
I believe this case is unique so that it'll contribute...
I have my own DigitalOcean droplet running a rails app. I need to send out 100-1000 emails every so often, each with a unique message (a link I'm using for tracking clicks originating from the email).
I'm also operating my own iRedMail server.
Can someone recommend how to best-handle this task? I was going to simply cycle through the list of emails and use the template.html.erb to drop in my link, but what types of problems might I run into?
Thank you!
You should decouple your Rails App from the mail sending so that you don't have to wait in your view for the mails to be sent (assuming that you click on something that triggers the start of your mail sending). Use something like delayed_job or another queueing mechanism that Rails offers and only queue up the sending job of the e-mails. Then when the queue comes to execute the particular job you can customize the message with an HTML part and a text part or whatever else you need and pass them on individually to your MTA.
How would i go about to receive mails in a Ruby on Rails application without going through a mail server like PostFix or to fetch them by pop3 etc.
What i was to do is to catch all mails sent to #mydomain.com and just do something with them in my application. I don't need to store the mails or anything like that.
Is this posible?
I just implemented this for my SAAS to autoprocess mailer-bounce notification messages.
Call me, call you?
You call me
You can set up a local mail server. It would then respond to an incoming email, and start up a rails executable to process the email. This method is NOT recommended since starting up rails is a big task (takes multiple secs and lots of memory). You don't want a Rails bad boy started up just because you received an email. You'd be writing your own DDOS attack. (Attacking yourself.)
I call you
Instead, poll for email on your own schedule by using a single job to process all currently waiting emails. You need to set up a background job handler since stock rails is focused on responding to web requests. I use delayed_job, but there are other alternatives including kicking off a cron job every so in often.
Another benefit is that you don't need to manage a mail server. Leave that headache to someone else. Then use the Ruby library net::imap to read the incoming mail and process it.
If your process doesn't recognize the email format, then forward the msg to a human for processing.
And be sure that if the process sends mail in addition to reading/processing it, that the process uses a different email address as its From address. Otherwise, odds are good that sometime along the way, you'll end up in an email loop and many gigabytes of messages going back and forth. For example, your process receives a message, responds to it, but in the meantime the sender (a human) has switched on vacation response. And your robot then responds to the vacation response..... oops....
Writing your own mail server
Re:
How would i go about to receive mails in a Ruby on Rails application without going through a mail server like PostFix or to fetch them by pop3 etc.
What i was to do is to catch all mails sent to #mydomain.com and just do something with them in my application. I don't need to store the mails or anything like that.
Direct answer: Yes, you could do this by writing an smtp server and setting up dns so your machine will be the mail destination for the domain. Your smtp server would process the messages on the fly, they would not be stored on your system at any point.
Is this a good idea? No, not at all. While appearances may be to the contrary, email is a store and forward system. Trying to avoid storing the messages before your app processes them is not smart. It would be a very very poor "optimization." However, using an access protocol (POP3 or IMAP) is a good way to avoid the costs of installing, configuring and managing a mail server.
You can do this if you write your own mail server, or if your mail server supports hooks to run external programs upon receipt of mail (e.g. procmail).
If you don't have procmail available (or, if on something like Exchange Server, don't feel like writing custom rules or extensions), you're simply better off using a pop3 library to fetch mail.
Obviously, writing a mail server is more difficult than any of the alternatives.
If you're mostly worried about checking potentially hundreds of email accounts, that's solvable by configuring your email server properly. If you're on a hosted provider, ask your server administrator about creating a "catch-all" account that routes all mail to unknown addresses to a single account.
If you're aiming to avoid having to poll a server, consider the IMAP IDLE command. I've successfully written a Ruby client that opens a connection to an IMAP server, and gets told by the server when new mail arrives.
For my side project kwiqi, I use ActionMailer's 'receive' method to process incoming email messages for tracking my expenses. Heroku doesn't have a local mail server running that same code will not work. One solution I've thought of is to periodically hit a controller action that will pull messages from Gmail. Are there other solutions that are reasonable? Is anyone processing incoming emails in Heroku?
You can use sendgrid addon, and their parse api (http://wiki.sendgrid.com/doku.php?id=parse_api). I've written a short tutorial on how to do so here: http://nanceskitchen.com/2010/02/21/accept-incoming-emails-into-a-heroku-app-using-sendgrid/
I know that this is a little late but for anyone else that might find this useful in future we created the http:///CloudMailin.com addon for Heroku that should help you to receive email on Heroku Rails apps really easily.
Heroku support running workers using DelayedJob. Workers are resourced just like Dynos (you pay by the hour) and for this you get a dedicated resource to process your emails.
In the past I have used Cron calling a controller in my app. It's pretty effective.
If the hourly limitation is an issue, you can call your app from another location ... I have a cheap Dreamhost account for some of my non-priority sites that I have used as Cron systems.
There are also a number of ping and uptime services that you can use for this purpose as well ... simply pass these services your email controller.
A real limitation of Heroku currently is that the most rapid frequency they support for cron jobs is hourly.
I'd recommend using Gmail and using delayed job as an alternative to cron to set a more reasonable frequency. There is a good tutorial on setting this up at WiseJive