I'm not linking to the recentlog-spamming losers on purpose. This entry is only here to call attention to what's going on here.

Scroll down to axtet2 (again, not linking on purpose), then go read article 794 from this very site, and notice where the content is coming from.

Is this yet another test of the trust metric?

MichaelCrawford: in response to your entry on designing software, I have to say you are not alone.

Many of my projects start with some kind of skeletal code that's peppered with comments. The comments briefly explain what's going to happen, and they make it easy to see the big picture. They can be moved around or changed without too much fuss, since they don't actually do anything by themselves.

Once I'm happy with the scheme that's laid out in the comments, then I go back in and start dropping bits of code in between. I keep things straight by having XXX in the comments that haven't been given matching code yet. When the source file no longer has XXX in it, everything has been written.

This does lead to some interesting effects in the source down the road, since the comments can be braindead at times. You'll get a section of code that looks like this:

/* open the music db */

f = fopen(dbfn, "r");

Anyone who reads that (myself included) should go "duh". What they don't realize is that the fopen line came second, not the other way around. I could delete the comments, but I usually choose to leave them in.

As for the planning and such: I'll usually start the above sequence in main, then as things seem to have enough complexity, I'll spin them off into their own functions. A simple section might stay in main, but something that's relatively tightly wound and returns a simple code will go into a function. Those functions can then spin off other functions, and so it goes up the line.

This is not to say that I don't diagram things. I do plenty of that, sometimes even with pencil and paper when things get hairy. Some things just have to be laid out visually to get the sequencing right. The difference is that it usually happens after the program has existed for awhile, once it's grown up to the point where some things are no longer fresh in my head.

Back in school, one teacher wanted diagrams turned in with our assignments. I used to write the code and then generate the diagram later until she caught me. That's about the only time the written diagrams came first.

domain forgeries

abg: there are technologies which can stop such forgeries, but they do no good until people start using them. This means that the people who run domains have to publish the right data, and the people running MTAs have to install tools which check it.

Right now, there is absolutely no reason for anyone to ever accept a single mail which forges one of my domains. It still happens, because nobody has gone to the trouble of adding the necessary magic to their mail servers. They're mad about getting spam, I'm mad about getting forged, and yet there they sit.

It'll probably take some kind of huge concerted forging effort to make most people go to the trouble of running checks. Everything else seems to happen that way.

dvpmilter

Recent versions of sendmail have an interface called milter which allows you to test all sorts of things during the SMTP transaction. This makes it the natural place to add checks for things like forged e-mail addresses.

dvpmilter is just a wrapper around dvpquery which speaks sendmail's milter language. If it detects a forgery, then it will instruct sendmail to generate a temporary failure. Permanent (5xx) rejections are also an option, but I'm going for the light approach at the moment.

In the short time that this code has existed, it's already stopped something dubious. Some random box tried to send mail to me using a forged exploits.org user name. My secondary MX did the DVP check, noticed that it failed, and kicked back a temporary failure as intended. It obviously works.

Long story short: if you run sendmail and hate forged e-mails, I'd like you to check this out. If you run some other MTA and know how to write a plugin/add-on for it, that would also be helpful.

recentlog: info

My take on info is that it probably scares away more than a few people since they're expecting it to work like lynx or links. Once you realize that the interface is pretty close but the keys are different, it's really not that bad. At some point in the past I saw a project which provided a lynx-ish interface to info. Perhaps those who are turned off by the stock interface could try that instead.

A quick search on Freshmeat turned up pinfo. It's been a long time, but that sounds like what I found in the past.

Many eggs, few baskets

The situation with savannah is presenting a roadblock in my plans to introduce people to my DVP project. The demonstration client (dvpquery) uses a library called RULI to handle the DNS SRV queries. It works well, but the source lives on savannah.

That means nobody has been able to install it ever since their machines were compromised, and by extension there's no way for them to try dvpquery. I finally punted tonight and put up my copies of the source and even a couple of binary packages to try to break the ice.

This is particularly bad timing, since dvpquery can now generate easily-parsed output. I've written a wrapper for this which runs as a milter, and sendmail on my system is now performing DVP checks on inbound mail. This will also be released shortly to allow other sendmail users to join in. I look forward to seeing similar plugins/modules for other MTAs.