The email industry's latest buyout happened a few days ago and we witnessed a highly reputable email monitoring and deliverability reputation company Pivotal Veracity agree to buyout terms from Unica, an Email Service Provider with  gunpowder. Unica is attempting to be a "one-stop shop" for marketers that utilize their suite of services and with the acquisition of Pivotal Veracity, Unica may have completed it’s mission of also providing email reputation and deliverability services to its core clients.

What amazes me about this transaction is that Pivotal Veracity was really making strides in becoming a thought-leader in this small field,  and was competing closely with archrival ReturnPath.  I believe the buyout could potentially alienate a number ESP's from eventually partnering with Pivotal Veracity.  As a result of the buyout, ESPs will be very cautious in their approach to working with Pivotal Veracity. However, this by no means diminishes Pivotal Veracity's tremendous accomplishment and a huge congratulations is in order to everyone associated with Pivotal Veracity including but not limited to Deirdre Baird, Michelle Eichner, Jordan Cohen and Len Schnyder.  It certainly looks like Pivotal Veracity accomplished their goal and executed on their exit strategy perfectly.  For many successful companies, "stage five" constitutes an exit strategy of some kind. This process usually happens after key executives and members of the board vote on such an initiative.  I just think that stage five might have come a bit early for Pivotal Veracity.

All evidence seems to show that the real winner in this transaction is ReturnPath.  ReturnPath no doubt also has an exit strategy, but they appear unwilling to divulge a strategy or partner with an ESP at this point, given their unique leadership position and respected voice in the industry.  Although Pivotal Veracity has many well spoken and thought provoking leaders on their staff, I think ReturnPath and their consummate staff are the real superheroes here.  From  Stephanie Miller, the passionate and relentless email advocate to the outspoken J.D. Falk, whose innate knowledge of email technology and deliverability illuminates us all.  Then, of course, there is the self-proclaimed spamfighter himself, Neil Schwartzman. Without a doubt, ReturnPath’s luminaries saturate the industry with reliable and balanced messaging every time.

Furthermore, with leading services in place that are more robust than ever (such as the latest from Sender Score outlined here by Spencer Kollas), and definitive plans in place for maximizing and monitoring domain reputation for senders, the future looks promising.  When you take emails bright future into account, it appears that  ReturnPath is poised for many quarters of strong growth.  I don’t want to sound like an analyst here, but I really think ReturnPath has what it takes to raise the bar for the entire email community and further develop its existing reputation services.

With these developments, ESPs will now will look to ReturnPath as the consummate leader in the email reputation monitoring space and see one fewer rival, one fewer choice to make.  Senders and ESPs will find that ReturnPath is the only high level and sovereign conduit for stellar email deliverability monitoring and reputation.  The allure of ReturnPath is its stout independent position in our space (a positon that only those in our space truly appreciate.) Certainly Matt Blumberg, George Bilbrey and their hardworking crew can now navigate the email reputation landscape exclusively.

At some point in the future, I’m sure ReturnPath also has an exit strategy in mind and that strategy is not for us to surmise. I would venture to guess that as the industry continues to mature and consolidate, ReturnPath may consider filing for an IPO, especially as we see continued consolidation in this space.   I think what matters most is to enjoy the exciting journey that ReturnPath is paving for our industry.  We now have two choices: we can either watch or we can help them build a company of which we can all be proud of. 

Fred Tabsharani

Port25 Solutions, Inc.

@tabsharani

The Final Word on DKIM and Deliverability

By: J.D. Falk of Return Path

Seems like every week, I see another industry colleague asking for a detailed list of how each DKIM option affects deliverability. Everyone who's asked for this is a smart person, generally clueful, but this question stumps me. Perhaps it's that while I learned about email technology as a way to get a message from one autonomous system to another, he learned about it in the frustrating context of trying to figure out why his mail was being blocked -- so it has never before crossed his mind that new email technology might be invented that won't make delivery of his marketing messages more difficult.

See, DKIM isn't some wacky new anti-spam method intended to reduce your ability to get mail delivered (that's what that made-up word "deliverability" means, after all.) It's authentication, designed to make it easier to identify the good senders.

DKIM only answers two questions:

1. Does the message have a valid signature?
2. If it does, what domain signed it?

The signing domain, identified by the d= tag in the DKIM signature header, is the only part of the DKIM signature where the choices you make now will directly affect the continued deliverability of your messages. This is because d= is how you tell the receiving system who you are.

With a valid signature on the message, if the receiving system has a domain-based whitelist, and your d= is on it, the message gets in. If they have a domain-based blacklist, and your d= is on it, the message will be rejected. Few mailbox providers have either of those today -- but if they have a domain-based reputation system, which we know the big mailbox providers are working on, then delivery depends on reputation. It's exactly the same as with IP addresses today.

And just as with IP addresses, consistency is critical. If you want to separate different mailstreams, then instead of sending from different IPs like you were before, you can now sign with different domains: shipping.example.com, marketing.example.com, corporate.example.com. Within the context of authentication, each of those is an entirely separate entity. Reputation assessment systems will quickly figure out that there's a relationship between everything that's part of example.com, though, so you can't use this to escape the much-deserved bad reputation of a bad mail stream.

If you send through an ESP today, chances are they sign with their own domain. This means that if you switch to another ESP, you can't take your reputation with you. However, it also means you can borrow the ESP's reputation as long as you're their customer. Work with your ESP to choose the configuration most appropriate for your situation.

So you can stop worrying, sign your mail, and get back to the important work of making sure your recipients are happy to receive the messages you send.

If you're interested, here's a rundown of all the other options in the base spec -- RFC 4871 -- and what effect they're likely to have on delivery of signed messages. If you haven't read the introduction and the terminology and definitions section yet, please do so now.

There's currently only one acceptable value for the version (v=) tag. If yours isn't 1, then the DKIM signature isn't valid. Effect on deliverability: none if it's 1, otherwise the message will be treated as if it wasn't signed.

The algorithm (a=) is very important to cryptography geeks, but we're not talking about ICBM launch codes here. Unless you remember why DLG2209TVX was replaced with CPE1704TKS, accept whichever algorithm and key size your mail software vendor or ESP recommends and be done with it. (Just watch, someone will comment that rsa-sha1 is insecure because someone could decrypt it in a matter of months -- per message.) Effect on deliverability: none.

Canonicalization (c=) is a sneaky way to get around the fact that sometimes an intermediary mail server will make minor changes to a message, like capitalizing header field names or snipping empty lines at the end of a message. With the default "simple" algorithm, those changes would cause the signature verification to fail. With the "relaxed" algorithm, those changes may pass. Effect on deliverability: none unless the message fails.

You can choose to specify, in the h= tag, which header fields you're signing. There's a good description in the base spec of why you might or might not choose particular fields. If you use this, I'd go with the headers that users are likely to see in their mail client, plus anything you use for tracking. Effect on deliverability: none.

Similarly, you can copy all of the signed header fields into the signature with the z= tag. I'm not sure why you would, except for debugging. Effect on deliverability: none.

The selector (s=) is just a way to look up which key you're using, allowing you to use multiple keys with the same domain. You might have different keys for different offices, or systems, or create a key that you can give to your ESP to sign on your behalf. The selector is also useful for changing keys periodically, in case the private key is no longer private -- for example, you could change selectors every other month, removing old ones a few months after you've stopped using 'em. Effect on deliverability: none.

A somewhat controversial option is the body length limit, designated by the l= tag. This allows the signer to say "I signed this much of the message, but there might be more content after that -- and if so I'm not responsible for it." It's a reaction to discussion list software which may automatically add an informational footer to the end of a message. Thing is, these lists invariably make other changes also -- new headers, et cetera -- so the signature would be broken anyway. And, if your focus is on keeping the recipient safe (as it is for all mailbox providers), why would you deliver a message where the top part is from a trusted sender and the bottom part could be malware? Effect on deliverability: could be bad. Don't use this.

The q= value is easy: it can only be "dns/txt". Anything else is invalid. Effect on deliverability: none if it's dns/txt, otherwise the message will be treated as if it wasn't signed.

There are two optional tags referring to time: t= is the time the signature was created, while x= is when it expires. Both of these are designed to catch stupid criminals. If the signature was (allegedly) created after the message was received, it's not valid. Or if the message is received after the signature expires, it's not valid. While it's not entirely clear what will happen in the wild, I'd recommend skipping both of these. Effect on deliverability: none if the times match up or the tags aren't used; otherwise, the message will appear suspicious.

A formerly controversial feature is the i= tag, which looks like an email address -- but probably isn't. As I explained back in March, Cisco uses this to identify individual users: i=santaclaus@cisco.com, if Santa Claus worked for Cisco. And you know, he might. More common, I'd expect, senders will use i= to denote distinct mailstreams or internal divisions for their own tracking purposes: i=transactional@example.com, i=marketing@example.com, i=nyc-office@example.com. Thing is, there's simply no way for anyone on the receiving side to know whether marketing@example.com is a mailstream, a department, a individual email address, or simply a string of randomly generated characters. As such, reputation is more likely to accrue to the d= value. Effect on deliverability: probably none.

So unless you use l= or have unrealistic expectations about i= or s=, as we discussed above, d= is the only thing that matters. See? Nothing to worry about.

------------

-Dennis
Eloqua

Don't Just Send, Deliver!

By J.D. Falk

Director of Product Management, Receiver Products

With every new technology, there are a few people who fully grok not only where it stands now, but where it's going -- who will be using it, and how. In our case, these are people whose thinking about reputation is so far ahead of the rest of the industry that if we would have had them as speakers at our IN conference a few weeks ago, and they revealed their visions of the future, everyone's heads would have exploded!

One of these is my friend Mike Adkins, who works on authentication and reputation for AOL. AOL has always been a leader in the industry, and Mike and I -- along with Dave Crocker, and other smart folks -- have been talking about the inevitable and much-needed intersection of authentication and reputation at MAAWG for the past few years. One of the recurring difficulties with this or any complex new technology is that it's new: there are no existing "best practices" and everyone is worried about making the first mistakes. Mike's fed up with this -- as are we all -- and he has decided to put a sharp wooden stake into the heart of the problem. Recently, he's been talking very candidly with the industry about AOL's future plans. The plans may change, he says, but this is their starting point -- and anyone who wants to continue sending mail to AOL's subscribers, or to understand the direction the rest of the industry is likely to take, needs to pay attention.

I tend to get overly wordy and perhaps somewhat theoretical when talking about this topic, so Return Path's marketing team has condensed what we understand of AOL's plan into a few simple bullet points:

•    AOL will be implementing domain reputation next year. It will be used in parallel with their existing IP reputation system, and will include a domain-based feedback loop and domain-based whitelisting.

•    Domain reputation will be based on DKIM. This way, it's actually your reputation -- not the reputation of some spammer who's been forging your domain. If you are not signing with DKIM, their old IP reputation system will still be in effect.

•    All AOL sites -- including Compuserve and Netscape -- will use the same system.

•    Announcements of the rollout and other relevant information will be posted on their postmaster site.

This is, still, a novel use of multiple, fairly young technologies -- and so we must applaud AOL's willingness to take the first public steps, and to be so open about their plans. Our colleagues elsewhere in the ISP world have indicated that they're developing similar plans, and for many, that will directly involve some new technology that we've been designing with them. Stay tuned for more..

Original Post

-Dennis
Eloqua

Don't Just Send, Deliver!

GREAT piece from our friend J.D. Falk of Return Path. Please take some time out to read this.

http://www.returnpath.net/blog/2008/10/the-root-of-all-email.php

-Dennis
Eloqua

Don't Just Send, Deliver!

This week the industry is, once again, abuzz with talk of the e360 lawsuit against Comcast.  e360 was attempting to use the federal courts to force Comcast to accept unwanted mail, and the judge has ruled on the case.  As email technology guru John Levine wrote on Friday morning, "it's a fun read."

I read Judge Zagel's order twice: first from an anti-spam perspective, and then again thinking about how it might affect our clients.  Some marketers will surely find reasons to fear this judgement - but they shouldn't.  This is good for them, too - because by protecting the ISPs' good-faith efforts to protect their users from objectionable email, Judge Zagel is protecting the inbox against the really bad stuff.  Inboxes that are filled with scams, spams, and things that look like they might be scams or spams, are simply unusable.  The only way for people to be able to find, read, and respond to the messages they want to receive is for the inbox to be free of the junk they don't want to receive.

Marketers who follow best practices, who respect their subscribers, and who (to put it simply) follow all the other advice we give, can and should continue to do what you've been doing.  You'll get to the inbox, just like today.

The judge reiterated that, as clearly stated in the law, CAN-SPAM compliance does not override the ISP's right to block messages that their customers don't want.  Matt Blumberg wrote a few weeks ago that CAN-SPAM "has loopholes so large you can drive a semi through it."  It's not a minimum standard for sending commercial email; it's a minimum standard for staying out of jail when you send commercial email.

Most ISPs already operate that way, of course, but it helps them to have additional confirmation of their right to protect their customers and their equipment.  Nearly all of Return Path's ISP partners use Sender Score   and Sender Score Certified  to assist in those decisions.  Yet even with external data vouching for email as being good (or bad), ISPs remain the sole determinant as to whether email is accepted and where in their system it is placed.  Only the receiving ISP themselves can absolutely guarantee email delivery -- or non-delivery.

Finally, a sender saying "hey, you let those other spams through, why not mine?" - which was another part of e360's suit - is simply backwards.  To be successful at marketing (or anything else), you don't want to be as bad as the worst.  Your job is to be better than the best: the most relevant, the most respectful, the most wanted commercial email that each of your subscribers receive.

(This article was written for & originally published by Return Path.)