Overview

Xen is a great open source platform to create multiple virtual machines in one physical machine. This article describes how to setup a Xen host domain in a PC and how to create a Xen guest domain on it.

Context

This article is for those who are new to Xen and with basic unix knowledge. It aims to provide easy-to-follow instructions for readers to start experimenting with Xen, as well as explaining the key concepts behind the setup.

Debian 5.0 Lenny is used as the operating system for the Xen host and guest domains in these instructions. Setup for other operating systems may be similar but are not covered in this article.

Solution

Virtualisation technologies like Xen make it possible to run multiple virtual machines concurrently in one physical machine. This allows you to, for example,

• Set up a team development environment and multiple testing environments in one physical machine,
• Set up a 10-machine virtual network to test various network configurations,
• Try out various linux distros and Windows in one PC.

This is also the core technology that made cloud computing a reality. In fact, Xen is used by service providers like Rackspace to provide virtual machines to their customers.

Xen is not an operating system that lets you put new systems on it – it is more like a software package in a linux operating system, except that it is so tightly integrated with the core system processes that it becomes part of the operating system (the kernel).

A great way to see Xen in action is by downloading the Xen Live CD image, create the CD and boot from it. It shows what a complete Xen system looks like. Note that the Xen Live CD is for demonstration only – you cannot install a host domain from it.

Another definitive knowledge source for Xen is through its User Manual.

We will set up a Xen system with host and guest domains through the following steps:

1. Pre-requisits
2. Install Debian 5.0 Lenny
3. Install Xen on Debian 5.0 Lenny to turn it to a Host Domain
4. Install Debian as a Guest Domain on the Host Domain

1. Pre-requisits

Before you begin, first check if your physical PC has what you need:

• Memory – As with other applications, the more the better. A 2GB RAM machine was used for the exercise in this article but less should be okay.
• Hard disk – Again, the more the better. It depends how many virtual machines you plan to create and what will be run in them. 10GB for each virtual machine will usually be more than enough. As a baseline indicator, the Xen Live CD is able to squeeze one host and one activated guest domain in one CD-ROM.
• CPU – Any modern Intel/AMD processor should do. For this exercise, the machine in use has an Intel Pentium 4 3.4 GHz processor.
• Operating System – According to the Xen User Manual, any “working Linux distribution using the GRUB bootloader” will do. More on this in the next section.

2. Install Debian 5.0 Lenny

First of all, you need a linux operating system in the machine before you can install Xen on it. This OS will automatically become the host domain, also known as domain 0 of Xen after Xen is installed, and will be used to control the other virtual machines (guest domains).

Personally, I recommend installing only the Xen host and guest domains in one PC (it is complex enough!), therefore you should wipe the PC clean when you do the installation described in this section.

Installing Debian 5.0 Lenny is simple – simply download the first CD-ROM image, burn the CD, then boot from it and follow on-screen instructions. Note that there are 31 (!) CD-ROM images in total for Debian 5.0 Lenny, but only the first one is required to create a basic installation as the Xen host domain.

During installation, note that

• Partitioning – Allocating 10 GB to the primary partition for the host domain will be more than enough. You probably also want to define a few logical partitions in the extended partition, so that Xen guest domains can be installed on them later. If 10 GB seems too much for you, consider at least allocating 4 GB to host domain, as Debian, Xen packages and related tools would have taken 3 GB of space.
• Select and Install Software – Select “Desktop Environment” and “Standard System” only. Your host domain should only do resource allocation and monitoring for your guest domains and should not carry other roles.

Perhaps you wonder if the other linux distros will do a better job as a Xen host domain, like I did. Here are some analysis after a few hours of online research,

• Fedora Core – Fedora Core used to be one of the popular candidates for Xen host domain OS, however it no longer supports Xen (as a host domain) starting from Fedora Core 8.
• Ubuntu – Ubuntu is one of the popular candidates for Xen host domain OS. It was almost used in this exercise – However, installing Ubuntu 9.10 was not successful and that was the end of the quest (the installation CD keeps being read after choosing “Install Ubuntu” in menu, and does not proceed).
• Debian – Debian is also popular. Plus, it was chosen as the Host Domain OS in the Xen Live CD, which provides a good source of reference for configuration issues.

3. Install Xen on Debian 5.0 Lenny to turn it to a Host Domain

Because of the many Linux distributions and their many verions, combined with the multiple verisions of Xen for them, and also the fact that there are multiple ways to install Xen, online instructions can be very confusing.

According to the Xen User Manual, there are three approaches in installing Xen.

1. Installing from Binary Tarball – Download a tar file and running the install script
2. Installing from RPMs – Use rpm command to get and install Xen
3. Installing from Source – Download source codes and build binaries manually

For Debian 5.0 Lenny, running the single command below as root user will be able to download and install Xen for you. This is similar to “Installing from RPMs” approach, except rpm is mainly used in Fedora Core.

apt-get install xen-linux-system-2.6.26-2-xen-686

After installation, reboot the computer. The GRUB boot loader should now have three new options, adding to the original two,

• Xen…
• Debian… -xen …
• Debian… -xen … (single user mode)
• Debian…
• Debian… (single user mode)

Boot with the first option will start up the Xen host domain. After logging in, run the command below as root user

xm list

It should show that Domain-0 is now running.

4. Install Debian as a Guest Domain on the Host Domain

Compared to installing host domain, online documentations for installing guest domains can be even more confusing due to the many combinations of host and guest linux distributions.

Fortunately, xen-tools has made the task of getting, deploying and managing Xen guest domains relatively simple. First of all, run the following command as root user to install xen-tools.

apt-get install xen-tools

Read through this tutorial from Virtuatopia.com to understand how xen-tools help you create a guest domain. There are also some useful information from the Xen Tools official site and another tutorial.

These tutorials mentioned above should have answered most of your questions. Adding my my two-cents from my own experience,

• If you do not understand the differences between the dir and lvm options, consider reading chapter 6 Storage and File System Management in the Xen User Manual.
• The LVM option is great – and there is a detail tutorial here.

Assuming you have understood how xen-tools work and made required changes in /etc/xen-tools/xen-tools.cfg to suit your needs, you can run

xen-create-image --hostname <hostname of virtual machine> --ip <IP of virtual machine>

to create your guest domain. While the command is executing, you can use

tail -f /var/log/xen-tools/<hostname of virtual machine>.log

to check its progress.

If all went well, you should be able to see the your guest domain created as logical volumes in your specified volume group (or as files if you used that option), and also a Xen domain config file in /etc/xen/ with your virtual machine hostname as the filename.

Before you boot-up your newly created virtual machine, remember to modify the Xen config file, /etc/xen/xend-config.sxp and change “network-dummy” to “network-bridge” in the network-script option. Otherwise, if your virtual machine has been configured any network information (IP address, gateway, name server etc), you will see this error when booting up the virtual machine:

Error: Device 0 (vif) could not be connected. Could not find bridge, and none was specified

And remember to run

xend restart

for the change to take effect.

And finally, if all went well, run this

xm create /etc/xen/<hostname of virtual machine>.cfg -c

and your virtual machine will start up!

Facebook Connect is a mechanism provided by Facebook that lets their users bring their identity and social experience to any website. The first step is authentication – let visitors login to your site with their Facebook accounts. This article explains how that works.

Context

This article is for web application developers learning how to implement Facebook Connect authentication in their websites. It is introductory and explains the interaction between the browser, Facebook and your website during authentication. The article also contains references to the sample Facebook Connect web application, The Turn Around, to point out where the actual function calls are.

Solution

The authentication process begins when user clicks on the Facebook Connect login button in your website. User will see a pop-up from Facebook and sign in with Facebook account details. Once user logs in, your website can retrieve Facebook user info like profile photo and will be able to write back to Facebook (e.g. publishing feed story in profile) if user grants the required specific permissions.

Exchange of handshakes, credentials, cookies and various function calls occur between the user browser, your website and Facebook server during the authentication process. They are illustrated in the interaction diagram below.

Facebook Connect Authentication - Interaction Diagram (click to enlarge)

1. User visits your website.
2. Your website checks with Facebook to see if user has already signed in using Facebook Connect.
3. Facebook says no. Using codes in TheRunAround as an example:
   1. index.php – checks if user has logged in Facebook via User::getLoggedIn()
   2. getLoggedIn() in lib/user.php – calls facebook_client() and retrieve the facebook user via Facebook::get_loggedin_user()
   3. facebook_client() in lib/fbconnect.php – creates Facebook object
   4. Constructor in facebook.php (in Facebook PHP library) – connects to facebook server using api_client, retrieves params via validate_fb_params() but will not get anything. As a result no user will be set
   5. get_loggedin_user() in facebook.php returns null which eventually gets passed back to index.php
4. Your website returns a page that displays a Connect with Facebook login button. In the sample app, this is done in render_fbconnect_button() in lib/fbconnect.php. Note how the button can be displayed by showing the image directly and calling the FB.Connect.requireSession(), or just by using the xFBML syntax.
5. User clicks on login button. FB.Connect.requireSession() is called
6. FB.Connect.requireSession() found that user has not logged in Facebook yet and display a “Connect with Facebook” pop-up. The pop-up could be in the form of pop-up window or an iFrame window depending on parameters. Note that starting from this step, it is part of the Facebook javascript library and is not open-sourced. Its API is available. This is also an example of the much-discussed “cross-site scripting”, as this is a page from your server dynamically loading a script from Facebook server.
7. User enters Facebook credentials.
8. Facebook verifies user credentials. Once verified, it calls the javascript callback function registered in waitUntilReady(). The callback function has been registered in facebook_onload() in fbconnect.js.
9. The callback function in facebook_onload() detects that session status has changed and refresh the page.
10. Step 1 is repeated again to check if user has logged in to Facebook.
11. Facebook says yes. User::getLoggedIn() will create and return a user object with a valid Facebook user ID.
12. Web page displays Facebook content such as profile photo, friends who are also using your website, etc.

Once connected, your website will be able to read from and write to the Facebook system on behalf of the logged in user via Facebook API.

Because of the many documents available online and the fact that many of them are outdated, downloading The Run Around sample application and studying it in detail is highly recommended.

Reference

• http://wiki.developers.facebook.com/index.php/Getting_Started_with_Facebook_Connect – The beginner’s guide to Facebook Connect.
• http://wiki.developers.facebook.com/index.php/Using_Facebook_Connect_with_Server-Side_Libraries – Facebook wiki doc explaining how server-side libraries are used.
• The Run Around – Sample Facebook Connect application provided by Facebook. Its source code is available for download.

You are trying to implement Facebook Connect in your site so that your visitors can log in to your site using their Facebook accounts. You followed the simplest example available in
a Facebook wiki document, however for some reason the “Connect with Facebook” button does not seem to do anything – no pop-up, no error, nothing. Why is that?

Context

This article is for those who want to implement Facebook Connect in their websites. It explains the scenario when a simple Facebook Connect login button does not seem to work.

Solution

The login button does not do anything most likely because you have not set it up to do anything.

The basic example shown in this Facebook developers wiki page: http://wiki.developers.facebook.com/index.php/Connect/Setting_Up_Your_Site has instructions in great detail, however it has not mentioned clearly that it actually only shows you how to display a Facebook Connect login button.

The test.html described in the wiki page is


<html xmlns="http://www.w3.org/1999/xhtml" xmlns:fb="http://www.facebook.com/2008/fbml">
<head></head>
<body>
<script src="http://static.ak.connect.facebook.com/js/api_lib/v0.4/FeatureLoader.js.php" type="text/javascript"></script>
<fb:login-button></fb:login-button>
<script type="text/javascript">
FB.init("YOUR_API_KEY_HERE", "xd_receiver.htm");
</script>
</body>
</html>


If all instructions in the wiki page have been followed correctly, clicking on the resultant Connect-with-Facebook login button should trigger a Facebook login form to appear in a pop-up window, given that the user has not logged in to Facebook yet.

If user has logged in to Facebook and clicks on the login button for the first time, a pop-up will appear to ask the user to authorize the integration between your website and Facebook.

Once user logs in via the pop-up window or agrees on the Facebook Connect authorization, clicking on the login button will no longer trigger any actions because user is now “connected” and there is no “callback function” specified in the html file.

To make it slightly more confusing, the authorization pop-up will only appear once: Even after you clear all the cookies and log out of Facebook in an attempt to start from the beginning, the login button will no longer trigger any actions if you log in Facebook again and click on the test login button. This is because Facebook remembers your authorisation from its servers.

When the wiki page says “Optionally, you can add a JavaScript handler to the callback function to call when the user logs in”, it actually meant “Unless you want user to see no changes after logging in, you need to add a JavaScript handler…”.

So how do you specify a “callback function” and how does Facebook Authentication work? A separate article has been written to answer this question.

Your server is a virtual private server running Fedora (or other linux distro) on a cloud computing service such as RackSpace Cloud Server. For some reason, whenever you change the system time, it gets reset back after a system restart. Why did that happen? Could it be fixed?

Context

Solution described in this article applies to Fedora Core 11 hosted in a Xen VPS environment. Other Fedora verions or linux distro in other virtualisation environment may have similar setup. Xen configuration is outside the scope of this article.

Solution

As a virtual server hosted using Xen virtualisation technology, such as those offered by RackSpace Cloud Server offer, system time will get reset by Xen to match the physical machine’s clock whenever the virtual server is restarted.

This time-reset behaviour can be modified if you can change the Xen configuration. However as a user of the cloud computing service, you most likely do not have such access.

You can however do the following to set your system to the time you want.

1. Change time zone

Changing the time zone of your system will set your system time to the correct time of that time zone, given that your virtualisation provider gives your server a correct UTC time.

To change the time zone in Fedora Core 11,

• Change the ZONE parameter value in /etc/sysconfig/clock according to your desired time zone, e.g. ZONE=”Australia/Sydney”. The list of possible values for ZONE can be found in /usr/share/zoneinfo/. The UTC parameter in /etc/sysconfig/clock can be omitted.
• Copy the correct time zone file to /etc/localtime. For example, if you want to set time zone to Sydney in Australia, do cp /usr/share/zoneinfo/Australia/Sydney /etc/localtime

2. Use a time-synchronising tool

After you have set your system to the correct time zone, the time may still be inaccurate because it simply relies on the time given by the virtualisation provider.

To compensate any inaccuracy from virtualisation provider, use time-synchronising tool like ntpdate to sychronise your server with publicly-available time servers.

1. Install ntpdate if it is not already installed in your system. Run yum install ntpdate to install ntpdate.
2. Turn on ntpdate service using chkconfig --level 3 ntpdate on so that time will be sync’d on boot time. Note that your “level” may be different, check /etc/inittab to be sure.
3. Use cron job to run ntpdate hourly or daily to keep an accurate time in the long term.

Note that in a virtualisation environment, ntpd will not be able to set the time of guest system properly because of the CPU time-sharing nature of virtualisation technology. Refer to ntp docs for more information: http://support.ntp.org/bin/view/Support/VMWareNTP

3. Use date command to change system date and do not restart

If setting your system to match specific time zones accurately still does not fulfill your requirement (e.g. if you want your time to be 15 minutes behind, for testing purpose), you can still change your system time using date command. However keep in mind that this will be reset back to the correct time of your time zone after a restart.

Reference

• http://support.ntp.org/bin/view/Support/VMWareNTP Network Time Protocol documentation regarding the virtualisation environment.

Web servers with web applications like forums or blogs often need to send out emails to users. These emails are often legitimate and useful to users, however email providers often incorrectly classify them as spam because of the amount of spam emails found in the internet today.

This article describes what you can do, as the system administor / post master of your mail servers, to make sure emails sent from your mail servers go straight to the inboxes of the recipients instead of landing in their spam/junk folder. Because of the bad guys, good guys have to do a lot more to prove their innocence.

Context

Solution described in this article has been tested in a Fedora / Postfix setup. Most of the steps are not specific to this setting and can be applied on other environments. Note that these are only possible actions one can *attempt* to prevent emails to be marked as spam. It is ultimately up to the recipient mail servers to decide whether emails are spam or not.

This article assumes reader to have a good understanding of DNS, Unix and web server-related terms and how they work in high level. Most changes described in this article require system-administration / root access to the server.

Steps

1. Make sure Sender Username and Server Look Legitimate

If you just configured your server to send email, chances are that your out-going emails have words like “apache”, “localhost”, “nobody”, “localdomain” all over the place in their mail headers. This is often a sign of improper setup and therefore such mails will be marked as spam by spam filters.

To get rid of them, check the following configurations:

• /etc/hosts This file needs to be set up properly so that the “hostname” command returns the public hostname instead of “localhost”, and “hostname -f” returns the fully-qualified domain name, like “foo.fooworld.com”.
• /etc/httpd/conf/httpd.conf Check the ServerAdmin and SererName of this Apache config file and ensure that it is a valid email address and a fully-qualified domain name.
• /etc/mail/trusted-users If you need to send emails under a privileged user like apache as some other users such as no-reply@yourdomain.com, modify this file and add the username of the privileged user.
• /etc/php.ini If you are using php to send emails, you can enforce a different sender identify by adding -f’sender_address@domain.com’ in the sendmail_path argument.
• Use postfix instead of sendmail if you are sending emails from apache and want to ensure that the word “apache” is not in the headers of your out-going emails. This is required because in sendmail, even if a “-f” option is used to enforce a particular sender identity, the text “apache@localhost” will still appear in the first Receive mail header.
• The mail header fields “From”, “Reply-To” and “Return-Path” should be the same and be a valid email address, and will not reply with a bounce message if an email is sent to it.

2. Setup Reverse DNS

The usual DNS records allow everyone to lookup “foo.foobar.com” and find “123.124.125.126″. Reverse DNS does the opposite: It allows you to look up the IP address using the domain name. If the domain name and IP address can be used to look up each other, the sender is more likly to be what it claims it is. Therefore this check is employed by spam filter as well.

Note that Reverse DNS setting is not controlled by the domain name server of the domain in question. Using the example above, the DNS server of “foo.foobar.com” cannot control its Reverse DNS settings. It is the responsibility of the ISP that maintains 123.124.125.126 to set up its Reverse DNS mapping.

To verify that it has been set up, use “nslookup <domain name>” to check for its IP and “nslookup <ip address>” to check for its domain name. They should find each other if DNS and Reverse DNS have been set properly.

3. Add SPF Record

SPF record is a TXT record in the domain server, like the other A / CNAME / MX type DNS records, that describes the domain. Spam filter gets the SPF record from DNS server and check if the sender mail server has been allowed or disallowed to send mails.

SPF implementation is free and simple. You can create a SPF record manually if you understand its specification, or you can go to one of the following websites to generate it after answering some questions about your mail server settings.

http://old.openspf.org/wizard.html
http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/default.aspx

4. IP Blacklist Check

Some of the bad guys might have used *your* IP address before to send out spam emails, and now any emails sent from your machine are classified as spam. A website like the one below lets you check if your machine falls into such category, and if it does, lets you request that your IP be taken out from the list.

http://www.mxtoolbox.com/blacklists.aspx

5. Ensure Mail-Sending Server is listed on MX record

The MX record in the DNS entries tells the whole world which machine should process emails for that domain. If the web server that sends outgoing emails is not listed on one of the MX records, spam filters may think that mails were sent without proper authorisation and therefore should be marked as spam.

As an example, let say you are sending emails from foo.foobar.com. A lookup of MX record of foobar.com shows that the mail server is mail.foobar.com instead. This could be a problem for spam-filter. Configure foo.foobar.com as a proper mail server, point to it using MX record and use it to send and receive emails for foobar.com.

6. Implement DKIM (Domain Keys Identified Mail)

DKIM is similar to SPF. The sender claims that it is from foobar.com and the recipient checks the DNS records of foobar.com to see if the sender is indeed from there. The difference is that, for DKIM, sender has to present a “signature” instead of just using its IP to prove its identity.

Refer to this article for implementation details of DKIM.

Gmail in particular appear to put emails in inbox only after DKIM has been implemented.

7. Contact Individual Providers

The recipient mail servers may still decide that your emails are spam, even after you have done the whole lot above.

For example, official support from Microsoft stated that “… IPs that have little to no history of sending email to Hotmail are more likely to be targeted by SmartScreen…”. SmartScreen is one of their spam-filtering tools that filter emails based on machine learning algorithms. With such assumption made by this program, emails from new servers will inevitably go to the junk folder of hotmail addresses.

Advise from official Microsoft Support for this issue is that “Following all the recommendations (from their postmaster policy guidelines)… will really make a big difference. Have a nice day!”. There is not much you can do. However, your out-going emails may become non-junk after a few weeks of SmartScreen learning about your server IP, given that your emails are not labelled as junk by your recipients and emails are sent consistently.

As a last resort, you can try to contact the free email providers directly using the web pages they provide:

• http://help.yahoo.com/l/us/yahoo/mail/postmaster/bulkv2.html Yahoo Mail support page for marked-as-spam problem
• https://support.msn.com/eform.aspx?productKey=edfsmsbl&ct=eformts Microsoft support page for marked-as-spam problem

Errors / Configuration Problems

Mail source from Gmail shows “Received-SPF: neutral”

This is a sign that your SPF record has not been implemented properly. If it has been done correctly, the header should say “Received-SPF: pass” instead. Have you specified the correct IP? Have the DNS records been updated properly?

Mail source from Gmail shows “dkim=neutral (body hash did not verify)”

A work-around for this problem is provided in http://allaboutlamp.com/2009/09/setup-dkim-for-postfix-in-fedora-using-dkim-milter/.

Reference

• http://dnsstuff.com A website that generates comprehensive report for your DNS records and tells you how “healthy” they are. Make use of the 7-day trial period!
• http://www.mxtoolbox.com/blacklists.aspx A website to check if the IP address of your mail-sending machine has been blacklisted by spam filters.
• http://postmaster.live.com/Troubleshooting.aspx Microsoft’s help for those trying to send emails to hotmail users but marked as spam.

DKIM is a technology that allows mail senders to attach a signature in outgoing mails, so that recipients can check the signatures against DNS records of the sender to see if mail is indeed sent from there.

Because free email providers like gmail make use of DKIM to determine if sender is sending spam, i.e. “if your domain does not implement DKIM, you are a spammer”, it is important to implement DKIM for your mail servers to avoid your legitimate out-going emails be classified as spam.

Context

This article describes how to implement DKIM for Postfix in Fedora using the dkim-milter open-source module. This solution has been tested with Fedora 10.

DKIM allows a domain to be associated with multiple “signatures”. Each signature is identified by its “selector”. In this example, we are going to create only one signature with its selector named “default”.

Steps

1. Generate a private key

openssl genrsa -out default.private 1024

A “default.private” key file will be generated. It will be moved to a specific location later.

2. Generate a public key for this private key

openssl rsa -in default.private -pubout -out default.public -outform PEM

A file with filename “default.public” will be generated with content like

-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDVqyBW3CvurzAJrWvw/rbiMVL2
6lytBkhIrgEBWjGWEjjhM6mQpQWLq9VR46xlL4OT6UdVtO8QOMEVI23LN0fwtrPc
/auwHC2U9joUWTWVjOMZWEywOHwATGevh9TApt2hQJkWjMy/xmCIqBs9VZIweRlf
VFqc9WEu6VamGe9C3QIDAQAB
-----END PUBLIC KEY----

It will be used to create a DNS TXT record. See next step.

3. Create a DNS record of type TXT

Modify DNS records and add a record of type TXT:

TXT record name
default._domainkey

TXT record value
v=DKIM1; g=*; k=rsa; p=<content of default.public>

Note that the prefix “—–BEGIN PUBLIC KEY—–” and suffix “—–END PUBLIC KEY—-” should not be put in the TXT record value.

This DNS record will be retrieved by mail receivers who want to verify emails with DKIM signatures. The record name “default._domainkey” tells verifier that the “selector” of this signature is “default”, therefore if you are changing selector name to something else, make sure you change all of them consistently.

4. Install dkim-milter in Fedora

Run the following as root to install the dkim-milter pacakge.

yum install dkim-milter

5. Enable dkim-milter to run on start-up

Make sure dkim-milter service will run on start-up by running this command:

chkconfig --level 3 dkim-milter on

Note that your server may use a different “runlevel”. You can check “/etc/inittab” to see which run level you are on.

6. Move private key to appropriate location

As root, copy the private key to the location specified by the “keylist” (refer to next step) and make sure it is readable by dkim-milter:

mkdir /etc/dkim-milter/
mv default.private /etc/dkim-milter/default
chown dkim-milter.dkim-milter /etc/dkim-milter/default

Make sure the filename of private key file matches the “selector” name specified in the DNS record.

7. Add an entry to the keylist for dkim-milter to read

Add the following line to /etc/mail/dkim-milter/keys/keylist. Replace <domain.com> with your domain name.

*:<domain.com>:/etc/dkim-milter/default

8. Configure postfix to use dkim-milter

Add the following lines to /etc/postfix/main.cf to ask postfix to use dkim-milter.

smtpd_milters = unix:/var/run/dkim-milter/dkim-milter.sock
non_smtpd_milters = unix:/var/run/dkim-milter/dkim-milter.sock

9. Start dkim-milter and restart postfix

Start dkim-milter service and restart postfix using the following commands. Or restart the server.

service dkim-milter start
service postfix restart

10. Change file permissions of the Mail Filter Socket file

Change file permissions of the “Mail Filter Socket” file and its parent directory to allow postfix to write to it:

chmod 755 /var/run/dkim-milter
chmod 777 /var/run/dkim-milter/dkim-milter.sock

Changing dkim-milter.sock permission unfortunately is required EVERYTIME after dkim-milter servuce is restarted. This is because dkim-milter resets the file to mode 755 that postfix cannot read.

For Fedora, one way to have this done automatically is to add the chmod command in /etc/rc.d/rc.local, so that it will be run on start-up everytime.

Errors / Configuration Problems

Gmail header says “dkim=neutral (body hash did not verify)”

If you are sending emails using mail() function in php, these out-going emails will not be verified by Gmail, for some unknown reason. Opening the mail source in Gmail shows that there is a line “dkim=neutral (body hash did not verify)”, hinting that the key in DKIM signature does not match the public key from DNS. Only Gmail knows why.

You may also notice that sending emails directly from the command-line in your server will be DKIM-verified by Gmail, resulting in a “dkim=pass” in the mail source headers. Therefore, a work-around for this problem is to modify your php scripts so that it will do a system call to a shell script, which will indirectly send your email out. This way, Gmail will verify your email and put it to the inbox of recipient instead of marking it as spam.

Gmail header says “dkim=neutral (no key)”

It means that gmail couldn’t find a matching key to verify your signature.

So, how does gmail (or any other dkim verifier) find a matching key? It relies on the “selector name” from the email header. In the email header there should be something like “DKIM-Signature: … s=some_selector_name; t=1254783208;…”, here the “some_selector_name” is the selector name. Dkim-milter specified that as your selector name as instructed by /etc/mail/dkim-milter/keys/keylist file.

Now if you look at the DNS record for your domain, it needs to have a DKIM public key record (TXT type DNS record) with the name “some_selector_name._domainkey” and value being the matching public key. If the name of the record is not “some_selector_name._domainkey”, the verifier will not be able to use the public key, because the selector name does not match.

You might have followed an example from internet to set your selector name to “domain.com_default.key.pem” and the DNS record name to “default._domainkey”, which are not matching each other and therefore getting this no-key message.

Reference

• http://www.howtoforge.com/postfix-dkim-with-dkim-milter-centos5.1 Instructions similar to this article, but for CentOS instead of Fedora.
• http://testing.dkim.org/reflector.html Free testing to check if your DKIM implementation works.
• Config files related to dkim-milter in Fedora:

  Socket file that Postfix connects to
  /var/run/dkim-milter/dkim-milter.sock

  Key List file
  /etc/mail/dkim-milter/keys/keylist

  Actual private key (can be anywhere as specified by “Key List”)
  /etc/dkim-milter/<key filename>

  Config file
  /etc/mail/dkim-milter/dkim-filter.conf

  Another config file but does not appear to be read by the service
  /etc/sysconfig/dkim-milter

  Postfix config that specifies where dkim-milter socket is:
  /etc/postfix/main.cf