Who didn't invent email, part 2

Back in 2014, Steve wrote an article discussing Shiva Ayyadurai,and his claims that he was the inventor of email. In that article he links to a number of articles from Techdirt. Earlier this year, Shiva sued Floor64, the parent company of Techdirt, as well as Michael Massnick the Founder, CEO and editor and Leigh Beadon, a writer for Techdirt. (Original Complaint pdf from ReCAP). Ars Technica has a good article on Shiva and his claims.

The complaint asserts that the defendants defamed Shiva in their articles, caused him economic harm and inflicted emotional distress on him.
Today the judge dismissed the case (Memorandum and Order, pdf from ReCAP) against Michael and Leigh.  The legal standard for punishable defamatory statements is there must be a way to prove them true or false. The judge ruled that since there is not a single definition of email, that there is no way to definitively prove Techdirt’s statements as true or false.
No one disputes the Shiva coded a system that encompasses the features we expect of any desktop or web based mail client. As many people have mentioned, the fact he was 14 and put together a complex program is impressive in and of itself. No one is disputing what he did accomplish.
To my mind the fundamental core of email is interoperability. It’s that I can sit in my lab at the University of Wisconsin, type a message, hit send and have someone in Boston receive the message. I can sit here in my office in California and write to my client in the the UK. The bits of the email client, which define email according to Shiva, are not email. They’re important for usability, but they’re not what makes  email email.
According to Ars Technica, Shiva is going to appeal the dismissal.
EDIT: Techdirt has posted an article on the lawsuit and the dismissal.
 

Improving Gmail Delivery
Equifax compromise and their insecure response

Related Posts

The twilight of /8s

A “/8” is a block of 16,777,214 usable IP addresses. That’s a big fraction of the entire IPv4 address space – about 1/224, in fact. Each one is all the addresses that begin with a given number: 10.0.0.0/8 is all the IP addresses that begin with “10.”, “184.0.0.0/8” (or “184/8” for short) is all the IP addresses that begin with “184.” and so on.
How are they used? You can see in this map of the entire IPv4 Internet as of 2006.
For the IPv6 map just imagine the XP default desktop picture.
In the early days of the Internet /8s were given out directly to large organizations. If you look near the middle-top of the map, just left of “MULTICAST” and above “DISA” you can see “MIT”.
The Massachusetts Institute of Technology got into the Internet game pretty early. This is the first map I have where they appear, in June 1970:

The Laboratory for Computer Science at MIT were assigned the 18.0.0.0/8 block sometime around 1977, according to RFC 739, though it looks like they may have been using it since at least 1976.
By 1983 (RFC 820) it belonged to the whole of MIT, rather just the CS Lab, though you have to wonder how long term that was supposed to be, given the block was named “MIT-TEMP” by 1983 (RFC 870). According to @fanf (who you should follow) it was still described as temporary until at least the 1990s.
But no longer. MIT is upgrading much of their network to IPv6, and they’ve found that fourteen million of their sixteen million addresses haven’t been used, so they’re consolidating their use and selling off eight million of them, half of their /8. Thanks, MIT.
Who else is still sitting on /8s? The military, mostly US, have 13. US Tech companies have 5. Telcos have 4. Ford and Daimler have one each. The US Post Office, Prudential Securities, and Societe Internationale de Telecommunications Aeronautiques each have one too.
One is set aside for use by amateur radio.
And two belong to you.
10.0.0.0/8 is set aside by RFC 1918 for private use, so you can use it – along with 192.168.0.0/16 and 172.160.0.0/12 – on your home network or behind your corporate NAT.
And the whole of 127.0.0.0/8 is set aside for the local address of your computer. You might use 127.0.0.1 most of the time for that, but there are 16,777,213 other addresses you could use instead if you want some variety. Go on, treat yourself, they’re all assigned to you.

Read More

The perfect email

More and more I’m moving away from consulting on technical setup issues as the solution to delivery problems. Delivery is not about the technical perfection of a message. Spammers get the technical right all the time. No, instead, delivery is about sending messages the user wants. While looking for something on the blog I found an old post from 2011 that’s still relevant today. In fact, I’d say it’s even more relevant today than it was when I wrote it 5 years ago.
authenticated
Email is a fluid and ever changing landscape of things to do and not do.
Over the years my clients have frequently asked me to look at their technical setup and make sure that how they send mail complies with best practices. Previously, this was a good way to improve delivery. Spamware was pretty sloppy and blocking for somewhat minor technical problems was a great way to block a lot of spam.
More recently filter maintainers have been able to look at more than simple technical issues. They can identify how a recipient interacts with the mail. They can look at broad patterns, including scanning the webpages an email links to.
In short, email filters are very sophisticated and really do measure “wanted” versus “unwanted” down to the individual subscriber levels.
I will happily do technology audits for clients. But getting the technology right isn’t sufficient to get good delivery. What you really need to consider is: am I sending email that the recipient wants? You can absolutely get away with sloppy technology and have great inbox delivery as long as you are actually sending mail your recipients want to receive.
The perfect email is no longer measured in how perfectly correct the technology is. The perfect email is now measured by how perfect it is for the recipient.

Read More

September 2016: The month in email

Happy October, everyone. As we prepare to head to London for the Email Innovations Summit, we’re taking a look back at our busy September. As always, we welcome your feedback, questions, and amusing anecdotes. Seriously, we could use some amusing anecdotes. Or cat pictures.
 
San Francisco and Coit tower
We continued to discuss the ongoing abuse and the larger issues raised by attacks across the larger internet infrastructure. It’s important to note that even when these attacks aren’t specifically targeting email senders, security issues affect all of us. It’s important for email marketers to understand that increased attacks do affect how customers view the email channel, and senders must take extra care to avoid the appearance of spam, phishing, or other fraudulent activity. I summarized some of the subscription form abuse issues that we’re seeing across the web, and noted responses from Spamhaus and others involved in fighting this abuse. We’re working closely with ESPs and policy groups to continue to document, analyze and strategize best practices to provide industry-wide responses to these attacks.
I was pleased to note that Google is stepping up with a new program, Project Shield, to help journalists and others who are being targeted by these attacks by providing hosting and DDoS protections.
I’m also delighted to see some significant improvements in email client interactions and user experiences. I wrote a bit about some of those here, and I added my thoughts to Al’s discussion of a new user interaction around unsubscribing in the iOS 10 mail client, and I’ll be curious to see how this plays out across other mail clients.
For our best practices coverage, Steve wrote about global suppression lists, and the ways these are used properly and improperly to prevent mail to certain addresses. I wrote about using the proper pathways and workflows to report abuse and get help with problems. I also wrote about the ways in which incentivizing address collection leads to fraud. This is something we really need to take seriously — the problem is more significant than some bad addresses cluttering up your lists. It contributes to the larger landscape of fraud and abuse online, and we need to figure out better ways to build sustainable email programs.
Is there such a thing as a perfect email? I revisited a post from 2011 and noted, as always, that a perfect email is less about technology and more about making sure that the communication is wanted and expected by the recipient. I know I sound like a broken record on this point (or whatever the 21st century equivalent metaphor of a broken record is….) but it’s something that bears repeating as marketers continue to evolve email programs.
We had a bit of a discussion about how senders try to negotiate anti-spam policies with their ESPs. Is this something you’ve experienced, either as a sender or an ESP?
In Ask Laura, I covered shared IP addresses and tagged email addresses, questions I get fairly frequently from marketers as they enhance their lists and manage their email infrastructures. As always, we welcome your questions on all things email delivery related.

Read More