Tag Archives: configuring

When your on-the-road ISP blocks your outbound mail

Now, we talked about allowing your computer to relay mail through the home machine when the ISP through which you’re connecting has made it onto a block list. What do you do when the ISP simply blocks all outgoing connections on port 25? Now you can’t even connect to your home computer to relay the mail.

The ISP does this to force you to pass email through their servers. The hope is that infected Windows computers will just try to open connections directly, and not forward the mail through the ISP servers. As noted in this story, that is not necessarily true.

So, now you find yourself unable to open connections on port 25, but you still want to send email. You could set up your computer to relay mail through the ISP’s servers, as described in this earlier article, but that may not be convenient if, for instance, you’re accessing the Internet at a relative’s home, since they would have to give you their passwords for you to do that.

So, the first thing to do is to check that you can connect to your home computer on the ESMTP port number 587. Telnet onto that port number on your home computer, and if you get a response, then this technique will work for you.

First of all, you should already have set up relaying as described here. If you set it up a while ago, verify that your keys are still valid and haven’t expired.

As we’re discussing this in the spirit of a temporary work-around, we’ll be editing the sendmail.cf file directly. First, of course, make a backup copy of your current sendmail.cf file, because you’ll want to reset it to its former behaviour after you stop using this particular ISP.

Now, go into your sendmail.cf file and find the smart relay line. It will look something like this:

# "Smart" relay host (may be null)

Change that line to indicate that you’re sending ESMTP to your home machine. It will look a bit like this:

# "Smart" relay host (may be null)

Next, we have to tell sendmail that it is to use port 587 for outbound mail to esmtp smart relays. Locate the block in the sendmail.cf file that looks like this:

Mesmtp,         P=[IPC], F=mDFMuXa, S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP, E=\r\n, L=990,
                A=TCP $h

and change the last line to read:

                A=TCP $h 587

That’s it. Restart the sendmail program, and you should be able to relay all mail through your home machine using authenticated relaying on port 587.

When other sites discard or refuse your email

We’ve covered setting up your sendmail to act as a relay for certain computers. Now, we look at another relaying problem.

You like running your own sendmail, you’re using it to manage your own email accounts. You could use your ISP’s mail server for all outbound messages, but let’s say you’re not doing that. Now, some third party, maybe another ISP, let’s call them “Dogers”, decides to silently discard all email coming from IP blocks owned by your ISP unless the sending IP number is one of the mail servers of your ISP. Even if you’re running a responsible sendmail on a static IP number, messages sent to “Dogers” just vanish.

The solution is to arrange your sendmail so that, when sending to certain domains, it relays the messages through your ISP’s servers. We’ll need two more features for this. First, the mailertable function will allow you to use a different mailer for certain addresses. Second, depending on your ISP, you may have to authenticate yourself with the ISP’s server before it will relay your messages. This configuration will show how to perform that authentication.

Make sure your sendmail.mc contains the following two lines before the first “MAILER” line:

FEATURE(`authinfo',`hash /etc/mail/auth/client-info')dnl

Also, add the following line anywhere in the file:


You will need to have cyrus-sasl installed, and configured for logins. Here is a sample cyrus-sasl configuration invocation:

./configure --prefix=/usr/local --enable-anon --enable-plain \
       --enable-login --disable-krb4 --with-mysql \
       --with-saslauthd=/var/state/saslauthd --with-openssl=/usr/local/ssl \
       --with-plugindir=/usr/local/lib/sasl2/ --enable-cram \
       --enable-digest --enable-otp --without-des

OK, now the mailertable entry. Add a line for the dogers domain, telling your sendmail to forward mail for those addresses through your ISP’s server:

dogers.com      smtp:smtp..

Now, to authenticate with the ISP. We told sendmail that our credentials would be stored in /etc/mail/auth/client-info, so we create a file there:

AuthInfo:smtp.. "U:root" "I:wintertoad@." "P:" "M:LOGIN"

Then, we just have to rehash the mailertable and authentication files with a command like this:

# makemap hash file.db < file

Now, assuming you’ve rebuilt your sendmail.cf after the changes we made to the .mc file above, you can just send a SIGHUP to the sendmail processes, and you should be able to send email to anybody at the dogers.com domain by relaying those messages through your ISP’s mail server.

Web browsing behind the great firewall of China

I sometimes spend time in China, and while there, I work remotely to my office and to my home computer. I do somewhat technical work that sometimes requires online research, and it’s annoying that a significant fraction of non-Chinese sites are unreachable from China.

The thing to remember is that the firewall isn’t there to keep me from working. I’m a Canadian passport holder, and they really don’t care what I read while in China. That explains certain curious omissions, such as the fact that TCP port 22 (ssh) is not blocked.

So, here I am, in China, with a Linux laptop, and I’d like to browse the web. Rather than take my chances with the firewall, I proxy the connection through my home computer’s apache daemon.

So, first I set up the proxy service on my apache. Make sure you’ve built the httpd with these configuration options:

--enable-mods-shared="proxy proxy-http proxy-connect"

These settings turn on the proxy service and set it to proxy HTTP traffic. The “proxy-connect” flag allows the httpd to be used as a reflector for SSL connections. If you want to visit a banking website, the data still travels as SSL between your laptop and the home machine, but the home machine just reflects the traffic to the bank without knowing what’s in the data stream (the home machine cannot decode that data, if it could, it would count as a man-in-the-middle compromise of the SSL stream).

Next, add some lines to the httpd configuration file. Mine’s in /etc/apache/httpd.conf.

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so

ProxyRequests On

Order deny,allow
Deny from all
Allow from

What this does is to enable proxying, but only on connections from localhost. I don’t want my httpd to be a proxy for any random person in the outside world.

Next, I set up my ssh on connections to my home computer. You can either add a switch like this to the invocation:

-L 8080:

or you can add a line to your ~/.ssh/config entry for the connection to the home computer:

LocalForward 8080

Now, you ssh into your home computer.

Finally, you start up firefox, and select the menu item:
Select “Manual proxy configuration”, and point your HTTP and SSL proxies at “localhost” with the port number 8080.

That’s it, now when you browse websites, the HTTP-related data stream appears simply as a pile of encrypted bits over your ssh connection. The firewall cannot know what websites you’re visiting, it can’t even tell that you’re visiting a website at all.

Important note: this system proxies the HTTP data. That means web pages, frames, images in the page, RSS feeds, and so on. It does not proxy UDP or post-connection traffic, like youtube videos. If your web browser has a plugin that downloads data from an external site, that plugin may not be using your proxy.

If you want to know what data is not passing through your proxy, you can run tcpdump in another window. Something like this:

tcpdump 'host  and not port 22'

where is the IP number of your external interface (not You may have to add a “-i” switch if your laptop has more than one network interface. This command will show you all traffic that is not going over the ssh connection.

Fixing sound in Linux Civ:CTP

When my old 64-bit motherboard died, and I replaced it with the DP35DP, one of the surprises I ran into was that the sound was badly broken on “Civilization:Call To Power”. All other applications that I tried worked well, any programs using the ALSA interface, as well as a few 32-bit binaries on the OSS interface, like Quake 2 and Heroes 3. However, with Civ:CTP, the sound stuttered and looped horribly. I couldn’t use the aoss wrapper because Civ:CTP is statically linked. After a lot of tinkering, I finally came to the conclusion that, for this one application, I had to load the sound module with different parameters.

For every application except Civ:CTP, my snd-hda-intel module is loaded with the parameters

position_fix=1 model=5stack

However, in order to run Civ:CTP, I have to exit all sound applications, remove the snd-hda-intel module, and re-load it with the parameters:

position_fix=3 model=5stack

With this change, the sound in Civ:CTP sounds fine. However, all other applications have poor sound, scratchy and unpleasant to the ear, so I only make this module change just prior to running the game, and re-load the module with the usual parameters immediately afterwards.

Experiences compiling X11R7

Compiling and installing X11R7, x.org 7.3, was a bit more rough than the X11 compiles I used to perform. I used the build script supplied with the source packages. When it finished, apparently successfully, there were two problems whose solutions were not obvious.

First of all, OpenGL worked on my NVidia box, but not my ATI laptop.

Second, my Chinese fonts for traditional characters in Emacs looked different, much worse. The simplified Chinese characters still looked fine.

OK, what were the problems, and how did I fix them. First of all, the OpenGL issue. I compiled X11 the same way on both computers, why did OpenGL not work on the ATI laptop? Well, both NVidia and ATI ship closed-source binary blobs with support libraries. The difference is that NVidia supplies its own libGL.so, while ATI uses the one from x.org. So, somehow I was failing to compile and install the OpenGL stuff. This didn’t matter for the NVidia case, because it supplied all of the libraries required, but ATI doesn’t do that. I had compiled and installed libMesa, so OpenGL should have worked. The OpenGL component is compiled as part of the xorg-server-1.4 package, and its configure script is executed by the build script that came with x.org. Aha, but in order to compile OpenGL, you have to provide the configure script with the path of the libMesa source tree. The x.org build script doesn’t do that, so OpenGL is not built. The solution is to interrupt the build at the point where the xorg-server-1.4 is about to be built (you can edit the script and put in an ‘exit 0’ there, for instance), then configure, build, and install the xorg-server-1.4 archive by hand, remembering to tell it where the mesa source tree is located. Once that completes, you can continue the build with the xorg script (I just commented out all entries above the server compile and resumed).

Now, the font problem. My TTF fonts are in /usr/share/fonts, and I verified that the files there were being read when I asked Emacs to display Chinese characters. So, it appeared as if the Chinese TTF fonts were the ones that were looking bad. A bit of research showed that Emacs does not, as of version 22.1.1, use scalable fonts. So I decided that it probably wasn’t supposed to be using those TTF fonts. Now, I had kept my old X11R6 tree around in case of issues like this, so a quick comparison of directories showed that there were some Chinese PCF fonts in the old install that I had forgotten to copy to the new location. So, I copied these files into their location in the X11R7 tree, and Emacs was restored to its former behaviour with respect to the displaying of Chinese fonts. The fonts, by the way, are taipei15.pcf, taipei16.pcf, taipei24.pcf, taipei24k.pcf, and taipeil24.pcf.