With Sendmail, I can block all email from (a sending domain to the server in question) and to a (foreign) domain using the /etc/mail/access file. However, apparently, it’s not so simple with qmail. Further complicating my need to prevent all users on one of my systems (which uses qmail) from sending email to certain domains is the fact that the system also uses Plesk, so I didn’t really want to start messing around with patching qmail and risk breaking something to do with Plesk.
After a fair bit of research I settled on a workaround using /var/qmail/control/smtproutes to artificially direct email sent to those domains from my qmail system to another mail server under my control, where the emails are rejected during the SMTP dialogue (because they’re not configured on that mail server, of course), thereby being bounced immediately to the sender.
If /var/qmail/control/smtproutes doesn’t exist on your server (it shouldn’t by default) you can create it with the following contents, or add the following contents to an existing file:
bad-domain.com:mx.your-other-domain.com
The file should be owned by the same user and group as most of the other configuration files in the “control” directory.
In this example you want to stop users from sending email to bad-domain.com email addresses, and you control an external mail server at mx.your-other-domain.com. When a user tries to send email to a bad-domain.com address, the sending mail server will not look up the MX record for bad-domain.com, instead routing the email to mx.your-other-domain.com. Because mx.your-other-domain.com is not configured to accept or relay email for bad-domain.com, it will reject it.
Caution: DO NOT route email to a mail server that is not yours. This will likely be considered spam by that mail server’s administrator, and the IP address of your mail server will then likely be blocked and perhaps added to more widely-distributed blacklists. If you don’t control another mail server you could route the forbidden email to a non-existent domain, such as no-such.domain or dev.null or bogus.invalid. To make the bounce message a little more helpful to the receiver (i.e., the original sender), perhaps make up a bogus domain like “Sending-to-that-domain-is.prohibited” which, on some systems, will return a bounce message that might include text like this:
Sorry, I couldn’t find any host named Sending-to-that-domain-is.prohibited.
Do not use a non-existent domain on a real top-level domain (e.g., v539bq59vb45.com, or some other string of randomly-typed characters followed by a real TLD), because there is no guarantee that domain won’t be registered and used in the future. Avoid using even your own real domain that you’re not using (unless you set up some unique but descriptive sub-domain such as “this-is-a-bogus-mx-vb49w4.example.com”), as you may use it in the future and forget that you’re directing email to it. That could result in mail loops if you end up hosting the domain on the same mail server, or being blacklisted if you host it with a third party or allow it to expire and it’s registered and used by someone else.
Anyway, having another mail server to use, I’m sticking with using that to cause the messages to bounce back.
Some assistance in coming up with this idea came from this thread at boardreader.com.
Have a comment or a better idea? Let me know in the comments.