FHS hacks

This webpage contains various configurations, tweaks and hacks to improve my working experience at the Salzburg University of Applied Sciences.


Operators of mail infrastructure are in a constant battle against various threats like phishing mails. As in politics, sometimes measures are taken that have a broad impact on the user experience, freedom and privacy. As in politics, there companies that earn money by providing security solutions, which some describe as snake oil (here, here).

URL rewriting

One such measurement is URL rewriting through some Email Security Appliance (ESA) vendor, like Cisco. One can argue that an ESA is ineffective, impacts privacy1, impairs usability and I personally do not like the idea that the mails I receive have been altered. But on the other hand, I do not2 need to fight against cyber criminals.

Nonetheless, I now receive mails that contain URLs like


They are hypertrophic and prohibitive in length. That is, they destroy my mail experience and therefore I want to transform them back into its (presumably) original version https://www.example.org/. At least, I would like to be able to do so, because mail also constitutes an archive to me, and of course you must not change the content of an archive. (Another argument why modifying mails is an improper thing to do. Besides, how long are those Cisco URLs actually working? Even after canceling contracts with Cisco? Unfortunately, also ciscoclean cannot restore the archive aspect, since we can only make an educated guess what the original URL might have been.)


Of course, people with computational eyes easily see that the original URL is encoded at the end of the new URL, so it can be trivially undone. And Linux users write scripts when they automate easy things.

In my case I called the script ciscoclean and you can download it here. You can integrate it into a powerful mail client, like mutt, or call it from command line by passing data through stdin or specify files:

% ./ciscoclean -h
Mr. Clean for Cisco's mail snakeoil. It restores the original URL from the URL
generated by Cisco's mail security software.

    ./ciscoclean -h
    ./ciscoclean [FILE]...

If no filename is given then stdin is processed. Otherwise all files passed are

% echo "My URL: https://secure-web.cisco.com/1VqOjcxMgKL3XZfH1RVFk4flLLurhrVbZyjVabNjFFrwcwvrjcKOq0YBEA_UeqrpX0yBPcmEGpNMmKGjUFJRPMyGPhHq61q7mepfDCD8F09vHfZp4tZ4VLllvl6yAKJ3Am4p3mivuBeZQqmXQqrRmhfrfFQTgPrQPpB1uvzRTH6Z0eD61H3RAZmT6U0e3iInSn8FFemTitFEVRT_VlrQh6CeiSE_1fEbpu81lEQoMSweguEckjoCEkG7J8LL0YKw5/https%3A%2F%2Fwww.example.org%2F" | ciscoclean
My URL: https://www.example.org/

% ciscoclean mymail.eml
My URL: https://www.example.org/

mutt and vim

The Mutt mail client knows a configuration called display_filter. When a message is viewed by mutt then it is send through the program specified, which can transform the content. So simply download ciscoclean, put it somewhere like ~/.mutt/scripts/ciscoclean and set display_filter to it. This way mutt displays mails with (what I believe are) the original URLs.

But you better know the philosophy of spiderman: With great power comes great responsibility. If you open a malicious URL that could have been filtered by the security appliance then you probably get into trouble.

So maybe you do not want to use ciscoclean as an always-on display filter but configure a macro that lets you display a clean version on demand, i.e., after pressing come key in mutt. Then you may have a look at the <pipe-message> function of mutt. This can also be handy if you want to forward a mail with undistorted URLs to somebody.

If you use vim as mail composer with mutt then, of course, you see the Cisco URLs when you reply to a mail. But vim is again a powerful editor and the simple command 1,$!~/.mutt/scripts/ciscoclean will filter the buffer through ciscoclean.

By the way, if you want to know more about mutt and how I use it together with vim then maybe this talk and this talk of mine might be interesting to you.

Local DNS resolvers

Update 2020-03-09: DNS queries are not blocked anymore, but the general hint may still be useful for other networks.

There are a few good reasons to run a DNS resolver on localhost.3 Linux users often like to use dnsmasq, which is supported by NetworkManager as a configuration option. I personally use bind, which I also run as authoritative DNS servers for my domain.

However, sometimes network providers – such as FHS or the ÖBB federal railways – block outgoing DNS traffic and your local DNS resolver cannot resolve any requests anymore. One option is to resolve DNS queries via VPN.4 This would be a clean solution from security’s point of view but it slows DNS resolving down. In a foreseeable future, DNS over HTTPS partially changes the situation.

In case of the FHS, for me personally, the lesser evil would be to resort the FHS DNS resolvers if I am in their network, but otherwise I would like to use my local resolver. This can be done with NetworkManager by using the dispatcher simply by placing the following script 99-localhost-resolver in the directory /etc/NetworkManager/dispatcher.d:


if [ "$2" == "up" ]; then
        # We got up in the FHS network
        if ip a | grep -q "inet 78.104.1[67]" ; then
                echo "# On FHS network" >> /etc/resolv.conf
        # Set resolver to localhost
                echo "nameserver" > /etc/resolv.conf
  1. The new URL redirects users through some vendor website, like websecure.cisco.com, which does some checks. That means that every access is reported and enables tracking. 

  2. I do run my own mail server, but the situation is of course a different one when you have hundreds or thousands of users and it requires only one to belief in a forged phishing mail from administrators or authorities. And after all I am not blamed by anyone but myself when things go wrong. 

  3. A local DNS resolver is a fast cache, can be configured to support conditional forwards, can supports DNSSEC. 

  4. For instance, set up a DNS resolver on your VPN server.