Hunny Software is getting hit hard by the Sobig.F worm as well as other worms. A couple of nights ago, I shut down computer systems because of the severe storm that threatened to knock out the electrical power. As a result, our server wasn't downloading the messages stored at our ISP. The mailboxes filled up, because of the worm, and the ISP's mail servers stopped accepting messages.
I have an issue with the ISP. Why can't they install a simple filter that can delete the Sobig.F worm messages? A simple filter that checks the subject line of each message would be sufficient to detect the Sobig.F worm. This worm has gotten so bad, I think defenses should be put up to stop it wherever possible.
Isn't it funny to see how network protocol designers like things complicated? Recall a discussion on the IETF general mailing list in May and June about a trusted sender protocol. Hey, if you want complicated, you already have S/MIME and OpenPGP!
I can't for the life of me see how we will stop spam by making it impossible to forge the sender's email address. There may be good reasons to prohibit forging, but stopping spam is not one of them. What about the AT&Ts, the Gevalias, the thousands of other companies out there that think they ought to be able to spam you because what they have to offer is just so darn good? No politician would dare go against "legitimate" email marketing.
Now for something really simple. You pick a password for your outgoing email. I'm not talking about high security here. I'm just going to call it a "password," because I'm going to pretend that I'm explaining it to my mother. You pick your password, then you go to a web form provided by your ISP and enter that password in a web form. Your ISP stores your password and associates it with your email address. Now, you enter the same password in your email client. You're done!
So, what happens behind the scenes? When you send an email, the email client puts the password in a header field in the message. When the receiving client receives the message, it calls up your ISP and asks "Is this the password associated with this email address?" The ISP's server answers with a "yes" or "no." A "yes" answer means that the sender's email address has not been forged. A "no" answer means that the sender's email address may have been forged -- one should interpret it as probably forged. Note that the server's responding with "yes" or "no" means that one can try to guess the password, but that would require some work to accomplish. And decent software could control that by limiting how many guesses are allowed per unit of time.
One of the key requirements to make it all work is a way to associate the verification server (the server that answers "yes" or "no" to a password check) with an email address. It could be accomplished by associating the verification server's hostname with the mail domain name.
This is just one of my ideas for simple, but hopefully effective, control of email. Like my other ideas, it depends on our constantly moving the target. With a moving target, spammers will need to continually re-adjust their aim. In this case, the sender can change the "password" without too much fuss. The spam situation has often been described as an "arms race." I think we should change the description to a "shell game." We should keep moving the shells around and make the spammers guess which one contains the hidden ball. I'm betting that very often they will guess wrong, which means less spam, or at least less effective spam.
I mentioned earlier that authenticated sender techniques would not reduce spam. So, the question must be answered, "How would this proposed 'sender password' system be any different?" My answer is, that it would be a more effective way to implement white lists. White lists don't reduce spam, but they help us to avoid false positives. Without any sender authentication at all, white lists are subject to abuse. What if spammers all start to forge a sender address that's used by Amazon.com?
Of course, this is not what one would call "security." We don't know to what extent spammers will go to continue to spam as the defensive measures are stepped up. Will they resort to malware to hijack broadband-connected computers? I tend to think that once spamming becomes difficult, the amount of spam will fall off dramatically. If a small number of spammers do resort to malware, then we will just have to start paying more attention to computer security (in Windows!), which will pay great benefits beyond reducing spam. (It really doesn't make sense to me to create an anti-spam technology that assumes the use of malware. Just find a way to stop the use of malware! In other words, blame those who are responsible for computer security for that spam!) So, this is not "security," and it doesn't even use any cryptography. What it is, is just a simple way for your mail server to call back my mail server and ask "Did X really send this message?" It's probably as secure as the domain system. When you visit www.ebay.com in your web browser, how do you know that you are really at Ebay's web site? The answer is: you don't. DNS is not high security, but for most uses, it's good enough. When it comes to authenticated senders, I would settle for simple and good enough.
On my main desktop computer, running Windows 2000 Professional, I set up a private blog where I can write notes intended primarily for myself. I'm using Blosxom as the blog software. I like it! Blosxom is as simple as it gets. I'm using IIS as the web server, and I had to make minor changes to the Perl source code to get Blosxom to work. And, I am using Blosxom to generate all static pages, instead of dynamic pages. There are plug-ins for Blosxom that are probably mandatory if you want a respectable weblog -- for example, if you want to allow posting of comments. All things considered, though, I think Blosxom is excellent software. It's simplicity means that it's easy to tinker with, which is great if you like to tinker. (I do.)
Blosxom is the third weblog software application that I have had significant experience with. The other two are Userland's Radio and GreyMatter. When I have more time, I really ought to write a review of these three software applications.
I was slightly disturbed after reading the article on Slashdot about CD-Rs having a relatively short lifetime. I had thought that a CD-R would last 10, maybe 20, years. Boy, was I off the mark! A better assumption is that a CD-R might last only two years. One thing is certain: CD-Rs are not a good long-term backup medium. And that raises the question: what is a good long-term backup medium?
Now, I have a confession to make. I have been talking to relatives and trying to convince them that digital photos (JPEG) and digital movies (MPEG1) are good, and that they can store them on CD-Rs. I guess I'll have to retract the part about storing them on CD-Rs.
Back to the question of a good long-term storage medium... CD-Rs are not it. Hard drives are cheap and seem to last a long time. The USB pluggable hard drives are perhaps not the best for everyday use, but as a backup medium, they might be useful. Having two or more computers on a network with large hard drives could be a solution that provides redundancy if you store the data on both hard drives. Perhaps this is the best short-term solution for long-term storage.
In the longer term, I fully expect that a new technology will become available that solves the problem of archival storage of digital data for consumers. I don't think I could speculate as to what that might be. With very fast Internet connections, it could be an offsite rental facility. One would pay a yearly fee for the offsite storage.
XML this, XML that. Bloody 'ell. What's wrong with MIME? As far as I've seen, once those XML worms eat into your brain, it's hard to ever get anything practical done again. To an XML person, every nail looks like a thumb. Or something like that.
-- Jeffrey Stedfast on Advogato
We hear this all the time from those who would instruct us in the proper use of mark-up languages: separation of content and presentation.
Now, I understand the argument, and I agree that in many cases separation of content and presentation is good. In many cases, I prefer separation of content and presentation, because then I can fiddle with the presentation without having to change a lot of tags.
On the other hand, I think that the campaign to rid the world of mixed
content and presentation is a lot like the campaign to rid the world of
goto statements. Sometimes the use of goto is
the cleanest way to write a section of code. goto is not
always evil.
The mixing of content and presentation is not always a bad thing either. Separation of content and presentation requires a structured document. Otherwise, how would the content be meaningfully interpreted and the presentation applied? But we often write documents that have no formal structure. Two good examples are email and weblogs.
Is it just me? Or is anyone else noticing that amateur web pages are using centered paragraphs more frequently?
These centered paragraphs have both ragged left and ragged right margins.
Is it supposed to be fancier? Is that why they use centered paragraphs?
This reminds me of how we used to see a lot of email messages that were written in all capital letters.
Is XML a good format for configuration files?
I think the answer depends on how the configuration file is supposed to be used. If the config file will be maintained by a UI tool, then XML may be okay. However, if the config file will be maintained by an administrator using a text editor, then I think the rush to use XML is a step backwards in terms of usability.
What's the argument that is made in favor of using XML as a config file format? Usually, it's "there are lots of XML parsers available," which is actually not an argument acceptable to anyone who cares about usability. It's an argument that says "our developers will have to do less work to parse the config file." This is classic: decisions are made on the basis of what is easier for developers.
Anyone care to make the argument that XML is a readable format? Maybe it is, or maybe it isn't. The use of namespaces certainly makes the XML less readable. And it's not an argument over whether XML is readable or not, as if it's a yes/no question. The real question is "is XML more readable that format X?" for some alternative format X. Frankly, I think that Microsoft's .INI file format is more readable. (Note: I don't know where this config file format originated. Please don't make a big issue over my calling it "Microsoft's .INI file format.")
The .INI file format uses sections set off with titles in square brackets. Within each section, there are name/value pairs, with an equals sign separating the name and value. It's a marvelously readable config file format compared to XML! Some people make the argument that XML permits more structure. I don't agree with that. In the .INI file format, structure is created by having a value refer to another section. That way, a config file can have a tree structure, with a parent section having one or more child sections. I will admit that it's probably easier to create a hierarchical configuration using XML than .INI, but I don't see that many application config files that require a lot of hierarchy. And the .INI file format permits reuse of a node in ways that would be more difficult with XML. Suppose I want to define a bunch of default values -- let's call it a "profile" -- and use that set of defaults in several other sections. In the .INI file format, I just add a name/value pair to those other sections with the value refering to the section that contains the defaults. To do this with XML would require using XPath. It could be done, but it's a little more convoluted.
XML may be good for some file formats, including some config file formats. Any good designer, I'm sure, will choose a format based on the specific requirements of the application, and there can be no one-size-fits-all format. But I do hope that designers will put users needs over developers needs.