Compensating for Spamhaus

Exercise. Some pundits claim that (so-called) end-users should never ever send their own mail directly. You beg to differ, especially after experience with rubbish ISPs, and for years at work and at home have happily delivered your e-mail directly from your network to destinations, using Plan 9's pleasant little upas/smtp. Why bother with middlemen?

One day, your Internet supplier provides a shiny new set-top box with separate cable modem. Plug in the RJ45, hit a few configuring web pages, DHCP, update Sender Policy entries on dyndns, and away you go. Except that your mail is now being rejected by some sites. Yahoo? MSN? Hate them anyway. Gmail?! Oh dear! Why? There is a peculiar organisation, let's call it Spamhaus (which really ought to be the name of a group that sends spam), that busies itself making lists of IP address ranges that supposedly belong to these horrible end-user people. (The ones that pay to connect to the Internet, but never mind.) It turns out that your new address, unlike the old, is on a list. (Same supplier, but again, never mind.)

Others in your house are now distressed by rejected mail (they actually know people on Yahoo and MSN!). Fix it, using other computers and software as needed, but without introducing a store-and-forward phase or changing your mail domain.

Solution. The network in the exercise is running Plan 9, but saddled with a Spamhosed address. You have fortunately got access to a virtual server elsewhere with a safe address, but it is running Linux. Run hosted Inferno on theserver and export /net:

exec /usr/inferno/Linux/386/bin/emu /dis/sh.dis -c "\

listen 'tcp!*!port' {export -a /net}"

That makes the socket-based interfaces of the Linux system accessible through the name space exported on port by the Inferno system using the Styx protocol.

On the Plan 9 system, add a chunk similar to the following to /mail/lib/remotemail, before it calls smtp:

while(! mount /srv/netexp /n/remote){

{rm -f /srv/netexp && srv tcp!theserver!port netexp} ||

exit "import failed"

}

bind /n/remote/tcp /net/tcp || exit "failed bind"

The Styx (=9P) connection for the /net exported from theserver is cached in /srv/netexp, and mounted at /n/remote in remotemail's own name space, allowing just /net/tcp to be bound in from the other machine. (If the cached connection has hung up, we get another.) When upas/smtp is later invoked by remotemail, it will dial the destination machines using the name /net/tcp as usual for Plan 9, but the name will refer to the instance bound from the other machine, which thus acts as a TCP/IP gateway, transparently. Because only the remote /net/tcp is used, DNS lookups will use the local /net/udp, and local name server /net/cs. The outgoing TCP/IP traffic (just for smtp) will have theserver's IP address, because it is using the server's TCP/IP sockets via the hosted Inferno. Adjust the Sender Policy Framework and related DNS entries to suit, and get back to productive work.