By default, the web server will listen on port 8081 on localhost. That means, that you can’t view the status information from the outside network. To view the page, you could use a command line browser like lynx. You could change the interface of the web server to a public IP address, but this is very insecure and not recommended. The PowerDNS web server provides some sensitive information about your DNS server and you should not expose this information to the public. Also, the PowerDNS web server is probably not as thoroughly tested and hardened as e.g. Apache or nginx. Another problem is, that you can only specify a single password and that you are limited to basic authentication, which is not very secure.

There is a secure way to retrieve the information provided by PowerDNS from outside your DNS server host. You could use Apache, nginx or any other web server you like as a proxy server. That way you can use more advanced authentication methods built into that web server to secure your status page. I will now show you how to do this using Apache 2 on Debian. We’ll need mod_proxy, mod_proxy_http and mod_headers enabled on the Apache 2 server. If you do not want to run an instance of Apache 2 on your DNS server, you could use an SSL tunnel or a secure back channel link to a remote Apache server to retrieve the status page. But this is beyond the scope of this post.

First, enable the internal PowerDNS web server by editing the configuration file.

1. webserver=yes
2. webserver-address=127.0.0.1
3. webserver-port=8081
4. webserver-password=PowerDNS

This tells PowerDNS to run the internal web server on port 8081 of the localhost interface. The user name will be admin and the password will be PowerDNS. Of course you should change the password to something more secure, it’s just an example. After a restart of PowerDNS you can connect to your server from your DNS server host. The password is optional, but it’s safer that way, especially in an environment where you’ve got other users on your DNS server box.

Now install and enable the required modules of Apache 2 by executing the following commands.

1. apt-get install libapache2-mod-proxy-html
2. a2enmod proxy
3. a2enmod proxy_http
4. a2enmod headers

The last module is only needed, if you set a password for your internal web server as recommended above. I assume that you’ve got some kind of virtual host configuration for your Apache server. You’ll want to add a new virtual host for the DNS status information. If you use a subdirectory, navigation might be a bit odd. Let’s add a new site to the available sites.

1. vi /etc/apache2/sites-available/status.dns.example.net
2. <VirtualHost 192.168.0.1:80>
3. ServerName status.dns.example.net
4. DocumentRoot /var/www/
6. ProxyRequests Off
7. <proxy *>
8. Order deny,allow
9. Allow from all
10. ForceType 'text/html; charset=UTF-8'
11. </proxy>
12. ProxyPass / http://localhost:8081
13. ProxyPassReverse / http://localhost:8081
15. </VirtualHost>

Alright, so what are we doing here? Basically, we’re adding a new virtual host status.dns.example.net on our main interface of dns.example.net. We’re using a reverse proxy to to send all requests coming from the outside to our internal PowerDNS web server on port 8081. Also, we’re forcing a text/html content type in the proxy request filter, because otherwise we would just get text/plain and we would simply see the source code, which is probably not what you want. Let’s enable the site for a test:

1. a2ensite status.dns.example.net
2. /etc/init.d/apache2 reload

If you point your web browser to status.dns.example.net you should now see the internal status page of PowerDNS. If you set a password above, you will see a password dialogue. This is the password dialogue sent by the PowerDNS web server. The user name is admin and the password is your password. Try it out now, because we’ll get rid of this in a minute.

For security reasons, you probably want to use Apache 2 for authentication. E.g. you might want use a SSL connection and authenticate your co-workers using the internal LDAP server of your company intranet. You might even stay with the insecure basic authentication method, but use other user names. This is entirely up to you and beyond the scope of this post. Consult the Apache 2 documentation on how to do this. What you probably don’t want to do, however, is to authenticate twice (first your secure authentication method and then PowerDNS basic authentication. Luckily, we can configure the Apache 2 proxy to do the authentication for us. This is a bit tricky, though.
To authenticate at the PowerDNS server, Apache 2 needs to send an additional Authorization header line to the PowerDNS server with every request it handles. We use the RequestHeader directive to override any existing Authorization header with our own authentication data. Add the following lines just before the end of the virtual host container.

1. <Location />
2. RequestHeader Set Authorization "Basic YWRtaW46UG93ZXJETlM="
3. </Location>

The above example works only for our example password, which is PowerDNS. Try it for a test. This is, because part of the header value is encrypted using the base64 algorithm. You need to change the encrypted part YWRtaW46UG93ZXJETlM=. In plain text the encrypted string would read admin:PowerDNS, where admin is the user name and PowerDNS is the password. To use your own password, you need to encrypt the string admin:yourownpassword using the base64 algorithm and replace our example string. Be sure to keep the Basic and the space. It is crucial for success, that you’ve got the right encrypted string. There are a number of online tools, to encode and decode these strings. To ensure, that you’ve got the correct encryption method, encode the example string and compare it to the string above for a reference. If you’ve got the wrong string, it will not work.

Restart the Apache 2 server. To clear your password cache, restart your browser. Now surf to the site again. You will see, that the password dialogue is gone. Now, don’t forget to secure the page again using Apache 2. Under any circumstances, do not use Directory containers in the configuration. These will not apply to the proxy, because the proxy is not a physical directory on your server. Use Location containers like we did above for setting the RequestHeader directive. Also, you could still use insecure basic authentication to secure the page, if you wanted. It would work regardless of the RequestHeader magic.

A light-weight alternative

For those of you, who think that Apache is too heavy, here is an example for the nginx web server:

1. vi /etc/nginx/sites-available/status.dns.example.net
2. server {
3. listen 192.168.0.1:80;
4. server_name status.dns.example.net;
5. root /var/www/nginx-default;
6. location / {
7. index index.html
8. proxy_pass http://localhost:8081;
9. proxy_redirect off;
10. proxy_set_header Authorization "Basic YWRtaW46UG93ZXJETlM=";
11. }
12. }

1. mysql> SELECT * FROM posts LIMIT 1;
2. +----+-------------+---------------------+---------------------+--------------------------------+--------------+-----------
3. ----+--------------+----------+----------+-------------+----------------+-------------+---------------+-------------+----
4. -----+--------+---------------------+---------------------+-----------------------+-------------+-------+------------+----
5. -------+----------------+---------------+
6. | ID | post_author | post_date | post_date_gmt | post_content | post_title |
7. post_category | post_excerpt | post_lat | post_lon | post_status | comment_status | ping_status |
8. post_password | post_name | to_ping | pinged | post_modified | post_modified_gmt |
9. post_content_filtered | post_parent | guid | menu_order | post_type | post_mime_type |
10. comment_count |
11. 

12. +----+-------------+---------------------+---------------------+--------------------------------+--------------+-----------
13. ----+--------------+----------+----------+-------------+----------------+-------------+---------------+-------------+----
14. -----+--------+---------------------+---------------------+-----------------------+-------------+-------+------------+----
15. -------+----------------+---------------+
16. 
| 1 | 1 | 2004-01-17 18:17:37 | 2004-01-17 16:17:37 | We'll see what time brings ... | Hello world! | 1
17. | | NULL | NULL | publish | closed | closed | | hello-world
18. | | | 2004-01-17 18:17:37 | 2004-01-17 16:17:37 | | 0 | /?p=1
19. | 0 | post | | 0 |
20. 

21. +----+-------------+---------------------+---------------------+--------------------------------+--------------+-----------
22. ----+--------------+----------+----------+-------------+----------------+-------------+---------------+-------------+----
23. -----+--------+---------------------+---------------------+-----------------------+-------------+-------+------------+----
24. -------+----------------+---------------+
25. 1 row in set (0.00 sec)

There is actually a nice solution for this. By default, the command line client uses horizontal mode to display the results of MySQL queries. If you use \G instead of ; or \g at the end of the line, your query result will be displayed in vertical mode, which will look a lot better:

1. mysql> SELECT * FROM posts LIMIT 1\G
2. *************************** 1. row ***************************
3. ID: 1
4. post_author: 1
5. post_date: 2004-01-17 18:17:37
6. post_date_gmt: 2004-01-17 16:17:37
7. post_content: We'll see what time brings ...
8. post_title: Hello world!
9. post_category: 1
10. post_excerpt:
11. post_lat: NULL
12. post_lon: NULL
13. post_status: publish
14. comment_status: closed
15. ping_status: closed
16. post_password:
17. post_name: hello-world
18. to_ping:
19. pinged:
20. post_modified: 2004-01-17 18:17:37
21. post_modified_gmt: 2004-01-17 16:17:37
22. post_content_filtered:
23. post_parent: 0
24. guid: /?p=1
25. menu_order: 0
26. post_type: post
27. post_mime_type:
28. comment_count: 0
29. 1 row in set (0.00 sec)

While vertical output uses a lot more vertical space than the horizontal output, the vertical output is a lot more readable. Now you can probably see what I used as example query. It is actually the first post from this blog. Yes, this blog just got 6 years old ;).

If you want your command line client to use vertical mode by default, you can add vertical to the client section ([client]) of your .my.cnf file. This would look something like this:

1. [client]
2. vertical

As the 26th Chaos Communication Congress is just around the corner, I’ve set up a public instance of TwoZero. Try it out and tell me what you think. You can also download the source code (see the About section) and hopefully send in your excellent patches.

1. <?php
2.  
3. function foo ( string $bar) {
4. echo $bar;
5. }
6. foo ('Hello World!');
7.  
8. ?>

What happens, when you execute the above code? You will get a rather cryptic error message:

1. Catchable fatal error: Argument 1 passed to foo() must be an instance of string, string given.

So the method expected a string as the first parameter and you passed a string to it, but PHP chose to throw up regardless. Great, isn’t it? Of course, the reason for this is right at the very bottom of the PHP documentation on Type Hinting. All the way down the page below a number of examples:

Type Hints can only be of the object and array (since PHP 5.1) type. Traditional type hinting with int and string isn’t supported.

Doh!

PS: I know that it’s early morning in Sydney right now. Never mind.

The Exim mail server comes with out of the box quota support. All you need to do is to set the quota, quota_warn_threshold and quota_warn_message options on your transport and you will be fine (see Chapter 26 of the Exim Specification). Combine this with a few custom database lookups and you’ve got a great way to handle your user’s mailbox quota. By utilizing some additional options and the power of regular expressions you could even define different quotas for each folder of your user’s IMAP mailboxes.

The problem

Using Exim’s quota management has a major drawback, though: Quota checking takes place after the message has been accepted for delivery. What does that mean in practise?

If the quota limit of a mailbox is exceeded, messages for this mailbox are still accepted for delivery, but deferred temporarily. At each queue run, Exim checks, if the quota limit is still exceeded. If the user has deleted mails from her mailbox since the last queue run, the mail will be delivered. If not, the mail will be deferred again. At some point, Exim will give up and finally bounce the mail back to the sender. How long Exim will try to deliver the message depends on your retry rules. While this is good for your user, because she has some more time to clear up her mailbox before she effectively looses mail, it is bad in a number of ways:

• The deferred mails add up to the queue and clutter it up.
• If the user does not delete messages from her mailbox (e.g. she is no longer using it actively), messages will sit in your queue for a long time, before they are finally bounced back to the sender. During this time, the sender does not know about the status of the mail. You need to provide disk space for these mails. If you set up quota limits to better manage the disk space at your disposal, this may hit you hard.
• If your user gets a lot of spam from faked sender addresses, you may generate a lot of collateral spam by bouncing her messages back to the faked sender addresses.

A possible solution

Exim were not Exim, if there wasn’t some way to get around this limitation and check quota right at RCPT time during the SMTP transaction. Actually, there are a number of ways to implement this. And all have pros and cons. I’d like to show you a way that is relatively easy to implement, but does have some minor issues.

Basically, the idea is to set up a database of those users that are over quota. You’d use an external script to periodically check, if a user exceeded her quota limit, and manage the database accordingly. You could use a flat file to store mailbox names of these users or – if you’re already using a relational database (e.g. MySQL, PostgreSQL) or an LDAP directory for mailbox management – add an additional property (e.g. isOverQuota) to your mailbox object.
Additionally, you need to configure Exim to check our file or database during the SMTP transaction and reject an incoming message, if it is for a mailbox that is over quota. How to do this depends a bit on your current configuration. Chances are, you’re already verifying the recipient of a message before you accept it (check your ACLs for require verify recipient). In this case, the fastest way to implement this in Exim is to add an additional router somewhere before (probably immediately before) the router that handles routing of messages to your user’s mailboxes (the router with the quota option). If you used a MySQL database it might look something like this:

1. virtual_mailbox_overquota:
2. driver = redirect
3. domains = +local_domains
4. condition = ${if eqi{$local_part} {${lookup mysql {SELECT username FROM exim.mailbox WHERE username='$local_part' AND domainname='$domain' AND enabled='1' AND overquota='1' LIMIT 1}}}{yes}{no}}
5. data = :fail: Mailbox is full, quota limit exceeded
6. allow_fail

Note: You’ll probably want to change the domains and condition options before you use this router in your configuration. But you get the idea, don’t you?

By default Exim calculates quota by adding the size of the new message to the size of the mailbox and comparing this to the quota limit of the mailbox (inclusive checking). This means that a user can’t go over quota. The mailbox will always remain below the quota limit. This is great, but it doesn’t work for us. Our script depends on users going over quota, because otherwise it would not detect the mailboxes that are over quota. Again, there are a number of possible solutions to this problem. You could increase the quota limit of every mailbox by 1% and check for mailboxes at 99%. Alternatively, you could disable inclusive quota checking. To do so, add the following option to the router, which handles routing of messages to your user’s mailboxes (the router with the quota option):

1. quota_is_inclusive = false

Testing the new configuration

To test, if the new configuration works, you might use Exim’s basic address deliverability checking.

1. $exim -C exim.new.conf -f sender@example.org -bt not.over.quota@example.org
2. not.over.quota@example.org
3. router = virtual_mailbox, transport = appendfile
4. $exim -C exim.new.conf -f sender@example.org -bt exceeded.quota@example.org
5. exceeded.quota@example.org is undeliverable: Mailbox is full, mailbox quota exceeded

If you get anything close to the above, you’re probably okay. Of course you need to have a mailbox that exceeded its quota limit for this test to work.

Some issues

There are two minor problems with this solution. Depending on your situation, these might be acceptable or not.

First, there is the checking interval. If a user exceeded her quota limit, mail to her mailbox wouldn’t be blocked at SMTP time until the checking script’s next run. This is not such a big problem, because the message won’t be delivered anyway. Instead it would be deferred and bounced back later (see above). Unfortunately, it’s the same the other way around. If a user deleted messages from her mailbox, this would not be recognized by Exim before the checking script’s next run. Mail would be rejected at SMTP time, although there might actually be enough space in the mailbox. This is a much bigger problem. Generally spoken, the interval between the runs of your checking script should be as low as at all possible. But don’t burn your mail server on the way ;).

Second there is the exclusive quota checking. Because we depend on the mailbox actually going over quota, we need to disable inclusive checking or – alternatively – increase quota limits and flag mailboxes as over quota at 99% or less.
If we do the latter, there is always the possibility, that the quota of a mailbox isn’t above the checking threshold and there are new messages coming in, which are too large for the mailbox. These messages would be queued. Consider an example: A user get’s 30 messages of 1 GB, but his mailbox is only 500 MB. He gets no small messages in between, so our checking script will not flag the mailbox in subsequent runs and the size of the queue will rise a lot. This is especially a problem, because this probably affects mostly messages that are quite large. Also, if you can’t check fast enough and get a lot of small messages, there might be a lot of mailboxes that go way above the checking threshold before you can flag them. If you have a very large user base, this might be a problem. A run of the script probably takes longer, if you have a lot of mailboxes, so this adds to the problem.
If we disable inclusive checking, the last message that brings a mailbox over quota will always be delivered. Depending on the message this might be okay (in case of small messages) or really bad (in case of very large messages). But: The mailbox will be flagged at the next run of our checking script, so the queue will remain relatively clear compared to our scenario above.
If you do not have a lot of users and your resources are limited, you might not like this option. If you’ve got a large user base, exclusive checking is probably better.

Of course, there are other solutions, that do not have these issues. But they are a lot harder to implement and to maintain.