Posts Tagged ‘qmailctl’

How to clean QMAIL mail server filled Queue with spam mail messages

Friday, June 8th, 2012

Sys Admins managing QMAIL mail servers know, often it happens QMAIL queue gets filled with unwanted unsolicated SPAM e-mails due to a buggy WEB PHP / Perl mail sendingform or some other odd reason, like too many bouncing messages ,,,,

For one more time I’ve experienced the huge SPAM destined mails queue on one QMAIL running on Debian GNU / Linux.

= … Hence I needed to clean up the qmail queue. For this there is a little tool written in PERL called qmhandle

A+) Download qmhandle;

Qmhandle’s official download site is in SourceForge

I’ve made also a mirror copy of QMHandle here

qmail-server:~# cd /usr/local/src
qmail-server:/usr/local/src# wget -q

As it is written in the program documentation one has to be very careful when cleaning the mail queue. Be sure to stop qmail with qmailctl or whatever script is used to shutdown any mail sever in progress operations, otherwise there is big chance the queue to mess up badly .

C#) Check extended info about the mail queue:

qmail-server:/usr/local/src/qmhandle-1.3.2# ./qmhandle -l -c
102 (10, 10/102) Return-path:
Subject: =?UTF8?B?QWNjb3VudCBpbmZvcm1hdGlvbiBmb3IgU09DQ0VSRkFNRQ==?=
Date: 1 Sep 2011 21:02:16 -0000
Size: 581 bytes
1136 (9, 9/1136)
Subject: Link Exchange Proposal /
Date: Fri, 2 Sep 2011 07:58:52 +0100 (BST)
Size: 1764 bytes
1103 (22, 22/1103)
Subject: =?UTF8?B?QWNjb3VudCBpbmZvcm1hdGlvbiBmb3IgU09DQ0VSRkFNRQ==?=
Date: 2 Sep 2011 00:36:11 -0000
Size: 578 bytes
Total messages: 1500 Messages with local recipients: 0
Messages with remote recipients: 1500
Messages with bounces: 500
Messages in preprocess: 300

D-) Delete the Queue
qmail-server:/usr/local/src/qmhandle-1.3.2# ./qmHandle -D

Fina1ly launch the qmail to continue normal oper.

qmail-server:~# qmailctl start

Share this on

How to exclude for a particular IP address in Qmail Mail server install / Fix to Thunderbird mail sent error (Exploitable Server See: error

Tuesday, November 1st, 2011

In the office, some of my colleagues has started receiving error messages, while trying to send mail with Thunderbird and Outlook Express
The exact error they handed to me reads like this:

An error occured while sending mail. The mail server responded: Exploitable Server See: Please check the message recipient

Here is also a screenshot, I’ve been sent via Skype with the error poping up on a Thunderbird installed on Windows host.

Typing the url lead me to to a page saying that the IP address of the mail client which is trying to send mail is blacklisted . This is not strange at all condireng that many of the office computers are running Windows and periodically get infected with Viruses and Spyware which does sent a number of Unsolicated Mail (SPAM).

The record for the IP seems to be an old one, since at the present time the office network was reported to be clear from malicious SMTP traffic.

The error disallowing the mail clients to send from the office continued for already 3 days, so something had to be done.

We asked the ISP to change the blacklisted IP address of xx.xx.xx.xx , to another one but they said it will take some time and they can’t do it in a good timely matter, hence to make mail sending work again with POP3 and IMAP protocols from the blacklisted IPs I had to set in the Qmail install to not check the xx.xx.xx.xx IP against mail blacklisting databases.

On qmail install disabling an IP check in RBLSMTPD is done through editting /etc/tcp.smtp and following recreate of /etc/tcp.smtp.cdb – red by qmailctl script start.
The exact line I put in the end of /etc/tcp.smtp to disable the RBLSMTPD check is:


Further on to recreate /etc/tcp.smtp.cdb and reload the new cdb db records:

qmail:~# qmailctl cdb
qmail:~# qmailctl restart

Onwards, the IP blacklist issue was solved and all office computers from xx.xx.xx.xx succeeded in sending mails via SMTP.

Share this on

Fix to mail forwarding error “Received-SPF: none ( domain at maildomain does not designate permitted sender hosts)

Tuesday, October 18th, 2011

I’m Configuring a new Exim server to relay / forward mail via a remote Qmail SMTP server
Even though I configured properly the exim to forward via my relaying mail server with host, still the mail forwarding from the Exim -> Qmail failed to work out with an error:

Fix to mail forwarding error "Received-SPF: none ( domain at maildomain does not designate permitted sender hosts)

I pondered for a while on what might be causing this “mysterous” error just to realize I forgot to add the IP address of my Exim mail server in the Qmail relay server

To solve the error I had to add in /etc/tcp.smtp on my Qmail server a record for my Exim server IP address xx.xx.xx.xx, like so:

debian-server:~# echo 'xx.xx.xx.xx:allow,RELAYCLIENT="",QS_SPAMASSASSIN="0"' >> /etc/tcp.smtp

The QS_SPAMASSASSIN=”0″ as you might have guessed instructs Qmail not to check the received mails originating from IP xx.xx.xx.xx with spamassassin.

Finally on the Qmail server to load up the new tcp.smtp settings I had to rebuild /etc/tcp.smtp.cdb and restart qmail :

– reload qmail cdb

linux-server:/var/qmail# qmailctl cdb
Reloaded /etc/tcp.smtp.
- restart qmail

linux-server:/var/qmail# qmailctl restart
Restarting qmail:
* Stopping qmail-smtpdssl.
* Stopping qmail-smtpd.
* Sending qmail-send SIGTERM and restarting.
* Restarting qmail-smtpd.
* Restarting qmail-smtpdssl.

This solved the issue and now mails are forwarded without problems via the Qmail SMTPD.

Share this on

How to fix “sslserver: fatal: unable to load certificate” Qmail error on GNU / Linux

Friday, October 14th, 2011

After setupping a brand new Qmail installation following the QmailRocks Thibs Qmail Debian install guide , I’ve come across unexpected re-occuring error message in /var/log/qmail/qmail-smtpdssl/ , here is the message:

@400000004e9807b10d8bdb7c command-line: exec sslserver -e -vR -l -c 30 -u 89 -g 89
-x /etc/tcp.smtp.cdb 0 465 rblsmtpd -r -r -r -r qmail-smtpd /home/vpopmail/bin/vchkpw /bin/true 2>&1
@400000004e9807b10dae2ca4 sslserver: fatal: unable to load certificate

I was completely puzzled initially by the error as the sertificate file /var/qmail/control/servercert.pem was an existing and properly self generated one. Besides that qmail daemontools init script /service/qmail-smtpd/run was loading the file just fine, where the same file failed to get loaded when sslserver command with the cert argument was invoked via /service/qmail-smtpdssl/run

It took me quite a while to thoroughfully investigate on what’s wrong with the new qmail install. Thanksfully after almost an hour of puzzling I found it out and I was feeling as a complete moron to find that the all issues was caused by incorrect permissions of the /var/qmail/control/servercert.pem file.
Here are the incorrect permissions the file possessed:

linux:~# ls -al /var/qmail/control/servercert.pem
-rw------- 1 qmaild qmail 2311 2011-10-12 13:21 /var/qmail/control/servercert.pem

To fix up the error I had to allow all users to have reading permissions over servercert.pem , e.g.:

linux:~# chmod a+r /var/qmail/control/servercert.pem

After adding all users readable bit on servercert.pem the file permissions are like so:

linux:~# ls -al /var/qmail/control/servercert.pem
-rw-r--r-- 1 qmaild qmail 2311 2011-10-12 13:21 /var/qmail/control/servercert.pem

Consequently I did a qmail restart to make sure the new readable servercert.pem will get loaded from the respective init script:

linux:~# qmailctl restart
* Stopping qmail-smtpdssl.
* Stopping qmail-smtpd.
* Sending qmail-send SIGTERM and restarting.
* Restarting qmail-smtpd.
* Restarting qmail-smtpdssl.

Now the annoying sslserver: fatal: unable to load certificate message is no more and all works fine, Hooray! 😉

Share this on

Fix 503 AUTH first (#5.5.1) mail receive errors in Qmail

Friday, September 2nd, 2011

I have one qmail rocks install based on Thibbs Qmalrocks tutorial

I had to do some changes, to:
/etc/service/qmail-smtpd/run and /etc/service/qmail-smtpdssl/run init scripts.

After a qmail restart suddenly qmail stopped receiving any mail messages and my sent messages was returned with an error:

Connected to but sender was rejected.
Remote host said: 503 AUTH first (#5.5.1)

After investigating the issue I finally found, that one value I’ve changed in /etc/service/qmail-smtpd/run and /etc/service/qmail-smtpdssl was causing the whole mess:

The problematic variable was:


To solve the issue I had to disable the value which it seems, I have enabled by mistake.

Below is a quote from which explains what REQUIRE_AUTH shell variable does:

Setting REQUIRE_AUTH=1 will make the service not accept ANY mail unless the client has sent a valid AUTH command. This also prevents incoming mail from being accepted for your own domains, so do not use this setting if the service is accepting “normal” mail from the outside world.
Restarting via qmailctl restart and qmail started receiving messages normal 😉

Share this on

How to renew self signed QMAIL toaster and QMAIL rocks expired SSL pem certificate

Friday, September 2nd, 2011


One of the QMAIL server installs, I have installed very long time ago. I've been notified by clients, that the certificate of the mail server has expired and therefore I had to quickly renew the certificate.

This qmail installation, SSL certificates were located in /var/qmail/control under the names servercert.key and cervercert.pem

Renewing the certificates with a new self signed ones is pretty straight forward, to renew them I had to issue the following commands:

1. Generate servercert encoded key with 1024 bit encoding

debian:~# cd /var/qmail/control
debian:/var/qmail/control# openssl genrsa -des3 -out servercert.key.enc 1024
Generating RSA private key, 1024 bit long modulus
e is 65537 (0x10001)
Enter pass phrase for servercert.key.enc:
Verifying - Enter pass phrase for servercert.key.enc:

In the Enter pass phrase for servercert.key.enc I typed twice my encoded key password, any password is good, here though using a stronger one is better.

2. Generate the servercert.key file

debian:/var/qmail/control# openssl rsa -in servercert.key.enc -out servercert.key
Enter pass phrase for servercert.key.enc:
writing RSA key

3. Generate the certificate request

debian:/var/qmail/control# openssl req -new -key servercert.key -out servercert.csr
debian:/var/qmail/control# openssl rsa -in servercert.key.enc -out servercert.key
Enter pass phrase for servercert.key.enc:writing RSA key
root@soccerfame:/var/qmail/control# openssl req -new -key servercert.key -out servercert.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [AU]:UK
State or Province Name (full name) [Some-State]:London
Locality Name (eg, city) []:London
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company
Organizational Unit Name (eg, section) []:My Org
Common Name (eg, YOUR name) []:
Email Address []

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

In the above prompts its necessery to fill in the company name and location, as each of the prompts clearly states.

4. Sign the just generated certificate request

debian:/var/qmail/control# openssl x509 -req -days 9999 -in servercert.csr -signkey servercert.key -out servercert.crt

Notice the option -days 9999 this option instructs the newly generated self signed certificate to be valid for 9999 days which is quite a long time, the reason why the previous generated self signed certificate expired was that it was built for only 365 days

5. Fix the newly generated servercert.pem permissions debian:~# cd /var/qmail/control
debian:/var/qmail/control# chmod 640 servercert.pem
debian:/var/qmail/control# chown vpopmail:vchkpw servercert.pem
debian:/var/qmail/control# cp -f servercert.pem clientcert.pem
debian:/var/qmail/control# chown root:qmail clientcert.pem
debian:/var/qmail/control# chmod 640 clientcert.pem

Finally to load the new certificate, restart of qmail is required:

6. Restart qmail server

debian:/var/qmail/control# qmailctl restart
Restarting qmail:
* Stopping qmail-smtpd.
* Sending qmail-send SIGTERM and restarting.
* Restarting qmail-smtpd.

Test the newly installed certificate

To test the newly installed SSL certificate use the following commands:

debian:~# openssl s_client -crlf -connect localhost:465 -quiet
depth=0 /C=UK/ST=London/L=London/O=My Org/OU=My Company/
verify error:num=18:self signed certificate
verify return:1
debian:~# openssl s_client -starttls smtp -crlf -connect localhost:25 -quiet
depth=0 /C=UK/ST=London/L=London/O=My Org/OU=My Company/
verify error:num=18:self signed certificate
verify return:1

If an error is returned like 32943:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:607: this means that SSL variable in the qmail-smtpdssl/run script is set to 0.

To solve this error, change SSL=0 to SSL=1 in /var/qmail/supervise/qmail-smtpdssl/run and do qmailctl restart

The error verify return:1 displayed is perfectly fine and it's more of a warning than an error as it just reports the certificate is self signed.

Share this on

How to fix a broken QMAIL queue with queue-repair and qmhandle

Friday, May 27th, 2011

How qmail works, qmail queue picture :)

The aim of this small post is to give just a brief idea of how I fix my qmail server after breaking it or in case it is broken after mail bomb attacks, etc.

Most common cases when I break my qmail queue myself, are after I’m implementing some new patches and reinstall parts of the qmail server with a patched version of default qmail binaries.
On other occasions, I simply used the qmailctl to start or stop the server as a part of some routine tasks necessery for the administration of the qmail server.

Everybody who has already experience with qmail should have experienced, that qmail is very fragile and could break even with a simple changes, though if it works once it’s rock solid piece of mail servant.

Below I explain few ways I used through my days as a qmail sys admin to deal with broken or messed queues.

1. Fixing a broken qmail queue using automatic tools There are few handy tools which in most cases are able to solve issues with the queue, one very popular one isqueue-repair – check
Installation of qmail-repair is dead easy, but it needs to be installed from source as no official debian package is available:

linux:/usr/local/src# wget
linux:/usr/local/src# tar -xzvvf queue-repair-0.9.0.tar.gzdrwxr-xr-x charlesc/qcc 0 2003-10-22 16:54 queue-repair-0.9.0/
-rw-r--r-- charlesc/qcc 268 2003-10-22 16:54 queue-repair-0.9.0/TODO
-rw-r--r-- charlesc/qcc 1700 2003-10-22 16:54 queue-repair-0.9.0/CHANGELOG
-rw-r--r-- charlesc/qcc 18007 2003-10-22 16:54 queue-repair-0.9.0/COPYING
-rw-r--r-- charlesc/qcc 1098 2003-10-22 16:54 queue-repair-0.9.0/BLURB
-rwxr-xr-x charlesc/qcc 26286 2003-10-22 16:54 queue-repair-0.9.0/

To check if there are issues fixable within the qmail queue it’s as easy as:

linux:/usr/local/src# cd queue-repair-0.9.0
linux:/usr/local/src/queue-repair-0.9.0# ./queue-repair -t
checking files...
checking queue/mess files...
checking split locations...

The tool will walk through the mail sub-directories containing mail queued files in /var/qmail/queue and will list any issues found.
It’s recommended that the qmail server is stopped before any queue modify operations are issued on the server:

linux:/usr/local/src# qmailctl stop

Further on in order to solve any found issues with the queue, there is the “-r”/repair option:

linux:/usr/local/src/queue-repair-0.9.0# ./queue-repair -r

Another tool which comes handy whether a repair of a messed qmail queue is needed is qmhandle

The use of qmhandle is also pretty easy, all one has to do is to follow the usual classical steps of a download the source & compile:

linux:/usr/local/src# wget
linux:/usr/local/src# tar -zxvvf qmhandle-1.3.2
linux:/usr/local/src# cd qmhandle-1.3.2

Once again it’s necessery that the qmail server is stopped via its init script before qmHandle tool is used, e.g.:

linux:~# qmailctl stop

There is a difference between qmail queue repair tool and qmail handle , while qmail queue-repair tool is used to fix improper permissions of queued files with the qmail queue, qmhandle ‘s application is to completely delete the stored mail contents of a broken queue.

Deleting all the qmail queue content is in some cases the only option to fix the queue.
Often such a drastic measure is required after a heavy mail server overload, let’s say a result of spammers or caused by virus infected mail users which send a massive amounts of spam mails.

Thus at many cases when queue-repair was unable to solve a queue mess, I use qmhandble and sacrifice all the queued emails by completely wiping them out like so:

linux:/usr/local/src/qmhandle-1.3.2# ./qmhandle -D

Above command would eradicate all queued emails. Hopefully after the qmail server gets launched again with qmailctl start all the mail server operations should be back to normal.

Note that the use of qmhandle’s queue delete capabilities is pretty dangerous, if you forgot to stop the qmail server before issuing the above command!

Note that in order to use both qmHandle and queue-repair tools you will need to install python interpreter as both of the tools are written in python.

To check what is currently in the queue in Qmail, there are also native tools available, as you should probably know if you have dealt with qmail, e.g.:

debian:~# qmail-qstat
debian:~# qmail-qstat
messages in queue: 2
messages in queue but not yet preprocessed: 0

Often when there are problems with Qmail and more specificly with qmail server queue the qmail-qstat command does show messages in queue, however when an attempt to check what kind of messages are in the queue with qmail-qread no messages are shown, for instance below you see an example of that, even though qmail-qstat claims 2 messages are in the queue, qmail-qread is unable to list the messages:

debian:~# qmail-qread

If all is fine with qmail queue above’s qmail-qread command should have returned something similar to:

debian:~# qmail-qread
26 May 2011 07:46:47 GMT #659982 3517 <>
26 May 2011 07:46:47 GMT #659983 3517 <>

2. Fixing qmail queue manually This is very dangerous initiative, so before you try anything, make sure that you know what you’re doing, the possibility that you make the situation worst if you attempt to tamper manually the qmail queue is quite high 🙂

However if you’re still convinced to try fixing it manually, take a look at /var/qmail/queue it’s very likely that there are permission issues with some of the queued files, in order to fix the situation it’s necessery that the following directories:


gets explored with midnight commander / mc or some kind of convenient file explorer.

If there are queued files owned by users different from qmailq and user group qmail , for instance if owned by the root user, a simple chown qmailq:qmail to the wrong permissions file, should be able to resolve the issues.

Apart from all I explain above, there are many other ways suggested online on howto clean a qmail queue, one very popular one is using James’s qfixq shell script.

This script as of this very date is not working on Debian based systems, the script is dedicated initially to run on Fedora and Redhat based Linuces

Moreover myy experience with qfixq was never successful.

One very important note which is often a cause of many problems, is always make sure you stop and start the qmail server with an interval of at least of 10 seconds.

I’ve managed many servers which after an immediate (undelayed) qmailctl stop and qmailctl start was unable to run the whole engine of the qmail server (and either email sending or email receiving was not properly working) afterwards.

In that cases many weird behaviours are common, consider this seriously if you deal with the qmail-queue, it might happen that even if you have fixed your qmail queue, after a restart the qmail might breaks up.
I’ve experienced this kind of oddities numerous times, thus when I do changes to qmail I always make sure I restart the server a couple of times (at least 5 times 😉 ) always with a good delay between the HUPs.

And as always with qmail prayer is always needed, this server is complex, you never know what will happen next 🙂

Share this on

How to fix “delivery 1: deferral: Sorry,_message_has_wrong_owner._(#4.3.5)/” qmail mail delivery failure message

Friday, May 20th, 2011

After a failed attempt to enable some wrapper scripts to enable domain keys support in a qmail powered mail server my qmail server suddenly stopped being able to normally send mail.

The exact error message which was logged in /var/log/qmail/current was:

@400000004dd66fcc16a088ac delivery 1: deferral: Sorry,_message_has_wrong_owner._(#4.3.5)/

This qmail messed happened after I substituted /var/qmail/bin/qmail-queue and /var/qmail/bin/qmail-remote with two respective wrapper shell scripts which were calling for the original qmail-queue and qmail-remote binaries under the names qmail-queue.orig and qmail-queue.orig

Restoring back qmail-queue.orig to /var/qmail/bin/qmail-queue and qmail-remote.orig to /var/qmain/bin/qmail-remote and restarting the mail server broke my qmail install.

After a bunch of nerves trying to isolate what is causing the error I found out that by mistake I forgot to copy the qmail-queue and qmail-remote permissions and ownership.

Thus I had to check another qmail working installation’s permissions for both binaries and fix the permissions to be equivalent to the permissions:

debian:~# ls -al /var/qmail/bin/qmail-remote
-rwx–x–x 1 root qmail 50464 2011-05-20 12:56 /var/qmail/bin/qmail-remote*
debian:~# ls -al /var/qmail/bin/qmail-queue
-rws–x–x 1 qmailq qmail 20392 2011-05-20 12:56 /var/qmail/bin/qmail-queue*

The exact chmod and chmod commands I issued to solve the shitty issues were as follows:

First I fixed the qmail-queue and qmail-remote ownership:

debian:~# chown qmailq:qmail /var/qmail/bin/qmail-queue
debian:~# chown root:qmail /var/qmail/bin/qmail-remote

Second I set the proper file permissions:

# make the qmail-queue binary suid
debian:~# chmod u+s /var/qmail/bin/qmail-queue
debian:~# chmod 611 /var/qmail/bin/qmail-queue
debian:~# chmod 611 /var/qmail/bin/qmail-remote

Third and last I did a restart of the qmail server and tested it sends properly

debian:~# /usr/bin/qmailctl stop
Stopping qmail...
debian:~# /usr/bin/qmailctl start
Starting qmail

Finally to test that the qmail server qmail-queue was queing and sending with qmail-remote I used the system mail command like so:

debian:~# mail -s "test email"

Afterwards the mail was properly received on my mail account immediately.

In my /var/log/qmail/current log file all seemed fine:

@400000004dd6702a2eb2b064 starting delivery 1: msg 85281596 to remote
@400000004dd6702a2eb2b834 status: local 0/20 remote 1/20
@400000004dd6702b34cc809c delivery 1: success:
@400000004dd6702b34cc886c status: local 0/20 remote 0/20
@400000004dd6702b34cc8c54 end msg 85281596

The test mail was properly received on my mail account immediately.

It took me like half an hour to figure out what exactly is wrong with the permissions in situations like this I really wanted to change all my qmail installs with postfix and forget forever I ever used qmail …

Share this on