RPost and Goodmail settle lawsuit

Last September, I blogged about RPost suing Goodmail for patent infringement. Today the two companies announced they’ve reached a settlement and have forged a partnership. Goodmail will be offering RPost’s technology as an upgrade to customers and replacing their own “proof of delivery” technology with RPost’s legal service technology.

“We carefully reviewed RPost’s patented technology,” said Daniel Dreymann, President and co-founder of Goodmail Systems, Inc.  “We decided that we could build the strongest product offering for these compliance products by partnering with them.”
“The combined product allows both RPost and Goodmail to do what they do best,” said Zafar Khan, CEO of RPost.  “Goodmail’s CertifiedEmail protects the recipients of email by letting them know that the message comes from a trusted sender. RPost’s Registered Email service protects email senders by allowing them to prove that their message was delivered and what it said.”

Last week, RPost announced a partnership with ReturnPath to offer proof of delivery certification into the ReturnPath product line as well.

Integrating your email channel
Watch those role accounts

Related Posts

Delivery case study

Mailchimp published a case study looking at a customer moving from sending in house to using Mailchimp.

Read More

Interview with Matt Blumberg

Mark Brownlow posted an interview with Matt Blumberg, CEO of ReturnPath, about the merger with Habeas. It is well worth a read.
I have not yet commented on the merger and how this is going to affect the delivery industry because I am not sure how it will. Some of the effect is dependent on what ReturnPath does with the two companies and how their policies change. Here at Word to the Wise, we have known the folks at both companies for a very long time.
One thing that strikes me about this merger is that it means there are few direct competitors left in the delivery market. Everyone currently in the whitelist / delivery certification market seems to have a slightly different target audience and slightly different business model.
ReturnPath has SenderScore Certified and the Safelist. To get on these lists senders must meet criteria that, while filtered through ReturnPath, are set by the ISPs. Many senders find that they can get consistently high inbox delivery just by meeting the ISP standards, even if they are not SenderScore Certified or on the Safelist. However, certification does provide senders with an assurance that they are meeting standards.
Goodmail has their CertifiedEmail product. While certified senders must also meet criteria, they are also paying ISPs for delivery. I have always seen the Goodmail product as more focused on and more valuable for transactional senders rather than other senders. This slightly overlaps with ReturnPath’s target market, but the senders in this market do have different needs pressures.
ISIPP has their SuretyMail product. This provides a framework for senders to make statements about the email they send in a way that receivers can reliably query. This is a slightly different approach, in that ISIPP does not classify mail for their customers, but allows customers to self-classify. The benefit of ISIPP is that the ISIPP framework is trusted by their receiver-users and can push back on ISIPP if customers incorrectly self-classify.
Different markets, different business models, different approaches.

Read More

20% of email doesn't make it to the inbox

Return Path released their global delivery report for the second half of 2009. To put together the report, they look at mail delivery to the Mailbox Monitor accounts at 131 different ISPs for 600,000+ sends. In the US, 20% of the email sent by Mailbox Monitor customers to Return Path seed accounts doesn’t make it to the inbox. In fact, 16% of the email just disappears.
I’ve blogged in the past about previous Return Path deliverability studies. The recommendations and comments in those previous posts still apply. Senders must pay attention to engagement, permission, complaints and other policy issues. But none of those things really explain why email is missing.
Why is so much mail disappearing? It doesn’t match with the philosophy of the ISPs. Most ISPs do their best to deliver email that they accept and I don’t really expect that ISPs are starting to hard block so many Return Path customers in the middle of a send. The real clue came looking at the Yahoo numbers. Yahoo is one of those ISPs that does not delete mail they have accepted, but does slow down senders. Other ISPs are following Yahoo’s lead and using temporary failures as a way to regulate and limit email sent by senders with poor to inadequate reputations. They aren’t blocking the senders outright, but they are issuing lots of 4xx “come back later” messages.
What is supposed to happen when an ISP issues a 4xx message during the SMTP transaction is that email should be queued and retried. Modern bulk MTAs (MessageSystems, Port25, Strongmail) allow senders to fine tune bounce handling, and designate how many times an email is retried, even allowing no retries on a temporary failure.
What if the missing mail is a result of senders aggressively handling 4xx messages? Some of the companies I’ve consulted for delete email addresses from mailing lists after 2 or 3 4xx responses. Other companies only retry for 12 – 24 hours and then the email is treated as hard bounced.
Return Path is reporting this as a delivery failure, and the tone of discussion I’m seeing seems to be blaming ISPs for overly aggressive spamfiltering. I don’t really think it’s entirely an ISP problem, though. I think it is indicative of poor practices on the part of senders. Not just the obvious permission and engagement issues that many senders deal with, but also poor policy on handling bounces. Perhaps the policy is fine, but the implementation doesn’t reflect the stated policy. Maybe they’re relying on defaults from their MTA vendor.
In any case, this is yet another example of how senders are in control of their delivery problems. Better bounce handling for temporary failures would lower the amount of email that never makes it to the ISP. This isn’t sufficient for 100% inbox placement, but if the email is never handed off to the ISP it is impossible for that email to make it to the inbox.

Read More