Goodmail sued for patent infringement

Late last week RPost sued Goodmail for infringing two patents. One patent authenticates content and delivery of documents. The second verifies the message was received by the recipient.
Patent #6,182,219: Apparatus and method for authenticating the dispatch and contents of documents.

Apparatus and method for authenticating that a sender has sent certain information via a dispatcher to a recipient is disclosed. The method includes the steps of: (a) providing a set A comprising a plurality of information elements a1, . . . an, said information element a1 comprising the contents of said dispatched information, and said one or more information elements a2, . . . an comprising dispatch-related information and comprise at least the following elements: a2-a time indication associated with said dispatch; and a3-information describing the destination of said dispatch, and wherein at least one of said information elements is provided in a manner that is resistant or indicative of tamper attempts by said sender, (b) associating said dispatch-related information with said element at by generating authentication-information, in particular comprising a representation of at least said elements a1, a2 and a3, said representation comprising a set of one or more elements, each comprising a representation of one or more elements of said set A; (c) securing at least part of said authentication-information against undetected tamper attempts of at least said sender. The dispatch relates either to transmission or to manual delivery. The apparatus implements the operations of the method.

Patent #7,240,199: System and method for verifying delivery and integrity of electronic messages

A server receives a message from a sender and transmits the message to a recipient. The server normally transmits the message in a first path to the recipient. When the sender indicates at a particular position in the message that the message is registered, the server transmits the message in a second path to the recipient. The sender can also provide additional indications in the message to have the server handle the message in other special ways not normally provided by the server. After learning from the recipient or the recipient’s agent that the message was successfully received, the server creates, and forwards to the sender, an electronic receipt. The receipt includes at least one, and preferably all, of the message and any attachments, a delivery success/failure table listing the receipts, and the receipt times, of the message by the recipient’s specific agents, and the failure of other agents of the recipient to receive the message and a an encrypted hash of the message and attachments subsequently. By verifying that the digital signature on the sender’s receipt matches the digital receipt at the server, the server can verify, without retaining the message, that the receipt is genuine and that the message is accurate.

Not being a patent attorney, I don’t know how valid the infringement case is. Given the industry push for authentication; however, the lawsuit may have further reaching consequences.

Compliance vs. Deliverability
Technology does not trump policy when it comes to delivery

Related Posts

Yahoo blocks unauthenticated PayPal and eBay Mail

Yahoo announced this morning that over the course of the next few weeks Yahoo would roll out a new feature to their email that blocks any unauthenticated email from eBay and PayPal.
In a blog post Nikki Dugan says:

Read More

DKIM implementation survey: prelim results

First off, I want to thank everyone who participated in the DKIM implementation survey. This week has been pretty hectic so far, so I haven’t had a chance to actually dig down into the data from the survey, but I thought I’d post some preliminary results.
The ESP survey had 45 respondents. 30% of those sent more than 15 million emails a month.
Of all the respondents: 40% are signing with Domain Keys, 51.1% are signing with DKIM.
Of all respondents: 79.5% are signing with Domain Keys and 78.8% are signing with DKIM to access services (whitelists or FBLs) provided by the ISPs.
50% of those not signing with Domain Keys are not doing so because customers have not requested it.  61% of those not signing with DKIM are not doing it because of technical difficulties with deployment.
The ISP survey had 16 respondents, with 37.5% handling less than 500,000 mailboxes and 18.8% handling more than 15 million mailboxes. 75% of respondents said they are not checking Domain Keys on inbound mail. 56% said they are not currently checking DKIM on inbound mail.
Only 10 ISPs answered the question if they plan to check either Domain Keys or DKIM.

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