neunzehn83.de

Ein Mann, ein Blog, kein Plan.

Mailjet und die Deliverability zu @t-online.de

Als kleiner Mailserver-Betreiber tut man sich bekanntlich schwer, eine gute Zustellbarkeit zu erreichen. Für wirklich wichtige E-Mails, bspw. transaktionale E-Mails eines Online-Shops wie Bestellbestätigungen usw., sollte man daher auf einen externen SMTP-Service zurückgreifen.

Da gibt es einige: Mailgun, Amazon SES, etc. Wer dann noch darauf achten muss oder will, dass die über den SMTP-Service versendeten Daten nicht in irgendwelchen US-Clouds landen hat es schon schwerer. Mailjet sieht hier nach einer ordentlichen Alternative aus.

Aus aktueller Erfahrung kann ich aber sagen, dass es dort selbst mit den bezahlten Paketen ohne exklusive IP immer wieder zu Problemen mit der Zustellbarkeit kommt. Insbesondere mit @t-online.de Adressen aber auch des öfteren zu @yahoo.de und ähnliche.

Ich wollte das zuerst nicht so recht glauben, dass so ein großer Anbieter solche Probleme mit der Zustellbarkeit zu einem der größten deutschen Mailprovider hat. Der Support wollte darauf aber nicht eingehen, hat das Problem aber bestätigt und als Alternative dazu nur ein Upgrade auf eine exklusive IP angeboten (Kosten: ab 50 Euro im Monat).

Da meiner Meinung nach eine exklusive IP nur mit entsprechend hohen Versandzahlen Sinn macht, scheidet für mich wie es scheint Mailjet als Mailversender aus.

Es ist verständlich, dass deren shared IP-ranges blacklist-anfällig sind, da darüber jeder free-user wilde E-Mails versenden darf. Warum bietet Mailjet dann aber keine premium shared IP-ranges an, welche nur bezahlte Accounts nutzen dürfen? Hier hätte Mailjet die bessere Kontrolle über blacklisting.

Ich bin also auf der Suche nach einer Alternative zu Mailjet, einem zuverlässigen SMTP-Service gehostet in Deutschland oder der EU. Selbstverständlich darf dieser Service auch etwas kosten. Das ist gar nicht so einfach, hier etwas zu finden. Vorschläge willkommen.

Kündigungs-Bluff: 25% Rabatt bei UnityMedia / KabelBW

Da ich demnächst in ein Gebiet umziehe, das nicht von UnityMedia versorgt wird, habe ich meinen Kabelanschluss kürzlich gekündigt. Und das kann ich allen Bestandskunden auch nur empfehlen, denn: Seit meiner Kündigung erhalte ich immer tollere Angebote von UnityMedia.

Zuerst kam eine E-Mail mit dem Betreff "Ihre Kündigung - Letzte Chance" und bot mir 20% auf alle Internet-Produkte. Zwei Wochen später kam dann die "Allerletzte Chance" mit 25% auf alle Produkte sowie:

Noch nicht überzeugt? Dann finden wir sicher ein individuelles Angebot, das Ihnen besser gefällt. Wir freuen uns auf Sie!

Donnerwetter! Das nenn ich Service. Für mich kommen diese Angebote mangels Versorgung im neuen Wohngebiet natürlich nicht in Frage - und UnityMedia sollte das eigentlich wissen - aber allen Bestandskunden würde ich den Kündigungs-Bluff schon empfehlen!

Armer kleiner Postmaster

Geht es nur mir so, oder wird es immer schwieriger als kleiner privater Mailserver-Betreiber eine gute "deliverability" zu erreichen? Soweit ich das beurteilen kann, habe ich alles in meiner Macht stehende getan und sämtliche neumodischen Technologien in die Postfix-Config geworfen: feste IP, rDNS, SPF, DKIM und DMARC. Sämtliche "Mail-Checker" und Blacklist-Auskünfte geben meinem Mailserver und dessen IP Höchstnoten! Und dennoch: Immer wieder passiert es, dass Mails an große Anbieter still und leise im Spam-Ordner landen.

Beispiel gmail: Hier liefere ich sowieso nur noch mit IPv4 ein, da eigentlich alle Mails, die über IPv6 eingeliefert werden, im Spam-Ordner landen - aber das ist ein anderes Thema. Hin und wieder sind aber auch über IPv4 eingeliefert E-Mails betroffen und landen teilweise im Spam, ohne besondere Rückmeldung vom Mailserver. Wahrscheinlich immer dann, wenn ein mehr oder weniger entfernter IP-Nachbar ein Spam-Vorfall hatte.

Beispiel AOL: Auch hier landeten meine Mails plötzlich im SPAM-Ordner. In meiner Verzweiflung habe ich an den AOL Postmaster geschrieben und auch tatsächlich eine Antwort erhalten:

Your issue has been resolved.  Please allow two business days for delivery to improve.  If you are still receiving errors after two business days, please submit a new support request at https://postmaster.aol.com/trouble-ticket .

Warum aber überhaupt meine IP eine schlechte Reputation hatte ist nicht nachvollziehbar. Generell sind die IP-Reputationssysteme der großen Mailprovider absolut intransparent.

Ständig auf seine IP-Reputation zu achten und Mailprovider anzuschreiben ist frustrierend. Zumal die Mailserver meistens die Mails anstandslos entgegennehmen und ohne weitere Nachricht in den Spam-Ordner zustellen. Man muss also aktiv Mails an alle großen Provider senden und den Posteingang prüfen (!) um überhaupt feststellen zu können, dass man betroffen ist.

Aus diesen Grund überlege ich mir, ob ich für E-Mails an Gmail&Co nicht einfach einen SMTP-Relay a la Mailjet oder Amazon SES vor meinen Postfix schalte.

Die Idee beim Betrieb eines eigenen Mailservers ist zwar eigentlich, die Daten möglichst bei sich zu halten und nicht unnötig sämtliche E-Mails an US-Unternehmen zu übergeben - wenn man die Nutzung eines SMTP-Relays aber auf die ohnehin an US-Provider adressierten Mails beschränkt macht es eigentlich keinen Unterschied.

Habe ich einfach Pech mit meiner IP und dessen Nachbarn oder ist dies ein generelles Problem privater Mailserver-Betreiber?

fail2ban.log mit fail2ban überwachen für hartnäckige Angreifer

Wenn man mit fail2ban die eigene Logdatei überwacht kann man besonders hartnäckige Angreifer für einen längeren Zeitraum ausschließen. Dazu wird ein eigener Filter auf die fail2ban.log Datei angelegt. Fail2ban logt hier sämtliche bans und unbans. Wenn also ein Angreifer bspw. bereits mehrere Male wegen fehlgeschlagener SSH Login-Versuche aufgrund des "ssh"-Jails gebannt wurde, kann dieser jetzt mit einer längeren bantime versehen werden.

Beispiel aus der fail2ban.log für einen geduldigen Angreifer, der jedes Mal die bantime des ssh-Jails abwartet:

2016-05-24 04:28:30,113 fail2ban.actions[726]: WARNING [ssh] Ban 218.255.3.67
2016-05-24 04:38:30,867 fail2ban.actions[726]: WARNING [ssh] Unban 218.255.3.67
2016-05-24 04:38:49,899 fail2ban.actions[726]: WARNING [ssh] Ban 218.255.3.67
2016-05-24 04:48:50,681 fail2ban.actions[726]: WARNING [ssh] Unban 218.255.3.67
2016-05-24 04:49:13,715 fail2ban.actions[726]: WARNING [ssh] Ban 218.255.3.67
2016-05-24 04:59:14,497 fail2ban.actions[726]: WARNING [ssh] Unban 218.255.3.67
2016-05-24 04:59:38,533 fail2ban.actions[726]: WARNING [ssh] Ban 218.255.3.67
2016-05-24 05:09:39,313 fail2ban.actions[726]: WARNING [ssh] Unban 218.255.3.67

Der Filter für die fail2ban.log ist somit eigentlich ganz einfach. Taucht eine IP hier mehr als maxretry auf, erfolgt ein Ban mit extra hoher bantime.

Wir legen einen Filter für die fail2ban eigene Logdatei unter /etc/fail2ban/filter.d/fail2ban.conf an:

[Definition]
failregex = fail2ban.actions\[(.*)\]?: WARNING \[(.*)\] Unban <HOST>
ignoreregex = fail2ban.actions\[(.*)\]?: WARNING \[fail2ban\] Unban <HOST>

Wir aktivieren unser Jail in /etc/fail2ban/jail.local:

[fail2ban]
enabled = true
action   = iptables-allports[name=fail2ban]
filter = fail2ban
logpath = /var/log/fail2ban.log
findtime = 86400
bantime = 86400

Dieser Filter ist deutlich rabiater als die Standardwerte von fail2ban und blockt alle Ports für einen ganzen Tag.

Je nach fail2ban Version kann es vorkommen, dass der Unban des zuerst auslaufenden ssh-Jails auch den fail2ban-Jail aufhebt. Ich konnte dies mit fail2ban unter Debian Jessie zwar nicht nachvollziehen, ein Workaround hierzu wäre aber beim fail2ban eigenen Jail auf die Unbans statt Bans zu monitoren, somit ist der fail2ban-Jail niemals parallel zu anderen Jails aktiv, sondern erst direkt nach deren Aufhebung.

Verschleierung von "SPIEGEL Plus" unter der Lupe

SPIEGEL Plus ist das neue Bezahlangebot von spiegel.de bei dem einzelne Artikel teilweise nur "verschwommen" angezeigt werden bis man diese eben durch einen kleinen Centbetrag freischaltet. So sieht das dann aus:

SPON1

Aus rein technischem Hintergrund habe ich mir diese Verschleierung der SPIEGEL Plus Texte einmal genauer angeschaut - und war überrascht wie einfach man an die unverschleierten Texte rankommt.

Über dem verschleiertem Text liegt ein Filter, der für diese verschwommene Optik verantwortlich ist. Mit einem Web-Debug-Tool wie Firebug lässt sich diese CSS-Regel aber einfach entfernen. Darunter kommt dann ein verschleierter aber lesbarer Text zum Vorschein:

SPON2

Dieser Text könnte natürlich tatsächlich ordentlich verschlüsselt sein und sich somit nicht ohne Weiteres in den Originaltext zurückwandeln lassen. Was hier aber bereits auffällt, ist die Tatsache, dass die Wortlängen wohl beim Verschleiern erhalten bleiben. Zudem fällt auf, wenn man annimmt bei dem Ausschnitt handelt es sich um ein Interview, dass der Name des Interviewers (fett dargestellt) mit einem Semikolon endet - üblich wäre hier wohl ein Doppelpunkt. Diese zwei Zeichen liegen in der Zeichentabelle ziemlich nah beinander.

ASCII-Tabelle:
DEC CHAR
57  9
58  :
59  ;

Der Verdacht liegt nahe, dass hier einfach jeder Charcode um eins erhöht wurde, und der Text somit verschleiert wurde. Wir testen das!

Dabei hilft die Tatsache, dass jeder verschleierter Absatz eine Klasse "obfuscated" hat. Es ist also ein Leichtes, mit Javascript sämtliche p-Elemente mit dieser Klasse durchzugehen, die Charcodes aller Buchstaben um eins zu verringern und das Ergebnis wieder in das p zu schreiben. Das Leerzeichen hat mit 20 übrigens den niedrigsten Charcode und ist deshalb als einzige Ausnahme von dieser Subtraktion ausgeschlossen, da davor in der Zeichentabelle die nicht-druckbaren Zeichen beginnen.

  1. // Verschwommen-Filter entfernen
  2. document.getElementsByClassName('obfuscated-content')[0].parentElement.className='';
  3. // Hinweis-Box entfernen
  4. document.getElementsByTagName('svg')[0].nextSibling.nextSibling.innerHTML='';
  5. // Beim durchlaufen der Chars müssen wir Ersetzungen innerhalb von Tags auslassen
  6. var inside_tag = 0;
  7. // alle verschlüsselten Elemente durchlaufen
  8. var p=document.getElementsByClassName('obfuscated');
  9. for (var i=0; i<p.length; i++) {
  10. var result ='';
  11. var text = p[i].innerHTML;
  12.  
  13. // Alle Buchstaben durchlaufen
  14. for (var j=0; j<text.length; j++){
  15. if (text[j]=='<') inside_tag = 1;
  16. var cc = text.charCodeAt(j);
  17. var diff = cc==32 ? 0 : 1;
  18. result += inside_tag ?
  19. text[j] :
  20. String.fromCharCode(cc+diff); // wir _addieren_ diff
  21. if (text[j]=='>') inside_tag = 0;
  22. }
  23. p[i].innerHTML = result;
  24. }
  25. alert(':)');

(Um keinen funktionsfähigen Code hier anzubieten, wird oben "diff" zum Charcode (cc) addiert statt subtrahiert!)

Für Testzwecke(!) kann dies auch komfortabel direkt auf der Seite in der URL-Leiste ausgeführt werden. Obiger Code als Einzeiler:

  1. avascript:document.getElementsByClassName('obfuscated-content')[0].parentElement.className='';document.getElementsByTagName('svg')[0].nextSibling.nextSibling.innerHTML='';tg=0;p=document.getElementsByClassName('obfuscated');for(var i=0;i<p.length;i++){f='';t=p[i].innerHTML;l=t.length;for(var j=0;j<l;j++){if(t[j]=='<')tg=1;cc=t.charCodeAt(j);diff=cc==32?0:1;f+=tg?t[j]:String.fromCharCode(cc+diff);if(t[j]=='>')tg=0;}p[i].innerHTML=f;}alert(':)');

Google-Chrome unterschlägt aus Sicherheitsgründen das "javascript:" am Anfang des Strings, wenn man das direkt aus der Zwischenablage so einfügt. Deshalb muss das "j" selbst in die Adressleiste getippt werden und dann kann obiger Code gepastet werden.

Und damit hier keine Missverständnisse aufkommen: Dies ist keineswegs eine Anleitung, um das Bezahlangebot von spiegel.de zu umgehen! Hier geht es rein um die technischen Aspekte dieser Verschleierung. Wer sich tatsächlich für den Artikel-Inhalt interessiert sollte diesen natürlich einfach kaufen! Aus diesem Grund ist der Beispielcode auch an einer Stelle verändert, um keine copy-paste Lösung hier anzubieten!

Archiv »