…or annoyances with the DSPAM hash driver

I’ve been running DSPAM for a long time and the spam classification is great, unfortunately the maintenance tools are not as it turns out. This is the tale of why and more especially HOW I moved from the hash driver to the mysql driver as a backend for my DSPAM installation.

Read the rest of this entry »

Comments No Comments »


The FreeBSD Diary and Riseup labs describe a way to anonymize the first “received from” header with usually contain the IP-address of the computer the mail was sent from.  This information is removed by taking advantage of the “Authenticated sender” and the header_checks directive in Postfix.

The “Authenticated sender” is added when a user has been authenticated by the MTA through SASL and the directive smtpd_sasl_authenticated_header have been set to yes.  The header_checks directive takes a file containing a regular expression which rewrites the header data and removes sensitive information.

This all works well – with IPv4. The regular expression posted on the pages mentioned above does not take IPv6 addresses into account, I modified it slightly to accept both IPv4 and IPv6 addresses.

/^Received: from (.* \(\[?[-._[:alnum:]]+\]? \[([\.0-9]{7,15}|IPv6[\:a-fA-F0-9]+)\]\))(.*)
\(Authenticated sender: ([^)]+)\)(.*)(by mx1\.example\.com) \(([^)]+)\) with (E?SMTPS?A?) id
 ([A-F[:digit:]]+)(.*)/ REPLACE Received: from smtp-auth.example.com (smtp-auth.example.com
 [127.0.0.1]) (Authenticated sender: hidden)$5$6 ($7) with $8 id $9 $10

Note that this should be one single line.

Put this in a file, for example /usr/local/etc/postfix/obscure_smtp_auth and add the following to your Postfix configuration (assuming you have SASL working).

header_checks = pcre:/usr/local/etc/postfix/obscure_smtp_auth
smtpd_sasl_authenticated_header = yes

The first header will now be rewritten, for both IPv4 and IPv6 clients and will look something like this.

Received: from smtp-auth.example.com (smtp-auth.example.com [127.0.0.1]) 127.0.0.1 (Authenticated sender: hidden)
	by mx1.example.com (Postfix) with ESMTPSA id 3677033C6F
	for &lthostmaster@example.se>; Wed, 10 Dec 2008 16:31:51 +0100 (CET)

instead of

Received: from [IPv6:2001:xxxx:xxxx:xxxx:xxxx:xxxx:fedd:7914] (unknown [IPv6:2001:xxxx:xxxx:xxxx:xxxx:xxxx::fedd:7914])
	(Authenticated sender: someuser@example.com)
	by mx1.example.com (Postfix) with ESMTPSA id 3677033C6F
	for  &lthostmaster@example.se>;  Wed, 10 Dec 2008 16:31:51 +0100 (CET)

Comments No Comments »

Note: This is about “intra-AS” IPv6 routing and networking as I haven’t had the opportunity to play with IPv6 BGP stuff.

I got a (insanely) large IPv6 address space from SixXS statically routed to me over a 6-in-4 tunnel, it’s connected to a static IPv4 address on a machine with plenty of bandwidth.  As I wanted IPv6 connectivity at multiple points I figured that instead of wasting a /48 for every location I could just as well setup my own “overlay” IPv6 network running on top of several IPv4 tunnels.

Read the rest of this entry »

Comments No Comments »

Granted it’s still poor-mans-ipv6 (aka ipv6 over a ipv4 tunnel), but still. If you’re IPv6 capable you’re most likely reading this over IPv6 already.

The IP address for www.shapeshifter.se is 2001:16d8:ffe5:1:1::1 (from 2001:16d8:ffe5:1::/64)

It has got some shiny AAAA/PTR records too.

shapeshifter.se has IPv6 address 2001:16d8:ffe5:1:1::1
1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.1.0.0.0.5.e.f.f.8.d.6.1.1.0.0.2.ip6.arpa domain name pointer www.shapeshifter.se.

I played with IPv6 several years ago (back during the 6BONE days) and recently decided to give it another shot.  Most of my services are now available through IPv6 and my local LAN has IPv6 connectivity. I’ll write more about that in another post.

Comments No Comments »

New release of hso(4), FreeBSD driver for Option iCON branded 3G/HSDPA devices.

Changes to hso(4)

  • Support for the new TTY layer, driver now works with 7.0 upto todays 8.0-CURRENT.
  • Device IDs for Option GlobeTrotter HSUPA and Option GMT382 added.
  • Minor performance and stability issues have been addressed.

Changes to hsoctl(1)

  • hsoctl now forks into background upon a successful connection, the old behvaior can be obtained with -n flag. Disconnection is possible by executing hsoctl -d hso0.  While running in background, important information is logged to syslog.  Complete daemonization is also possible with the -b flag.
  • Use of AT+CGREG in addition to AT+CREG to detect network registration (for service plans where voice calls are disabled).
  • resolv.conf handling have been improved, only nameserver entries are changed, other content is left intact. A bug that sometimes caused garbled data to be prepended to resolv.conf have also been addressed.  The resolv.conf path can be altered with the -r flag, disable resolv.conf with -r /dev/null.
  • hsoctl does now gracefully terminate upon unexpected device removal.
  • Default route installation have been improved.

The code can be obtained from the hso page, the update should hit the ports tree soon (comms/hso-kmod).

Speed test from a rural location. Values are in bits/s, so that’s almost 300 kB/s downstream and around 40 kB/s upstream. Hopefully downstream is slightly better from a more urban location.

hso(4) speedtest

hso(4) speedtest

Comments 2 Comments »