SubscribeOne of the rails projects I’m working on recently has been having issues sending email from our web servers. Some 80% of mail was getting marked as SPAM, despite having the reverse DNS entries, SPF record and SMTP port open to verify.
The domain we were using is hosted by Google using thier Google Apps for small business service. On a whim, we decided to try sending directly through Google to see what happened.
We used the convenient write up at Ruby Inside for sending via TLS encryption, which is required by Google. It worked like a charm and the deliverability issues went a way.
However, there is one issue with doing so. Regardless of the from address you specify, it always sends as the email address you use to login to the server. Google deliberately modifies the from address. It’s not all bad though. It protects their deliverability rates with other ISPs and keeps spam way down.
The only way around this is to run overrides in each of the notifiers you want to use a different account for auth. Had they allowed it to come from any valid account in the domain that word be much, much easier, but they don’t. Sorry kids.
One more thing I couldn’t find online, but found by trial and error was how to specify the from name when sending using ActionMailer. Most spam filters knock for not having this information. Here’s how to do it:
def some_notification(message)
recipients message.email
from “Your Name
subject “Welcome to YourDomain.com”
body “This is where the body of the email goes.”
end
choonkeat
/ October 3, 2007I’m facing the same problem as you (google apps domain, spf, senderid, reverse dns, still marked as spam)
I’m moving to sending outgoing with smtp.google.com, let’s see what happens.
any idea yet why the original deliverability is so bad?
gbenedict
/ October 9, 2007There are several things that all contribute to this. It starts with making sure SPF records are valid. This is becomming more and more of an issue.
Next, the sending server needs to be able to listen to SMTP requests from the outside. Several of the big players will try to connect back to see if it is an actual mail server. If not, it denies your message.
Third, some of them are starting to match the sending server’s domain name to the sender of the message. This one is a nightmare and a big reason Google helps out.
The third one is reverse DNS records. Godaddy (secureserver.net) looks for mx or mail in your reverse DNS entries. Until we did this, we could not deliver to Godaddy hosted accounts, period.
Last, but not least is content. We were sending thank you notices for a congressional campaign. I’m sure this made things 10 times worse. We have a couple mortgage brokers we host as well and thier deliverability is terrible because of what others have done.
If you look at it from the flip side, Google does a large volume of email and has some weight with the big players. They all want to play nice with each other to make sure their email gets through. Power, power and more power.
Brian Armstrong
/ May 13, 2009I have experienced problems with this as well in the past. I’ve managed to eliminate the spam problem as you did, but be careful – the connection to google smtp is spotty. I’m seeing about one out of every couple hundred (rough guess here) where the connection is refused. Retrying it works. But if you aren’t checking for it in your code explicitly you’ll never see it’s happening because it isn’t a standard exception.
http://www.codeweblog.com/rails-timeout-exception-handling/
Further complicating things, in my case I had it in a spawn process (so the view would return quickly) and you get no messages from exception notifier in a spawn process.
In short – using Google Apps to send mail in Rails has not been very stable for me, and I don’t think it’s production worthy.
Hope this helps,
Brian
sandrar
/ September 10, 2009Hi! I was surfing and found your blog post… nice! I love your blog.
Cheers! Sandra. R.
Leo Quarterman
/ September 23, 2009Wow, this is great stuff and I’m glad I ran across your blog. Keep it coming!