Probleme mit einem Postfix-Mailserver, der seine Userdaten aus einer MySQL-DB holt

Vor ein paar Tagen bekam der Mailserver eines von mir betreuten Root-Servers mehrfach pro Tag Probleme, die sich zunächst in Mails mit Fehlerbenachrichtigungen manifestierten. In diesen Mails, die ein Subject der Art "Postfix SMTP server: errors from unknown[216.1.64.211]" und ungefähr folgendem Inhalt hatten:

Transcript of session follows.

 Out: 220 hostname.server.tld ESMTP Postfix (2.5.5)
 In:  EHLO DougTest
 Out: 250-hostname.server.tld
 Out: 250-PIPELINING
 Out: 250-SIZE 50000000
 Out: 250-ETRN
 Out: 250-STARTTLS
 Out: 250-AUTH LOGIN PLAIN
 Out: 250-AUTH=LOGIN PLAIN
 Out: 250-ENHANCEDSTATUSCODES
 Out: 250-8BITMIME
 Out: 250 DSN
 In:  MAIL FROM:<believersn3@iinet.net.au>
 Out: 250 2.1.0 Ok
 In:  RCPT TO: <username@kundendomain.tld>
 Out: 451 4.3.0 <username@kundendomain.tld>: Temporary lookup failure
 In:  DATA
 Out: 554 5.5.1 Error: no valid recipients
Session aborted, reason: lost connection

Nach ein paar Minuten hat sich dann scheinbar alles wieder normalisiert und es waren nur noch Spuren in den Logs zu finden. Auszug aus den Logdatein: postfix-mysql-problem.log Dieses Problem trat mehrfach pro Tag auf, aber in absolut unregelmäßigen Abständen und mit unterschiedlich häufigen Vorfällen pro Tag. Nach 2 oder 3 Tagen kam es dann auch zu Loginproblemen via POP3 und IMAP, u.a. auch via Webmail, denn auch Cyrus arbeitet hier mit virtuellen Usern via MySQL-DB. Es konnte dann auch keine Mail mehr verschickt werden. Googlen nach "fatal: mysql:/usr/local/etc/postfix/mysql-mydestination.cf(0,lock|fold_fix): table lookup problem" und anderen Symptomen brachte zunächst nichts. Ich habe dann erstmal die Zahl der postfix smtp und amavisd child Prozesse hochgesetzt und gegenseitig angepaßt, da ich erst dachte, daß es vielleicht bei der Zahl der Prozesse die bei Postfix und Amavisd-new sich gegenseitig zuarbeiten, vielleicht klemmt – aber das hatte keinen nennenswerten Erfolg. Erst das Suchen nach "mysql to many connections" brachte mich auf diese Seite und damit der Lösung näher. Eine Überprüfung des Werts von max_connections vom MySQL-Server mit

show variables like 'max_connections';

zeigte dann, daß der Default-Wert des mysql-server 5.0 Ports unter FreeBSD 6.4 sogar nur 100 beträgt. Ich habe ihn dann zunächst mit

set GLOBAL max_connections=500;

vorläufig hochgesetzt und dann durch Einfügen einer Zeile

set-variable=max_connections=500

in der Rubrik [mysqld] der /usr/local/etc/my.cnf den Wert dauerhaft gesetzt. Seitdem ist das Problem nicht wieder aufgetreten. Wie man im Log /var/log/messages sehen kann, findet gleichzeitig ein brute force Eindringversuch statt und da sowohl bei jeder eintreffenden Mail als auch bei jedem Mailabruf mindestens eine MySQL-Abfrage auslöst, treibt das die Zahl der gleichzeitigen Verbindungen erheblich in die Höhe und so kam es durch die wieder ansteigende Spamwelle, den brute force Angriff und die natürlich auch noch stattfindenden MySQL-Verbindungen durch PHP-Webanwendungen zu Situationen, in denen der Default-Wert von 100 Verbindungen nicht ausgereicht hat.