[ Home | Articles | Account | People | Projects | FAQ ] 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?
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.
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.
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.
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.
There is slightly less vaporware in the world tonight. As promised, I have released a simple server which should handle most domain validation situations. You just write rules to define your policy. Each section is a fully-qualified host or domain name, like example.net or test.example.net. Inside that, you list accept statements which take the usual CIDR n.n.n.n/n notation, plain IP addresses, or a hybrid with a dotted-quad netmask.
Once that's running, you just add SRV records to the domain in question so DVP clients can find it. As long as your configuration is correct and your ports aren't being filtered, then it should Just Work (tm).
This implementation provides a usable base so I can move on to other pressing needs like a caching server. Later on I will tackle the issue of hooking into MTAs so that people can actually run "live" queries with it based on incoming mail.
Anyone who's experimented with sendmail milters or similar programs for other MTAs should be able to whip up a quick client. It will only have to connect to the local caching server, push out a question, and wait for a reply. It doesn't have to worry about SRV lookups since that will all be handled in the caching server.
I'm writing this in C, but this could be done in any language which can handle strings and sockets. I'd like to see other implementations of the protocol to get some more diversity out there.
"authserv" turned out to be a lousy name. Too many things already use it, and it was awkward when describing how things work. The fix was to rename everything to DVP.
The initial design stands. When someone claims to be a certain domain name, you see if that domain speaks DVP with a SRV query. If they do, you connect to their server, provide a few details (IP address, claimed e-mail address), and see what they think. Their answer is based on their local private policy, and all you get is a yes or no.
There have been some improvements to this in the form of optional extensions. Servers can state that a given host or network is the only one which happens to be valid for that sender. This allows the client to cache both the positive answer for that host/network and a negative answer for the rest of the Internet - 0.0.0.0/0.
This by itself doesn't seem interesting until you realize that it reduces the query load on your server. Anything you can do to make a client find the answer in its own cache without asking you is a win.
I'm currently working on a simple server which can handle basic situations like a list of domains, each with a set of valid source networks. Once that's available, then anyone will be able to run this to see how it works on their own systems.
The web pages have been cleaned up and split up, so anyone who was turned off by the old single page which went on forever should give it another shot.
I've been learning about different proposals and techniques for stopping e-mail domain forgeries in the past couple of months. Some of them add new data in DNS. Others guess based on the PTR data of the source host, or the data presented in the HELO during the transaction.
My opinion is that anything which tries to fit the decision process into the DNS namespace will either be ugly, incomplete, or both. You may be able to validate simple questions like "is this IP allowed to send mail as this domain?", but something a bit more complicated becomes very difficult.
So, based on some of my earlier musings, I decided to put together something that takes the simple way out. Before you accept mail which claims to be a domain, you see if that domain has a server available which speaks this protocol with a SRV query. If it does, then you connect, provide the details, and ask for a verdict. Then you take the result and use it as part of your decisionmaking process as to whether to accept the mail.
I've put together a web page which goes into more detail. There is source code for a simple testing client, and I am running a server on my local system. If there is sufficient interest, then I will also clean up the server and make that available.
I think this is the simplest approach to the problem, and hope that others will find it useful.
Steps to make life less lame in this brave new world of com and net wildcards:
zone "com" {
type delegation-only;
};
zone "net" {
type delegation-only;
};
djbdns vs. Verisign
Here's another approach:
Greetings: I've been lurking here for far too long, so it's time for an introduction. I've been reading the recentlog to get new ideas and to hear about new things in the world of free software. As a result, I will strive to bring quality content to the recentlog for the benefit of other readers.
Mail delays and spam traps: I've been running a delaying system on the mail exchangers at work since the beginning of the year. Many people now know of this technique as "greylisting". I don't claim to have invented it, since there are Usenet posts going back to 2000 which propose the same scheme.
Here's how it works in a nutshell: some system connects and tries to mail a bunch of my accounts. These mail entries (IP, HELO, from, to) are new, so they all get temporary failures and the clock starts running. They eventually retry, and if enough time has passed, the mail gets in. Once in awhile, the spammer has a dirty list and mails one of my spam traps. This gets them added to a quarantine list, and now all of their mail is tempfailed forever.
Once in awhile I check the logs, find spam trap hits, and add them to the usual domain/network blocking lists. They tend to be stupidly persistent, so most of them get filtered at the IP layer shortly thereafter.
FOAF updates: Trust rankings are now exported, making the data available to other users and websites. An external FOAF URI has been added, allowing users to link to an additional FOAF file.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!