This is a collection of notes I’ve taken, primarily to help me remember how I solved certain problems when I deployed various server pieces.
qmail
qmail is a very secure, high-performance MTA. However, because of its extremely modular nature and lack of documentation, its deployment and configuration varies wildly from one installation to another.
I followed David Sill’s The qmail Handbook when I installed and configured qmail, so the information in this note should be considered within the context of that book.
Fixing the Queue When TMDA Goes Awry
Every now and again I get sent a message, almost always from a legitimate source, that makes TMDA spin in circles consuming massive amounts of CPU time.
Solution to “Fixing the Queue When TMDA Goes Awry”
These are very quick steps, so that next time it happens I have something to trigger my memory. I’ll probably never come back to clean this up. *sigh*
- Grep in /var/qmail/queue/info for a file containing the sender address on the ps -x line that persists (it'll be the one that initiated the TMDA/python process)
- Copy the file with the same name in /var/qmail/queue/mess/ so you can send it to the TMDA folks.
- Stop qmail. There might be some additional qmail processes that need to be killed; when I tried deleting the message files, they sort of reappeared.
- Kill the sucky TMDA process(es).
- Remove all files associated with the filename found above. (Files with same name in all subdirs of /var/qmail/queue/).
- Start qmail.
- Check /var/log/qmail/current to make sure qmail isn't complaining about anything.
Allowing Local Processes to Send Mail
A lesson learned in this was that it’s important to test the email-send capability with an email address not on the local machine! It’s entirely possible that everything is configured fine to send email to addresses in local domains, but not to remote addresses.
One problem I had was that my Java eCommerce engine was unable to send mail to domains not hosted on the same machine. I kept getting the dreaded “553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)” error. This was odd, because I had just recently tested the system by logging in and placing an order, for which it sent me a nice confirmation. But, that error kept showing up in the logs.
Now, as far as I knew, I had
properly configured qmail to allow the localhost
to send mail anywhere. I have a /etc/tcp.smtp file which controls what happens when connections occur
from specified addresses. In that file I had a line like
127.0.0.:allow,RELAYCLIENT=""
so it seemed obvious that anything on the local machine had free relaying capability. (I had installed the SMTP AUTH patch, so I was concerned that this was somehow interfering, but this turned out not to be the case.)
As it turned out, the problem was a little more subtle. My server has multiple IP addresses assigned (even thought it uses a single NIC). The Java process was send email by making a connection to the SMTP port, port 25. One not-so-helpful suggestion from the qmail list was to reconfigure the Java process to use qmail-inject or sendmail to send the message (this would have worked by placing the message directly in the queue, skipping the network connection and associated security involved in going through port 25). Unfortunately, this is a non-portable solution, as the standard Java mail API goes through port 25.
Instead, a more helpful person on the qmail list suggested I check to see just what the local
Java process was connecting to. He argued that if it was not connecting to 127.0.0.0/24, then
it would not be connecting from 127.0.0.0/24, and so the line in /etc/tcp.smtp would
be irrelevant. He was right. I’d have thought that the Linux network stack would be smart enough
to recognize that any connection to the localhost was a local connection, and route it accordingly.
I guess that was asking too much.
Solution to “Allowing Local Processes to Send Mail”
Add all of the machine’s local addresses to /etc/tcp.smtp, and
rebuild the cdb files.