After upgrade to 8.2.1 Qmail started working very slow

[microeuropa]

Hello,

We upgraded our C-mail server to Plesk Version psa v8.2.1_build82070918.10 os_Debian 4.0. After this upgrade our
qmail started to deliver mail very slow.
The local box delivery start to gather mail and mail and
is unable to process the incoming mail, we had'nt have this
problem before the upgrade.

Other problem is, the SMTP connect takes ages... it gives
timeout to a lot of clients when trying to send the e-mail...

A third problem noticed is when sending an e-mail to several
recipients (for example 10), the 10 recipients receive 10
copies of that mail...

For ending... the machine load is allways high... because of qmail...

We recently changed to Plesk plataform, we are really considering
quit this platform... our previous server (still working with more than 600 domains) is based on Postfix, is a weaker machine and we do
not have mail waiting and the load never go up 1.00...

When will SWSoft understand that Qmail is not good enough for the
job...

Can anyone help me? any ideas?? I really need help on this one.
We are seriously harming our clients... and soon they'll quit our
services.

Plesk ticket [SWsoft #385543]

Cheers,
Hugo Ferreira

 

[dynamicnet]

Greetings Hugo:

qmail can handle a lot more than other types of mail servers.

That stated, please make sure incoming TCP 113 is rejected.

Make sure your tcp session count for qmail is set appropriately; 100 to 200 is typical of most medium volume mail servers.

Make sure your concurrencyremote and concurrencylocal is set appropriately; typically remote is two times the size of local, and typical values of 250 and 125 respectively are common for medium sized mail servers.

Make sure your mail server IP address has a proper reverse DNS set up by your data center.

Test your mail server domain name at http://www.dnsreport.com/ and clean up any errors.

Thank you.

 

[microeuropa]

Hi,

Thankx for your reply. The problem is with the local delivery...
I disabled SpamAssassin and even so the local mail is being
deliverid very slow...

The remote mail is being delivered normally, weird!

I worked with Qmail for a few years... I quit fighting. It's
nonsense patching something a program for everything when we
have another that comes with all features built in and with
better with performance like postfix. But that is
conversation for another time and place...

Any ideias...

Hugo

 

[divisionx]

We have had a number of problems with qmail. I have listed below a number of tips and tricks (not just qmail-related) taken from different articles at a number of different websites including SWsoft's. I am sure you can google each problem in turn and find a list of related articles. Below is a list of some of the things we did to improve performance, specially of qmail, and make the system more secure.

The discussion below is for information purposes only. If you decide to do any of these things then it is at your own risk. If you have any more tips and tricks please post them.

We are running CentOS and Plesk 8.2.1 so that is what this article relates to. On different systems things would obviously be different.

You can run this command for a while and see if there is any application that trying to send emails via the web server. This may be a vulnerable application so after disabling it check to see if your qmail remote queue improves. phpBB is the usual suspect.

/usr/sbin/lsof +r 1 -p `ps axww | grep httpd | grep -v grep | awk ' { if(!str) { str=$1 } else { str=str","$1}}END{print str}'` | grep vhosts | grep php

Files: /etc/xinetd.conf
Modification: If you have lots of spare memory you can increase the number of instances and restart xinetd
instances = 200

Files: /etc/xinetd.d/smtp_psa and /etc/xinetd.d/smtps_psa
Modification: you can add -Rt0 to the start as below and restart qmail. This should stop qmail checking for reverse DNS

server_args = -Rt0 /var/qmail/bin/relaylock /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth /var/qmail/bin/true /var/qmail/bin/cmd5checkpw /var/qmail/bin/true

You may want to log into your Plesk and go to Server > Mail > White List If you have the default 127.0.0.1/8 in your White List you are effectively running an open relay. Remove that one and change it to 127.0.0.1/32 (changing the subnet mask to 32 from 8). Why SWsoft have not fixed this yet is unknown.

I still have not found a good way to stop double-bounce messages filling up the qmail queue. This is something that I think SWsoft must address. IMHO, there should be a setting such that rejected emails are sent to /dev/null. At the moment the best solution I have is to install qmHandle.

http://sourceforge.net/projects/qmhandle

and run a cronjob say every 2 hrs to qmHandle -S"failure notice" qmHandle may have a problem finding the pidof command so I edited it to include a direct path to pidof. At any rate qmHandle is a very useful tool for working with qmail.

my ($pidcmd) = '/sbin/pidof qmail-send';

We also added

nameserver 127.0.0.1

as the first nameserver in /etc/resolv.conf and I think it improved performance.


Other useful security fixes you may consider are:

If in /etc/named.conf there is no option for

allow-recursion {
localnets;
};

Then you could add the following line to the options section in your file:

allow-recursion {127.0.0.1; ... all the server ips ....;};


and add this to the options section stop version being broadcast:

version "Dunno";

and add this to stop logging lame servers

// Logging
logging {
category lame-servers { null; };
};


Also you can stop root login. Be careful with this so you don't lock yourself out! Make sure you can login as the wheel user and su from that user to root before you proceed. We added a new user to the wheel group and then I edited /etc/ssh/sshd_config and made the following changes

Protocol 2
PermitRootLogin no
AllowUsers thewheeluseryousetup

I hope someone finds the above of some use.

DivisionX, Inc.
www.divisionx.com

 

[Linulex]

Originally posted by divisionx

I still have not found a good way to stop double-bounce messages filling up the qmail queue. This is something that I think SWsoft must address. IMHO, there should be a setting such that rejected emails are sent to /dev/null. At the moment the best solution I have is to install qmHandle.

We have a very simple solution to this problem:

- disable all catchalls and set them to reject
- create an empty mail on the server.
- alias mailer-daemon to that email address.

Ill explaine a bit: All our servers have an admin subdomain in the form of adminX.linulex.net where X is the servernumber. In this domain we create a mailaccount [email protected] without any config. Plesk will warn that mail will not be delivered, but thats just what we want, mail will go to /dev/null

In /var/qmail/alias create the file .qmail-mailer-daemon with &[email protected] as content.

ALL mail to mailer-daemon (like double-bounces) will now be sent to this email address and disapear into /dev/null.

hope this helps a bit
Jan

 

[divisionx]

Couple of more qmail speedups

Forgot these two:

Increase concurrencyremote setting to say 100. This is done by putting a number in /var/qmail/control/concurrencyremote and then restarting the qmail service.


queuelifetime file located in the control directory has a default of 604800 (in seconds). I set this to 86400.

 

[divisionx]

Thanks Jan!

That is an elegant solution. Some time ago I read about a similar solution so I tried editing .qmail-mailer-daemon and I put an existing email address in it, and restarted qmail to check if double-bounced emails would go to that address. Unfortunately emails neither originate from nor go to the email address in .qmail-mailer-daemon.

Our servers like yours are designated as proteousX.divisionx.com. The bounced emails originate from [email protected] no matter what is in .qmail-mailer-daemon.

As a possible fix I created the [email protected] email address and set it without a mailbox and or forwarding so it is supposed to go to /dev/null/. Fingers crossed I hope it works.

At ant rate thanks very much for your help. Much appreciated.

 

[Linulex]

it doesn't matter what domain the email adres is under, but we use local domains to avoid "trow away" mail from generating traffic. You could just as easely create the nomail address on 1 server and have all the other servers send it there. As long as the .qmail file of that email address is empty or only has a | true in it, everything delivered there will go into /dev/null. In the end all double bounces will be delivered to mailer-daemon.

Another option is to use this perlscript to periodicly clean the queue from offending mail. We run this every hour on every server. Also handy when a server queue is overcome by a spamattack.

#!/usr/bin/perl
use File::Find;

#word to find in the mailspool.  Can be any common trait
#among stale spame.#
#$wordtofind = "MAILER-DAEMON|voxcards";
$wordtofind = "MAILER-DAEMON|Margrit|Auslaender|Berlin";
$num_of_files = 0;
$num_processed = 0;
push (@DIRLIST, "/var/qmail/queue/mess/");
find(\&checkfile, @DIRLIST);
print "Processed $num_processed messages!\n";
print "Deleted $num_of_files messages!\n";
exec('/sbin/service qmail restart');

sub checkfile {
 my $tainted = 0;
 my $queuedir = "/var/qmail/queue";
 my $queuefile = "";
 $name = $_;
 $fullname = $File::Find::name;
 $path = $fullname;
 $path =~ s/\.\///;
 @queuepathparts = split(/\//,$path);
 $messagenum = pop(@queuepathparts);
 $qdir = pop(@queuepathparts);
 print "$File::Find::dir - $name \n";
   open (MESSFILE, "<$name");
   while (<MESSFILE> ) {
    if (/$wordtofind/) {
     print "$name tainted! ";
     $queuefile = "$qdir/$name";
     $tainted = 1;
     push (@taintedfiles, $name);
    }
   } #elihw
   $num_processed++;
   close MESSFILE;
   if ($tainted) {
     print "unlinking Message $queuefile";
# NOTE!! Uncomment the following unlink lines to actually
# delete the queue files
     unlink "$queuedir/mess/$queuefile";
     unlink "$queuedir/remote/$queuefile";
     unlink "$queuedir/todo/$queuefile";
     unlink "$queuedir/local/$queuefile";
     unlink "$queuedir/bounce/$queuefile";
     unlink "$queuedir/info/$queuefile";
     unlink "$queuedir/intd/$queuefile";
     unlink "$queuedir/lock/$queuefile";
     $num_of_files++;
     print " done\n";
   }
}

I have no idea if the code will be ok here. Just save it as something.pl, give it rights 755 and put it in the cron.

I don't take credit for the script, i just found it somewhere on the net but cant remember where.

Jan

 

[microeuropa]

Hi,

I would like to thank all that helped here with their suggestion.
Last night SWSoft entered the server made some changes and gave
a few recomendations also and the system look ok now.

Today is hollyday here and we have two more days for the weekend,
the fire proof will be on monday.

The SWSoft solution passed by creating a new Queue and disabling all
the catchall from the domains. So I'm a little bit suspicious that
I might have the problem again on Monday, when people get back to work.

If the system go back to the same lame performance, we already
have our scrips ready to migrate the mail to our old Postfix server.

I don't know and they didn't tell me, why all the system performance
went to space after the 8.2.1 upgrade. What originated all this.

Again, thank you very much for your help...

Cheers,
Hugo Ferreira

 

[divisionx]

We only have a handful of clients who have catchall email addresses and everything worked fine before the upgrade to 8.2.1. We have done everything we know to speed up qmail but after doing numerous tests it is at least 10 times slower than it was before the upgrade. This is based on dozens of test emails sent to various email addresses we have on remote servers. I think disabling catch-alls will help you but I doubt it will fix the problem. I hope SWsoft will do something about this soon or at least provide instructions on how to set qmail back to its old version until they have sorted this out.

This feels like they forgot to switch off debugging when they compiled.

It would be nice to see a response from SWsoft. We develop software and hardware solutions, some of which has been used on spacecraft, so there is no margin for error. We never release anything until it has been fully tested in-house and produces no warnings or errors and then beta-tested for at least a month in actual situations. We have simulations that create worst-case scenarios. It would be wise if SWsoft put in place aggressive quality assurance procedures before it is too late.

I really hope all goes well for you Hugo.

DivisionX, Inc.
www.divisionx.com

 

[meto]

for me dpkg-reconfigure psa-qmail fixed a problem (debian only)

 

[divisionx]

/usr/local/psa/admin/bin/mchk --with-spam

seems to be the equivalent on CentOS and it definitely improved things.

 

[thewolf]

Hi,

Anyone figured the change introduced by Plesk 8.2.1 that caused the qmail slowness?

Thanks.

 

[microeuropa]

Hi,

I really don't now... I noticed that QMail when
you send an e-mail to undreds of recipients TO:, CC:
or BCC: keeps sheewing the message and delays all
queue... :-/

See'ya

 

[bsasser]

Uhm, Yahoo uses qmail.... it is quite capable of nearly any email task.

 

[kevork]

Hello,

Just to say I have problems with qmail queue, on Panel 8.6 / FC 4.
This began 2/3 days ago.
I tried all recommended here, but still can not get qmail queue flush, it only grows.
I can not get qmail flush, it only grows and grow.

I am convinced that Qmail is not graceful manageable, but why Plesk have not enough tools on panel to manage and tune this MTA ?.

Upgrading to 9.0 is the solution ?.
Hummm, after read how many problems became when people upgraded to 9.0, I get scared to upgrade.

Thanks ...

 

[meto]

At first i'd try to upgrade Fedora, FC4 is quite old... If it was me i'd move to 9.0.1, I had no problem while migration from 8->9 and 9.0.1 fixed some of bugs.

 

[kevork]

Hi meto, thanks for your comments.

Yes, I would dlike to upgrade FC, but doing it remotelly may end in a endless pain ...

By the way, you bring hope to me !, you are almost the only one who has not problem going to plesk 9, as least as I read here !.

I am planning to take 2 new brand dedicated server, one to have plesk running on it, and the other to manage MX in, and SMTP out, using postifx. As my experience I have had very less pain with mail queues, and spam blocking.

This also will free myself using drweb ...

I insist Plesk might offer using other MTA, and a more professional queue managment.

Thank you very much for your comment.