I have a rails app and I am using ActionMailer to send email but now I need to know if the email is delivered or what?
Do anyone has an idea of how to handle sent emails status(e.g bounced, delivered) ?
thanks.
Email service providers use a technique called variable envelope return path. The idea is to encode a unique key for each message into the (envelope) return address so that when a destination smtp server returns email as a bounce you can tie it to the originating message.
If it sounds complex, it is. It gets harder if you want to track response rates, which links were clicked, opens, use Domain Keys, etc. Note that it requires you to set up or configure an SMTP server for handling returned mail.
There are a number of services that provide this all to you on a Software As Service basis. We use socketlabs and are very happy with them. Industrial strength and all. I've also heard of people using Postmark in the Ruby community.
Related
I'm currently creating an email app that is able to send emails to many users. However, I want to know whether there are bounced emails. I'm currently using Amazon SES to notify me if the email is bounced. However, I want the bounced email's data to be automatically entered into my Rails application instead of typing it manually based to the mailer daemons I get from Amazon. Is there are way to do so?
If you are willing to pay, this SaaS site called bouncely seems to provide an interface and an api wrapper around SES bounces.
send_email() returns a response object which can be interrogated for the response metadata.
Compare the status of this with the code you are interested in, perhaps a 550.
I couldn't find any clean existing solution for this, so I wrote a gem (email_events) that allows you to put a email event handler method (including for bounce events) right in your mailer class: https://github.com/85x14/email_events. It supports SES and Sendgrid, so should work for you if you still need it.
I'm fairly new to Ruby on Rails and actually entirely new to website mailing. In a lot of example tutorials I see a "from" object assigned to, for example, "new#example.com". When I setup the emailing functionality on a localhost the RoR command prompt says that everything finished fine even when I keep "new#example.com" as the from object. Can I actually mail from a localhost port? What would I have to put as my "from" address in order to actually send mail from the my local web application? Just a regular email I have? How would it be authenticated to ensure that the "from" address is actually the real address?
It seems a really fundamental concept and I understand all the model/view/controller actions that have to be done to make it work but I'm confused I guess as to how it actually works
In general the from field can be anything.
Some mail servers may take action if they think that you are claiming to be someone you are not, such as blocking mail or marking it as spam (via mechanisms such as DKIM or SPF). These are done at the domain level, ie the mail server tries to work out whether the server talking to it is allowed to send email claiming to be from #example.com.
Other mail servers mail just silently rewrite your from field if they know who you are, for example if you are talking to the gmail smtp servers and have authenticated as bob then the from field will be set to bob#gmail.com, unless it is already set to an email address gmail knows you own.
By default, in development rails doesn't try and send email at all. For it to send email you need to configure the deluvery_method, usually this involves either setting it to :sendmail (if you have an appropriately configured instance of sendmail running locally) or setting to :smtp and also providing details of an smtp server to use.
I am building an application using Ruby on Rails. I want to do something that I am not even sure is possible;
I have a mailer that is working, however I want to enable users to send emails using their own email address in the FROM parameter. Its almost as if the ":from" parameter has no effect on the email sent.
I'm a bit of a noob when dealing with email servers so please be as detailed as possible. I doubt there is a smtp mail server set up on my hosting account, so if I need to do something like install smtp on my hosting account please be as descriptive as possible.
You are able to set the From: field to whatever you want, theoretically, but in practice you are often limited as to what you can put in there. Many email providers will automatically replace the From address with your own regardless so that you can't masquerade as someone else.
You're probably intending to do something like this:
From: Example Customer Name <name#example.com>
Also keep in mind that sending email from arbitrary domains will result in a very high chance of being flagged as spam since you are most likely not listed as as a host authorized to send for those domains which is typically implemented with SPF.
The best practice is to set the address to be something like this:
From: Example Customer Name <you#yourdomain.name>
That way you're not spoofing your actual email address, only the associated label, which is not typically verified.
Right now my app sends out email notifications. I'd like to allow the user to reply directly to the email, which then gets ingested by my app and inserted into the database.
Are there any Rails gems, services, tutorials that can point me in the right direction.
Also, probably need to make the reply-to email have a UID, replyto--UID#domain.com, so I don't have to rely on the from (sender).
What do you think?
Thanks
A few good articles to get you started:
http://railstips.org/blog/archives/2008/10/27/using-gmail-with-imap-to-receive-email-in-rails/
http://jasonseifer.com/2009/04/24/receving-email-with-rails
We have a free service that posts incoming email to a url of your application (same as sendgrid API):
http://www.smtp2web.com
You can also use the mailman gem if you want to poll for the email at regular intervals:
https://github.com/titanous/mailman
As far as the 'replyto--UID#domain.com' kind of email addresses are concerned, you will have to create a catch-all address for your domain (it is better if you use a obscure subdomain, as it would reduce the amount of spam) which forwards all such email to a given mailbox(say notifications#domain.com).
I would highly recommend using CloudMailin for the same.
It provides you a receiving email address, which you can add as a reply-to header in your mail.
About the unique UID, for tracking each reply in context of the sent email, you could generate a random string, and modify your reply-to header as "[email provided by cloudmailin]+[your random string]"
You'd need to look at configuring your sendmail/postfix to accept incoming mail first off ( if you're using unix based server ).
Heres a good article:
http://jasonseifer.com/2009/04/24/receving-email-with-rails
You can use Sendgrid to parse incoming email and have it send along to your app via a web-post.
This is a decent tutorial (heroku focused)
Or you can view Sendgrid's ParseAPI to see how to integrate.
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.