Tag Archiv für Postfix

Lösung des Problems von Postfix mit der OpenSSL Option ZLIB

Vor knapp 2 Wochen habe ich meinen Mailserver von FreeBSD 9.3 auf FreeBSD 10.2 umgezogen. Ich hatte so ziemlich alles vorher getestet, allerdings nicht die Verschlüsselung des Mailverkehrs von Postfix und Dovecot, weil das offizielle Zertifikat auf den Hostnamen ausgestellt war, der zum Zeitpunkt des Testens noch auf dem alten Server konfiguriert war. Da das offizielle StartSSL Zertifikat 2 Tage nach dem Umzug ausgelaufen wäre, habe ich mir ein neues ausstellen lassen und das dann gleich auf dem neuen Server aktiviert. Als dann der Produktivbetrieb auf dem neuen Server startete, produzierten  die SMTP und SMTPD Prozesse von Postfix plötzlich beunruhigend viele Abstürze mit Signal 11:

Dec 10 16:17:10 saruman kernel: pid 72535 (smtpd), uid 125: exited on signal 11
Dec 10 16:18:49 saruman kernel: pid 72552 (smtp), uid 125: exited on signal 11
Dec 10 16:18:49 saruman kernel: pid 72556 (smtp), uid 125: exited on signal 11
Dec 10 16:18:49 saruman kernel: pid 72557 (smtp), uid 125: exited on signal 11
Dec 10 16:18:50 saruman kernel: pid 72553 (smtp), uid 125: exited on signal 11
Dec 10 16:18:50 saruman kernel: pid 72555 (smtp), uid 125: exited on signal 11
Dec 10 16:18:50 saruman kernel: pid 72551 (smtp), uid 125: exited on signal 11
Dec 10 16:18:50 saruman kernel: pid 72550 (smtp), uid 125: exited on signal 11
Dec 10 16:18:51 saruman kernel: pid 72554 (smtp), uid 125: exited on signal 11
Dec 10 16:19:44 saruman kernel: pid 72542 (smtpd), uid 125: exited on signal 11
Dec 10 16:28:18 saruman kernel: pid 72785 (smtpd), uid 125: exited on signal 11

Nach einigem Ausprobieren (Deaktivieren sämtlicher Postfixerweiterungen wie Postgrey, Amavisd-New, dccifd, policyd-weight), Neukompilieren von Postfix mit allen Paketen, von denen es selber abhängig ist, und natürlich ausgiebigen Netzrecherchen bin ich auf diesen Thread der Postfix-User ML gestoßen und die schon 2 Jahre alte und für ein 2.9er Postfix unter FreeBSD 9.2 vorgeschlagenen Lösung, die OpenSSL Kompression beim Bauen von OpenSSL wegzulassen hat mir aktuell auch noch geholfen. Nachdem ich erst OpenSSL ohne ZLIB Option und dann Postfix neu kompiliert hatte, traten keine Signal 11 Crashs mehr auf.

RBLs für Postfix

Ich wollte schon länger endlich mal die von mir in Postfix genutzten RBLs dokumentieren (das sind direkt die entsprechenden Zeilen aus der main.cf):

reject_rbl_client dynablock.easynet.nl,
reject_rbl_client proxies.blackholes.easynet.nl,
reject_rbl_client ix.dnsbl.manitu.net,
reject_rbl_client relays.bl.kundenserver.de,
reject_rbl_client relays.nether.net,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client list.dsbl.org,
reject_rbl_client psbl.surriel.com,
reject_rbl_client spamguard.leadmon.net,
reject_rbl_client dnsbl.ahbl.org,
reject_rbl_client virbl.dnsbl.bit.nl,
reject_rbl_client all.rbl.kropka.net,
reject_rbl_client dnsbl.njabl.org,
reject_rbl_client cbl.abuseat.org,
reject_rbl_client bl.csma.biz,
reject_rbl_client 0spam.fusionzero.com,
reject_rbl_client aspews.ext.sorbs.net,
reject_rhsbl_sender dsn.rfc-ignorant.org,
check_sender_access hash:/usr/local/etc/postfix/spamlist,
check_policy_service inet:127.0.0.1:12525,
reject_unauth_destination,
permit

 

#  reject_rbl_client sbl.csma.biz,
# scheint nicht mehr zu existieren: reject_rbl_client opm.blitzed.org,
# blockt freebsd.org: reject_rbl_client all.rbl.kropka.net,
# Fuer die kubanischen Emailpartner eines Kunden rausgenommen (24.03.07):
# reject_non_fqdn_sender, #reject_unknown_sender_domain,
# Scheint nicht mehr zu existieren (09.02.07): reject_rbl_client relays.bl.kundenserver.de,
# beide RBLs wurden zusammengefasst reject_rbl_client sbl.spamhaus.org,
# reject_rbl_client xbl.spamhaus.org,
# RBL hatg dicht gemacht: reject_rbl_client relays.ordb.org,
# blocked Volksbank (08.09.06): reject_rbl_client cbl.abuseat.org, testweise reaktiviert
# nicht erreichbar (27.02.06): reject_rbl_client dun.dnsrbl.net,
# reject_rbl_client spam.dnsrbl.net,
# blockt T-Online (27.10.05) reject_rbl_client dnsbl.ahbl.org,
# blockt GMX (07.10.05) reject_rbl_client list.dsbl.org,
# blockt Kunden von XYZ  reject_rbl_client bl.spamcop.net,
# blockt Kunden von YZX reject_rbl_client spamsources.fabel.dk,
# reject_rbl_client kr.rbl.cluecentral.net,
# reject_rbl_client kr.countries.nerd.dk,
# blockt Kunden von ZXY reject_rbl_client cn.rbl.cluecentral.net,
# reject_rbl_client cn.countries.nerd.dk,
# reject_rbl_client korea.services.net,
# reject_rbl_client dnsbl.njabl.org,
# reject_rbl_client relays.bl.kundenserver.de,
# blockt Mailer Uni Marburg: reject_rhsbl_sender dsn.rfc-ignorant.org,
# blockt GMX: reject_rbl_client blackholes.five-ten-sg.com,
# kostenpflichtig: reject_rbl_client dialups.visi.com,
# reject_rbl_client relays.visi.com,
# reject_rbl_client dnsbl.njabl.org,
# warn_if_reject reject_unverified_sender,
# reject_rbl_client dul.dnsbl.sorbs.net,
# reject_rbl_client blackholes.easynet.nl,
# reject_rbl_client bl.spamcop.net,
# eingestellt: reject_rbl_client proxies.relays.monkeys.com,
# reject_rbl_client formmail.relays.monkeys.com,
# eingestellt: reject_rbl_client dialups.relays.osirusoft.com,
# reject_rbl_client inputs.relays.osirusoft.com,
# reject_rbl_client spamhaus.relays.osirusoft.com,
# reject_rbl_client spamsites.relays.osirusoft.com,
# reject_rbl_clientsocks.relays.osirusoft.com, # reject_rbl_client proxy.relays.osirusoft.com,
# reject_rbl_client spews.relays.osirusoft.com,
# reject_rbl_client sg.countries.nerd.dk,
# reject_rbl_client tw.rbl.cluecentral.net,
# reject_rbl_client tw.countries.nerd.dk,
# reject_rbl_client vn.rbl.cluecentral.net,
# reject_rbl_client vn.countries.nerd.dk,
#  kostenpflichtig: reject_rbl_client blackholes.mail-abuse.org,
#  kostenpflichtig: reject_rbl_client relays.mail-abuse.org,

Die RBLs habe ich größtenteils von einer Liste von DECLUDE. Eine weitere Aufstellung von RBLs findet man bei DNSBL.info.

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.