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.

Related Posts

Email authentication

The great folks over at MailChimp have compiled a list of which authentication methods (DK, DKIM, SPF and SenderID) are in use at which ISPs.
Good stuff and very clear showing who is using what authentication.

Read More

DKIM "i=" vs "d=" and Reputation

This really should be part seven of a twelve part series or some such as it deals with an aspect of DKIM that’s really important, but is way down in the details of implementation. (dkim.org is a reasonable place to start for a general overview of DKIM).
There’s an apparently endless thread on the DKIM-SSP spec development mailing list at the moment about the differences between two fields in a DKIM signature that could be used to tie a senders reputation to. Several ESP delivery folks asked me to explain what everyone was talking about, and this post is a first cut at that.
“i=” vs “d=”
There are two possible fields in a DKIM signature that could be used to identify the sender of a message, and so to tie a sender history and reputation record to. They are the so-called “i=” and “d=” field, from the syntax used to include them in the signature.

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