Posts Tagged ‘Qmail’

Linux Send Monitoring Alert Emails without Mail Server via relay SMTP with ssmtp / msmtp

Friday, July 10th, 2020


If you have to setup a new Linux server where you need to do a certain local running daemons monitoring with a custom scripts on the local machine Nagios / Zabbix / Graphana etc. that should notify about local running custom programs or services in case of a certain criteria is matched or you simply want your local existing UNIX accounts to be able to send outbound Emails to the Internet.

Then usually you need to install a fully functional SMTP Email server that was Sendmail or QMAIL in old times in early 21st century andusually postfix or Exim in recent days and configure it to use as as a Relay mail server some Kind of SMTP.

The common Relay smtp setting would be such as Google's, Yahoo!'s relay host, or External configured MTA Physical server with proper PTR / MX records or a SMTP hosted on a virtual machine living in Amazon's AWS or m$ Azure that is capable to delivere EMails to the Internet.

Configuring the local installed Mail Transport Agent (MTA) as a relay server is a relatively easy task to do but of course why should you have a fully stacked MTA service with a number of unnecessery services such as Email Queue, Local created mailboxes, Firewall rules, DNS records, SMTP Auth, DKIM keys etc. and even the ability to acccept any emails back in case if you just want to simply careless send and forget with a confirmation that remote email was send successfully?

This is often the case for some machines and especially with the inclusion of technologies such as Kubernettes / Clustered environments / VirtualMachines small proggies such as ssmtp / msmtp that could send mail without a Fully functional mail server installed on localhost ( ) is true jams.

ssmtp program is Simple Send-only sendMail emulator  has been around in Debian GNU / Linux, Ubuntu, CentOS and mostly all Linuxes for quite some a time but recently the Debian package has been orphaned so to install it on a deb based server host you need to use instead msmtp.

1. Install ssmtp on CentOS / Fedora / RHEL Linux

In RPM distributions you can't install until epel-release repository is enabled.

[root@centos:~]# yum –enablerepo=extras install epel-release

[root@centos:~]# yum install ssmtp

2. Install ssmp / msmtp Debian / Ubuntu Linux

If you run older version of Debian based distribution the package to install is ssmtp, e.g.:

root@debian:~# apt-get install –yes ssmtp

On Newer Debians as of Debian 10.0 Buster onwards install instead

root@debian:~# apt install –yes msmtp-mta

can save you a lot of effort to keep an eye on a separately MTA hanging around and running as a local service eating up resources that could be spared.

3. Configure Relay host for ssmtp

A simple configuration to make ssmtp use SMTP servers as a relay host below:

linux:~# cat << EOF > /etc/ssmtp/ssmtp.conf
# /etc/ssmtp/ssmtp.conf
# The user that gets all the mails (UID < 1000, usually the admin)
# The full hostname.  Must be correctly formed, fully qualified domain name or GMail will reject connection.
# The mail server (where the mail is sent to), both port 465 or 587 should be acceptable
# See also

# The address where the mail appears to come from for user authentication.
# Email 'From header's can override the default domain?


# Username/Password
# Use SSL/TLS before starting negotiation
logfile        ~/.msmtp.log


This configuration is very basic and it is useful only if you don't want to get delivered mails back as this functionality is also supported even though rarely used by most.

One downside of ssmtp is mail password will be plain text, so make sure you set proper permissions to /etc/ssmtp/ssmtp.conf

– If your Gmail account is secured with two-factor authentication, you need to generate a unique App Password to use in ssmtp.conf. You can do so on your App Passwords page. Use Gmail username (not the App Name) in the AuthUser line and use the generated 16-character password in the AuthPass line, spaces in the password can be omitted.

– If you do not use two-factor authentication, you need to allow access to unsecure apps.

4. Configuring different msmtp for separate user profiles

SSMTP is capable of respecting multiple relays for different local UNIX users assuming each of whom has a separate home under /home/your-username

To set a certain user lets say georgi to relay smtp sent emails with mail or mailx command create ~/.msmtprc


linux:~# vim ~/.msmtprc

Append configuration like:

# Set default values for all following accounts.
port 587
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
account gmail
from <user>
auth on
user <user>
passwordeval gpg –no-tty -q -d ~/.msmtp-gmail.gpg
# Set a default account

account default : gmail

To add it for any different user modify the respective fields and set the different Mail hostname etc.

5. Using mail address aliases

msmtp also supports mail aliases, to make them work you will need to have file /etc/msmptrc with

aliases               /etc/aliases

Standard aliasses them should work 

linux:~# cat /etc/aliases
# Example aliases file
# Send root to Joe and Jane
# Send everything else to admin
default: admin@domain.example


6. Get updated when your Debian servers have new packages to update 

msmpt can be used for multiple stuff one example use would be to use it together with cron to get daily updates if there are new debian issued security or errata update pending packages, to do so you can use the apticron shell script.

To use it on debian install the apticron pack:

root@debian:~# apt-get install –yes apticron

apticron has the capability to:

 * send daily emails about pending upgrades in your system;
 * give you the choice of receiving only those upgrades not previously notified;
 * automatically integrate to apt-listchanges in order to give you by email the
   new changes of the pending upgrade packages;
 * handle and warn you about packages put on hold via aptitude/dselect,
   avoiding unexpected package upgrades (see #137771);
 * give you all these stuff in a simple default installation;


To configure it you have to place a config copy the one from /usr/lib/apticron/apticron.conf to /etc/apticron/apticron.conf

The only important value to modify in the config is the email address to which an apt-listchanges info for new installable debs from the apt-get dist-upgrade command. Output from them will be be send to the configured EMAIL field  in apticron.conf.


The timing at which the offered new pending package update reminder will be sent is controlled by /etc/cron.d/apticron

debian:~# cat /etc/cron.d/apticron
# cron entry for apticron

48 * * * * root if test -x /usr/sbin/apticron; then /usr/sbin/apticron –cron; else true; fi

apticron will use the local previous ssmtp / msmpt program to deliver to configured mailbox.
To manually trigger apticron run:

root@debian:~# if test -x /usr/sbin/apticron; then /usr/sbin/apticron –cron; else true; fi

7. Test whether local mail send works to the Internet

To test mail sent we can use either mail / mailx or sendmail command or some more advanced mailer as alpine or mutt.

Below is few examples.

linux:~$ echo -e "Subject: this is the subject\n\nthis is the body" | mail

To test attachments to mail also works run:

linux:~$ mail -s "Subject" < mail-content-to-attach.txt


Prepare the mail you want to send and send it with sendmail

linux:~$ vim test-mail.txt
Subject: Test Email
This is a test mail.

linux:~$ sendmail -t < test-mail.txt

Sending encoded atacchments with uuencode is also possible but you will need sharutils Deb / RPM package installed.

To attach lets say 2 simple text files uuencoded:

linux:~$ uuencode file.txt myfile.txt | sendmail

echo "

To: From: Subject: A test Hello there." > test.mail

linux:~$ cat test.mail | msmtp -a default <username>

That's all folks, hope you learned something, if you know of some better stuff like ssmtp please shar e it.

How to solve qmail-inject: fatal: qq temporary problem (#4.3.0) Qmail and Qmail Scanner problems on Debian Linux Wheezy

Monday, October 16th, 2017


Below QMAIL error

qmail-inject: fatal: qq temporary problem (#4.3.0)

occured to me right after upgraded from Debian Linux Squeeze 6 to Debian 7 Wheezy,

qmail-inject: fatal: qq temporary problem (#4.3.0) is really terrible error and I only experienced that error in my Thunderbird during sending mails, mail receiving doesn't work either, so as normally when there are problems with Qmail its a lot of puzzling until you get it.

There is no even trace in logs on what might be causing it, strangely enough nothing in qmail-smtpd, qmail-send logs, the mail server and all components seemed to work perfectly fine I checked whether there are libraries that are missing with a small loop line as follows:


root@pcfreak:/var/log/qmail/qmail-smtpd# for i in $(ls -1 /var/qmail/bin/*); do ldd $i |grep -i "not found"; done


The absence of result indicates, all binaries are properly linked and no found mmissing libraries.

After investigating closely what might be wrong and reading comments on Thibs QmailRocks Install Qmail-Scanner page, I realied
the error might be caused, because of problems with suid perl, as I already checked my earlier post in which I seemed to have faced the same qmail-inject: fatal: qq temporary problem (#4.3.0) error on Debian Wheezy and explained the possible reasons what might be causing the qq qmail error  here as well


and a related issue I experienced earlier with qmail scanner unable to create files in previous article here Suid Perl no longer available as a package and therefore because of the inability of perl to run as root anymore in Debian Wheezy, script did not work either.

root@pcfreak:/downloads/simscan-1.4.0# 320  echo "hi, testing." > /tmp/mailtest.txt
root@pcfreak:/downloads/simscan-1.4.0# env QMAILQUEUE=/var/qmail/bin/qmail-scanner-queue /var/qmail/bin/qmail-inject < /tmp/mailtest.txt
qmail-inject: fatal: qq permanent problem (#5.3.0)

root@pcfreak:/downloads/simscan-1.4.0# /var/qmail/bin/qmail-scanner-queue



A short note to make here is qmail-scanner-queue and are set with suid bit set as follows:

root@pcfreak:/home/hipo/info# ls -al /var/qmail/bin/{qmail-scanner-queue,}
-rwsr-sr-x 1 qscand qscand   6814 окт 14 17:22 /var/qmail/bin/qmail-scanner-queue*
-rwsr-sr-x 1 qscand qscand 158880 окт 14 23:52 /var/qmail/bin/*

Good to say here is qmail-scanner-queue is a suid wrapper binary that actually invokes

root@pcfreak:/downloads/simscan-1.4.0# su hipo
hipo@pcfreak:/downloads/simscan-1.4.0$ /var/qmail/bin/ -g
perlscanner: generate new DB file from /var/spool/qscan/quarantine-events.txt
hipo@pcfreak:/downloads/simscan-1.4.0$ exit

root@pcfreak:/downloads/simscan-1.4.0# cp /downloads/qmail-scanner-2.11st/contrib/logrotate.qmail-scanner /etc/logrotate.d/qmail-scanner
root@pcfreak:/downloads/simscan-1.4.0# chmod 644 /etc/logrotate.d/qmail-scanner
root@pcfreak:/downloads/simscan-1.4.0# cd /downloads/qmail-scanner-2.11st/contrib
root@pcfreak:/downloads/qmail-scanner-2.11st/contrib# chmod 755
root@pcfreak:/downloads/qmail-scanner-2.11st/contrib# ./ -doit
Sending standard test message – no viruses… 1/4
qmail-inject: fatal: qq temporary problem (#4.3.0)
Bad error. qmail-inject died

This are the other things, I've done to fix possible permission issues

root@pcfreak:/downloads/qmail-scanner-2.11st/contrib#  sudo -u qscand /var/qmail/bin/ -z
root@pcfreak:/downloads/qmail-scanner-2.11st/contrib# chown qscand:qscand /var/spool/qscan/qmail-scanner-queue-version.txt

In /etc/sudoers add following lines:

root@pcfreak:~# vim /etc/sudoers

ALL ALL=(qscand) NOPASSWD: /var/qmail/bin/
##necroleak ALL=(ALL) ALL

root@pcfreak:/downloads/qmail-scanner-2.11st/contrib# cat /etc/sudoers

# /etc/sudoers
# This file MUST be edited with the 'visudo' command as root.
# See the man page for details on how to write a sudoers file.

Defaults    env_reset

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL) ALL
hipo    ALL=(ALL) ALL
ALL ALL=(qscand) NOPASSWD: /var/qmail/bin/
##necroleak ALL=(ALL) ALL
# Allow members of group sudo to execute any command
# (Note that later entries override this, so you might need to move
# it further down)
%sudo ALL=(ALL) ALL
#includedir /etc/sudoers.d

In case you wonder why we put the line in /etc/sudoers:


The reason behind this is that by default sudo resets the environment variables when executing the command. Thus qmail-scanner cannot recognize the important info regarding the incoming mail and treats everything as coming from localhost, which leads to passing everything without scanning. The above line preserves the important ENV variables for qmail-scanner.

In /etc/sudoers add following lines:

root@pcfreak:/downloads/qmail-scanner-2.11st/contrib# vim /var/qmail/bin/

Right after comments or in Line 1  ADD

my $real_uid="qscand";

my $effective_uid="qscand";

Also somewhere in the beginning of scripts lets say after above two variable declarations add:

$whoami = getpwuid($<) || "unknown";
if($whoami ne "qscand") {
    exec("/usr/bin/sudo -u qscand /var/qmail/bin/") || die;

To prevent your users logged in on physical console and via SSH it is necessery to disable emergency logs for users in syslog / rsyslog, otherwise due to bug, users will logged in will get flooded with messages such as:

Message from syslogd@pcfreak at Oct 15 16:43:04 … qmail-scanner[6834]: Clear:RC:0( 2.959242 10574 Светлана_Георгиева_оставила_Вам_личное_соо� <36b63ec9a0ce7ecc570de2fcbba6ed73@localhost.localdomain> 1508074981.6836-1.pcfreak:6219 1508074981.6836-0.pcfreak:545


open /etc/rsyslog.conf and find the line starting with:

root@pcfreak:~# vim /etc/rsyslog.conf



right after it so it reads like:


Installation and Configuration of Clamav antivirus on Debian GNU / Linux

Monday, September 9th, 2013

Clamav logo installing Clamav antivirus to scan periodically Debian server websites for viruses

Clamav Antivirus is one of must have packages installed on a new Debian Linux server. It is not only necessary whether configuring a new Mail server be it Qmail or Postfix but is good to have to always check files on a Webserver. Until few years infecting of Sites with Viruses / Installing WebShells or Backdooring for further access using Perl or PHP vulnerable PHP code was not so common, However nowadays with increase of complexity of languages and increase of not security minded programmers this possibility dramatically increaed. Thus nowadays, whether I configure a new Apache + PHP + CGI support server I always install Clamav AV. Some might argue that Clamav Virus definitions are still too little compared to proprietary solutions like BitDefender / AVG or Avast but since my experience with this under Linux is not so bright as well as Clamav captures essential Viruses and Backdoors I still prefer to keep on with Clamav.  Even on home Desktops with Linux clamav is of use as there are plenty of free-ware software for Linux which come only distributed only in a binary form and hence its good to check them with clamav before use whether they don't contain some well known Rootkit or Virus. Over the years Clamav has done great job for me whether I had to clean up "hacked" hosts containing  script kiddie exploit scanners or Virus infected ELF binaries
1. Installing ClamAV in Debian Wheezy Linux

Before time there was a separate Debian repository called Volatille providing latest version release of Clamav, since Debian Squeeze Volatille project is discontinued, thus installing on Wheezy as a deb package is only available via standard Debian repositories.

apt-get update && apt-get --yes upgrade

apt-get install --yes clamav clamav-daemon

As package dependencies you get installed:

clamav clamav-base clamav-freshclam libbz2-1.0 libclamav1 libcurl3 libidn11 ucf

Clamav-Daemon will launch immediately after packages are installed and is available as process name /usr/sbin/clamd

# ps ax |grep -i clam
 2641 ?        Ssl    6:39 /usr/sbin/clamd
 2791 ?        Ss    12:04 /usr/bin/freshclam -d --quiet
12300 pts/0    S+     0:00 grep -i clam

2. Updating Clamav Antivirus Definitions

Its worthy say few words on clamav-freshclam as it is part of ClamAV which is used to update Clamav Virus definitions. Update of ClamAV vir definitions are updating automatically through /usr/bin/freshclam daemon which is started automatically by Debian postconfiguration scripts right after Clamav install.

Manual update of AV definitions can be done also with freshclam.

# freshclam
ClamAV update process started at Sun Sep  8 17:48:36 2013
main.cvd is up to date (version: 54, sigs: 1044387, f-level: 60, builder: sven)
daily.cvd is up to date (version: 17830, sigs: 1696886, f-level: 63, builder: neo)
bytecode.cld is up to date (version: 225, sigs: 42, f-level: 63, builder: dgoddard)

To keep an eye on definition auto-updates (useful to check where something fails), check out in /var/log/clamav/freshclam.log

A sure indication that Anvirus updates are conducting fine should be log records like:

Sun Sep  8 16:27:44 2013 -> ————————————–
Sun Sep  8 17:27:44 2013 -> Received signal: wake up
Sun Sep  8 17:27:44 2013 -> ClamAV update process started at Sun Sep  8 17:27:44 2013
Sun Sep  8 17:27:44 2013 -> main.cvd is up to date (version: 54, sigs: 1044387, f-level: 60, builder: sven)
Sun Sep  8 17:27:44 2013 -> daily.cld is up to date (version: 17830, sigs: 1696886, f-level: 63, builder: neo)
Sun Sep  8 17:27:44 2013 -> bytecode.cld is up to date (version: 225, sigs: 42, f-level: 63, builder: dgoddard)
Sun Sep  8 17:27:47 2013 -> ————————————–

3. Configuring ClamAV

For Desktop use clamav default config is pretty good. However for servers its good to raise  2 up MaxThreads:

By default MaxThreads is 12

MaxThreads 12

Change to from 30 to 80 depending on how powerful machine ClamAV runs, even on some servers more Clamav threads might be necessary

MaxThreads 30

Other value I like changing is SelfCheck 3600 is too long time for clamav Virus definitions integrity I prefer to set it to 600, i.e.

SelfCheck 600

By default ClamAV is also configured to scan archive files as well. However for this to work you will have to have previously installed unzip and unrar on system. If still you don't have them installed run:

# apt-get install --yes unrar unzip

Note that you will need to have non-free part of Debian deb repositories to /etc/apt/sources.list

Here is one of my sources.list

deb squeeze main contrib non-free
deb squeeze/updates main contrib non-free
deb-src squeeze/updates main contrib non-free

deb squeeze main contrib non-free
deb-src stable main contrib non-free

deb squeeze/updates main contrib non-free
deb-src squeeze/updates main contrib non-free

3. Scanning with ClamAV

# clamscan -r /tmp/
./dos- OK
./dos- OK
./dos- OK
./dos- OK
./dos- OK
./dos- OK
./dos- OK
./dos- OK

----------- SCAN SUMMARY -----------
Known viruses: 2735887
Engine version: 0.97.8
Scanned directories: 1
Scanned files: 129
Infected files: 0
Data scanned: 0.00 MB
Data read: 0.00 MB (ratio 0.00:1)
Time: 4.769 sec (0 m 4 s)

-r flag stands for recursive scan – e.g. scan all sub-directories in directory and its content

To not flood your console / ssh connection one very useful option is -i (print only whetherinfected files are matched). Here is one more sample case:

# clamscan -r -i /var/tmp/
----------- SCAN SUMMARY -----------
Known viruses: 2735887
Engine version: 0.97.8
Scanned directories: 1
Scanned files: 2
Infected files: 0
Data scanned: 0.26 MB
Data read: 0.13 MB (ratio 1.97:1)
Time: 4.824 sec (0 m 4 s)

Whether you're on a physical server console and it has pc speaker or sound blaster use –bell option to ring a bell every time a Virus infection is found, for exmpl.

# clamscan -r -i --bell /var/www/

4. Scanning periodically and reporting with ClamAV directories with websites

A very common use of ClamAV is to just setup a scheduled cronjob once a month to scan, whether server folder containing a bunch of websites in separate Virtualhosts contain some viruses or malicious stuff. Then as administrator check those logs once a month to make sure server site or group of sites does not become banned in search engine (blocked by Google Chrome and Firefox as Virus hotbed) …
# crontab -u root -e
00 02 01 * * clamscan -r /var/www -l /var/log/websites-scan.log

Then once a month check out /var/log/websites-scan.log

Is it possible mail server to work on alternative port to 25?

Thursday, February 28th, 2013

If you're running a small home based Linux or BSD server with Qmail, Exim or Postfix and it happens your ISP has filtered incoming connections to TCP/IP port 25 and you wonder if it is possible to use other alternative port to 25 for example the (Secure SMTP) SMTPS 465 supported by all major SMTP servers, the answer unfortunately is it is not possible.

The only accepted and working mail transmission port works on TCP/IP Port 25, thus the only option to make the mail server working fine is contact your ISP and convince them to remove filtering for port 25 to your custom IP. Many ISPs set a Firewall filter for 25, because nowadays many Windows XP / Vista / 7 PCs get infected with Viruses and Trojans running a tiny SMTP server on the host and trying to send million of SPAM messages via the poor unknowing victim. This congests the network and often even creates ISP network overloads, thus ISPs prefer to filter Port 25 to get rid of such eventual problems.

Once again,  alternative port to 25 for Mail is impossible !

Testing Qmail installation for problems: Common reasons for unworking qmail / How to debug Qmail mail server failing to delivery or send emails

Friday, November 9th, 2012

Testing qmail installation for problemes finding qmail common component failures

Through my 10 years of experience  in managing and "life with qmail", I've at many times had to deal with suddenly broken or misconducting, qmail installs. With some of them the problems started during new Qmail install configuration time, with others QMAIL worked perfectly for years and then suddenly it stopped working. Nomatter what the situation was, there was a kind of "scenario" and common things to check to debug and find out what is causing the respective qmail installation to not work. In this little, article I will try to share my knowledge in hope that others which configure new QMAIL based mail servers or are in situation to need to recover – "resurrect" a one that suddenly stopped working qmail to its normal operations.

Here are few cases , there are many more, probably hundreds of reasons which might be causing Qmail + Vpopmail  to stop properly delivering e-amails but  as this ones ones are really most likely ones just checking them gives a good clue What is going wrong with  Qmail?.:

  • Something broke up with scheduled daemontools processes;
  • There is no hard disk (the disk is full) and Qmai is unable to writeinside its mail Queue directories (/var/qmail/queue) or Spamassassin or AntiVirus programs fails to write on disk
  • ( /var/qmail/bin/ ) perl script is messed up or if using simscan to do antivirus check-ups instead simscan is failing somewhere
  • something messed up with /var/qmail/control/rcpthosts
  • something messed up with /var/qmail/control/validrcptto.txt or /var/qmail/control/validrcptto.cdb
  •  incorrect main server host in /var/qmail/control/me or /var/qmail/control/plusdomain
  • Messed up vpopmail (virtual domain) records in /var/qmail/control/virtualdomains file
  • problems with insufficient memory (whether there is a softlimit memory limit for /service/qmail-smtpd/run (qmail daemontools start up and monitoring script) – /usr/local/bin/softlimit is no longer proposed used by newer qmail guides but in older ones it was common to appear in /../qmail-smtpd/run
  • Something is wrong with clamd (/usr/sbin/clamd – for example crashed due to bug) or something is wrong with clamav database ( /var/lib/clamav or wherever set to be stored; on some installs /usr/local/lib/clamav) – there most commonly main.cvd and daily.cld break up during freshclam clamav database update.
  • As freshclam takes care for AntiVirus database updates it is good to check it is properly running, either as a service or via a cronjob
  • Assure there are no mistakes or wrong (unexistent) variables in /etc/tcp.smtp file or / and /etc/tcp.smtp.cdb is not broken
  • Permission issues with; qmail main binaries in /var/qmail/bin/ , queue files – /var/qmail/queue or qmail log files /var/log/qmail/…

As I said there are plenty of other possible, reasons but I listed this here, since they're the most common reasons for problems with sent or receive of messages with Qmail mail server.

Checking all of the above and making sure they're okay, I've checked daemontools readprodctitle process as it often signalize for problems with any part of qmail install, there all seemed normal no warnings and errors, e.g.:

qmail:~# ps ax|grep -i -E 'clam|freshclam|spam|vpopmail'
2241 ? Ssl 3:49 /usr/sbin/clamd
2408 ? Ss 11:54 /usr/bin/freshclam -d --quiet
2853 ? S 0:00 tcpserver -H -R -v -c100 0 110 qmail-popup /home/vpopmail/bin/vchkpw qmail-pop3d Maildir
2856 ? S 0:01 tcpserver -vR -l /var/qmail/control/me -c 30 -u 89 -g 89 -x /etc/tcp.smtp.cdb 0 25 rblsmtpd -t0 -r -r -r -r qmail-smtpd /var/qmail/control/me /home/vpopmail/bin/vchkpw /bin/true
2857 ? S 0:00 sslserver -e -vR -l -c 30 -u 89 -g 89 -x /etc/tcp.smtp.cdb 0 465 qmail-smtpd /home/vpopmail/bin/vchkpw /bin/true

qmail:~# ps ax|grep -i qmail
2840 ? S 0:00 supervise qmail-send
2844 ? S 0:00 supervise qmail-smtpd
2846 ? S 0:00 supervise qmail-pop3d
2848 ? S 0:00 supervise qmail-smtpdssl
2850 ? S 0:05 qmail-send
2852 ? S 0:00 multilog t n1024 s1048576 n20 /var/log/qmail/qmail-smtpdssl
2853 ? S 0:00 tcpserver -H -R -v -c100 0 110 qmail-popup /home/vpopmail/bin/vchkpw qmail-pop3d Maildir
2854 ? S 0:00 multilog t s100000 n20 /var/log/qmail/qmail-pop3d
2855 ? S 0:01 multilog t n1024 s1048576 n20 /var/log/qmail/qmail-smtpd
2856 ? S 0:01 tcpserver -vR -l /var/qmail/control/me -c 30 -u 89 -g 89 -x /etc/tcp.smtp.cdb 0 25 rblsmtpd -t0 -r -r -r -r qmail-smtpd /var/qmail/control/me /home/vpopmail/bin/vchkpw /bin/true
2857 ? S 0:00 sslserver -e -vR -l -c 30 -u 89 -g 89 -x /etc/tcp.smtp.cdb 0 465 qmail-smtpd /home/vpopmail/bin/vchkpw /bin/true
2858 ? S 0:01 multilog t n1024 s1048576 n20 /var/log/qmail/qmail-send
2868 ? S 0:01 qmail-lspawn ./Maildir
2869 ? S 0:00 qmail-rspawn
2870 ? S 0:00 qmail-clean
2871 ? S 0:04 qmail-todo
2872 ? S 0:01 qmail-clean
27742 pts/6 S+ 0:00 grep -i qmail

qmail:~# ps ax |grep -i readproc|grep -v grep
48060 ?        S      0:00 readproctitle service errors: ................................................................................................................................................................................................................................................................................................................................................................................................................

As you see  "….." signalize, all is fine with processes scheduled to run over daemontools process. If you instead get warnings or error messages usually the error will point you what is wrong with the qmail install. Common error, I've got over the years here especially on long time functionining qmail installs is insufficient disk space to write in qmail queue and log files.

Also above ps ax|grep -i -E 'clam|freshclam|spam|vpopmail'
shows all 3 clamd, freshclam and vpopmail are up and running so this most likely means all is good with them. Of course sometimes some of those 3 is working and there are problems with the services properly processing emails so it is always a good idea to read qmail log files, in most qmail installations qmail logs are located in /var/log/qmail .

Quickest way is to check all of the qmail related logs in a loop with something like:

qmail:~# for i in $(ls -d /var/log/qmail/*qmail*/); do tail -n 10 $i/current|tai64nlocal; sleep 5; done

Also it is always a good idea to check last 10 lines of clamav, freshclam, qmail-scanner and spamd logs:

qmail:~# tail -n 10 /var/log/qmail/clamav/clamav.log;
Fri Nov 9 06:52:28 2012 -> SelfCheck: Database status OK.
Fri Nov 9 07:52:28 2012 -> SelfCheck: Database status OK.
Fri Nov 9 08:52:28 2012 -> SelfCheck: Database status OK.
Fri Nov 9 09:52:28 2012 -> SelfCheck: Database status OK.
Fri Nov 9 10:52:29 2012 -> SelfCheck: Database status OK.
Fri Nov 9 11:57:29 2012 -> SelfCheck: Database status OK.
Fri Nov 9 12:57:29 2012 -> SelfCheck: Database status OK.
Fri Nov 9 14:14:35 2012 -> SelfCheck: Database status OK.
Fri Nov 9 15:33:46 2012 -> SelfCheck: Database status OK.
Fri Nov 9 16:33:46 2012 -> SelfCheck: Database status OK.

qmail:~# tail -n 10 /var/log/qmail/clamav/freshclam.log
Fri Nov 9 16:20:44 2012 -> --------------------------------------
Fri Nov 9 17:20:44 2012 -> Received signal: wake up
Fri Nov 9 17:20:44 2012 -> ClamAV update process started at Fri Nov 9 17:20:44 2012
Fri Nov 9 17:20:44 2012 -> WARNING: Your ClamAV installation is OUTDATED!
Fri Nov 9 17:20:44 2012 -> WARNING: Local version: 0.97.5 Recommended version: 0.97.6
Fri Nov 9 17:20:44 2012 -> DON'T PANIC! Read
Fri Nov 9 17:20:44 2012 -> main.cvd is up to date (version: 54, sigs: 1044387, f-level: 60, builder: sven)
Fri Nov 9 17:20:44 2012 -> daily.cld is up to date (version: 15557, sigs: 284869, f-level: 63, builder: jesler)
Fri Nov 9 17:20:44 2012 -> bytecode.cld is up to date (version: 191, sigs: 37, f-level: 63, builder: neo)
Fri Nov 9 17:20:46 2012 ->

qmail:~# tail -n 10 /var/log/qmail/qscan/qmail-queue.log
Fri, 09 Nov 2012 13:14:35 EET:14705:
from='', subj='Network Developer', via SMTP from
Fri, 09 Nov 2012 13:14:44 EET:14705: ------ Process 14705 finished. Total of 8.846395 secs
Fri, 09 Nov 2012 15:04:27 EET:21979: +++ starting debugging for process 21979 (ppid=21969) by uid=89
Fri, 09 Nov 2012 15:04:27 EET:21979: g_e_h: return-path='', recips=''
Fri, 09 Nov 2012 15:04:27 EET:21979: from='"G. Georgiev" ', subj='Re: Network Developer', via SMTP from using auth (
Fri, 09 Nov 2012 15:04:34 EET:21979: ------ Process 21979 finished. Total of 6.626484 secs
Fri, 09 Nov 2012 15:33:46 EET:23891: +++ starting debugging for process 23891 (ppid=23884) by uid=89
Fri, 09 Nov 2012 15:33:46 EET:23891: g_e_h: return-path='', recips=''
Fri, 09 Nov 2012 15:33:46 EET:23891: from='"Sandy Richardson" ', subj='RE: Network Developer', via SMTP from

qmail:~# tail -n 10 /var/log/spamd/current |tai64nlocal 2012-11-09 16:25:43.091680500 Nov 9 15:04:27.858 [22049] info: spamd: connection from localhost [] at port 54494
2012-11-09 16:25:43.091683500 Nov 9 15:04:27.948 [22049] info: spamd: checking message <> for qscand:89
2012-11-09 16:25:43.091684500 Nov 9 15:04:33.837 [22049] info: spamd: clean message (0.0/5.0) for qscand:89 in 6.0 seconds, 1104 bytes.
2012-11-09 16:25:43.091690500 Nov 9 15:04:33.838 [22049] info: spamd: result: . 0 - scantime=6.0,size=1104,user=qscand,uid=89,required_score=5.0,rhost=localhost,raddr=,rport=54494,mid=<>,autolearn=ham
2012-11-09 16:25:43.091692500 Nov 9 15:04:34.077 [22043] info: prefork: child states: II
2012-11-09 16:25:43.091692500 Nov 9 15:33:53.626 [22049] info: spamd: connection from localhost [] at port 54681
2012-11-09 16:25:43.091696500 Nov 9 15:33:53.656 [22049] info: spamd: checking message <05e201cdbe7e$d1c83c90$7558b5b0$> for qscand:89
2012-11-09 16:25:43.091697500 Nov 9 15:33:59.467 [22049] info: spamd: clean message (0.0/5.0) for qscand:89 in 5.8 seconds, 33845 bytes.
2012-11-09 16:25:43.091698500 Nov 9 15:33:59.467 [22049] info: spamd: result: . 0 - scantime=5.8,size=33845,user=qscand,uid=89,required_score=5.0,rhost=localhost,raddr=,rport=54681,mid=<05e201cdbe7e$d1c83c90$7558b5b0$>,autolearn=ham
2012-11-09 16:25:43.091702500 Nov 9 15:33:59.506 [22043] info: prefork: child states: II

Whether observing, some of above logs reveals problems to delivery e-mail messages because e-mail boxes are not existing in  /var/qmail/control/validrcptto.cdb – this often happens whether new e-mail boxes are created and the new mail somehow did not enter validrcptto.txt / validrcptto.cdb , you will have to re-build validrcptto.cdb. Rebuilding validrcptto.cdb manually is done with cmd:
br />  

qmail:~# /usr/local/bin/mkvalidrcptto > /var/qmail/control/validrcptto.txt qmail:~# cdbmake-12 /var/qmail/control/validrcptto.cdb /var/qmail/control/validrcptto.tmp < /var/qmail/control/validrcptto.txt

Of course, if the qmail was already properly installed with validrcptto support, this should be done automatically with some cron job set to invoke above commands every 5 minutes or so. In Thibs QmailRocks followed install the script is called /usr/sbin/update-validrcptto and is set to exec every 5 mins.

If spamassassin is configured to automatically update its set of anti-spam rules, via some cron job or smth. it is always a good idea to check if spamassassin, properly loads up does not fail due to some antispam rule:

qmail:~# spamassassin --lint -D ...

You will have to examine carefully, the long returned content for "warning" and "error" keywords. If you don't won't to bother with details you can do, spamassassin –lint

Another good idea whether problems with qmail is of course to rebuild tcpserver cdb file for smtp – this usually solves problems caused by broken /etc/tcp.smtp.cdb.cdb files.

Re-building manually tcp.smtp.cdb is done with:
qmail:~# tcprules /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp < /etc/tcp.smtp
qmail:~# chmod 644 /etc/tcp.smtp.cdb

However, most qmail installation guides recommend or set a qmailctl bash script file, to start / stop / reload / flush qmail queue or simply get status of the qmail installation, so it much easier to rebuild tcp.smtp.cdb through it:
qmail:~# qmailctl cdb
Reloaded /etc/tcp.smtp.

Checking the status of the Qmail Queue state and fixing issues with it can be done using little external tool qmHandle – check my previous article ( Cleaning Qmail filled queue with Spam messages )

To check the basic qmail compontents (qmail-send, qmail-smtpd , qmail-smtpdssl)do:

qmail:~# qmailctl stat
/service/qmail-send: up (pid 2850) 1886193 seconds
/service/qmail-send/log: up (pid 2858) 1886193 seconds
/service/qmail-smtpd: up (pid 2856) 1886193 seconds
/service/qmail-smtpd/log: up (pid 2855) 1886193 seconds
/service/qmail-smtpdssl: up (pid 2857) 1886193 seconds
/service/qmail-smtpdssl/log: up (pid 2852) 1886193 seconds
messages in queue: 2
messages in queue but not yet preprocessed: 0

Another good practice if you have doubts that something is messed with qmail-queue is to check what is waiting to be send in queue:

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

In above paste, from my mail server I have just 2 mails, if you however notice here some large numbers like 5000 or 10000, this might be the cause for asetbacks. If you have plenty of undelivered mails waiting in mail server queue, examine the queue:

qmail:~# qmail-qread ....

Of course it is sometimes, possible to be in situation, where more than one components are creating mail server's sent / receive delivery issues. Anyhow doing a close examination of all possible components usually should (if not reveal what causes the issue) at least give you some pointer to where to search for the problem.

Also for qmail installations based on QmailRocks or Thibs QmailRocks guide, there is a tiny shell script provided, that does evaluation on standard qmail files permissions and binary locations and reports, whether it finds problems with some of them. You can fetch a copy of the qmr_inst_check from here . Although the script is created to check a newly install qmail for problems, it also often helps in determining issues with qmails who mysteriously stopped working.

If you suspect, there are::

Well that's it. Hope this little walk through give you idea where to check on troublesome Qmail install. Please leave a comment if it help you (somehow) solve your issue. Also will be glad to hear if I'm missing somethingi'm sure I am.

How to speed up qmail qmail-smtpd response time on QmailRocks Thibs based install

Saturday, October 6th, 2012

I have recently installed Qmail following the Updated Debian QmailRocks Thibs Install

The qmail is configured just like Thibs points out the server was configured to a run qmail-smtpd script together with DJB’s Daemontools

I’ve figured out today connecting to the newly install Qmail host with telnet, using:

qmail:~# telnet 25
Connected to
Escape character is '^]'.
220 This is Mail ESMTP

Does a few seconds delay until my configured qmail greeting shows up. This is not a a deadly problem, but the delay itself might have a negative influence and make the host look like a spammer host to someone, hence I took few seconds to find a way to reduce this SMTP port connection delay.

The mail server responds on port 25, using qmail-smtpd so it was logical delay is caused somewhere by /service/qmail-smtpd/run (which actually links to /var/qmail/supervise/qmail-smtpd/run).

I did a quick review of /var/qmail/supervise/qmail-smtpd/run and found two lines that possibly create unnecessery delay, cause on each and every Port 25 connection request from repote SMTP server /usr/bin/head and /usr/bin/which are executed.
Here are two lines in /service/qmail-smtpd/run, I refer to:

LOCAL=`head -1 $VQ/control/me

(located on line 34)


TRUE=`which true`

located on line 116

The script was smartly written as planned to run on multiple Linux distributions. However since QmailRocks Thibs guide and my particular case needs to run on Debian Linux I think this is totally waste of system CPU time.

Therefore I substituted above two lines with:



I checked in /var/qmail/control/me I have only my primary mail server host defined, cause otherwise this changed could pose random mail server errors:

qmail:~# wc -l /var/qmail/control/me
1 /var/qmail/control/me
qmail:~# cat /var/qmail/control/me

An updated version of /service/qmail-smtpd/run script you can download from here

If you don’t want to temper manually edit the script the quickest way is to overwrite old script with changed one, i.e.:

qmail:~# cd /var/qmail/supervise/qmail-smtpd
qmail:/var/qmail/supervise/qmail-smtpd# wget -q
qmail:/var/qmail/supervise/qmail-smtpd# mv qmail-smtpd-daemontools-run run

To test connection time delay afterwards, you can use:

# time (echo HELO localhost | telnet 25)
Connected to
Escape character is '^]'.
Connection closed by foreign host.
real 0m0.070s
user 0m0.004s
sys 0m0.000s

Well still there is a connection delay – it is not so quick as, but now connection response delay is better. For sake of comparison here is same test with Google’s SMTP:

$ time (echo HELO localhost | telnet 25)
Connected to
Escape character is '^]'.
Connection closed by foreign host.
real 0m0.017s
user 0m0.004s
sys 0m0.000s

BTW a bit of time delay sometimes, can have a positive impact against spammers, as it can reduce a bit the amount of spammer mail servers connecting to the host. So i’m not sure if being 4 times slower in connection than Gmail is necessery bad 🙂

Fix QMAIL mail server – “warning: dropping connection, unable to SSL accept:protocol error” and why error occurs

Friday, August 24th, 2012

Every time I had to modify something in productive QMAIL server install, I end up with some kind unexplainable problems which create huge issues for clients. For one more time I end up with errors after minor “innocent” modifications of a working for more than year time QMAIL ….

After last changes I made to combined qmail install of Thibs, QmailRocks in Daemontools qmail start up files:


In both files I set variable:

SSL=0 to SSL=1:

After making the change I restarted qmail tested sending emails and all looked well. Therefore I thought all works as usual, e.g. e-mail are properly sent and respectively received to the mail server….

So far so good until just today, when I received urgent phone call in which my employer reported about severe problems with receiving emails.
Trying to send from Gmail or Yahoo to our mail server were unable to be received with some delivery failure errors …
First I was a bit sceptical, hoping that maybe the errors reporting are not caused by the mail server but after giving a try to send email to the mail server in question the reported problem prooved true.
As always when errors with QMail, I checked what the logs says about the problem just to find in /var/log/qmail-smtpd/current log following err:

@4000000050374a0e1a5dc374 sslserver: warning: dropping connection, unable to SSL accept:protocol error

I’ve dig over almost all primary forums, threads and blog posts online but nowhere I couldn’t find anymeaningful as explanation to the error, so was forced to look for solution myself.
Obviously, there was error with SSL, so my first thought was to check if all is fine with permissions of servercert.pem and clientcert.pem. The permissions of two files were as follows:

ls -al /var/qmail/control/clientcert.pem
-rw-r----- 1 root qmail 2136 2011-10-10 13:23 /var/qmail/control/clientcert.pem
ls -al /var/qmail/control/servercert.pem
-rw-r--r-- 1 qmaild qmail 2311 2011-10-12 13:21 /var/qmail/control/servercert.pem

At first glimpse I was suspicious concerning permissions of /var/qmail/control/clientcert.pem but after checking on other Qmail servers which worked just fine I was sure the problem did not root in clientcert.pem permissions.

As you can guess another failure point I suspected was the previous day change of SSL=0 to SSL=1 in /var/qmail/supervise/qmail-smtpd/run and /var/qmail/supervise/qmail-smtpdssl/run. On that account, I immediately reversed back the yesterday setting of SSL=0 and then restart QMAIL.

The usual QMAIL to restart qmail is via qmailctl, but since so often qmailctl does not reload qmail current settings I had to also refresh current working qmail binaries via both stopping qmail with qmailctl stop and through /etc/inittab by commenting out in it line dealing with daemontools svscanboot:

Hence I first stopped all running qmail processes via init script:

# /usr/bin/qmailctl stop

Then commented line:




Onwards did reload of initab with command:

# /sbin/init q

Right onwards I uncommented the commented line:




And load up daemontools (svscanboot) via inittab issuing:

# /sbin/init q

Finally I had to start QMAIL processes:

# qmailctl restart

Change of SSL svscanboot daemontools service script SSL=0 to SSL=1 however created other problems for clients cause any present clients which used crypted connections to SMTP server viaSSL encryption rendered unable to send mails anymore with error messages like:

Cannot establish SSL with SMTP server, SSL_connect error 336031996.

To work around this issue I had to once again start SSL (set SSL=1) in /var/qmail/supervise/qmail-smtpssl/run and leave SSL switched off for /var/qmail/supervise/qmail-smtp/run.

Even doing this changes for about 20 minutes though I restarted QMAIL multiple times, qmail continued having issues with mails received with the shitty:

@4000000050374a0e1a5dc374 sslserver: warning: dropping connection, unable to SSL accept:protocol error

After multiple restarts “magically” the stupid server figured out it should load my changed setting in qmail-smtpdssl/run (before it finally worked I probably had to restart 20 times using qmailctl stop; qmailctl start ….

I’ve figured out as a good practice to put delay between qmailctl stop and qmailctl start cmds so in restarts I used a little 3 secs sleep in between like so:

# qmailctl stop; killall -9 multilog; sleep 3; qmailctl start

Also killing multilog (killall -9 multilog) is good practice cause often nevertheless restarts server logging is not refreshed …

Something else that might be important is the AUTH settings in qmail-smtpd/run and qmail-smtpdssl/run in thisfinally working qmail they are:


Hope this post helps someone to solve same crazy error …

How to disable spammer domain in QMAIL mail server with badmailto variable

Thursday, July 12th, 2012

I've recently noticed one of the qmail SMTP servers I adminster had plenty of logged spammer emails originating from destined to reache some random looking like emails (probably unexisting) again to *

The spam that is tried by the spammer is probably a bounce spam, since it seems there is no web-form or anything wrong with the qmail server that might be causing the spam troubles.
As a result some of the emails from the well configured qmail (holding SPF checks), having a correct existing MX, PTR record and even having configured Domain Keys (DKIM) started being marked, whether emails are sent to * legit emails.

To deal with the shits, since we don't have any Taiwanese (tw) clients, I dediced to completely prohibit any emails destined to be sent via the mail server to * This is done via /var/qmail/control/badmailto qmail control variable;

Here is content of /var/qmail/control/badmailto after banning outgoing emails to;;;

qmail:~# cat /var/qmail/control/badmailto

The first 4 lines are default rules, which are solving a lot of badmailto common sent emails. Thanks God after a qmail restart:

qmail:~# qmailct restart

Checking in /var/log/qmail-sent/current, there are no more outgoing * destined emails. Problem solved …

How to change users quota to NO QUOTA on Qmail with Vpopmail Mail server install / Qmail mail over quota issue

Monday, February 20th, 2012


Qmail Vpopmail quota exceeded Dolphin Logo

Already on a couple of mail boxes located on one of the qmail powered mail servers I adminiter, there is an over QUOTA reached problem encountered.

Filling up the mailbox quota is not nice as mails starts get bounced back to the sender with a message QUOTA FULL or EXCEEDED MESSAGE, if this is a crucial mail waiting for some important data etc. the data is never received.
Below is a copy of the mail quota waarning notification message:

Date: Wed, 15 Feb 2012 17:40:36 +0000
X-Comment: Rename/Copy this file to ~vpopmail/domains/.quotawarn.msg, and make appropriate changes
X-Comment: See README.quotas for more information
From: Mail Delivery System <>
To: Valued Customer:;
Subject: Mail quota warning
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Your mailbox on the server is now more than 90% full. So that you can continue
to receive mail you need to remove some messages from your mailbox.

As you can read from the copy of the mail message above, the message content sent to the mail owner whose quota is getting full is red from /var/vpopmail/domains/.quotawarn.msg

The mail reaching quota problem is very likely to appear in cases like low mailbox quota set, but sometimes also occurs due to bugs in vpopmail quota handling.

Various interesting configuration settings for mail quotas etc. are in /home/vpopmail/etc/vlimits.default file, (assuming vpopmail is installed in /home).

In my specific case, the default vpopmail mailbox quota size was set to only 40 Megabytes.
40MB is too low if compared to todays mailbox size standards which in Gmail and Yahoo  mail services are already a couple of gigabytes.
Hence to get around the quota troubles, I  removed the quota for the mail.
To remove the quota size in vpopmail set for address ( used cmd:

qmail-server:~# vmoduser -q NOQUOTA

To save myself from future quota issues, I decided to apply a permanent fix to all those over quota size VPOPMAIL mailbox problems by removing completely quota restriction for all mailboxes in my vpopmail existent mail domain.

To do so, I wrote a quick simple bash loop one-liner script:

qmail-server:~# cd /home/vpopmail/domains
qmail-server:~/vpopmail/domains# cd
qmail-server:~/vpopmail/domains/ for i in *; do \
vmoduser -q NOQUOTA $(echo $i|grep -v vpasswd); \

This works only on vpopmail installations which are configured to store the mail messages directly on the filesystem. Therefore this approach will not work for people who during vpopmail install had configured it to store mailboxes in MySQL or in other kind of SQL db engine.

Anyways for Vpopmail installed to use SQL backend, the script can be changed to read directly a list with all the mailboxes obtained from databasae (SQL query) and then, loop over each of the mail addresses apply the vmoduser -q NOQUOTA

I've written also a few lines shell script (, it accepts one argument which is a vpopmail domain to which the admin would like to reset all applied mailbox quotas. The script is useful, if you have to often remove all quotas for vpopmail domainsor have to do quota wipe out simultaneously for multiple email domain names  located on different servers.

Cause and solution for Qmail sent error “Requested action aborted: error in processing Server replied: 451 qq temporary problem (#4.3.0)”

Friday, October 28th, 2011

One of the qmail servers I manage today has started returning strange errors in Squirrel webmail and via POP3/IMAP connections with Thunderbird.

What was rather strange is if the email doesn’t contain a link to a webpage or and attachment, e.g. mail consists of just plain text the mail was sent properly, if not however it failed to sent with an error message of:

Requested action aborted: error in processing Server replied: 451 qq temporary problem (#4.3.0)

After looking up in the logs and some quick search in Google, I come across some online threads reporting that the whole issues are caused by malfunction of the (script checking mail for viruses).

After a close examination on what is happening I found out /usr/sbin/clamd was not running at all?!
Then I remembered a bit earlier I applied some updates on the server with apt-get update && apt-get upgrade , some of the packages which were updated were exactly clamav-daemon and clamav-freshclam .
Hence, the reason for the error:

451 qq temporary problem (#4.3.0)

was pretty obvious which is using the clamd daemon to check incoming and outgoing mail for viruses failed to respond, so any mail which contained any content which needed to go through clamd for a check and returned back to did not make it and therefore qmail returned the weird error message.
Apparently for some reason apparently the earlier update of clamav-daemon failed to properly restart, the init script /etc/init.d/clamav-daemon .

Following fix was very simple all I had to do is launch clamav-daemon again:

linux:~# /etc/inid.d/clamav-daemon restart

Afterwards the error is gone and all mails worked just fine 😉