Url

Protocol-relative URLs in email

When you link to an external resource – an image, a javascript file, some css style – from a web page you do so with a URL, usually something like “https://example.com/blahblah.css” or “http://example.com/blahblah.css”.
The world is beginning to go all https, all the time, but until recently good practice was to make a web page available via both http and https.
The problem is that if you try and load a resource from an http URL from a page that was loaded via https it’ll complain about it, and not load the resource.
And if your users web browser is loading the http version of your page because it’s Internet Explorer 6 and doesn’t speak modern SSL then it’ll be unable to load anything over https, including any of your resources.
So whether you choose https or http protocol for loading your page resources it’s going to break for someone.
One common trick to avoid the problem is to use a protocol-relative URL. That looks like “//example.com/blahblah.css”, and it’ll load the resource over the same protocol that the page was loaded over.
While we can safely use “https://…” everywhere now, “//…” URLs are still a common idiom for things like loading things like CSS libraries from public content-distribution networks as well as your own resources.
I was reading long-but-excellent writeup about Stack Overflow’s migration to TLS (hey, I read this sort of stuff for fun) and they point out something I hadn’t considered – mail clients don’t really have any sensible way to use protocol-relative URLs. The mail client loaded the “page” from a mailbox and so has no base document protocol to work from (even if there’s a <base> element in the content it’s not likely to affect a mail client). If the user is reading it via webmail or a mail client that’s using an embedded web browser to render HTML it might work, sometimes, but it’s not going to reliably load that resource in general.
So, if you’re copy-pasting content from your web collateral to reuse in an email, make sure you’re not loading anything external – including images – via a “//…” style URL. Rewrite them to use “https://…”.

Gmail filtering in a nutshell

Gmail’s approach to filtering; as described by one of the old timers. This person was dealing with network abuse back when I was still slinging DNA around as my job and just reading headers as a hobby.

New top level domains

ICANN have signed agreements for four new top level domains, all internationalized domains from the 2o12 applications for new TLDs.
They are شبكة (“network” or maybe “web” in arabic), 游戏 (“game” in chinese), онлайн and сайт (“online” and “website” in russian).
It’ll take a while for the registries to ramp up their infrastructure, but you might start seeing domains registered in these TLDs as soon as Q1 of next year. Email in internationalized domains is still not really viable, but web pages with fully internationalized URLs certainly are, and they’re likely to get much more popular with these new TLDs.
Can your message composition and reputation monitoring infrastructure handle non-ascii URLs correctly? If not, you’ve got six months or so to start getting that in place.