Beim Testen von Applikationen oder beispielsweise Lasttests will man verhindern, dass irgendwelche Mails an Benutzer raus gehen.
Um das zu erreichen bietet postfix das kleine Tool smtp-sink an. Hier werden E-Mails vom MTA normal angenommen, aber statt tatsächlich verschickt, dann einfach in eine Datei geschrieben.
Continue reading SMTP-Sinkhole mit postfix smtp-sinkManchmal passiert es, dass eine Webseite- oder das Passwort eines Mailserver-Benutzers gehackt wird.
In der Folge steigt die mail queue auf dem Server rasant an.
In einem solchen Fall ist sehr rasches eingreifen des Administrators gefragt, denn nicht selten sendet der Server so innert wenigen Stunden Zehntausende Spam-Mails raus und die IP-Adresse des Servers landet auf diversen blacklisten, aus die man zum Teil nur sehr schwierig wieder herauskommt.
Zumindest die Mails, welche noch in der Mailqueue sind, kann man aber so entfernen, bevor dieser ebenfalls herausgeschickt werden.
Bei einem Hosting-Webserver besteht ein grosses Problem wenn eine Webseite, beispielsweise ein CMS wie Drupal, Joomla, usw. „gehackt“ wird: Durch Sicherheitslücken gelingt es den hackern einen PHP-Mailclient auf der Wesbeite zu installieren und Zehntausende Spam-Mails über den Mailserver auf dem Webserver zu verschicken.
Auch Web-Benutzer. welche ein CRM-CMS installieren und über die Marketting Funktion „Newsletter“ Mails zu tausenden sendet sind eine Gefahr.
Denn verschickt ein Server zu viele „Spam-Mails“ wird dieser schnell auf diverse blacklists kommen. Und das will man nicht.
Bei vielen SSL Zertifikats-Anbietern, wie z.B: StartSSL muss man noch die intermediate Zertifikate, bzw. die certificate chain angeben, damit das Zertifikat als gültig anerkannt wird.
Dies ist vor allem wichtig, da ab PHP 5.6 sämtliche SSL-Verbindungen ohne gültiges Zertifikat abgelehnt werden.
Continue reading postfix/dovecot: SSL intermediate/certificate chain
Nachdem ich mein Postfix für die Verwendung mit mysql Tabellen konfiguriert hatte, bekam ich auf einmal beinahe täglich mails, die den Text: "451 4.3.0 Error: queue file write error" und/oder: "Temporary lookup failure" enthielten:
Transcript of session follows. Out: 220 mail.domain.tld ESMTP Postfix In: EHLO [X.X.X.X] Out: 250-mail.domain.tld Out: 250-PIPELINING Out: 250-SIZE 10240000 Out: 250-VRFY Out: 250-ETRN Out: 250-AUTH PLAIN LOGIN Out: 250-AUTH=PLAIN LOGIN Out: 250-ENHANCEDSTATUSCODES Out: 250-8BITMIME Out: 250 DSN In: AUTH PLAIN XXXXXXXXXXXXXXXXXXXXXXX Out: 235 2.0.0 Authentication successful In: MAIL FROM:<sender@example.org> SIZE=1037 Out: 250 2.1.0 Ok In: RCPT TO:<empfaenger@example.org> Out: 250 2.1.5 Ok In: DATA Out: 354 End data with <CR><LF>.<CR><LF> Out: 451 4.3.0 Error: queue file write error Session aborted, reason: lost connection |
Zwar schien alles zu funktionieren und die mails kamen auch immer noch rein, ich wollte jedoch der Meldung nachgehen.
Im maillog wurde ich dann fündig, denn folgende Fehlermeldung tauchte ziemlich oft auf:
warning: mysql query failed: Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '= |
Dies kam davon, weil ich die postfix Datenbank noch auf dem alten Server angelegt hatte und auf dem der Zeichensatz: latin1_swedish_ci standardmässig eingestellt war, beim neuen Server war jedoch UTF8 standard.
Das Problem kann man dann lösen, wenn man die Postfix Datenbank wie folgt konvertiert:
Login auf mysql:
mysql -uroot -p |
dann für jede Tabelle:
ALTER TABLE tbl_name CHARACTER SET utf8 COLLATE utf8_general_ci; |
und für jedes Textfeld:
ALTER TABLE tbl_name MODIFY email varchar(255) CHARACTER SET utf8; |
