Archive for the ‘Qmail’ Category

QMail (Considered to be the most secure Mail server out there whose modified version is running on Google – Gmail.com and Mail Yahoo! and Yandex EMail (SMTP) servers, nowadays has been highly neglected and considered obsolete thus most people prefer to use postfix SMTPor EXIMbut still if you happen to be running a number of qmail old rack Mail servers (running a bunch of Email addresses and Virtual Domains straight on the filesystem – very handy by the way for administration much better than when you have a Qmail Mail server configured to store its Mailboxes within MySQL / PostgreSQL or other Database server – because simple vpopmail configured to play nice with Qmail and store all user emails directly on Filesystem (though considered more insecure the email correspondence can be easily red, if the server is hacked it is much better managable for a small and mid-sized mailserver) or have inherited them from another sys admin and you wonder how to redirect a single Mailbox:

(under domain lets say domain's email my-server1.com should forward to to SMTP domain my-server-whatever2.com (e.g. your-email-username@server-whatever1.comis supposed to forward to your-email-username2@server-whatever2.com).
To achieve it create new file called .qmail

!!! NOTE N.B. !!! the last slash / after Maildir (…Maildir/) is important to be there otherwise mail will not get delivered
That's all now send a test email, just to make sure redirection works properly, assuming the .qmail file is created by root, by default the file permissions will be with privileges root:root.

Note

That shouldn't be a problem at all. That's all now enjoy emails being dropped out to the second mail 🙂

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:/downloads/simscan-1.4.0# /var/qmail/bin/qmail-scanner-queueYOU HAVEN'T DISABLED SET-ID SCRIPTS IN THE KERNEL YET!
FIX YOUR KERNEL, PUT A C WRAPPER AROUND THIS SCRIPT, OR USE -u AND UNDUMP!

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

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.

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:

If you followed Qmailrocks or the updated QmailThibs Qmailrocks tutorialyou have configured Qmail Mail SMTP server to listen by default for encrypted SSL connections on port 465. However many Mail for POP3 Secure / Imapd Secure Clients are doing auto configuration and many prefers to have the 587 port configured too to accept Secure SMTP connections with STARTTLS support and not 465 Secure Connections with SSL certificate.

So the logical queston comes how to configure 587 port to listen for STARTTLS connections?

In below article I'll show you how you can configure Qmail to also have a listener on TCP port 587.

Perhaps there are numerous ways to configure Qmail Mail to listen on 587(assuming it is already configured to properly accept mail on SMTP port 25) and a properly configure IMAP Secure and POP Secure in order for Thunderbird and Outlook desktop mail clients to be able to communicate (Send / Receive) mails without obstacles to the custom confiured Mail server.

By the way having Qmail SMTP listener on 587 besides 25 has another reason for many as some Internet Service Providers (ISPs) have purposefully filtered access to unencrypted port 25 for the sake of reducing auto spam sent in their networks.

So here we go.

Howto setup Qmail Mail server to use have listener on Port 587

Here I assume you have already qmail-smtpd running as a service via Dan Bernstein's Daemontools (Supervice), e.g. the qmail-smtpd run script is stored in lets say /var/qmail/supervise/qmail-smtpd and linked properly to run from /service/qmail-smtpd

Once the script template is copied we need to change the default listener port from 25 to 587 for edit the /var/qmail/supervice/qmail-smtpd587/run respawnscript

vim /var/qmail/supervise/qmail-smtpd587/run

If you're not familiar with vim use nano / pico / joe / emacs etc. or your favourite text editor if you're running Xserver environment with gnome on the server (hope you didn't) for simplicity you can use even gedit

Here we need to change

PORT=25

to

PORT=587

Also make sure the script value of

FORCE_TLS=0

(if configured that way) is set to:

FORCE_TLS=1

Value of

AUTH=0

should also be equal to

AUTH=1

Here I assume the run script is standard one from ex-QmailRocks step by step qmail install (which up2date is the so called QmailRocks Qmail Thibs).

For some older or custom Qmail Installs /var/qmail/supervise/qmail-smtpd587/run might look slightly different e.g. could be something like:

Save the file now what is left is to also make the necessery changes for logging to work for /var/qmail/supervise/qmail-smtpd587/log/run

Before we do that we'll copy the log files from /var/log/qmail/qmail-smtpd to /var/log/qmail/qmail-smtpd587
(Note here if your qmail-smtpd log is configured on some other location just change the appropriate paths in below cp command)

As you see everything looks fine we're listening on 587, it is generally a good idea to check also all the running services on the server including rest of Qmail listeners to make sure something else did not broke, so I recommend you issue once again:

netstat -lptn
…
….

It is recommended to also check the readproctitle daemontools process to make sure no any kind of errors are reporting while runing the supervise scripts, to do so run:

Above many dots indicate no errors were encountered while runing the supervise scripts and everything is okay, if you instead get some errors, you have to debug what is crashing and fix it, but hopefully you should have gone without any errors just like me. Even if there errors expect something minor like a typo in the just modified run scripts or some missing log path or something.

If you happen to be installing Qmail Mail server on a Debian or Ubuntu (.deb) based Linux, you will notice by default there will be some kind of MTA (Mail Transport Agent) already installed mail-transfer-agent package will be installed and because of Debian .deb package depedency to have an MTA always installed on the system you will be unable to remove Exim MTA without installing some other MTA (Postix / Qmail) etc.

This will be a problem for those like me who prefer to compile and install Qmail from source, thus to get around this it is necessery to create a dummy package that will trick the deb packaging depencies that actually mta-local MTA package is present on the server.

The way to go here is to use equivs(Circumvent debian package dependencies):

debian:~# apt-cache show equivs|grep -i desc -A 10

Description: Circumvent Debian package dependencies
This package provides a tool to create trivial Debian packages.
Typically these packages contain only dependency information, but they
can also include normal installed files like other packages do.
.
One use for this is to create a metapackage: a package whose sole
purpose is to declare dependencies and conflicts on other packages so
that these will be automatically installed, upgraded, or removed.
.
Another use is to circumvent dependency checking: by letting dpkg
think a particular package name and version is installed when it

Btw creating a .deb dummy package will be necessery in many other cases when you have to install from some third party debian repositories or some old and alrady unmaintaned deb-src packages for the sake of making some archaic software to resurrect somewhere, so sooner or later even if you're not into Mail servers you will certainly need equivs.

Then install equivs and go on proceeding creating the dummy mail-transport-agent package

Above command will build and package /tmp/mta-local_1.0_all.deb dummy package.
So continue and install it with dpkg as you use to install debian packages

debian:~# dpkg -i /tmp/mta-local_1.0_all.deb
…

From then on you can continue your standard LWQ – Life with Qmail or any other source based qmail installation with:

./config-fast mail.yourmaildomain.net
…

So that's it now .deb packaging system consistency will be complete so standard security package updates with apt-get and aptitude updates or dpkg -i third party custom software insatlls will not be breaking up any more.

I've been stuck with qmail-scanner-queue for a while on each and every new Qmail Mail server installation, I've done, this time it was not different but as time evolves and Qmail and Qmail Scanner Wrapper are not regularly updated it is getting, harder and harder to make a fully functional Qmail on newer Linux server distribution releases.

I know many would argue QMAIL is already obsolete but still I have plenty of old servers running QMAIL whose migration might cause more troubles than just continuing to use QMAIL. Moreover QMAIL once set-upped works like a charm.

I've been recently experiencing severe issues with clamdscan errors and I tried to work around this with compiling and using a suid wrapper, however still the clamdscan errors continued and as qmail-scanner is not actively developed and it is much slower than simscan, I've finally decided to give simscan as a mean to fix the clamdscan errors and thanksfully this worked as a solution.

Here is what I did "rawly" to make simscan work on this install:

Make sure simscan is properly installed on Debian Linux 7 or Ubuntu servers and probably (should work) on other Deb based Linuxes by following below steps:

a) Configure simscan with following compile time options as root (superuser)

It might be a good idea to also place that lines in /etc/rc.local to auto change permissions on Linux boot, just in case something wents wrong with permissions.

Yeah, I know 777 is unsecure but without this permissions, I was still getting errors, plus the server doesn't have any accounts except the administrator, so I do not worry other system users might sniff on email 🙂

h) Test whether Qmail mail server send / receives fine with simscan

After that I've used another mail server with mail command to test whether mail is received:

Then it is necessery to also install latest clamav daemon from source in my case that's on Debian GNU / Linux 7, because somehow the Debian shipped binary version of clamav 0.98.5+dfsg-0+deb7u2 does fail to scan any incoming or outgoing email with error:

I've lost a whole day and was angry and irritated after moving (migrating) a Working Qmail installation in a binary form from a Debian Lenny 5.0 to a Debian 7.0 Wheezy Linux. The whole migration exercise was quite of a crazy move and I can tell you it didn't worth the effort as I lost much more time than even if I went on installing the server following Thibs Great Qmail Tutorial.

Yes I know many would say why do you still bother with an old and unsupported Qmail Mail server and not go with Postfix, the logic is correct however the whole issue is the previous installation has a number of domains already running VirtualMail hosting using VPopMail, so migrating all the old mailboxes from Qmail to Postfix are not worthy IMHO. Plus I honestly love qmail for being so stable even today (even without support). After all most of Qmail is secure enough already 🙂
And to be honest I don't so much care about security as in the old days as I know NSA, does already have access to any server on planet 🙂

Almost always when a Qmail migration happens I end up swearing and sweating and generally getting crazy, but anyways …

The overall migration of binaries went quite OK I just copied every binary and all the related libraries from the old Debian 5.0 to Debian 7.0 and installed the following long list of perl deb binaries using apt-get:

I've also copied all the old binaries from /usr/local/lib from server1 to server2, some others from /usr/local/share and /usr/share as well as /usr/lib/courier/usr/lib/courier-authlib/usr/local/libexec /usr/local/sbin also had to link a couple of libraries such as /usr/lib/libcrypto* , link /usr/lib/libperl.so.5.10 to /usr/lib/libperl.so.5.14 and copy /usr/lib/libltdl.so.3 and few others which i don't exactly remember.

Well anyways once I've copied everything Qmail looked fined except I had a couple of permission issues and had to clean up and fix the queue with qfixq, I've also used qmail-scanner*/contrib/test_installation.sh script to test whether qmail-scanner was running fine, e.g.:

./test_installation.sh -doit

As well as

qmr_inst_check

script, thanks to which I've captured and resolved few of permission problems

Finally I've stuck upon this shitty errors (appearing) in /var/log/syslog and /var/log/messages

But all written is too obscure and too old already somewhere between 2004 and 2010, I've been digging through Gentoo Forums, Fedora Debian and other Linux installs and everyone used to be pointing a permission issue with /var/spool/qscan/ said theoretically to be causing the error, however all looked perfectly fine with my /var/spool/qscan , e.g.:

This didn't help either … I saw some suggestions online that the permission issues are caused by some wrong clamd.conf and freshclamd.conf configuration options – failing clamdscan, but this didn't work either. I also tried to remove clamdscan and substitute it with clamscan as a suggested workaround but this didn't work either …

I spend about 6 hours trying to catch what is causing this issues so finally I went on and re-installed bigger part of Qmail using Thibs tutorial over the old installation.

I've also tried in mean time multiple time to rebuild qmail scanner database with:

Finally, I tried to reinstall qmail-scanner and in mean time update it to Version: 2.11 – st – patch – 20130319
Just to realized something was wrong with suidperl, e.g. in Debian 7.0.* Wheezy perl-suid binary is no longer in repositories so only way to have suidperl there is either to re-compile perl from source manually which is too much work and I think in most cases not worthy the effort or to use a small suid-wrapper:

Finally to test emails are sent and receiver properly I used good old mail command part of bsd-mailx deb package

# mail -s "testing 12345678" testemail1234@gmail.com
asdfadf
.
Cc:

I've also tested with plain telnet to verify no errors because often the mail command doesn't return (show) errors on email sent and errors are written only in /var/log/mail.log or /var/log/qmail/* logs

Even though Qmail is considered as obsolete email server lately and it lacks good systematical official documentation and requires a lot of "hacking" to make work. It is surely still the fastest and maybe securest mail server out there (if properly configured).
My Qmail uses Vpopmail (for Virtual Email hosting). Every now and them some client requires to add a new e-mail forwarding from E-mail mail@host.com to Email to mail1@host2.com. Though many like to use Web interface as QmailAdmin for adding the forward I still prefer do it via old fashioned way, by SSH-ing to qmail server host and manually creating .qmail file.

On one of the Debian Squeeze Servers, where I have Running QMAIL Server, I haven't checked logs for a long time. Cause Qmail is configured and all runs smoothly. Just today while checking logs, I've noticed in /var/log/clamav/clamav.log, clamav database fails to be updated with an error, e.g.:

If you just configured new Qmail Mail server installation following some of the many Qmail install tutorials available online (i.e. – Life with Qmail, QmailRocks etc.) andall seemed configured fine, but still sending mails via mail server is not working in Thunderbird or Outlook with an error message like:

As you can see as of time of getting Error, connection security is set to None, however the Qmail SMTP Mail server is configured to not support Transmissions of Passoword (in plain text) insecurely, hence whenever Thunderbird tries to authenticate sending my Mailbox password via SMTP Auth protocol in plain text, authentication fails with the ugly archaic error:

Solution to problem is as simple as changing,Connection Security: to STARTTLS

To finalize and, restarting Thunderbird is necessary. After that sending mail via Mail server works like a charm.
Note that the meaning of;'sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1).

Sending mail client or user is not authorized to deliver to mailbox to whose delivery is attempted (in my case to Gmail.com). This message pops-up because the SMTP Mail server is configured properly and not Open Relay host.

Hope this helps someone. In case it worked for you drop a comment with version of Mail Client and Mail server and a thank you message 😉

I routinely checked, if afterwards all is fine with Qmail?, just to find out connect to port 25 was hell delayed about 40-50 seconds before qmail responds with standard assigned Mail Greeting.
I Googled long time to see if I can find a post or forum thread discussing, exact issue, but though I found similar discussions I didn't found anything that exactly match problem. Thus I decided to follow the good old experimental try / fail method to figure out what causes it.

After going, through all of possible causes the only clue for problems, were some slowness with spamassassin. This brought me the idea that something is done wrong with spamassassin .I tried disabling, Spamassassin Razon and Pyzor restarting spamd through (in my case done not via the standard start/stop debian script) but through daemontools with svc and qmailctl i.e.:

# svc -d /service/spamd
# svc -u /service/spamd
# svc -a /service/spamd
# qmailctl restart
* Stopping qmail-smtpdssl.
* Stopping qmail-smtpd.
* Sending qmail-send SIGTERM and restarting.
* Restarting qmail-smtpd.
* Restarting qmail-smtpdssl.
* Restarting qmail-pop3d. This doesn't help, so I continued trying to figure out, what is wrong .One assumption for slow qmail-smtpd responce was of course slow DNS resolve issues. I checked /etc/resolv.conf to find out server is configured to use local configured DJBDNS server as first line DNS resolver. I used djbdns for it is simple and easy to configure, however it is a bit obsolete so it was possible bottleneck. After commenting line to use localhost 127.0.0.1 and settings as primary DNS Google Public DNS 8.8.8.8, problem persisted so problems with hosts resolving was obviously not the problem.

I pondered for about 30 minutes, checking again all logs and checking machine processes. Just to remember before I experienced similar issues caused by unresolving RBL (blacklist IP) hosts. I checked configured SPF records in
(process list) and noticed following 4 hosts;

After a close examinations in mail server config /var/qmail/control/spfrules, found one other Unresolvable SPF Blacklist host configured ;# cat /var/qmail/control/spfrules
include:spf.trusted-forwarder.org