Archive for the ‘Qmail’ Category

How to configure Exim to relay mail to remote SMTP server on Debian and Ubuntu

Wednesday, August 24th, 2011

I’m required to do some mail relaying on a Debian Linux host which should use a remote mail server to relay its mails.
Until so far I’ve had not much experience with exim as I prefer using qmail, whever a mail server is needed. However since now only a relaying was necessery and exim is the default installed MTA on Debian, I’ve decided to use exim to take care of the SMTP mail relaying.
After a bit of reading it happened configuring exim to relay via remote SMTP server is more than easy!

All I had to do is run the command:

debian-relay:~# dpkg-reconfigure exim4-config

Next in the Ncruses interface to appear:

Debian Exim relay smtp config screenshot

I had to choose the option:

mail sent by smarthost; no local mail

Next a dialog appears asking for:
System mail name:
Therein it’s necessery to type in the hostname of the remote SMTP to be used for mail relay.
Next dialog asks for:
IP-addresses to listen on for incoming SMTP connections:
and I left it with 127.0.0.1 however if exim is supposed to be visible from external network one might decide to put in real IP address there.

Pressing OK leads to the next dialog:
 Other destinations for which mail is accepted: 
I decided to leave this blank as I don’t want to accept mail for any destinations.
Next pane reads:
Visible domain name for local users:
I’ve typed inside my smtp relay server e.g.:
smtp.myrelaymail.com

Further comes:
IP address or host name of the outgoing smarthost:
There once again I typed my mail relay host smtp.relaymail.com

The next config screen is:
Keep number of DNS-queries minimal (Dial-on-Demand)?
On any modern Linux host the default answer of No is fine.
Following prompt asked if I want to:
Split configuration into small files?
I’ve decided not to tamper with it and choosed No
Afterwards mail relaying works like a charm thx God 😉

How to solve crashing spamassassin spamd service preventing QMAIL mail server to properly deliver mails / Setting spamd work via daemontools

Monday, November 12th, 2012

How to solve crashing spamd, script to restart spamd on failure, set spamd to run via daemontools, configure spamd to be restarted from monit service

On my home router configured qmail install, I have recently noticed I receive e-mails only sent via contact forms on the few websites hosted there. I'm subscribed to Debian newsletter, as well as usually receive about 10 emails and few spam mails every day, so after a few days of reduced emails on my email (receiving only e-mail notification about  blog issued comments), I logically suspected something is not properly working with the qmail installation.
My first logical guesses was the usual Qmail problems I've previously experienced through the years, earlier I blogged about most common problems / causes and solutions with qmail mail here

First thing I did as usual is to send a test e-mail from Gmail to my Mailboxes on the mail server, the test mail was not received and in Gmail a failure to delivery notice was returned, I paste the TXT content of it as taken from Gmail's webmail -> Show Original menu:
 

                                                                                                                                                                                                                                                               
Delivered-To: hipodilski@gmail.com
Received: by 10.112.27.135 with SMTP id t7csp91961lbg;
Mon, 29 Oct 2012 11:08:28 -0700 (PDT)
Received-SPF: pass (google.com: domain of  designates 10.60.171.72 as permitted sender) client-ip=10.60.171.72
Authentication-Results: mr.google.com; spf=pass (google.com: domain of  designates 10.60.171.72 as permitted sender) smtp.mail=; dkim=pass header.i=
Received: from mr.google.com ([10.60.171.72])
by 10.60.171.72 with SMTP id as8mr17839903oec.140.1351534106946 (num_hops = 1);
Mon, 29 Oct 2012 11:08:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:from:to:x-failed-recipients:subject:message-id:date
:content-type:content-transfer-encoding;
bh=GOkrGPurYWG9obiJDBWq6v3JHXdHlUebhVco7rIE73E=;
b=mQemNDUu1Wl7d/VoIseXgXFbL0SdwMIY4MZH9GOm8TuRSVaU8oz80wdWt93zJTt/DR
TEYTT6VRxUaDRAE2igBRLqjiSXdpZAJuBhoNA+bOTPwU53v+eaAUaV/7uHVHG0SYvF6u
rkpc1Rbf41VYIDLthm+e7X8vFdaxqiYFiiHcih2stsAzgI9jAQy62SLlBytYRZeDc3po
BXsb4SLm3+4kF4PuBlmhnCL+ba0hR3vQE5yC8/et0lPaxdSaJk0bHFkrjtmvg00fkyXo
Pv+0dPJHvAInzHlPGtL+XHuvjZCq5XD5ZJjsajyAlG6J64z9dmziz8YM+qqA0KpNaF8+
CVrA==
Received: by 10.60.171.72 with SMTP id as8mr17839903oec.140.1351534106944;
Mon, 29 Oct 2012 11:08:26 -0700 (PDT)
MIME-Version: 1.0
Return-Path: <>
Received: by 10.60.171.72 with SMTP id as8mr20755231oec.140; Mon, 29 Oct 2012
11:08:26 -0700 (PDT)
From: Mail Delivery Subsystem <mailer-daemon@googlemail.com>
To: hipodilski@gmail.com
X-Failed-Recipients: hipo@www.pc-freak.net
Subject: Delivery Status Notification (Failure)
Message-ID: <bcaec54edff658a23d04cd368e01@google.com>
Date: Mon, 29 Oct 2012 18:08:26 +0000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Delivery to the following recipient failed permanently:
hipo@www.pc-freak.net
Technical details of permanent failure:=20
Google tried to deliver your message, but it was rejected by the recipient =
domain. We recommend contacting the other email provider for further inform=
ation about the cause of this error. The error that the other server return=
ed was: 451 451 qq temporary problem (#4.3.0) (state 17).
----- Original message -----
DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed;
d=3Dgmail.com; s=3D20120113;
h=3Dmime-version:date:message-id:subject:from:to:content-type;
bh=3DoaO9B2OZ1YJ19nwzUGkqXFVmVnakcfMdp7uW1TTA/u4=3D;
b=3DQGaaKOgrnXxSa7X0ZjdmbG2/CWDPK10czq4n0YxHLRfX8N+pzJLHWXBFWmVWUNt=
yte
rs8VrYu0BkdAE18MXS3x61cklvi/gk/eCUTzTm+L8fRu/Iiy6pZCr8S3Y6BWBN+5F1=
dm
1LkL0mTpSHqVIoMB/fZwHIzz6q5tTqYSSNHX+hapu30eI5liyK5rbf2/4T9BhJ1VM0=
v+
6NwupzAJK12jniKD8q9b4qJEhEoEqKKZrLKbTYiflHkAVMsg/C3v5zzwH+KZqsHP4W=
Us
Tl/sHUcErXWOry1OrQXLNYR2K9vgqVdBUS5aoU2Jy1FgxbL/t5+XzB3tUK2mv43ttX=
0k
wWbw=3D=3D
MIME-Version: 1.0
Received: by 10.60.171.72 with SMTP id as8mr10945566oec.140.1351262651282;
Fri, 26 Oct 2012 07:44:11 -0700 (PDT)
Received: by 10.182.41.232 with HTTP; Fri, 26 Oct 2012 07:44:11 -0700 (PDT)
Date: Fri, 26 Oct 2012 16:44:11 +0200
Message-ID: <CAPk3ZemH=3D6U0oCihDqDwb9DT8EbE8mTjZou6zzw2LUHHO4ObbA@mail.gma=
il.com>
Subject:=20
From: Georgi Georgiev <hipodilski@gmail.com>
To: hipo@www.pc-freak.net
Content-Type: multipart/alternative; boundary=3Dbcaec54edff653f66804ccf75ab=
9
http://www.nybooks.com/blogs/nyrblog/2012/sep/04/jesus-vs-mao-interview-yua=
n-zhiming/
--=20
Georgi Georgiev
Mobile: +31644943358

After evaluating on qmail logs and various qmail components and basic qmail configurations, noticed the spamassassin spamd process is not running on the host. I've figured it out from qscanner-scanner.pl  in /var/log/qscan/qmail-queue.log, there were records saying, qmail-scanner can't pass incoming scanned mail to spand and thus failing

I onwards check in proclist to make sure qmail-queue.log suggestion is right, i.e.:

qmail:~# ps axu|grep -i spamd|grep -v grep
qmail:~#

As you see from my paste qmail scanner logs were right,spamd process died due to some memory leak bug or whatever. To temporary solve the problem I first launched spamd, via its init script:

 

qmail:~# /etc/init.d/spamassassn start

....

 

However it was clear, that in future spamd might unexpectedly terminate and this might ruin whole email receive processing again.

I've encountered on few qmail servers issues like this, so I knew of 3 work-arounds.

 

  • One is to use a tiny script set to run via cron job with superuser which checks every few minutes if spamd is running and if not re-launch it via the init script.

In some qmail installations, I've solved issues by using a tiny shell script – here you can download the script restart_spamd_if_crashed.sh

To use it download it to any directory lets say in /usr/local/bin and set cron job like:

qmail:~# crontab -u root -e

*/5 * * * * /usr/local/bin/restart_spamd_if_crashed.sh  >/dev/null 2>&1

 

  • Third and in my view best spamd crashes work-around  is to configure spamd to be constantly monitored and respawned whether found missing via daemontools.

To do so download those  spamd_daemontools_supervise_script.tar.gz archive and place it in /var/qmail/supervise (or wherever qmail/supervise dir is located) and create directory for spamd daemontools monitoring logs

qmail:~# cd /var/supervise
qmail:/var/supservice:# wget -q https://www.pc-freak.net/files/spamd_daemontools_supervise_script.tar.gz
qmail:/var/supervise:# tar -zxvvf spamd_daemontools_supervise_script.tar.gz
....
qmail:/var/supervise:# chmod +t spamd/
qmail:/var/supervise:# mkdir /var/log/spamd
qmail:/var/supervise:# chown -R qmaill:root /var/log/spamd
qmail:/var/supervise:# touch /var/log/spamd/current qmail:/var/supervise:# chown qmaill:nofiles /var/log/spamd/current

It is also generally good idea to check the content of scripts spamd/run and spamd/log/run, a common problem with those scripts is spamassassin might be custom installed in /usr/local/bin/spamd and not in the usual /usr/bin/spamd – spamd location is defined in spamd/run; as well as location of daemontools logging tool multilog might be not /usr/bin/multilog but in /usr/local/bin/multilog – depending on what kind of Qmail guide was used on qmail install time.

Finally, to make daemontools schedule for monitoring spamd service link it in /service dir:

qmail:~# ln -sf /var/supervise/qmail/ /service/qmail
qmail:~# ls -al /service/spamd lrwxrwxrwx 1 root root 27 Nov 8 14:38 spamd -> /var/qmail/supervise/spamd//

To check whether daemontools, started and watch over spamd check what is in /var/log/spamd/current and check the status of daemontools:

qmail:~# tail -n 5
qmail:~# ps ax|grep -i readproc|grep -v grep 27916 ? S 0:00 readproctitle service errors: .............................
qmail:~# tail -n 5 /var/log/spamd/current |tai64nlocal 2012-11-12

Whether, you're sure daemontools, now handles spamd, startup it is also recommended, you stop the on boot time /etc/init.d/spamassassin start-up.

qmail:~# mv /etc/rc2.d/S18spamassassin /etc/rc2.d/K81spamassassin

Of course if spamd is crashing due to some newly included anti-spam rule, which prevents spamassassin from starting, suggested fixes and even daemontools will be unable to "respawn" spamd. In most cases however, implementing any of above "fixes" will assure you a peaceful sleep.  

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
  • qmail-scanner-queue.pl ( /var/qmail/bin/qmail-scanner-queue.pl ) 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 mail.www.pc-freak.net /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 zen.spamhaus.org -r dnsbl.njabl.org -r dnsbl.sorbs.net -r bl.spamcop.net qmail-smtpd /var/qmail/control/me /home/vpopmail/bin/vchkpw /bin/true
2857 ? S 0:00 sslserver -e -vR -l mail.www.pc-freak.net -c 30 -u 89 -g 89 -x /etc/tcp.smtp.cdb 0 465 qmail-smtpd mail.www.pc-freak.net /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 mail.www.pc-freak.net /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 zen.spamhaus.org -r dnsbl.njabl.org -r dnsbl.sorbs.net -r bl.spamcop.net qmail-smtpd /var/qmail/control/me /home/vpopmail/bin/vchkpw /bin/true
2857 ? S 0:00 sslserver -e -vR -l mail.www.pc-freak.net -c 30 -u 89 -g 89 -x /etc/tcp.smtp.cdb 0 465 qmail-smtpd mail.www.pc-freak.net /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 http://www.clamav.net/support/faq
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='noreply@theitjobboard.eu', subj='Network Developer', via SMTP from oy-ip-034.smwebhost.com
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='hipo@www.pc-freak.net', recips='sandy.richardson@hyperionrecruitment.com'
Fri, 09 Nov 2012 15:04:27 EET:21979: from='"G. Georgiev" ', subj='Re: Network Developer', via SMTP from ip156-108-174-82.adsl2.static.versatel.nl using auth (hipo@www.pc-freak.net@ip156-108-174-82.adsl2.static.versatel.nl)
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='sdy.richardson@hyperionrecruitment.com', recips='hipo@www.pc-freak.net'
Fri, 09 Nov 2012 15:33:46 EET:23891: from='"Sandy Richardson" ', subj='RE: Network Developer', via SMTP from
ostrich.dnsmaster.net

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 [127.0.0.1] at port 54494
2012-11-09 16:25:43.091683500 Nov 9 15:04:27.948 [22049] info: spamd: checking message <509CFF4F.9030601@www.pc-freak.net> 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=127.0.0.1,rport=54494,mid=<509CFF4F.9030601@www.pc-freak.net>,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 [127.0.0.1] at port 54681
2012-11-09 16:25:43.091696500 Nov 9 15:33:53.656 [22049] info: spamd: checking message <05e201cdbe7e$d1c83c90$7558b5b0$@hyperionrecruitment.com> 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=127.0.0.1,rport=54681,mid=<05e201cdbe7e$d1c83c90$7558b5b0$@hyperionrecruitment.com>,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.

Pc-Freak 2 days Downtime / Debian Linux Squeeze 32 bit i386 to amd64 hell / Expression of my great Thanks to Alex and my Sister

Tuesday, October 16th, 2012

Debian upgrade Squeeze Linux from 32 to 64 problems, don't try do it except you have physical access !!!

Recently for some UNKNOWN to ME reasons New Pc-Freak computer hardware crashed 2 times over last 2 weeks time, this was completely unexpected especially after the huge hardware upgrade of the system. Currently the system is equipped with 8GB of memory a a nice Dual Core Intel CPU running on CPU speed of 6 GHZ, however for completely unknown to me reasons it continued experience outages and mysteriously hang ups ….

So far I didn’t have the time to put some few documentary pictures of PC hardware on which this blog and the the rest of sites and shell access is running so I will use this post to do this as well:

Below I include a picture for sake of History preservation 🙂 of Old Pc-Freak hardware running on IBM ThinkCentre (1GB Memory, 3Ghz Intel CPU and 80 GB HDD):

IBM Desktop ThinkCentre old pc-freak hardware server PC

The old FreeBSD powered Pc-Freak IBM ThinkCentre

Here are 2 photos of new hardware host running on Lenovo ThinCentre Edge:

New Pc-Freak host hardware lenovo ThinkEdge Photo
New Pc-Freak host hardware Lenovo ThinkEdge Camera Photo
My guess was those unsual “freezes” were caused due to momentum overloads of WebServer or MySQL db.
Actually the Linux Squeeze installed was “stupidly” installed with a 32 bit Debian Linux (by me). I did that stupidity, just few weeks ago, when I moved every data content (SQL, Apache config, Qmail accounts, Shell accounts etc. etc.) from old Pc-Freak computer to the new purchased one.

After finding out I have improperly installed (being in a hurry) – 32 Bit system, I’ve Upgrade only the system 32 bit kernel hich doesn’t support well more than 4GB to an amd64 one supporting up to 64GB of memory – if interested I’ve prior blogged on this here.
Thanks to my dear friend Alexander (who in this case should have a title similar to Alexander the Great – for he did great and not let me down being there in such a difficult moment for me spending from his personal time helping me bringing up Pc-Freak.Net. To find a bit more about Alex you might check his personal home page hosted on www.pc-freak.net too here 🙂
I don’t exaggerate, really Alex did a lot for me and this is maybe the 10th time I disturb him over the last 2 years, so I owe him a lot ! Alex – I really owe you a lot bro – thanks for your great efforts; thanks for going home 3 times for just to days, thanks for recording Rescue CDs, staying at home until 2 A.M. and really thanks for all!!

Just to mention again, to let me via Secure Shell, Alex burned and booted for me Debian Linux Rescue Live CD downloaded from linke here.

This time I messed my tiny little home hosted server, very very badly!!! Those of you who might read my blog or have SSH accounts on Pc-Freak.NET, already should have figured out Pc-Freak.net was down for about 2 days time (48 HOURS!!!!).

The exact “official” downtime period was:

Saturday OCTOBER 13!!!( from around 16:00 o’clock – I’m not fatalist but this 13th was really a harsh date) until Monday 15-th of Oct (14:00h) ….

I’m completely in charge and responsible for the 2 days down time, and honestly I had one of my worst life days, so far. The whole SHIT story occurred after I attempted to do a 32 bit (i386) to AMD64 (64 bit) system packages deb binary upgrade; host is installed to run Debian Squeeze 6.0.5 ….; Note to make here is Officially according to documentation package binary upgrades from 32 bit to 64 arch Debian Linux are not possible!. Official debian.org documentation recommended for 32 bit to 64 packs update (back up all system existent data) and do a clean CD install / re-install, over the old installed 32 bit version. However ignoring the official documentation, being unwise and stubborn, I decided to try to anyways upgrading using those Dutch person guide … !!!

I’ve literally followed above Dutch guy, steps and instead of succeeding 64 bit update, after few of the steps outlined in his article the node completely (libc – library to which all libraries are linked) broke up. Then trying to fix those amd64 libc, I tried re-installing coreutils package part of base-files – basis libs and bins deb;
I’ve followed few tutorials (found on the next instructing on the 32bit to 64 bit upgrade), combined chunks from them, reloaded libc in a live system !!! (DON’T TRY THAT EVER!); then by mistake during update deleted coreutils package!!!, leaving myself without even essential command tools like /bin/ls , /bin/cp etc. etc. ….. And finally very much (in my fashion) to make the mess complete I decided to restart the system in those state without /bin/ls and all essential /bins ….
Instead of making things better I made the system completely un-bootable 🙁

Well to conclude it, here I am once again I stupid enough not to follow the System Administrator Golden Rule of Thumb:

IF SOMETHING WORKS DON’T TOUCH IT !!!!!!!!! EVER !!!!, cause of my stubbornness I screw it up all so badly.
I should really take some moral from this event, as similar stories has happened to me long time ago on few Fedora Linux hosts on productive Web servers, and I went through all this upgrades nightmare but apparently learned nothing from it. My personal moral out of the story is I NEVER LEARN FROM MY MISTAKES!!! PFFF …

I haven’t had days like this in which I was totally down, for a very long time, really I fell in severe desperation and even depressed, after un-abling to access in any way Pc-Freak.NET, I even thought it will be un-fixable forever and I will loose all data on the host and this deeply saddened me.
Here is good time to Give thanks to Svetlana (Sveta) (A lovely kind, very beautiful Belarusian lady 🙂 who supported me and Sali and his wife Mimi (Meleha) who encouraged and lived up my hardly bearable tempper when angry or/and sad :)). Lastly I have to thank a lot to Happy (Indian Lady whose whose my dear indian brother Jose met me with in Skype earlier. Happy encouraged me in many times of trouble in Skype, giving me wise advices not to take all so serious and be more confied, also most importantly Happy helped me with her prayers …. Probably many others to which I complained about situation helped with their prayers too – Thanks to to God and to all and let God return them blessing according to their good prayers for me !

Some people who know me well might know Pc-Freak.Net Linux host has very sentimental value for me and even though it doesn’t host too much websites (only 38 sites not so important ones ), still it is very bad to know your “work input” which you worked on in your spare time over the last 3 years (including my BLOG – blogging almost every day for last 3 yrs, the public shell SSH access for my Friends, custom Qmail Mail server / POP3 and IMAP services / SQL data etc. might not be lost forever. Or in more positive better scenario could be down for huge period of time like few months until I go home and fix it physically on phys terminal …

All this downtime mess occurred due to my own inability to estimate properly update risks (obviously showing how bad I’m in risk management …). Whole “down time story”” proofed me only, I have a lot to learn in life and worry less about things ….
It also show me how much of an “idol”, one can make some kind of object of daily works as www.pc-freak.net become to me. Good thing is I at least realize my blog has with time, become like an idol to me as I’m mostly busy with it and in a way too much worrying for it makes me fill up in the gap “worshipping an idol” and each Christian knows pretty well, God tells us: “Do not have other Gods besides me”.

I suppose this whole mess was allowed to happen by God’s Great Mercy to show me how weak my faith is, and how often I put my personal interest on top of real important things. Whole situation teached me, once again I easy fall in spirit and despair; hope it is a lesson given to me I will learn from and next time I will be more solid in critical situation …

Here are some of my thoughts on the downtime, as I felt obliged to express them too;

Whole problem severeness (in my mind), would not be so bad if I only had some kind of physical access to System terminal. However as I’m currently in Arnhem Holland 6500 kilometers away from the Server (hosted in Dobrich, Bulgaria), don’t have access to IPKVM or any kind of web management to act on the physical keyboard input, my only option was to ask Alex go home and tell him act as a pro tech support which though I repeat myself I will say again, he did great.
What made this whole downtime mess even worser in my distorted vision on situation is, fact; I don’t know people who are Linux GURUs who can deal with the situation and fix the host without me being physically there, so this even exaggerated me worrying it even more …

I’m relatively poor person and I couldn’t easily afford to buy a flight ticket back to Bulgaria which in best case as I checked today in WizzAir.com’s website would costs me about 90EUR (at best – just one way flight ticket ) to Sofia and then more 17 euro for bus ticket from Sofia to Dobrich; Meaning whole repair costs would be no less than 250 EUR with prince included train ticket expenses to Eindhoven.);

Therefore obviously traveling back to fix it on physical console was not an option.
Some other options I considered (as adviced by Sveta), was hiring some (pro sysadm to fix the host) – here I should say it is almost impossible to find person in Dobrich who has the Linux knowledge to fix the system; moreover Linux system administrators are so expensive these days. Most pro sysadmins will not bother to fix the host if not being paid hour – fee of at least 40 / 50 EUR. Obviously therefore hiring a professional UNIX system adminsitrator to solve my system issues would have cost approximately equal to travel expenses of myself, if going physically to the computer; spend the same 5 hours fixing it and loose at least 2 or 3 more days in traveling back to Holland …..
Also it is good to mention on the system, I’ve done a lot of custom things, which an external hired person will be hardly possible to deal with, without my further interference and even if I had hired someone to fix it I would have spend at least 50 euro on Phone Bills to explain specifics ….

As I was in the shit, I should thanks in this post also (on first place) to MY DEAR SISTER Stanimira !!! My sis was smart enough to call my dear friend Alexander (Alex), who as always didn’t fail me – for a 3rd time BIG THANKS ALEX !, spending time and having desire to help me at this critical times. I instructed him as a first step to try loading on the unbootable linux, the usual boot-able Debian Squeeze Install LiveCD….
So far so good, but unfortunately with this bootable CD, the problem is Debian Setup (Install) CD does not come equipped with SSHD (SSH Server) by default and hence I can’t just get in via Internet;
I’ve searched through the net if there is a way to make the default Debian Install CD1 (.iso) recovery CD to have openssh-server enabled, but couldn’t find anyone explainig how ?? If there is some way and someone reading this post knows it please drop a comment ….

As some might know Debian Setup CD is running as its basis environment busybox; system tools there provided whether choosing boot the Recovery Console are good mostly for installing or re-installing Debian, but doesn’t include any way to allow one to do remote system recovery over SSH connection.

Further on, have instructed Alex, brought up the Network Interfacse on the system with ifconfig using cmds:


# /sbin/ifconfig MY_IP netmask 255.255.255.240
# /sbin/route add default gw MY_GATEWAY_IP;

BTW, I have previously blogged on how to bring network interfaces with ifconfig here
Though the LAN Interfaces were up after that and I could ping ($ ping www.pc-freak.net) this was of not much use, as I couldn’t log in. Neither somehow can access system in a chroot.
I did thoroughfully explained Alex, how to fix the un-chroot-table badly broken (mounted) system. ….
In order to have accessed the system via SSH, after a bit of research I’ve asked Alex to download and boot from the CD Drive Debian Linux based AMD64 Rescue CD available here ….

Using this much better rescue CD than default Debian Install CD1, thanks God, Alex was able to bring up a working sshd server.

To let me access the rescue CD, Alex changed root pass to a trivial one with usual:


# passwd root
....

Then finally I logged in on host via ssh. Since chroot over the mounted /vev/sda1 in /tmp/aaa was impossible due to a missing working /bin/bash – Here just try imagine how messed up this system was!!!, I asked Alex to copy over the basic system files from the Rescue CD with cp copy command within /tmp/aaa/. The commands I asked him to execute to override some of the old messed up Linux files were:


# cp -rpf /lib/* /tmp/aaa/lib
# cp -rpf /usr/lib/* /tmp/aaa/usr/lib
# cp -rpf /lib32/* /tmp/aaa/lib32
# cp -rpf /bin/* /tmp/aaa/bin
# cp -rpf /usr/lib64/* /tmp/aaa/usr/lib64
# cp -rpf /sbin/* /tmp/aaa/sbin
# cp -rpf /usr/sbin/* /tmp/aaa/usr/sbin

After this at least chroot /tmp/aaa worked!! Thanks God!

I also said Alex to try bootstrap to install a base debian system files inside the broken /tmp/aaa, but this didn’t make things better (so I’m not sure if debootstrap helped or made things worse)??. Exact bootstrap command tried on the host was:


# debootstrap --arch amd64 squeeze /tmp/aaa http://ftp.us.debian.org/debian

This command as explained in Debian Wiki Debootstrap section is supposed to download and override basis Linux system with working base bins and libs.

After I logged in over ssh, I’ve entered chroot-ing and following instructions of 2 of my previous articles:

1. How to do proper chroot and recover broken Ubuntu using mount and chrooting

2. How to mount /proc and /dev and in chroot on Linux – for fail system recovery

Next on, after logging in via ssh I chrooted to mounted system;


# mount /dev/sda1 /mnt/aaa
# chroot /mnt/aaa

Inside chrooted environment, I tried running ssh server, listen on separate port 2208 with command:


# /usr/sbin/sshd -p 2208

sshd did not start up but spitted mer error: PRNG is not seeded, after reading a bit online I’ve found others experiencing PRNG is not seeded err in thread here

The PRNG is not seeded error is caused due to a missing /dev/urandom inside the chroot-ed environment:


# ls -al /dev/urandom
ls: cannot access /dev/urandom: No such file or directory

To solve it, one has to create /dev/urandom with mknod command:


# mknod /dev/urandom c 1 9

….

Something else worthy to mention is very helpful post found on noah.org explaining few basic things on apt, aptitude and dpkg which helped me over the whole severe failed dependency apt-get issues experienced inside chroot.

Inside the chroot, I tried using few usual apt-get cmds to solve the multiple appearing broken packages inter-dependency. I tried:


# apt-get update
....
# apt-get --yes upgrade
# apt-get -f install

Even before that apt, package was broken, so I instructed Alex, to download me one from a web link. By mistake I gave him, a Debian Etch apt version instead of Debian Squeze. So using once again dpkg -i apt* after downloading the latest stable apt deb binaries from debian.org, I had to re-install apt-get…

Besides that Alex, had copied a bunch of libraries, straight copied from my notebook running amd64 Debian Squeeze and has to place all this transferred binaries in /mnt/aaa/{lib,usr/lib} in order to solve missing libraries for proper apt-get operation.

As it seemed slightly impossible fix the broken dependencies with apt-get, I first tried fixing failed inter-dependencies using the other automated dependency solver tool (written in perl language) aptitude. I tried with it solving the situation issuing:


# aptitute update
# aptitude safe-upgrade
# aptitude safe-upgrade --full-resolver

No of the above aptitude command options helped anyhow, so
I’ve decided to try the old but gold approach of combining common logic with a bit of shell scripting 🙂
Here is my customly invented approach 🙂 :

1. Inside the chroot, make a dump of all installed deb packages names in a file
2. Outside the chroot straight ssh-ing again to the Rescucd shell, use RescueCD apt-get to only download all amd64 binaries corresponding to dumped packages names
3. Move all downloaded only apt-get binaries from /var/cache/apt/archives to /mnt/aaa/var/cache/apt/archives
4. Inside chroot, run cd to /var/cache/apt/archives/ and use for bash loop to install each package with dpkg -i

Inside Chroot-ed environment chroot /tmp/aaa, dpkg – to dump list of all installed i386 previous packages on broken system:


# dpkg -l|awk '{ print $2 }' >> /mnt/aaa/root/all_deb_packages_list.txt

Thereon, I delete first 5 lines in beginning of file (2 empty lines) and 3 lines with content:


Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
Err?=(none)/Reinst-required
Name

should be deleted.

Onwards outside of chroot-ed env, I downloaded all deb packages corresponding to previous ones in all_deb_packges.txt:


# mkdir /tmp/apt
# cd /tmp/apt
# for i in $(cat /mnt/aaa/root/all_deb_packages.txt; do \
apt-get --download-only install -yy $i \
....
.....
done

In a while after 30 / 40 minutes all amd64 .deb packages were downloaded in rescuecd /var/cache/apt/archives/.
/var/cache/apt/archives/ in LiveCDs is stored in system memory, thanksfully I have 8 Gigabytes of memory on the host so memory was more than enough to store all packs 😉
Once above loop, completed. I copied all debs to /mnt/aaa/var/cache/apt, i.e.:


# cp -vrpf /var/cache/apt/archives/*.deb /mnt/aaa/var/cache/apt/archives/

Then back in the (chroot-ed broken system), in another ssh session chroot /mnt/aaa, I run another shell loop aim-ing to install each copied deb package (below command should run after chroot-ing):


# cd /var/cache/apt/archives
# for i in *.deb; do \
dpkg -i $i
done

I had on the system installed Qmail server which was previously linked against old 32 bit installed libs, so in my case was also necessery rebuild qmail install as well as ucsp-tcp and ucsp-ssl, after rebooting and booting the finally working amd64 libs system (after reboot and proper boot!):

a) to Re-compile qmail base binaries, had to issue:


# qmailctl stop
# cd /usr/src/qmail
# make clean
# make man
# make setup check

b) to re-compile ucspi-tcp and ucspi-ssl:


# rm -rf /packages/ucspi-ssl-0.70.2/
#mkdir /packages
# chmod 1755 /packages
# cd /tmp
# tar -zxvf /downloads/ucspi-ssl-0.70.2.tar.gz
....
# mv /tmp/host/superscript.com/net/ucspi-ssl-0.70.2/ /packages
# cd /packages/ucspi-ssl-0.70.2/
# rm -rf /tmp/host/
# sed -i 's/local\///' src/conf-tcpbin
# sed -i 's/usr\/local/etc/' src/conf-cadir
# sed -i 's/usr\/local\/ssl\/pem/etc\/ssl/' src/conf-dhfile
# openssl dhparam -check -text -5 1024 -out /etc/ssl/dh1024.pem

Then had to stop temporary daemontools service, through commenting line in /etc/inittab:


# SV:123456:respawn:/usr/bin/svscanboot


# init q

After that remove commented line:


SV:123456:respawn:/usr/bin/svscanboot

and consequentually install ucsp-{tcp,ssl}:


# cd /packages/ucspi-ssl-0.70.2/
# package/compile
# package/rts
# package/install

c) Rebuild Courier-Imap and CourierImapSSL

As I have custom compiled Courier-IMAP and Courier-IMAPSSL it was necessery to rebuild Courier-imaps following steps earlier explained in this article

I have on the system running DjbDNS as local caching server so I had to also re-install djbdns, re-compiling it from source

Finally after restart the system booted OKAY!! Thanks God!!!!!! 🙂
Further on to check the boot-ed system runs 64 bit architecture dpkg should be used
To check if the system architecture is 64 now 64 bit, there is a command dpkg-architecture, as I learned from superuser.com forums thread here


root@pcfreak:~# dpkg-architecture -qDEB_HOST_ARCH
amd64

One more thing, which helped me a lot during the whole system recovery was main Debian deb HTTP repositories ftp.us.debian.org/debian/pool/ , I’ve downloaded apt (amd64 Squeeze) version and few other packages from there.
Hope this article helps someone who end up in 32 to 64 bit debian arch upgrade. Enjoy 🙂

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 mail.qmailhost.com 25
Trying 83.228.93.76...
Connected to mail.qmailhost.com.
Escape character is '^]'.
220 This is Mail mail.qmailhost.com 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)

and


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:


LOCAL="/var/qmail/control/me"


TRUE="/bin/true"

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
mail.qmailhost.com

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 https://www.pc-freak.net/files/qmail-smtpd-daemontools-run
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 mail.qmailhost.com 25)
Trying 83.228.93.76...
Connected to mail.qmailhost.com.
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 smtp.gmail.com, but now connection response delay is better. For sake of comparison here is same test with Google’s SMTP:


$ time (echo HELO localhost | telnet smtp.gmail.com 25)
Trying 173.194.70.108...
Connected to gmail-smtp-msa.l.google.com.
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:

/var/qmail/supervise/qmail-smtpd/run
/var/qmail/supervise/qmail-smtpdssl/run

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:

SV:123456:respawn:/usr/bin/svscanboot

to:

#SV:123456:respawn:/usr/bin/svscanboot

Onwards did reload of initab with command:

# /sbin/init q

Right onwards I uncommented the commented line:

#SV:123456:respawn:/usr/bin/svscanboot

to:

SV:123456:respawn:/usr/bin/svscanboot

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 xx.xxx.xxx.xxx:465, 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:

AUTH=1
REQUIRE_AUTH=0
ALLOW_INSECURE_AUTH=0

Hope this post helps someone to solve same crazy error …
Cheers

Thunderbird mail check problem fix to: “An error occurred sending mail: Unable to establish a secure link with SMTP server smtp.examplehost.com using STARTTLS since it doesn’t advertise that feature.”

Wednesday, August 22nd, 2012

Some clients of one of the qmail servers mail domain complained that there are problems sending e-mails with Thunderbird (pop / imap) client.

The exact Thunderbird sending error is:

Unable to establish a secure link with SMTP server smtp.examplehost.com using STARTTLS since it doesn't advertise that feature.
Switch off STARTTLS for that server or contact your service provider.

For for almost half an hour I pondered why the heck this odd error happens in sending mails with a fresh new Thunderbird (auto) configured mail address.
Few months back some clients were experiencing similar STARTTLS errors so I went back to check my previous post to get an idea what was wrong then in order to determine if the current reported error had to do with the previous one. My previous post is here – How to work around STARTTLS Qmail Thunderbird / Outlook mail sending (error) issues

After reading on the previous error and some assumptions I found out the whole problem lays in incorrectly set DNS records.
By default Thunderbird (and probably other mail clients) are configuring automatically as SMTP server (smtp.examplehost.com) if the DNS record for smtp.examplehost.com points to an IP address / host which belongs to another mail server, everytime thunderbird tries to send email the incorrect smtp.examplehost.com is used, hence the mail sending fails with the err:

Unable to establish a secure link with SMTP server smtp.examplehost.com using STARTTLS since it doesn't advertise that feature.
Switch off STARTTLS for that server or contact your service provider.

In my case the DNS for examplehost.com which is the mail server host was managed by Godaddy’s DNS-es:

ns49.domaincontrol.com
ns50.domaincontrol.com

The A record for our domain smtp.examplehost.com was by default set in GoDaddy to point to incorrect IP, so the fix was simply to change the Domain alias of smtp.examplehost.com to the proper mail host.

Another thing I had to do is change variables in /var/qmail/supervise/qmail-smtpd/run and /var/qmail/supervise/qmail-smtpdssl/run

In both files I changed variables:

SSL=0
ALLOW_INSECURE_AUTH=0

to

SSL=1
ALLOW_INSECURE_AUTH=1

Also variables FORCE_TLS and DENY_TLS in /var/qmail/supervise/{qmail-smtpd,qmail-smtpdssl}/runs should be:

FORCE_TLS=0
DENY_TLS=1

Though the problem was occuring in Mozilla Thunderbird, i’m sure same email sending problem will be present if Microsoft Outlook Express or any other desktop pop3 client is used.
After this changes I had to restart qmail server through qmailctl:

# qmailctl stop; sleep 5; qmailctl start

This fixed clients mail sending issues … hope this will help to others looking for way to remove STARTTLS, TLS, SSL qmail support

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 yahoo.com.tw destined to reache some random looking like emails (probably unexisting) again to *@yahoo.com.tw

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 *@yahoo.com 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 *@yahoo.com.tw. This is done via /var/qmail/control/badmailto qmail control variable;

Here is content of /var/qmail/control/badmailto after banning outgoing emails to yahoo.com.tw;;;

qmail:~# cat /var/qmail/control/badmailto
[!%#:\*\^]
[\(\)]
[\{\}]
@.*@
*@yahoo.com.tw

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 *@yahoo.com.tw destined emails. Problem solved …

Fixing QMAIL mail server SMTP auto-configure issues in Thunderbird and other mail IMAP / POP3 mobile clients

Friday, July 13th, 2012

One of the QMAIL mail servers, setup-uped on a Debian host has been creating some auto configuration issues. Every-time a new mail user tries to use the embedded Thunderbird client auto configuration, the auto config fails leaving the client unable to use his Mailbox through POP3 or IMAP protocols.

Since about 2 years Thunderbird and many other modern pop3 and imap mail desktop and mobile clients are by default using the auto configuration and hence it was unthinkable to manually change settings for new clients with the QMAIl install; Besides that most of the Office users are always confused, whether they have to manually change SMTP or POP3 host for a server.

Below is a screenshot displaying the warning during email auto-configuration:

Thunderbird new Mail account setup auto config warning SMTP not OKThe orange color in the button for the newly auto-detected smtp.mail-domain.com indicates, something is not right with the SMTP host.

Obviously, something was wrong with smtp.mail-domain.com, hence I checked where smtp.mail.domain.com resolves with host command. What I found was actually smtp.mail-domain.com Active ( A ) DNS records was pointing to an IP address, our company previously used for the mail server. At present time the correct mail server host name is mx.mail-domain.com and the QMAIL installation on mx.soccerfame.com is configured to be the actual SMTP server.

By default Thunderbird and many other POP3, IMAP mail clients, however automatically assume the default SMTP host for a mail server is to be configured under a host name smtp.mail-domain.com. This is really strange, especially when the primary MX record for mail-domain.com domain is pointing to mx.mail-domain.com, e.g.:

qmail:~# host -t MX mail-domain.com
soccerfame.com mail is handled by 10 mx.mail-domain.com.
soccerfame.com mail is handled by 20 mail.mail-domain.com.
soccerfame.com mail is handled by 30 mail-domain.com.

The whole warning was caused due to the fact mx.mail-domain.com was resolving to an IP like xxx.xxx.xxx.xxx, whether smtp.mail-domain.com was resolving to yyy.yyy.yyy.yyy

Both xxx.xxx.xxx.xxx and yyy.yyy.yyy.yyy hosts were configured to have a different qmail SMTP host i.e.:

The server under IP xxx.xxx.xxx.xxx – (mx.mail-domain.com) was configured in /var/qmail/control/me to be mx.mail-domain.com and the other old one yyy.yyy.yyy.yyy – (mail.mail-domain.com) had (mail.mail-domain.com) in /var/qmail/control/me

As smtp.mail-domain.com was actually being still resolved to mail.mail-domain.com, the EMAILs were improperly trying to be sent with a configured DNS hostname of smtp.mail-domain.com, where the actual one on the server was mail.mail-domain

It took, me about an hour of pondering what is causing the oddities until I got the here explained issue. As the DNS recors for the domain the sample mail-domain.com were handled by Godaddy, to fix the mess, I logged in to Godaddy and;

a) deleted – DNS record for smtp.mail-domain.com.
b) Created new CNAME record for smtp.mail-domain.com to be a domain alias for mx.soccerfame.com

A few minutes, afterwards I tried configuring once again the same email account in Thunderbird and this time both imap.mail-domain.com and smtp.mail-domain.com turned green; indicating everything is configured fine.

To be 100% sure all is working fine I first fetched, all email via the IMAP protocol without hassles and onwards sent a test email to my Gmail account; thanksfully the sent email was delivered to Gmail indicating both Get Mail and Send Mail functions worked now fine.

Thunderbird icedove new mail account setup auto config Okay
 

How to add multiple email accounts in qmail’s vpopmail with vpasswd via ssh (console) / Little shell script to add multiple email addresses

Sunday, June 12th, 2011

I’ve been assigned the task to add on one of the qmail powered servers I administrate about 50 email addresses via command line.

Each email addresses was required to be configured to have the same mail password.
Adding the email addresses via an interface would be a killing time consuming task and will probably require at least 1 hour of time to add the emails with qmailwebmin, qadmin, qubit or the other vpopmail qmail web administration interfaces available nowdays.

To solve the task, I’ve used a line oner bash shell script which reads all my 80 emails from a file and adds them with vpopmail’s command line tool vpasswd on the mail server.

Here is the one liner shell script I’ve written to solve the task:

debian:~# while read line; do vadduser $line Email_Pass_Phrase; done < email_list_file.txt

In above’s code I’ve used the email_list_file.txt file is a text file on the server and contains list of all my 50 email addresses, where each line in the file contains one email. The Email_Pass_Phrase is actually the password I’ve set for all the new email addresses being created with vpasswd

That’s all now the 50 email addresses on the server are created and I’ve saved at least one hour of boring repeating actions in the browser 😉