No Such Weblog

Here's a [PDF] chart of data elements found in registrar and registry WHOIS services.

The chart (prepared for WHOIS Task Force 2's purposes) ignores .name (which is special), and TLD-specific data elements like eligibility related elements in the sponsored/restricted TLDs, and trademark information in .info and .pro. Also ignored: name server names v. name server IP addresses, opaque database keys, contacts' "organization" fields.

SMTP SPF: Senders Permitted From is a spam-avoiding proposal that looks like it might be adopted widely; it gives senders of e-mail a way to describe through DNS records what their messages look like and where they come from. E-Mails that don't match the description can then be discarded.

The proposal is likely to be adopted widely because it creates interesting incentives: If significant e-mail receivers apply SPF checks where available (and don't require senders to use SPF), and require existing sender domain names, this creates incentives for spammers to abuse non-SPF-enabled domain names. This will be painful for the holders and users of these domains, who in turn have strong incentives to publish SPF records. The same incentives apply for SPF records that are so loose that they are ineffective, or almost ineffective.

Later: Steve Bellovin (on IP) has a number of problems with the scheme.

I'm unimpressed by the privacy offered by .name WHOIS: The "detailed WHOIS" service which, according to the TLD agreement, is supposed to be password protected is the default service for port 43 queries, and is available from the web form without giving a password.

But then again, these guys might have better things to do.

Updated WHOIS data element chart including .name here.

A reader from PIR writes to note that the whois data element chart is wrong about the thick .org whois service. In August 2003, the .org registry WHOIS appendix was changed to be consistent with the data elements that registrars need to publish: The Registry Operator will not be required to post Whois Output Fields that are not required for posting in the Registrar Accreditation Agreement.

Updated data element chart here.

Writes Esther Dyson in the New York Times (link credit: Bret Fausett): What I'm proposing is not a rule-free society, but one in which rules come from the bottom up: generally enforced by peers, with governments in the background. ... The basic rule is transparency: You need to know whom you are dealing with, or be able to take proper measures to protect yourself.

Unfortunately, the article essentially sets up anonymity and accountability online as contradictions. They need not be: The kind of accountability Esther describes is not so much about knowing who someone is in real life, but rather about recognizing a party you are dealing with (or knowing that you don't recognize a party seeking to communicate with you, and taking appropriate action). It's, often, not so much about linking on-line activity to real lilfe, but more often about linking current on-line activity to past on-line activity -- and, by symmetry, linking future on-line activity to current on-line activity.

This is so because for many activities online, stakes are actually quite low: To decide who's messages to read on mailing lists, or blogs, or slashdot -- or, in the past, Usenet --, for instance, it may quite well be enough to know that source's reputation among peers, or to have read earlier messages from that source. If something goes wrong, only littlel damage is done. All one needs to know to make this kind of choice is a regularly-used online pseudonym (most often, that's the e-mail address these days). If the same person uses a different pseudonym elsewhere, that's their business.

(Where the stakes are higher, reliable links to a person's online existence are, of course, useful.)

Accountability online is not a binary choice between total anonymity on the one hand, and total transparency with links to real life on the other: There is a broad spectrum between these, and often, the level of transparency and accountability that's needed will lie somewhere in between.

As a side note, all the accountability you can get won't fix viruses and similar security intrusions, unlike what Esther suggests: Just like the ordinary flu, successful online viruses often travel along the links in social networks.

So I finally couldn't resist: Keine Photos bitte ("no photos please") is where I'm posting the occasional picture. The text that comes with the photos will be in German.

ICANN has published proposed corrections to the bylaws, to be considered by the board on 15 January 2004. These corrections change the number of council members per constituency back from two (as suggested by the reformed bylaws, but never implemented) to three (as favored by the majority of the council, and accepted by the board in Carthage) until the 2004 annual meeting.

It's worth noting that the change as drafted seems to need a correction: The terms suggested (2 reps until 2005, 1 rep until 2004, two-year terms from 2005) do not lead to the staggered terms for council members that are mentioned elsewhere in the bylaws -- unless there is another board decision that removes the 2004 sunset date on the three representative scheme.

Habeas attempts to fight spam with haikus: The theory is that whoever puts a habeas header into e-mail without having received a license gets sued by the corporation. Unfortunately, most of the spam that currently gets past my spam filter has the magical haiku -- and, even worse, is autolearned as "ham" by spamassassin.

score HABEAS_SWE -1.0

Since last week-end, sitefinder.verisign.com (the search engine to which the wildcard redirected) no longer resolves. The final nail in the coffin, or the first step towards re-branding and re-launching?

At work, I share my office with our systems administrator. Enters a colleague, puts on her sweetest "I neeed computer support" smile. "Hi, you've got this 'my computer does something I don't want it to do' expression in your face." -- "Errm, well, couldn't you remove the games from my computer? They are, well, preventing me from getting my work done. I mean, it would be nice if you could remove them, but it's not that urgent. Oh, by the way, the games that come with Fedora are not as good as the ones with the previous Redhat."

I've just sent ALAC's preliminary remarks on the new registry services PDP to the GNSO Council. The remarks are "preliminary" because we solicit public comment and further input on these; we will make sure that comments we get are heared by the GNSO.

Heise reports (in German) that a new instance of k.root-servers.net has gone life in Frankfurt.

It seems that some criminal is using my e-mail address, roessler@does-not-exist.org, as a sender address for (so far) body-part enlargement spam; typically, my address shows up both as the envelope sender, and in the From header of the messages in question. I'm, of course, not involved with that -- I'm just getting the bounces.

Things are, so far, on a much smaller scale than what happened to others, but it's still annoying. I'm not planning to change either my domain name, or my e-mail address; bounce messages that were not generated in response to messages I sent are discarded automatically.

Looking at Bret's latest insights into the kind of input the IPC (but not just the IPC) is getting from the public, one may be lead to believe that nothing goes on at ICANN. That's not precisely accurate, as far as the GNSO is concerned -- the last couple of weeks have been busy with conference calls.

WHOIS task forces #1 and #2 (access mechanisms, review of data elements collected and displayed; I'm a liaison to both, but currently focusing on #2) have been busy figuring out what kinds of questions need to be asked in order to gather the input people believe they need for an informed discussion; I understand that task force #3 (accuracy) is going through a similar exercise. Fortunately, none of the task forces is going to repeat the large-scale survey exercise of the DNSO's WHOIS Task Force. Instead, the plan is to tap GNSO constituencies and other specific sources of information. ICANN staff is expected to compile the input received before the Rome meetings. In Rome, there will be workshops for all three WHOIS PDPs. Constituency statements are then expected to arrive some time after Rome, with policy recommendations ideally ready by the time of the Kuala Lumpur meetings this summer.

The GNSO council is working on the new registry services PDP. On last Thursday's call, the council first discussed the business constituency's request to remove two "out of scope" items from the Terms of Reference for that PDP. From the discussion, it didn't become clear whether the BC was suggesting that the PDP should actually create a new consensus policy (that would be binding for registries, and would surely be highly contentious), or whether the BC was mis-reading the limits on the scopes of the PDP as limits on the scope of the process that is being designed. The discussion was settled by leaving the terms of reference unchanged, and by noting that the BC may, of course, include "additional remarks" with its constituency statement.

Speaking of constituency statements, these were due on 12 January. Among the statements received so far, the registry constituency is still missing in action, some other constituencies have only posted draft statements. The statements were briefly presented on the council call, and ICANN staff was asked to produce a summary and identify areas of convergence or divergence as far as visible from the current statements. I understand that the new registry services PDP will be the topic of another workshop in Rome.

The work that is going on on the four PDPs means that the GNSO is collecting a lot of experience with the new PDP. If anything is clear by now, then it's that the time lines outlined in the new bylaws were the product of wishful thinking: Task Forces that have to gather input in order to produce results (like all of the whois task forces) have no chance at all to meet the deadlines suggested. And even council-driven policy-development processes that "only" involve deliberation within constituencies, and between constituencies (like the new registry services process), are not able to follow the process: According to the original announcement of the new registry services PDP, results were due on January 15.

The latest worm (called Novarg.a, Mydoom, or MIMAIL_R) is big news all over the place; technical analysis here and here and later here. In a nutshell, the virus uses tech babble as its social engineeering trick, claiming that some message couldn't be transported and had to be wrapped into an attachment. Once people fall for that trick (and amazingly many seem to do that), MyDoom apparently installs a key stroke logger and a network backdoor, and prepares to launch a DoS attack on sco.com.

Being armed with good filters, a mail client I trust, and an operating system that won't run Windows viruses, I normally consider e-mail virus outbreaks as part of the general noise that gets thrown away automatically.

So, what makes this one special and worth a blog item? First, it has a new approach to social engineering. No more sex and crime (we recently had a relatively successful worm here which claimed -- in German -- that the recipient had been indicted for file sharing), but dry tech babble instead. And that approach works surprisingly well, leading to bombardment rates and bandwidth consumption last reached by Sobig.F last summer.

Also, the large scale of this outbreak makes it interesting to look at e-mail statistics again. I received the first instance at roughly 9pm CET, that's 3pm EST. Within just an hour, the bombardment peaked at several pieces of the virus per minute; fortunately (and somewhat surprisingly) much of this was caught by spamassassin. The virus scanner I'm also running kicked in at about 1 am, and has been catching the actual virus traffic since. Junk background noise is still far above the usual numbers, mostly due to bounce messages generated in response to viruses sent out with my e-mail address as the sender.

What are the lessons? First, hardly news, but still worth repeating: Virus scanners don't prevent infections, and -- even when updated within hours -- leave a huge window of opportunity for spreading a virus. Second, considerable annoyance is caused by virus scanning systems that still believe that they need to notify a message's alleged sender of infections. Third, spamassassin's heuristics prove surprisingly effective against much of the incoming virus flood.

From TelecomWeb: The 2nd U.S. Circuit Court of Appeals has upheld an injunction barring a Web hosting company from accessing a registration service [i.e., WHOIS] for Internet domains in order to harvest information for mass-marketing use.

The guys at ICANNfocus.org have published a story today that claims that ICANN is subject to the Data Quality Act. (The story is also at ICANNwatch, CircleID -- and there was a copy in my inbox this morning; I understand that I'm not the only one who got that.)

Two sets of messages here: First, there's this organization named Center for Regulatory Effectiveness which suddenly gets interested in ICANN, sets up icannfocus.org, and puts much focus on the MoU and the Department of Commerce's oversight role. The obvious question is, of course: What's behind that rather specific focus, and the sudden interest?

Second, the news itself. The Data Quality Act (maybe) applies to ICANN. The first question here is: What's this all about? I'm European. I don't have the faintest idea about US administrative law. So, what's the Data Quality Act, and what would it mean for ICANN, in practical terms?

Comments welcome.

Writes Jeff Neuman: It has just come to my attention that there is a scheduled hearing entitled "Internet Domain Name Fraud -- New Criminal and Civil Enforcement Tools" on Wednesday February 4th at 10:00 in 2141 Rayburn House Office Building. It is being sponsored by the Subcommittee on Courts, the Internet and Intellectual Property. It is a Subcommittee of the House Judiciary Committee. The list of witnesses testifying has not been finalized, but I have learned that a member from the IPC as well as a member from the International Anti-Counterfeiting Coalition may be testifying.

Ira Rothken on Politech: We decided to add ICANN and the United States Department of Commerce to our Federal Case in Northern California (Syncalot v. Verisign) involving the legality of Verisign's SiteFinder service. We added the above additional parties in an effort to have a more complete record and a full and fair adjudication of the issues. We are seeking to enjoin the SiteFinder service and declare it illegal. Here is a link to the First Amended Complaint which alleges, amongst other things, that Verisign breached its agreements and violated the law when it attempted to use control of the domain name root server to "break the Internet" and monetize domain name properties it did not own.

Later: Bret Fausett has read the complaint and suggests that the lawyers in question haven't done their homework.

As a follow-up to Tuesday's notes on Novarg, some MRTG plots that illustrate what happened in my inbox this week. The blue curve is legitimate mail; green is spam (and other junk), or recognized virulent material.

First, spam (and other junk that's automatically recognized). Note the peak on Monday evening, when Novarg first appears, and also the substantially higher junk bandwidth ever since -- due to notifications about the worm:

Second, recognized viruses (getting really interesting later in the same night):

If you want to compare the effect to Sobig.F, here's a similar plot showing Sobig's last days.

ICANN's latest board meeting was on 15 January. There is still no preliminary report available.

Relevant Bylaw language: No later than five (5) business days after each meeting (as calculated by local time at the location of ICANN's principal office), any actions taken by the Board shall be made publicly available in a preliminary report on the Website.