Kategorien
Linux

Bounced Mails am IMAP Server finden und erneut versenden

Was tun wenn durch einen Fehler jede Menge Mails vom Mailserver gebounced wurden und man es nicht allen Leuten zumuten möchte dass sie die Mails erneut versenden müssen?

Alle an diesem Tag gesendeten Mails finden und via Script erneut in die Mail-Queue einordnen – was so einfach klingt ist im Grunde auch so einfach! (fast) 😉

Angenommen die gesendeten Mails liegen alle im Verzeichnis /srv/imap/{benutzer}/Maildir/.Sent/cur/ – dann könnte man anhand des Dateinamens schon mal ein wenig eingrenzen, alle Mails vom 19. und 20. Juli beginnen mit 1532… (Unix Timestamp).

Wir suchen also alle Mails die mit 1532 beginnen und prüfen dann mit „ls -al“ und grep ob sie an besagtem Tag versendet wurden – es interessieren uns nur die vom 20. Juli.

Alle Mails die gefunden werden injizieren wir dann unserem Postfix mit dem „sendmail“ Kommando.

#!/bin/bash

cd /srv/imap/

IFS=“

for I in $(ls);do

if [ -d „$I/Maildir/.Sent“ ]; then
for F in $(ls -al $I/Maildir/.Sent/cur/1532* 2>&1 |grep -v „No such file or directory“);do
TOSEND=$(echo $F|grep „Jul 20″|awk ‚{print $9}‘)
if [ $TOSEND ]; then
echo „$TOSEND“
cat „$TOSEND“||sendmail -t
fi
done
fi

done

Damit werden alle Mails erneut an den Mailserver übergeben und ausgeliefert.

Kann einem schon mal helfen, besser wär’s natürlich man kommt erst nicht in die Situation…!

Kategorien
Linux

Amavis/Postfix Mailversand an bestimmte externe IP Adresse binden

Wenn ein Server zwei oder mehrere IP Adressen hat, dann sollte Postfix seine Mails möglichst über eine schicken damit der PTR Record vom empfangenden Mailserver korrekt aufgelöst werden kann.

Ist das nicht der Fall lehnen viele Mailserver die Mails ab. Oder wie bei meinem Fall die zweite Adresse liegt in einem dynamischen Bereich und wird von Blacklists entsprechend geführt und somit vom Mailserver auch abgelehnt.

Also muss Postfix an eine bestimmte Adresse gebunden werden und zwar für ausgehende Mails, das erledigt man mit folgender Zeile in der Datei /etc/postfix/main.cf

smtp_bind_address = öffentliche_ip_adresse

So weit so gut – nur verhindert die default Einstellung von Amavis den Versand der Mail noch mit folgender Fehlermeldung:

Jul 22 18:52:39 servername amavis[11337]: () (!)DENIED ACCESS from IP öffentliche_ip_adresse, policy bank “

Aber auch das kann man umgehen indem man Amavis bei bringt von welchen Adressen es Mails zu akzeptieren hat, dafür editieren wir die Datei /etc/amavis/conf.d/50-user und tragen folgende Zeile ein:

@inet_acl = qw( 127.0.0.1 öffentliche_ip_adresse weitere_interne_ipadressen );

Nachdem Neustart von Postfix und Amavis sollte die Mails dann wie gewollt über die richtige Adresse versendet werden!

 

Günstige SSL Zertifikate – Nginx/Dovecot/Postfix

Nachdem es inzwischen wohl nicht mehr unter Sport sondern eher zum guten Ton gehört verschlüsselte SSL Verbindungen mit zu schneiden oder per Man-In-The-Middle Attacke abzuhören (zumindest für den einen oder anderen Service-Dienst unserer lieben Politiker), hatte ich mal wieder die Aufgabe für einen Server ein SSL Zertifikat zu organisieren.

Die Preise fallen ja in letzter Zeit ein wenig und so muss man zum einfachen Absichern einer Web-Anwendung nicht mehr unbedingt hunderte Euros im Jahr ausgeben.

Wer nur eine einzige Domain mit ssl-Zertifakt versorgen will kann sich bei ssls.com das günstiges Zertifikat für knapp 5 $ im Jahr (bei 5 Jahres Vertrag) holen!

Die einzelnen Schritte sind recht einfach – erst das gewünschte Produkt in den Warenkorb und anschließend bezahlen, jetzt noch den CSR einreichen und nach kurzer Zeit bekommt man eine Zip Datei geliefert in der alles Nötige enthalten ist.

Das CSR generiert man sehr schnell mit folgendem Befehl:

openssl req -nodes -newkey rsa:2048 -keyout myserver.key -out server.csr -subj „/C=AT/ST=Tirol/L=Kufstein/O=Meine Firma/OU=IT/CN=mysubdomain.mydomain.com“

 

Anschließend kann hat man die erwähnte CSR Datei.

Erhält man das E-Mail mit dem Zip-Archiv retour sollten darin neben dem eigentlichen Zertifikat „mysubdomain.mydomain.com.crt“ auch noch diese drei Dateien vorhanden sein:

AddTrustExternalCARoot.crt
COMODORSADomainValidationSecureServerCA.crt
COMODORSAAddTrustCA.crt

Aus den vier Dateien kann man jetzt ein Bundle schnüren in dem alle Infos enthalten sind die die verschiedenen Dienste so brauchen:

cat mysubdomain.mydomain.com.crt COMODORSAAddTrustCA.crt COMODORSADomainValidationSecureServerCA.crt AddTrustExternalCARoot.crt > ssl-bundle.crt

Jetzt beinhaltet die Datei ssl-bundle.crt auch die CA-Daten so dass die Clients das Zertifikat bis zum Aussteller erfolgreich zurück verfolgen können und keine Fehlermeldung mehr auswerfen.

Die Integration in nginx ist recht einfach und schnell:

einfach die folgenden Zeilen der vhost-Konfiguration hinzufügen

    ssl on;
    ssl_certificate /etc/ssl/certs/ssl-bundle.crt;
    ssl_certificate_key /etc/ssl/private/mysubdomain.mydomain.com.key;
    ssl_session_timeout 5m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers „ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4“;
    ssl_prefer_server_ciphers on;

Ganz ähnlich funktioniert es beim dovecot /etc/dovecot/dovecot.conf:

ssl = yes
ssl = required
ssl_protocols = !SSLv2 !SSLv3
ssl_cert =

ssl_key = Und auch den Postfix sollte man nicht vergessen (/etc/postfix/main.cf):

smtpd_tls_security_level = may
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_loglevel = 0
smtpd_tls_cert_file = /etc/ssl/certs/ssl-bundle.crt
smtpd_tls_key_file = /etc/ssl/private/mysubdomain.mydomain.com.key
smtpd_tls_auth_only = no
smtpd_tls_received_header = yes

Für den Fall dass sich jemand wundert woher die Datei /etc/ssl/private/mysubdomain.mydomain.com.key kommt – diese wurde beim erstellen des CSR angelegt und beinhaltet den private-Key des Zertifikats, sollte also niemals abhanden kommen!

Ob das Ganze funktioniert kann man recht schnell und einfach mit dem openssl Befehl testen:

openssl s_client -connect mail.kufnet.at:993

Das Ergebnis sollte dann in etwa wie oben im Screenshot aussehen – wichtig ist das „verify return:0“, dann sollte der Client keine Fehlermeldung ausgeben.

Mailserver Reputation – was’n’das?

Jan 11 09:19:53 mail2 postfix/smtp[5122]: 630932F00E68: host exchange.globex.se[195.198.86.212] refused to talk to me: 421  temporary blocked by GlobalView, see http://www.commtouch.com/check-ip-reputation

Schöne Meldung und mal wieder was neues 🙂

Spam hat keiner gerne und so lassen sich alle immer wieder mal was neues einfallen, keine Ahnung wie lange es die Variante jetzt schon gibt (meine Server hatten bisher wohl immer eine gute „reputation“) aber Anfang der Woche bin ich über die obige Meldung bei einem neuen Mailserver gestolpert.

Mit der Mailserver Reputation hat man das klassische Henne-Ei Problem – ein neuer Mailserver hat noch nie Mails versendet und hat daher auch keine Reputation, ein paar wenige Mailserver (z.B. von aol) lehnen aber Mails von solchen Servern ab .

Wie kriegt man jetzt aber eine Mailserver Reputation hin damit der eigene Mailserver akzeptiert wird? Ganz klar, die Antwort liegt auf der Hand – wir reisen in die Vergangenheit, installieren den Mailserver bereits zu einer Zeit wo’s noch keine Reputation-Sperren gegeben hat und schon hat Jahre später unser Server massig Mails versandt und eine passende Reputation.

Ach da war ja das Problem mit den Zeitreisen, na egal Ende des Jahres geht die Welt eh unter – wer braucht da eine Reputation? Wobei sie ja eigentlich schon seit dem 8.1.2012 untergegangen ist und daher obiger Eintrag aus dem Logfile sowieso obsolet!

OK, wieder zurück zur Realität – es gibt drei Möglichkeiten die mir auf die Schnelle einfallen:

  1. Einfach aussitzen, irgendwann hat der Server schon genügend Mails an andere Mailserver geschickt die nicht blocken aber in die Statistik mit einfließen.
  2. Man kontaktiert die Betreiber der Reputation-Lists und versucht sein Glück dass die einen Aufnehmen bzw. einen Weg zeigen wie man eine gute Reputation bekommt. (versuche ich gerade, mit mäßigem Erfolg)
  3. Die E-Mails bei betroffenen Domains einfach über einen anderen Server senden.

In meinem Fall konnte ich mir mit Variante 3 kurzfristig gut weiterhelfen weil noch ein alter Mailserver aktiv war, dessen Reputation gut und ein Eintrag in der transport-Map von Postfix die Mails einfach über diesen leitet.

Auf lange Sicht ist das aber keine Lösung darum werde ich mit Variante 2 noch weitermachen und hoffe dass ich nicht auf Lösung 1 zurückgreifen muss.

2012-01-18 Nachtrag: Wie’s scheint werden nach dem x-ten Zustellversuch die Mails dann ähnlich wie beim Greylisting durchgelassen. Also verzögert eine fehlende Reputation nur die Zustellung und verhindert sie nicht komplett.

Spam-Vermeidung durch Blocken der unallocated IP Adressen

Vor einigen Jahren habe ich es selbst mal auf einem Mail-Server im Einsatz gehabt, das Ausfiltern von als „unallocated“ gekennzeichneten Adressen. Bereits damals wurden aber diese Adressen zunehmend auch zugewiesen und so hätte man die Tabelle der geblockten Bereiche ständig prüfen und aktualisieren müssen.

Angesichts der Tatsache dass aus solchen Bereichen tatsächlich kein Spam angeliefert wurde und mir der Aufwand zum Prüfen und Aktualisieren viel zu hoch war, habe ich mich schnell wieder davon verabschiedet.

Es gibt aber tatsächlich nach wie vor Provider die das einsetzen:

(host mx.sa.ew.hu[212.108.200.67] said: 421 4.5.1 sender mx in an unallocated or reserved network ! (in reply to MAIL FROM command))

 Was steckt da eigentlich dahinter?

Die IANA kümmert sich um die Vergabe der IP-Adressen, wie sich inzwischen ja herum gesprochen hat gehen die IPV4 Adressen langsam zur Neige und IPV6 kommt noch nicht so richtig aus den Startlöchern.

Daher werden seit ein paar Jahren zunehmen auch reservierte Bereiche zugewiesen. IANA bietet dazu eine Webseite an welche die verschieden Bereiche und deren Zuordnung auflistet.

Der betroffene Mailserver hat eine IP-Adresse aus dem Bereich „176/8“ der im Mai 2010 zugewiesen wurde und eigentlich schon länger im Einsatz ist. Kaum zu glauben dass es mancher Hoster bis heute noch nicht geschafft hat seine Blockinglisten  entsprechend anzupassen!

Ich habe via whois Auskunft die Mailadresse des Betreibers herausgefunden und versuche jetzt ihn zu kontaktieren, mit etwas Glück überdenkt er sein Handeln ja und hebt die unnütze Sperre auf.

Apropos Glück – heute ist ja Freitag der 13.!!! 🙂

2012-01-18 Nachtrag: Man glaubt es kaum, aber nach 5 Tagen wurden tatsächlich die geblockten IP-Adressen aus deren Mailserver Konfiguration entfernt!

Kategorien
Linux

Postfix mit TLS – Fehlermeldung beim Verbinden mit openssl

Ich richte gerade einen Postfix-Mail-Server mit TLS  verschlüsselter Verbindung ein, folgende Fehlermeldung habe ich beim verbinden mit „openssl“ bekommen:

openssl s_client -connect 192.168.100.1:587
CONNECTED(00000003)
5899:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:601:

Wenn man sich klassisch mit „telnet 192.168.100.1 587“ auf den Server verbindet kommt folgendes:

Trying 192.168.100.1…
Connected to 192.168.100.1.
Escape character is ‚^]‘.
220 karli ESMTP Postfix (Ubuntu)
ehlo domain.com
250-karli
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

Man könnte jetzt meinen der Server verschlüsselt die Verbindung nicht so wie er sollte – das stimmt allerdings nur zum Teil!

Verwendet man beim „openssl“ Befehl die korrekte Syntax, dann funktioniert das Ganze ohne Probleme! 🙂

openssl s_client -starttls smtp -connect 192.168.100.1:587

Die Lösung ist also das „-starttls“ Kommando mit zu schicken!

Kategorien
Linux

Postfix – warning: mail_queue_enter: create file maildrop Permission denied

Nach der gestrigen Aktion habe ich heute am Mailserver noch folgende Fehlermeldungen im Logfile gefunden:

Dec 13 11:45:41 server28 postfix/postdrop[12873]: warning: mail_queue_enter: create file maildrop/735325.12873: Permission denied

Dass es mit den Berechtigungen zu tun hat war mir klar, bei der Installation und Rücksicherung gab’s damit ein paar kleinere Probleme.

Der Befehl „postfix set-permissions“ funktioniert unter Ubuntu nicht, dafür müssten sämtliche Postfix Module installiert sein und das ist selten der Fall.

Als Alternative gibt es den Befehl „postfix check“ der eine Liste mit den Dateien oder Verzeichnissen liefert mit denen es Probleme gibt.

Der Befehl liefert dann Meldungen wie die folgende:

postfix/postfix-script: warning: not owned by root: /var/spool/postfix/etc/ssl

Anhand der Fehlermeldungen kann man dann schnell die entsprechenden Rechte auf die Verzeichnisse oder Dateien setzen.

Ein Neustart von Postfix hat dann allerdings noch nicht geholfen – in meinem Fall blieben noch jede Menge postdrop Prozesse aktiv und brachten nach dem Neustart von Postfix noch Fehler.

Erst ein:

service postfix stop
killall /usr/sbin/postdrop
service postfix start

brachte dann den gewünschten Effekt und die Fehlermeldungen waren Geschichte…

Kategorien
Linux

Postfix/Goldfish Vacation nicht ganz reibungslos

Ich habe vor kurzem bei einem Mailserver mit Postfix Goldfish als Abwesenheits-Tool eingebaut – eigentlich funktioniert es sehr gut, bis auf eine Kleinigkeit:

Trifft man auf einen Absender in der Form:

From: =?ISO-8859-15?Q?Jens_B=FCrger?=
<jens@buerger.de>

Klappt alles wunderbar – aber wenn die Zeile wie folgt aussieht gibts Probleme:

From: jens@buerger.de

Dann wird beim der Vacation-Mail folgender Empfänger daraus konstruiert:

To: „rom:jens“@buerger.d

Also irgendwie scheint sich das Teil da ein wenig zu verwurschteln und nimmt einen Teil von From, ein Stück vom Namen und einen Teil der Domain – aber nicht ganz das Richtige! 🙂

Hab das Ganze mal an die Mailingliste weitergegeben, mal sehen wie gut die betreut ist und wie schnell sich jemand meldet. Ansonsten werd ich mich selbst um einen Patch kümmern müssen…

Anmerkung: Einen Patch habe ich inzwischen geschrieben, wer daran Interesse hat – bitte einfach melden!

Kategorien
Linux

dronebl.org Blacklist sperrt localhost (127.0.0.1) aus

Eine gewisse Menge an Mails kommt bei mir täglich rein – das tägliche Sicherungsmail diverser Server z.B. – nur heute waren es deutlich weniger als sonst!

Per Fernwartung habe ich als erstes die Server kontrolliert und deren Logfiles geprüft, Sicherungsmail ist überall raus gegangen – also als nächstes meinen Mailserver kontrolliert, ein paar sind wie gewohnt angekommen und bei ein paar weiteren habe ich folgende Meldung im Logfile gefunden:

Feb 6 04:38:06 argev postfix/smtpd[29236]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 554 5.7.1 Service unavailable; Client host [127.0.0.1] blocked using dnsbl.dronebl.org; from=<root@argev3.com> to=<supp@argev1.com> proto=ESMTP helo=

Wie man anhand der Abfrage bei dronebl.org gut sehen kann ist dort die localhost Adresse 127.0.0.1 nicht zum ersten Mal gelistet!

Darf eigentlich nie vorkommen, da es aber doch der Fall ist muss ein Workaround her.

In der Postfix Konfiguration /etc/postfix/main.cf steht bei mir der Eintrag

mynetworks = 127.0.0.0/8 192.168.93.0/24

drinnen, den kann ich in diesem Fall gut verwenden um die „smtpd_client_restrictions“-Regel ein wenig zu entschärfen!

Also sieht anschliessend der Eintrag wie folgt aus:

smtpd_client_restrictions = permit_mynetworks, reject_rbl_client bl.spamcop.net, reject_rbl_client sbl.spamhaus.org, reject_rbl_client list.dsbl.org, reject_rbl_client dnsbl.njabl.org, reject_rbl_client dnsbl.dronebl.org

Leider kann man’s nur recht schwer testen – es sei denn jemand kennt einen einfachen Weg einer Blacklist die 127.0.0.1 Adresse erneut einzuimpfen 🙂