Sunday, November 8, 2009

Magic Eraser Policy

If you've been around email long enough, you know there's a reason that gmail has that magic undo send feature. (Well, ok, once you see what it is, it's not that magic).

Your permanent recordBecause of the nature of digital information, it's too easy to have that email end up somewhere you'd rather not see it. Once you hit send, you don't have much control over the copying process. That email immediately becomes part of your permanent record. And, well, you've probably been there yourself at one time or another, wishing you hadn't sent it.

Even though there are a ton of sources on email etiquette. it's not too surprising that folks send email they wish they hadn't. We get weekly evidence of that. Like search engines and other popular archives, we get our share of requests to remove content. Sometimes folks ask for individual emails to be removed. Other times, we get more open-ended requests like, "please remove my name from your site".

The funny thing is that mailing list tools aren't really set up for redaction. They don't make it easy to remove individual emails, let alone parts of emails, from their archives. So, what does MarkMail do with this issue?

Magic Eraser

MarkLogic Server to the rescue!

One of the cool things for us, is that MarkMail actually has a magic eraser. With little pain, thanks to the real-time index provided by our MarkLogic server, we can remove emails from our index at a moment's notice. With a single line of XQuery code, we can move the document representing that email into a hidden collection and in nanoseconds, it's gone from all further queries to MarkMail. Yes, that is neato.

So we have the technology.

Still, we don't take message removal lightly. As an authoritative record of public history, removals are treated as the exceptional case. MarkMail provides content that it receives from publicly available sources. Everything we serve, we received another source. List administrators control their own lists and set policies on archives and we respect that. By posting on their list, you follow their rules, and we do too. So, if you want something removed from MarkMail, you'll usually have to get it removed from the original source first.

We've recently added our removal policy to the site, which has full details on how we deal with removal requests. The mechanism starts at our feedback page. In a nutshell, we will remove emails under two specific cases:
  1. Content in Violation of the MarkMail Content Policy (e.g. spam, porn, virus, fraud, illegal activities, copyright violations)
  2. Content Removed from Official Archive
When content clearly violates our content policy, we may simply remove it. No surprise there. That's bad stuff. Any other material needs to be removed from the original source before we'll act. In all cases, we prefer requests from the archive owner and/or requests that come with evidence that the content has been removed from the originating source.

This policy attempts to balance the rights of many parties, including those who have posted content to public lists and forums, those who own and administer the public lists and forums, and those who link to and reference the MarkMail archives as an information source and accurate record of history. We hope you find it reasonable.

Wednesday, November 4, 2009

Easy Change

As we look to make MarkMail pay for itself, it's pretty darn obvious that the traffic the site gets is sufficient to generate some revenue from advertising. A good number of well-known developer-centric sites display ads (e.g., sourceforge.net, www.xml.com, vim.org, linux.org, many others) with varying degrees of success. It even looks like msdn.com displays ads (albeit for other MS properties). And there are also sites like Expert Exchange that charge users a premium to search their archives, while also displaying ads.

The plan is to make minor adjustments to the site layout and provide relevant ads that are meaningful to a software developer. Over time, we'll be looking to bring in ad content that is

  • targeted to the list archive the developer is reading
  • suitable for a library (quiet, text-only, unobtrusive)
  • designed for and targeted to a developer audience
We'll be enabling Google AdSense text-based ads soon, as they appear to be best-of-breed, simple to implement. But we'll also be looking to sell advertising space ourselves.

In the meantime, before we're fully set up, if you're reading this and you have something worth communicating to some of the millions of folks that end up at MarkMail, give us a holler.

PS. If you sign up for a MarkMail account, you'll have access to a switch that will enable you to opt out of the AdSense ads.