DebConf11

Pondering to go to debconf11 by car. It'll be quite a ride, but Belgium -> Bosnia should be doable. That is, if I'm not doing it alone.

Anyone care to join me?

Blocking newsletter spam

It's incredible how many people are of the misguided belief that just because I happen to run a company, I am automatically interested in their newsletter about whatever it is that they are doing, no matter how far it is removed from the kinds of things my company actually does.

Are these people spammers? Yes, definitely, and I don't want to do business with them. But there's a major difference between this kind of mails and your common nigerian scammer or counterfeit blue pill "salesperson". Unlike the latter, some newsletter spammers are interested in forming a genuine business relationship with my company. They're going about it the wrong way, but that doesn't necessarily mean they're trying to trick me into doing something that would not be in my best interest—they're not just after my money.

Although their methods are wrong, that does not mean they're entirely clueless. Some of these unwanted newsletters are sent with VERP-style return paths, which suggests that if the mail bounces at SMTP time, I would no longer receive their junk. So bouncing them is what I do. Exim makes this very easy:

acl_check_mail:
  deny
	message = Your domain has been blacklisted
	log_message = domain blacklisted
	condition = ${
			lookup{$sender_address_domain}
			wildlsearch{/etc/exim4/blacklist-domains}
			{true}
			{false}
		     }
  accept

What this does is use a wildlsearch lookup to verify whether the domain of the envelope sender (i.e., as specified in the MAIL FROM: SMTP command) exists in the /etc/exim4/blacklist-domains file. Since we use a wildlsearch, we can use the * as a wildcard—*grep.be would mean 'grep.be, or any of its subdomains', whereas *.grep.be would mean 'any of the grep.be subdomains'. This is because at least one of the people I've blacklisted that way sends their newsletter through a distributed service, and the VERP-style header is based upon the server that actually communicates with my system; and others have a subdomain for the newsletter, but don't use it (or use a different one) for regular mail. If I'm not interested in their spam, I'm probably also not interested in their other mail, so therefore the wildcard (is this overkill? Maybe, but I don't care—I don't do business with spammers).

This ACL is then activated for the SMTP MAIL FROM: command (search for acl_smtp_mail variable in the exim specification). This makes it impossible for the spammer to reach postmaster@ from the same domain, too, but that doesn't matter; they can always use a different address.

One might be wondering why I'm using this kind of domain-based blacklisting rather than a regular bayesian spamfilter, or anything of the sorts. The reason is fairly simple: because the general format of these newsletters is distinctly different from regular spam. For instance, some of these newsletter spammers are in fact competitors who didn't bother to check who they're sending mail to. As a result, their newsletters would contain key words that would appear in mails which I send to my regular customers, too; if I were to classify them as spam in my bayesian classifier, that would increase the chance of the classifier misclassifying a mail from an actual customer as spam. Most of these are very similar in format to newsletters that I did consciously subscribe to, and which are therefore not spam, etc.

Finally, bouncing mail rather than blackholing it or filing it in a separate folder (as I have spamassassin do) has the added advantage of making it clear to a newsletter spammer that their junk is not wanted. Most (though certainly not all) will then remove me from their newsletter, saving me bandwith and processing power. And since we do this at MAIL FROM: time, rather than upon completion of the RCPT TO: or DATA commands, I'm not actually giving away any information that they don't have, either.

Loadays 2011

Went to loadays, where I did a talk on "Single sign-on with Kerberos and LDAP". Or, at least, that was the intention—when I found out that there was going to be a tutorial on LDAP the next day, I decided to focus my talk mostly on kerberos, only lightly touching LDAP. As it turned out, that was a great decision—I could easily fill a whole hour on Kerberos, anyway, and though doing a kerberos setup without doing ldap too is fairly silly, doing it properly would have required more time than was assigned to me.

Instead, I managed to talk the audience through most of the important theory about kerberos (things like "what is a principal", "what is a ticket", etc), and did a live demo in which I configured a kerberos realm on a virtual machine, and then used SSH to connect—passwordless—to that machine from a second virtual machine on the same virtual network. While I would've loved to make it even better by throwing in a kerberized HTTP configuration, I couldn't do much more than just mention the fact that it can be done—as is the case for sasl-enabled protocols (imap, ldap, smtp, etc) and some other things.

The talk seems to have been a success with the audience, too; the room itself was full, nobody actually left (which usually is a good sign in and of itself), and I got only positive feedback from the people who were there; one person even went so far as to say that he considerd it the best talk he'd seen thus far, today. Which I think is pretty high praise, considering how my talk was in the penultimate time slot.

All in all, a good day.

Slides online

I've just put the slides of my LOADays kerberos/ldap talk online. The talk wasn't recorded, and most of the interesting bits were in what I said rather than what's in the slides, but maybe someone finds them interesting. There's also slightly more information in the handouts, though even that doesn't contain everything I said during the talk.

I'll also point to these three articles in my blog, which I wrote a few years ago, and which explain how kerberos works and how you should set it up.

If all else fails, and you have a budget, I do have rates. Or catch me on IRC

beid software version 4

No, it hasn't been released yet, but they're working on it.

We've not been doing much about beid since squeeze was released, mostly because we understood that version 4 of the software was quite close, and that working on some 3.x version in that light would not make much sense anymore. But that doesn't mean I haven't done anything about it, at all; a while back, the FedICT people contracted me to help them build Debian packages they could put an 'official' stamp on, and provide through their website or some such. Some pre-release versions of these packages are now available through their google code project, and it would be welcome if people could try them out and give feedback.

Links:

• The middleware package contains the browser plugin, which doubles as the PKCS#11 library. It should even auto-install, which the packages currently in the archive don't (due to technical reasons that would take us too far).
• The viewer contains an application that allows you to view the data on your eID card, print out a page with identity information, etc. It's not required for everyone, but can be interesting none the less.

In both cases, look under 'featured downloads'. These contain snapshot builds that should be fairly stable, but are not officially supported yet. Alternatively, you can track the head of the code (packages that are built automatically upon commit) by going to some alternative pages for the middleware and the viewer. Feedback is welcome, preferably through the relevant Google Code bugtrackers.