The first thing to know is: THE PBL IS NOT A BLACKLIST.

Oh, and since you’re already there you may want to linger a bit in this warning:

WARNING! Some post-delivery filters use “full Received line traversal” or “deep parsing”, where the filter reads all the IPs in the Received lines. Legitimate users, correctly sending good mail out through their ISP’s smarthost, will have PBL-listed IPs show up in the first (lowest) Received header where their ISP picks it up. Such mail should not be blocked! So, you should tell your filters to stop comparing IPs against PBL at the IP which hands off to your mail server! That last hand-off IP is the one which PBL is designed to check. If you cannot configure your filters that way, then do not use PBL to filter your mail. Instead, you may wish to use sbl-xbl.spamhaus.org, but even that may have unacceptable “false positive” filtering, for example when a an exploited end-user machine sends legitimate mail out through the ISP smarthost, or when the dynamic assignment changes the IP to an uninfected machine. Do not use PBL or XBL if you do not understand the issues of “deep parsing”.

(Emphasis mine)
So if your top-of-the-line multi-thousand-dollar antispam appliance starts blocking all my email just because there’s a dynamic IP address somewhere in the header and there’s no freaking way to turn it off please go ask for a refund. And stop bouncing my messages.
Oh and by the way the default SpamAssassin configuration in Debian assigns a 0.905 score if the last hop is in PBL.

And yes, SpamAssassin does the right thing and checks only the *last* external address — I’ve seen the code:

So once again kudos to Open Source — and Common Sense.

To use it, enter

Enjoy!

Now in user mode use KBlueMon to find out the Bluetooth address of your device and write it down.
Then go ahead and initiate an OBEX file transfer to make sure that you can actually link to your phone and to establish a trust relationship. In your phone add the Laptop to your trusted device list, so it won’t nag you whenever you establish a link.
Now edit /etc/bluetooth/rfcomm.conf :

Replace your own device address after “device”.
Now edit /etc/wvdial to add these two entries:

You can give them any name you want. I have defined several providers, to avoid confusions and to use the provider at hand. Replace the “XXXX” in Init1 with your SIM’s PIN.
Now to use them restart the Bluetooth subsystem:

And use wvdial to dial out:

You should get an Internet link, complete with an IP, a default route and a couple of DNS servers. If it doesn’t, reboot your phone liberally.
Please note that this might get expensive quite quickly unless you get a data plan from your provider. Go ahead and make their day.
Enjoy!

Now SSH X forwarding should work and a myriad other disasters waiting to happen will surely be averted.

Now “POLICY_DELIVER_NCO_SELACTS” returns *exactly* one match in Google, and it points to the aforementioned documentation. It’s “POLICY_DELIVER_NCO_SELACTS” all over.
After a lot of frustration,

shows that “POLICY_DELIVER_NCO_SELACTS” is a typo. They really meant “POLICY_DELIVER_NCO_SELACT” instead. No final “S”, you see! And this happened SOME TIME IN THE LAST TEN FREAKING YEARS.
The list of things I’d like to do to the project managers, documentors, and technical writers of this particular product suite is too graphic even for the Internet.
And most importantly — how do they get away with these levels of incompetence?

I tried David Johnson’s pre-compiled driver for AMD64 but it didn’t work right away, so I compiled AtL1Linux_v1.0.41.0 for the stock 2.6.18-4-486 kernel in the official Debian 4.0 netinst CD and tested it. Although it was supposed to work right out of the box I kept getting “invalid module format” messages. So I stripped out the version information with

and it worked immediately. I completed the installation and I will upgrade the server to 2.6.21-2-amd64 over the weekend. So here is a atl1.ko for 2.6.18-4-486 that should work just fine.

By the way, I stripped the version information off David’s atl1.ko but I didn’t get a chance to test it because I was in a hurry. Here it is anyway in case someone finds it useful: atl1.ko for 2.6.18-4-amd64.
Oh, by the way, the M2V has four PCI slots but no built-in VGA adapter, and most PCI-e video cards are so thick that the first slot becomes unusable. Since I bought this motherboard precisely to maximize the number of available PCI slots in the server… well, it just sucks.

*heh!* I guess it takes another Commodore fan to appreciate this kind of humor.