Older blog entries for dwmw2 (starting at number 92)

The email flood seems to be fairly easily stemmed by a few simple rules.

First, don't accept mail without a Message-ID.
Second, don't let mailing lists accept bounce messages (i.e. messages with empty MAIL FROM:<>)
Third, enable sender verification callouts; also for recipients if your machine is MX backup for anyone.

There's been no vir{uses,ii} and only one 'bounce' get through to the linux-mtd list, and that one was because some vegetable managed to configure a virus checker to send its bounces as real messages instead of bounces -- either through cluelessness or in an attempt to add mail loops to the fun which is already being had by all. Abuse@upstream duly notified.

Eventually I'd like to see all mail cryptographically signed, with the public key available in the DNS for verification purposes.

The birds sang her to sleep.

27 Jan 2003 (updated 27 Jan 2003 at 23:17 UTC) »
mwh, obi, others:

Note that filtering on List-ID or X-Mailing-List isn't 100% reliable. You probably want to filter on the SMTP reverse-path, which will usually end up in a 'Return-Path' header or the 'From ' line.

List-ID and X-Mailing-List get preserved if someone bounces (in pine parlance, aka 'redistributes') a mail to you.

Consider, for example, the case where you're on vacation so you've filtered a certain list to /dev/null, or you're just not reading it till you get back; at which point you'll read it with grep.

A colleague sees a mail he _knows_ you'll want to read from that list, and bounces it to you. With broken filters, the mail ends up in /dev/null again even though it was sent to you personally. With filters on the _actual_ sender, it lands in your inbox and gets read as intended.

You also sometimes find that lists won't add such headers if they already exist, so if someone sees a mail on one list and bounces it to another list, your filters for the latter list won't necessarily catch it. Again, the return-path works correctly.

Argh. Why is it so difficult to import an xfig diagram into OpenOffice in a vector format? Other than EPS, which OpenOffice doesn't render onscreen properly (or indeed at all).

Hmmm. Got bored last week so I played with improving JFFS2 mount time. By delaying data node and data payload CRC checks till after the mount, on the basis that we don't actually _need_ them done that early, and by using a pointer directly to the flash rather than copying into RAM every time, we get a fairly dramatic improvement in mount time -- from ~3s to ~0.3, and from ~5s to ~0.75s on a iPAQs with 14MiB and 31MiB file systems, respectively.

Not bad. Now the iPAQ bootloader is slower to scan the JFFS2 to find the kernel and parameters in it than the kernel is it mount it later :)

2 Sep 2002 (updated 2 Sep 2002 at 10:23 UTC) »
Just as I thought it was going alright
I find out I'm wrong when I thought I was right
Always the same, it's just a shame
That's All
30 Apr 2002 (updated 30 Apr 2002 at 19:02 UTC) »

Is it just me, or is this kind of cluelessness from someone in that position plain fucking scary?

Hmmm. He said 'From: <>' not 'MAIL FROM: <>' -- the header not the envelope.
Too hasty to condemn someone?


moray: Not all, but many. Personally, I find I'm physically incapable of typing my initials without the '2' any more.

Decided I should try to overcome my irrational hatred of C++.

So I started playing with Opie; developing a little program for playing with GSM phones.

I chose to use gsmlib for the actual communication with the phone. Upon first glance, it seemed to be quite nice.

Unfortunately it seems its effective footprint on the iPAQ is about 2MiB - layers upon layers of derived classes with gratuitous autorefcounting for objects which are only ever going to be allocated and discarded once, all based on libstdc++.

Strictly speaking, the project seems to be well on course to achieve the stated goal - I shall be left with a deep-seated but perfectly rational hatred of C++. :)

Ankh: Yes, I know. That was the point - perhaps I should have said "By the time you leave, you ought to know the difference."

In fact, I think I shall go back and change it :)

83 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!