We have a system running CentOS 5 with Plesk 8.6 and Qmail running. Our primary domain is hosted through Media Temple. When Plesk and Qmail are hosted on a single Dedicated Virtual server, it reads the primary server IP and domain and reports that when sending emails from the system.

Our pages are written in PHP so we are using the mail() function. While our email goes out to everybody, several enterprise email domains reject our email because it shows a different originating IP (our primary server IP and domain) than the domain we list in the 'from' address. This is not modifiable. Every domain we own of course does have its own IP as well underneath our primary server IP.

I have seen several places online that provide a patch, specifically - which allows Domain Binding:

"DomainBindings -- For servers that host multiple domains or have multiple IP addresses assigned to them, it is sometimes useful (or important) to have qmail use a specific IP address for its outgoing mail. By default, qmail uses whatever address the OS chooses for all outbound connections. With this patch, you can specify which address to use. It uses a control file similar to smtproutes to specify the outbound IP address to use, based on the sender's domain (local copy) (pyropus.ca)"

Qmail Link

First off I do not have netqmail installed so I'll need to find another source, but also I am completely unfamiliar with applying patches to qmail. Will I lose email services if I patch? Is it a simple apply and use process? Will my existing email accounts and data be restored after the patch?

I am very, very new to unix/linux so this does make me a bit nervous but I am the only person who can make the change and it is one our company "HAS" to have. Any ideas?

  • What bounce messages do these receiving hosts give? – sebix Jan 8 '15 at 19:34

This is typically addressed on the network layer, where all outbound SMTP would be source NAT'd to the same IP.

The definitive source for QMAIL's official distribution is Qmail.org, which is where you could acquire netqmail. netqmail is QMAIL packaged with recommended patches that were commonly applied, as there had not been an official release in a while.

There are numerous patches linked on QMAIL's web site, which change the interface binding behavior. I have successfully implemented this patch in a production environment before, which allows different domains to use different IPs.

The patch isn't documented that well but I have the following in my notes:

        IP addresses to be used on outgoing connections.   Each  line  has
        the  form fromdomain:localip, without any extra spaces.  If domain
        matches the domain part  in  sender,  qmail-remote  will  bind  to
        localip  when connecting to host.  If it matches, it will also set
        the HELO string to the domain part of sender.

Changing your MTA's behavior will likely be impacting in some way but how that impact affects your services is going to depend on your deployment plan. If nothing else, QMAIL will need to be restarted, which will briefly impact delivery.

Compiling from source and patching is slightly more advanced but if you are standardized on QMAIL and need this feature, you are not going to have many options unless you want to pay someone else to do it for you.

Your existing users and e-Mail should not be affected but if your QMAIL installation has other patches, such as those that allow authentication data to be stored in a database, you may need further patches to duplicate your existing functionality. If you are using "stock" QMAIL 1.03 it should be rather straight forward.


Some additions to Warner's advice (sorry but I don't have enough reputation to use the comment function):

  • The qmail setup that comes with Plesk is already highly patched, however Parallels offers the source as well as any patches applied together with rather good documentation in its knowledge base.

  • Beware: Patches that not only change the outgoing IP address but also the host name are considered harmful, if an IP shares more than one hostname. There a couple of MX hosts that stop receiving mails from hosts which connect using different HELO strings.

  • You're talking about qmail reading "the primary server IP and domain and reports that when sending emails from the system". In fact, those are different things. While choosing a different IP address for outgoing connections, you can simply set the hostname used for saying HELO in /var/qmail/control/me.

  • Regarding the problem itself: Please provide the exact error message you receive from target MX hosts, as I guess you're mixing up things here. It is perfectly acceptable to send mail from a different host than the host offering the website of a domain being its MX host. There is also no direct correlation between the HELO string and the 'from' address of a mail, unless the recipient implements some really brain-dead anti-spam "solution".

  • thank you for your reply here. I am just getting started but will get back to you with the specifics. Essentially, sending from one domain while the server lists another (every plesk/qmail owner has this problem) will flag the SPF record as a soft-fail or fail (never a pass). Matching the spf record is necessary to bypass even the most normal of spam filters (i.e. I cannot even email my own work email from our site because the spf records dont match). – JM4 Oct 13 '10 at 9:24

I have the same problem, i.e. I have a multi-homed host (6 IPs) and several domains binding to each IP.

Qmail uses a single hostname and IP address for the sending IP/Host but for hosts with multiple domains/IPs there are two issues:

  1. Some mail servers reject mail if the senders From field domain does not match whats in the envelope

  2. From a design view point Qmail should do by default what outgoingips does;

Plesk comes up with updates constantly and some of the updates are applied to Plesk's patches to qmail so one has to make sure nothing else breaks; if Qmail did this problem would not exist.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.