No Such Weblog

I've been lugging my laptops and assorted gadgets around half the globe in a variety of bags -- from too heavy backpacks and Dell bags (providing good protection, but almost heavier than the laptop itself) to flimsy conference give-away bags, nothing seemed right.

The ideal laptop bag to me must be within the limits for cabin luggage, spacious inside, lightweight, robust, and provide some reasonable protection to the electronics stored in it. Where do I get it?

..., then this bug report was made for you.

(I finally fixed some standards compliance issues with this blog. This exercise included correctly tagging all content here as iso-8859-15 -- after all, I'm occasionally writing ¤ signs. As a result, mt-rssfeed stopped being able to read my own RSS feeds. Generating iso-8859-15.enc according to the instructions above and copying it to the appropriate place on the system fixed that problem.)

Some weeks ago, I finally gave up on unmoderated discussion of ICANN-related topics. But then again, I'm still not convinced that blogs and icannwatch should be the only places for public discussion of ICANN topics.

That's why I have set up a new mailing list, called icann-people. The concept is simple: I'll run the list the autocratic way; no message is distributed unless I believe it is reasonable, and reasonably relevant to the ICANN community.

Subscribe here. When enough people have come together, I'll send an initial posting to let you know.

The GNSO Council met today for a one-hour conference call.

ICANN staff plans to prepare a revised report on new registry services by September 23/24.

On new gTLDs, ICANN is expecting further reports from WIPO and SSAC. A public comment period on the reports is expected to begin as early as next week. A "strategy implementation plan" is expected for the end of the month. Council plans to discuss this on its next call on October 21. The ten applications for new sTLDs are not affected by this.

On the recruitment front, ICANN is currently reviewing CVs received.

Under any other business, Marilyn Cade asked about the report prepared by Liz Williams, who had -- as a consultant to the President -- had asked GNSO participants about their experiences with the PDP; this work had come as a surprise for Council members.

NISCC Vulnerability Advisory 380375 talks about vulnerabilities caused by ambiguous MIME messages -- basically, a single e-mail body part may claim to be of two different types, or encoded according to two different mechanisms, at the same time. Implementations then just pick one interpretation, and, of course, they differ in which one they pick. Thus, a virus scanning e-mail gateway may see a message that's never displayed to the user, and the user may see one that was never inspected. Likewise, a message may be signed with PGP/MIME or S/MIME, but may still look quite differently to users relying on different implementations.

Corsaire is trumpeting this as an example for their "specialist approach" (press release); in the context of digital signatures, however, you may also have read about it here (November 2001).

(And that was just an obvious application of this January 1998 paper by Ptacek and Newsham to e-mail.)

Here's how one Internet dial-in provider here in Luxembourg greets its customers' modems:

Access to this device or the attached networks is prohibited without express written permission. Violators will be prosecuted to the fullest extent of both civil and criminal law. We don't like you. Go away. Visual Online S.A.

What an interesting attitude in customer relations.

In January, I mentioned that bounce messages that were not generated in response to messages I sent are discarded automatically.

The technique for doing this goes as follows: My mutt installation is configured to use envelope sender addresses (MAIL FROM, that is) different from my normal e-mail address for anything but list mail. Bounces sent to my normal e-mail address are discarded by my mail filter configuration -- these are the fake ones. Bounces directed to the specific MAIL FROM address I use, however, pass the filter, and end up in my inbox.

The sytem works fairly well for me, but of course requires rather fine-grained control over the different addresses to go into MAIL FROM (for machine answers) and the From header (for human answers).

(Maybe I should attempt to patent this?)

I haven't been using IRC "seriously" for quite some time; back then, ircII was the dominant client.

I now had a look at irssi, a perl-extensible client. The features and usability are really nice, but it takes some time to actually customize the program -- the documentation is not very good.

One has to wonder what Google AdSense was "thinking" when it put an ad for acnefreein3days.com next to this blog entry...

Majordomo 2 is the latest piece of e-mail forwarding software at least one of whose authors considers it a "good thing" to re-encode any MIME parts they touch, and argues that cryptographic signatures that are invalidated in the process are to blame on "broken" software on the sender's end.

The argument is bogus: Ever since 1995's RFC 1847 (which first specified multipart/signed), not treating the first part of a multipart/signed as opaque has been a violation of applicable standards. RFC1847 is the basis of both OpenPGP/MIME and S/MIME. The basic idea is to encrypt and hash MIME bodies as they {would be, are} transferred over the wire, with some additional constraints.

But why is multipart/signed the right approach?

First, the "defensive" argument: Re-encoding messages adds complexity to e-mail transport, hence makes errors and problems more likely, without adding any demonstrable benefit. Hence, it is generically evil. Given the elegance and simplicity of RFC 1847, designing MIME signatures in a way that is friendly to re-encoding transport or forwarding agents would be wasteful, add no visible benefit, and make generically evil practices appear less evil. Besides, it's hardly an option at this point of time.

On the feature side, multipart/signed has the important property to include meta information with a signature: Is this postscript code to be interpreted as text, or as postscript? Did they mean to discuss postscript coding standards, and sign that, or did they really sign the contract that is rendered when you interpret the PostScript code? Building a "canonical format" that lets MIME signatures assure the same set of information would amount to designing a feature-complete replacement for MIME. So, why not just use MIME itself?

(This is not to say that there are no problems with MIME and digital signatures -- I'll be the first to say that MIME's ambiguities are a real problem. But these are not degrees of freedom that MIME encoders get to choose -- these are degrees of freedom introduced by MIME's "gentle" handling of misformatted messages.)