Older blog entries for dwmw2 (starting at number 112)

Ankh, you seem a little confused. Are you speaking of my own article when you say that it " reappears every now and again "? That was written from scratch only a day or two before it was posted on Advogato; the original is here.

I suspect you're confusing it with someone else's work. Although I hadn't seen anything which was particularly similar, it wouldn't surprise me if such articles do exist elsewhere -- many people do have the same opinion of SPF, of course. Please could you provide a reference to the article with which you were confusing mine? I'd provided links to the only ones I knew about.

I'm not sure why you think the arguments are unsound and unsubstantiated. For the sake of conciseness I assumed the reader would have a reasonable understanding of how email works in theory and in the real world. So I didn't go into mind-numbing detail for the benefit of those who lack such knowledge; providing an 'email 101' course wasn't my intention. However, I don't see that I ask the reader to take any great leaps of faith without pointing at the reasoning.

If there's anything in particular which you don't understand, please don't hesitate to ask for clarification -- either in fora like this if you think it'll help with general education of the peanut gallery, or in private email if you prefer. You'll need to be far more specific about your queries though.

You say that "neither a whitelist nor a blacklist seems to solve all use cases". That's true; each performs an entirely different function and cannot sensibly be abused as if it were the other. That is my point, in fact. SPF offers a whitelist and not a blacklist, and using it as if it offers a blacklist is wrong. Yet that is the usage which is being advocated, and the usage which I'm warning against.

What most people need is a blacklist-style answer. You want to be able to know that you can reject a given mail. A whitelist is a more esoteric thing, which just allows you to bypass certain other checks for trusted incoming mail. Using SPF as a whitelist isn't what I was talking about, and isn't what most of its users are doing with it. See my response to elanthis on a similar topic -- as with many technologies, of course you can find something to do with the information in SPF records which isn't utterly broken. That was beside the point; I was speaking of the way it's advertised, as a way to reject mail.

Your comments about prevention of IP spoofing seem strange. Mail forgery isn't done by IP spoofing. A lot of ISPs do prevent subscribers from forging their source IP address, and certainly you don't get packets back which are destined for the IP address which you're spoofing. It's fairly much impossible to conduct a TCP session using a spoofed IP address from a trojan dialup or broadband machine.

Disallowing dialup clients from making outgoing connections to port 25 of anything but the ISP's mail server is a good idea, already practised in by FreeServe in the UK, for example. But it doesn't entirely block trojaned systems. Those domains offering SMTP AUTH to their users in order to use SPF/DomainKeys/SES/etc. will need to use MSA on port 587, and trojaned systems can use that route to deliver their unwanted mail.

You also seem entirely confused when you refer to "problems with forwarding services that don't themselves publish [SPF] records". Whether the forwarding site publishes an SPF record is entirely irrelevant. In the SPF world, every server which forwards mail would have to perform some arcane mangling of the reverse-path in transit; a process which even the inventor of SPF admits is unworkable. But if you'd actually read my article before commenting on it, you would have known most of that.

I was highly amused to hear of Zaitcev's experience of a debate on SPF.

The person who was going to be arguing the case for SPF turned up and said that now he's actually looked into it in detail, he's concluded it's a bad idea.

If only others had sufficient clue to work that out for themselves.

Hm. Flights to Canberra are cheaper than I thought they'd be. Failed to resist the temptation that is linux.conf.au.

Switched mobile phone service to O2 this weekend. The only major UK mobile telco I haven't had an opportunity to hate yet.

I'm doing well at it already -- their network doesn't even handle delivery status reports for text messages. I send a message with a status report requested, watch it get delivered to the destination.... and watch it still reported as 'pending' on the phone I sent it from. Every other network can manage delivery reports -- but O2 don't seem to be able to do it.

They can't get voicemail notification right either -- they send you a text message telling you that you have voicemail, instead of just turning on the voicemail icon on the handset.

99% of times I get notified of a voicemail, it's either because I'm busy -- in which case I've just rejected the call and I don't want to listen to the message now, or because I've been out of network coverage -- in which case I don't want to listen to the message now because I'm probably driving, or I've only just got enough coverage for the _text_ to work, not for voice yet. This means I look at their silly text message, don't bother to check the message immediately, and promptly forget that it exists, because it's no longer a new message.

The GSM standard defines a method for turning on a 'voicemail' icon on the handset, which when used properly will stay on for as long as there is voicemail waiting on the system -- it's far more useful. But O2 don't seem to be able to manage that either.

Fucking Useless Telco.

kaeru writes:
Assign mailto: for Firefox to launch new mail window for evolution, add this line for Mailer:

evolution-1.5 mailto:%A?Subject=%S&Cc=%C&body=%B

Er, why mangle the mailto: URL you were given? That's just bizarre.

Stick to 'evolution %r' and you get the rest of the headers preserved too. Some mailing list archives give mailto links with In-Reply-To: headers intact, etc. and your version would gratuitously discard them.

louie writes:
no one should say 'RH is doing it badly' without an understanding of the difficulty it entails

If I have an understanding of the difficulty, and I'm still dismayed by the length of time it's taken to do anything concrete, am I allowed to say it then?

louie: It is indeed a hard task. But I wouldn't say that the aim is to create Debian. I'd say that is one of the things we need to avoid.

Not that I'm saying Debian is a bad thing, mind you -- but I certainly hesitate to suggest that the world needs another Debian.

Been playing with Fedora Core 2 on my shiny new toy.

It's mostly working fine apart from the fact that the installer doesn't quite manage to make the thing bootable, and doesn't make an Apple Bootstrap partition if you let it autopartition. Switching to tty2 after the install has finished, when it wants to reboot, and then setting up yaboot manually, should get you round that. There are a few remaining annoyances but nothing too major. I made a tracking bug for it: #121179.

There's a handful of packages for FC2/ppc in a yum repository at ftp://ftp.uk.linux.org/pub/people/dwmw2/fc2-mac. There's some Livna RPMS including Xine fixed to work on PPC, pine, and qemu. There was OpenOffice.org 1.1.1 for a while but now that's in the rawhide tree so I removed my build.

Qemu is impressive -- it runs i386 acroread very nicely, and does it inside a Mozilla window with mozplugger. If only I could get a flash player to work similarly. I do have the standalone flash player app working, but the sound is wrong-endian. I wonder how hard it would be to make a mozilla plugin which uses qemu and thunks in and out of native code, to allow you to use i386 plugins...

hub writes:

In fact we don't bounce [mails to nonexistent recipients], we reject them at SMTP time with a 450 error code.

That's bad too. That's a temporary failure. Which means the mail stays on the remote queue and they retry it again after a while. They do this over and over again until a week or so has expired, at which point they decide the 'temporary' failure is in fact a permanent one.

It also means that people who do callouts to verify the sender of mail they're receiving might have been accepting mail with your addresses faked, rather than rejecting it as they would have done if there'd been a permanent (5xx) rejection from you.

If rejecting mail to unknown users with a temporary failure code is, as you say, "the standard behaviour", then I suggest you go file that as a serious bug with whatever distribution you're using. You effectively brought the DoS upon yourself.

3 May 2004 (updated 3 May 2004 at 17:59 UTC) »

Advogato is playing silly buggers. I made a new post, it seemed to overwrite the previous entry. So I edited it, adding 'WTF happened to my previous entry'. Now I have two posts again, but the former -- the one which had disappeared -- contains the post-edit copy of the first.

Now I'm editing to contain this text. I wonder what will happen.

103 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

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!