new release of postal

Today I have released a significant new version of my mail server benchmark Postal! The list of changes is below:

• Added new program bhm to listen on port 25 and send mail to /dev/null. This allows testing mail relay systems.
• Fixed a minor bug in reporting when compiled without SSL.
• Made postal write the date header in correct RFC2822 format.
• Removed the name-expansion feature, it confused many people and is not needed now that desktop machines typically have 1G of RAM. Now postal and rabid can have the same user-list file.
• Moved postal-list into the bin directory.
• Changed the thread stack size to 32K (used to be the default of 10M) to save virtual memory size (not that this makes much difference to anything other than the maximum number of threads on i386).
• Added a minimum message size option to Postal (now you can use fixed sizes).
• Added a Postal option to specify a list of sender addresses separately to the list of recipient addresses.
• Removed some unnecessary error messages.
• Handle EINTR to allow ^Z and "bg" from the command line. I probably don't handle all cases, but now that I agree that failure to handle ^Z is an error I expect bug reports.
• Made the test programs display output on the minute, previously they displayed once per minute (EG 11:10:35) while now it will be 11:10:00. This also means that the first minute reported will have something less than 60 seconds of data - this does not matter as a mail server takes longer than that to get up to speed.
• Added support for GNUTLS and made the Debian package build with it. Note that BHM doesn't yet work correctly with TLS.
• Made the programs exit cleanly.

Thanks to Inumbers for sponsoring the development of Postal.

I presented a paper on mail server performance at OSDC 2006 that was based on the now-released version of Postal.

I've been replying to a number of email messages in my Postal backlog, some dating back to 2001. Some of the people had changed email address during that time so I'll answer their questions in my blog instead.

/usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory
In file included from /usr/include/openssl/ssl.h:179

One problem reported by a couple of people is having the above error when compiling on an older Red Hat release (RHL or RHEL3). Running ./configure --disable-ssl should work-around that problem (at the cost
of losing SSL support). As RHEL3 is still in support I plan to fix this bug eventually.

There was a question about how to get detailed information on what Postal does. All three programs support the options -z and -Z to log details of what they do. This isn't convenient if you only want a small portion of the data but can be used to obtain any information you desire.

One user reported that options such as -p5 were not accepted. Apparently their system had a broken implementation of the getopt(3) library call used to parse command-line parameters.

email disclaimers

Andre Pang blogs about the annoyance of email disclaimers. For a while I had a .sig indicating that it was a condition of sending email to me that the sender agrees to legalistic terms in their .sig being inapplicable to me.

220 smtp.sws.net.au ESMTP Postfix - by sending email to this server you agree that any legalistic sig in your message does not apply to anyone who receives the message through this service.

Now I have changed my Postfix greeting to the above. Anyone who sends me mail agrees that their .sig does not apply to me. Suggestions for improvements to the above text are welcome.

more about MX records

In response to my previous post someone pointed out that MX records have an obvious benefit of offering multiple servers at different priority levels.

I don't believe that this is a benefit for many machines on the modern Internet. Most systems that have secondary MX records implement them poorly, they have less SPAM checks on the secondary MX server, and it often doesn't even have a canonical user-list! This is a really serious problem, spammers apparently often target the secondary MX server (I don't have evidence for this but many people assert it to be true and it would obviously work so is likely to be true) and it's well known that spammers often guess account names (a quick scan of the logs of any mail server will prove this). These factors combine to make a secondary MX server without a canonical list of user-names a serious spam problem, it will receive mail and then bounce it to innocent third parties (the vast majority of spam has a forged sender nowadays).

If you have the ability to run a well configured secondary MX server with a canonical list of valid account names (which must be maintained independently of the master mail server for obvious reasons) then there is the issue of why you would want to do so. What problem does it solve? In the early days of the Internet mail storage machines were often end-nodes on the network, many hops away from the central well-connected machines. This meant that sometimes connections would time-out or the hop count (which was smaller then than it is now) would be exceeded. Having a well connected server being a secondary MX server was a significant advantage for a small mail server in those times (by todays servers almost all the mail servers of 1993 are small and the biggest servers of 1993 were medium sized by today's standards).

I just did a quick search for machines with secondary MX records (IE multiple MX records at different priorities). The only significant mail service with such configuration that I could find was gmail. Hotmail.com, ibm.com, microsoft.com, aol.com, and zonnet.nl all have multiple MX records at the same priority - this is a cluster of primary mail servers not a primary/secondary configuration. The evidence suggests that mail servers such as hotmail.com do not benefit from a secondary MX record, so I doubt that any other domain needs it either.

In response to a comment on my previous post, I have previously mentioned in mailing lists the issue of spammers attacking secondary MX servers, but I couldn't see it when reviewing my blog archives.

Above is day 10 of the beard.

MX vs A record

One issue that has been the topic of some pointless discussion is whether a mail server should have an A record or an MX record. Mail can be delivered to a domain that has no MX record but simply an A record pointing to an IP address. But the most common practice is to have an MX record pointing to the name of the machine that serves the mail. A common use for this is to have a bulk mail hosting machine with multiple MX records pointing at it, which then allows you to have matching forward and reverse DNS entries for the machine name.

If you have no MX record for a domain then Postfix will do the following DNS requests:

IP postfix.34245 > DNS.domain:  3448+ MX? example.com. (32)
IP postfix.34261 > DNS.domain:  50123+ A? example.com. (32)

If you have an MX record then it does the following:

IP postfix.34675 > DNS.domain:  29942+ MX? example.com. (32)
IP postfix.34675 > DNS.domain:  33294+ A? mail.example.com. (37)

Now if there are multiple domains on a bulk mail hosting system then the A record might already be in a local cache on the sending machine, so having bulk mail hosting with MX records may reduce the number of DNS lookups, with the minumum number of lookups being half plus one.

If there is no bulk mail hosting then an MX record would still offer some slight benefits if the positive responses are cached for longer than negative responses. This would mean less lookups which gives faster and more reliable delivery of mail plus being more friendly to the net. I don't know what the cache behaviour is in this regard so I'm not sure if this would actually give a benefit (I'm sure someone will comment with the answer).

Now regardless of these issues I think that using an MX record is the better option. It's what most software expects and saves you from the excitement of discovering corner case bugs in various software that's out there on the net.