In our last installment we discussed MIME, Unicode and UTF-8, and IDNA, three things that have brought the Internet and e-mail out of the ASCII and English only era and closer to fully handling all languages. Today we'll look at the surprisingly difficult problems involved in fixing the last bit, internationalized e-mail addresses.
As we, here in the United States celebrate our independence this Fourth of July, we are reminded that the liberties and freedoms that come with that independence have yet to be won online. As citizens of this country we are blessed with safety and security from threats both foreign and domestic, but those guarantees have not yet extended to our citizenship in the global Internet community. This is true not just for American citizens, but for all Internet users throughout the world.
Back when the Internet was young end servers came with shovels (for the coal), everyone on the net spoke English, and all the e-mail was in English. To represent text in a computer, each character needs to have a numeric code. The most common code set was (and is) ASCII, which is basically the codes used by the cheap, reliable Teletype printing terminals everyone used as their computer consoles. ASCII is a seven bit character code, code values 0 through 127, and it includes upper and lower case letters and a reasonable selection of punctuation adequate for written English.
Email is a complex service and email abuse adds confusing deceptions. Worse, like postal mail and even telephone service, Internet mail is inherently open, flexible and even anonymous, making things much easier for abusers. Bad actors hide their true identity and their true purpose. Most other communication tools for users also are also quite open, and problems with email are being replicated elsewhere, such as instant messaging and social media.
Gradually it seems the word is spreading about a new blocking methodology to interrupt the ability of end users to click and visit phishing sites - thereby having their personal information/credentials at risk. This is the DNS Response Policy Zones. DNS RPZs allows companies that run recursive resolvers to create a zone that will not resolve specific domains.
In Taking Back The DNS I described new technology in ISC BIND as of Version 9.8.0 that allows a recursive server operator to import DNS filtering rules in what ISC hopes will become the standard interchange format for DNS policy information. Later I had to decry the possible use of this technology for mandated content blocking such as might soon be the law of the land in my country. I'm a guest at MAAWG this week in San Francisco and one of the most useful hallway discussions I've been in so far was about the Spamhaus DROP list.
I'm a guest at the MAAWG conference in San Francisco this week and several people have now mentioned to me the problem and the opportunity of anti-spam e-mail filtering for IPv6. Tomorrow is World IPv6 Day but since a bunch of the pieces have clicked together in my head I'll post this a day early.
As new Top-Level Domains (TLDs) are launched, the industry mustn't overlook the customer experience. A key question is this: Will the software applications we all use, recognize the new TLDs and know what to do with them in a timely fashion? Think email and even form-fill applications. I speak from experience here. In 2006 when we launched the .MOBI TLD, there were arguably only a handful of .MOBI email addresses in existence. To my dismay, I found that often emails sent only from my .MOBI account were not being received at the other end...
At the ENISA presentation on her botnet report at eco in Cologne, 9 and 10 March, one of the slots was dedicated to threats to the mobile environment. The message I was supposed to come home with was: we can still count the numbers of mobile viruses manually, <600; the problem will never be the same as on a fixed network as traffic is monitored and metered: We detect it straight away. We are studying the problem seriously. Are mobile operators really prepared for what is coming?
It's been a very bad month for ESPs, companies that handle bulk mailings for their clients. Several of them have had internal security breaches, leaking client information, client mailing lists, or both. Many have also seen clients compromised, with the compromised credentials used to send spam. The sequence of events suggests all the ESPs whose clients were compromised were themselves compromised first. (That's how the crooks knew who to attack.)