Greylisting und "nicht-Standard" Server

H

heinztoedter

New Member
Hallo Plesk/Greylisting-Experten!

Ich habe jetzt seit einer Woche Greylisting mit dem Controlpanel im Einsatz, so wie es hier von huschi und haggybear vorgestellt und beschrieben wird.

Zuerst war ich auch absolut beeindruckt, mittlerweile sind aber ein paar unschöne Probleme aufgetaucht, die ich hier mal zur Diskussion stellen möchte.

Erstmal meine Konfiguration: Suse 10.1, Plesk 8.3, Greylisting und CP aktuell und einwandfrei installiert (inkl. des Compiler-Fehlers in tls.c, der von Claus VB auf seiner Seite beschrieben wird). Außerdem nach Problemen mit extrem hoher Load (>50!) die Tipps von Huschi zu Timeout und Zertifikat.

Wenn ich per telnet teste, bekomme ich auch die Meldung 421 temporay envelope zurück, Datenbank und Logfile auch einwandfrei (soweit ich es beurteilen kann).
Weiterhin wahrscheinlich wichtig: alle Domänen haben sowohl einen MX-Eintrag auf den Server mit Greylisting, als auch (mit niedrigerer Prioritätm, also höheren Werten) MX-Einträge zu Backup-Servern bei anderen Dienstleistern, damit unser Server auch mal Pause machen darf.

Ich beobachte jetzt folgendes:
1. Viele Server verhalten sich einwandfrei: der erste Zustellversuch wird in der Datenbank protokolliert, nach einigen Minuten kommt der zweite Versuch und wird dann wunderbar zugestellt.
2. Einige Server machen nur einen Versuch, dann ist Ruhe, auch nach Tagen kein zweiter Kontakt. Das ist ja prinzipiell so gewollt (ein Versuch=Spammer), allerdings gehören zu diesen Servern auch einige von z.B. T-Online, ebay und anderen großen Providern.
3. Einige Server sind nach diesem ersten Versuch sofort beleidigt und geben eine Fehlermeldung an den Absender zurück (in der Form: Server nicht erreichbar, allerdings je nach Provider unterschiedliche Meldungen). Auch hier wieder T-Online und andere wichtige Provider.
4. und der Rest nutzt gleich nach dem ersten Versuch die Backup-Server, so daß die Mail dann über diese Backups läuft (diese Backups sind auf den Whitelisten). Hierzu gehört z.B. auch der Mailserver dieses Forums.

Das Problem sind jetzt im Wesentlichen die Server, die sich entsprechend Punkt 3 verhalten, und natürlich die Kandidaten von T-Online und Co. mit Verhalten entsprechend Punkt 2.

Da sich jetzt etliche Nutzer über nicht ankommende Mails beschwert haben, bin ich überhaupt erst auf diese Merkwürdigkeiten aufmerksam geworden, eigentlich bin ich total begeistert von der Geschichte, da ich jetzt seit einer Woche Ruhe vor Viagras und Co. habe. Die Frage ist bloß, was kann ich tun, damit "dumme" Server von "guten" Absendern erkannt werden. Es scheint die Nutzer weniger zu stören, jeden Tag mehr als 100 Spammails zu bekommen, als das mal eine Mail nicht ankommt (kann ich ja auch irgendwie nachvollziehen....)

Ich habe jetzt bereits viele T-Online, ebay, web.de-Server auf die Whitelist gesetzt und zumindest etwas Ruhe in das Ganze gebracht, das scheint aber nicht die wirkliche Lösung zu sein.
Mich würde erstmal interessieren, ob meine Beobachtungen so korrekt sind, und ob es vielleicht Verbesserungsvorschläge / Erfahrungswerte dazu gibt.
Bin für jede Hilfe dankbar :-)
Heinz
 
Das T-Online-Server so schnell aufgeben ist mir neu.
Ich habe lediglich von einem Schweizer Provider gehört, der wohl keinen 2ten Zustellversuch macht.
Ich teste es mal schnell mit T-O:
Erster Versuch 09:08 geblockt; zweiter Versuch 09:35 durchgelassen
Kann ich also nicht bestätigen.

Was mir in den Logfiles auffällt ist, daß tatsächlich viele Absender mit @t-online (und auch ebay, uvm.) drin stehen, die IP dazu aber gar nicht zu T-Online gehört.

Das Problem mit Mail-Clustern ist allerdings bereits bekannt. Beispiel Amazon:
Während bei den meisten Providern die Emails und deren Zustellung immer vom selben Server (selbe IP) kommen, ist dies bei Amazon anders: Hier kann die selbe Email von verschiedenen IP's eingeliefert werden. Und jedesmal wird sie von Greylisting geblockt. Etwas unschön, aber meistens kommt die Mail irgendwann dennoch an. Das Maximum lag bei mir bisher unter 30 Stunden Verzögerung.

Zum Backup-MX ist noch zu sagen:
Einige Spammer versuchen ein Greylisting zu umgehen, indem sie direkt den MX mit geringster Priorität nehmen.
Häufig ist es die falsche Annahme, man würde was versäumen, wenn der Server mal ausfällt. Ordentliche Email-Server versuchen mind. 3 Tage lang den Zustellversuch bevor sie aufgeben.

huschi.
 
Aber prinzipiell sollte man doch schon den Backup MX auf die selbe Greylisting Datenbank zugreifen lassen, um ein Umgehen des Greylisting zu umgehen, oder nicht?
 
Zumindest sollte er auch Greylisting aktiviert haben -- dass die Server sich die Datenbank teilen ist nicht in jedem Fall möglich und führt auch zu einem "Single Point of Failure", den man ja mit mehreren MX-Rechner gerade verhindern will. Aber Huschi hat es ja bereits gesagt: Heutzutage braucht man keine Secondary-MXe mehr -- die machen eher mehr Probleme als sie lösen.

Viele Grüße,
LinuxAdmin
 
Ich habe jetzt aufgegeben und das Greylisting abgeschaltet...
Heute haben jetzt wieder diverse Kunden angerufen, und von Problemen berichtet, hauptsächlich von Anrufern, die keine Mails schicken können und sofort die Fehlermeldungen mit Nichtzustellbarkeit bekommen. Immerhin haben die sich dann noch gemeldet, kann man ja nicht unbedingt erwarten.

Schön wäre es gewesen, wenn man jetzt die komplette Empfänger-Domain auf eine White-List hätte setzen können, aber das funktioniert (zumindest bei Plesk 8.3) ja wohl nicht.
Dabei bleibt dann für mich absolut fragwürdig, warum einige Server das mit der sofortigen Fehlermeldung so machen, kann doch immer mal ein Ausfall sein, und dafür gibt es ja dann auch die secondary mx Einträge.

Nun freue ich mich wieder auf Viagra und Co und blicke etwas ratlos auf die vergangenen Tage zurück...

Heinz
 
Schicken die Kunden die Mails über Deinen Server (d.h. haben die den als Relay/Mailserver eingetragen), oder schicken die über einen Provider?
 
Der Server ist der Mail-Server für unsere Kunden, manche nutzen ihn, andere nehmen die Server ihrer Zugangsprovider (verschiedene, von T-Online, EWEtel, Hansenet...). Die Probleme kommen aber von den Servern der Versender (heute z.B. ya.com (Provider in Spanien), aventis.com, bosch.de, vaillant.de, einige Unis, T-Online.de/com. Es sind also nicht nur die Mailcluster, sondern auch viele Server von Firmen, die ihr Netz wohl in Eigenregie betreuen. Und das Hauptproblem ist nicht die Verzögerung sondern die sofortige Erstellung einer Unzustellbarkeits-Rückmail. Mit der Verzögerung kann man ja leben (ist ja nur beim ersten Mal), aber wenn die Mails gar nicht zugestellt werden, ist das einfach nicht tragbar, da bekomme ich Ärger...
Heinz
 
Ich kann ebenfalls nicht bestätigen, dass die non-RFC-Mailer so verbreitet sind. Wir benutzen in der Firma seit vielen Jahren Greylisting mit durchweg positivem Resultat.
 
Ich glaube wir kommen hier an einen Punkt, wo Heinz uns ein paar Fakten liefern muß. (Also Logfiles, Beispiele von Fehlermails, usw.)
So ganz blicke ich bei den Aussagen auch nicht wirklich durch.
Z.B. die seltsame Mischung aus Mail-Server der Zugangsprovider und dennoch das Greylisting des Servers... :eek:
Oder welche Emails werden denn geblockt und nicht neu zugestellt? Woher nimmst Du die Information welche Server das angeblich sind?

Sonst kommt hier noch die fehlerhafte Stimmung auf, daß Greylisting nicht funktionieren würde. Und das ist definitiv nicht der Fall.

huschi.
 
Dann ein paar Klarstellungen, hatte ich doch aber alles im ersten Versuch relativ breit dargelegt:

- Greylisting funktioniert, wenn alle Server sich an die Spielregeln halten (also nach einigen Minuten / zumindest Stunden) erneute Zustellversuche machen

- bei mir hat der Einsatz über 8 Tage ergeben, daß viele Server sich nicht an diese Spielregeln halten, und zwar insbesondere Mailserver von großen Anbietern (T-Online, ebay, Amazon, Unis, Web.de) aber auch durchaus von diversen anderen Servern, wobei die Beobachtung ist, dass diese a) sofort eine Fehlermeldung (Unzustellbare Mail) liefern oder b) auch nach Tagen (!) keinen neuen Zustellversuch unternehmen oder c) direkt zum Backup-Server mit niedriger Priorität umschalten.

Besonders Punkt a) hat dazu geführt, daß die Sender sich per Telefon an unsere Kunden gewandt haben und ich dann in Erklärungsnot gekommen bin :-( Nachvollziehen konnte ich das leider nicht, meine eigenen Tests sind immer angekommen. Aber aus Spaß ruft mich auch niemand an und meckert.

Punkt b) und c) läßt sich relativ klar mit dem ControlPanel zeigen, wenn also auch nach drei Tagen kein erneuter Zustellversuch zu sehen ist und die Mail nicht ankommt oder bei c) halt, daß die Mail bereits wenige Sekunden später ankommt, im ControlPanel aber nicht angezeigt wird (Backup_Server sind auf Whitelist, Whitelist_Server werden nicht angezeigt). Geprüft habe ich das alles mit dem ControlPanel, wobei mir durchaus klar ist, das Absendeadressen falsch sein können, was man ja durch die nette IP-Auflösung gut überprüfen kann.

Das mit den Zugangsprovidern war eine Antwort auf die Frage davor, hat sicher nichts mit der Geschichte zu tun, ist mir auch klar, ist aber auch nicht seltsam. Wenn ein Kunde halt lieber über seinen Zugangsprovider verschickt als über seinen / unseren Server, ist da doch nichts seltsam. Die Problemmails kommen natürlich von außen.

Ich wollte hier halt meine Erfahrungen der 8 Tage schildern, weil es halt bei mir zu diesen Problemen gekommen ist, und ich trotz relativ gründlicher Vorbereitung dazu vorher nichts gelesen hatte (Im Verlauf habe ich dann hier im Forum die eine gefüllte Whitelist entdeckt, was für mich auf ähnliche Erfahrungen hindeutet). Vielleicht habe ich ja auch nur sehr sensible Kunden, aber als Fazit für mich möchte ich schon festhalten, daß ein Tool schwierig zu nutzen ist, wenn man mit den größten Mail-Versendern von vornherein Probleme erwarten darf. Daß die Ursache für die Probleme nicht beim greylisting liegt, sondern bei den Betreibern der anderen Server möchte ich durchaus anerkennen, ist halt nur schwer vermittelbar, und für unsere Kunden war ich halt der "Buhmann", weil sie statt Mail nur noch böse Anrufe von bestimmten Versendern bekommen haben.
 
Ich hab eben mal in die Whitelist geschaut (die kommt übrigens mit dem Paket aus der Distribution (Fedora) - ich habe mich seit ich mit Greylisting zu tu hab (ca. 5 Jahre) noch nie darum kümmern müssen).
Da stehen schon ein paar drin; Die meisten, weil sie zu langsam erneut versuchen - oder einen zu großen Pool von MTAs haben. Ein paar ganz wenige (z.B. Amazon) haben uniq-Sender-IDs auch beim wiederholten Versuch.
Die wenigsten (eigentlich fast niemand) wissen nicht, dass die RFC bei einem non-permanent-error Wiederholungen verlangt. Und T-Online steht in der Whitelist gar nicht drin - Mails von denen kommen bei uns aber trotzdem an.

Ich glaube dir nicht, dass du in 8 Tagen Greylisting als generell untauglich herausgefunden hast, wenn ich das selbst seit 5 Jahren erfolgreich einsetze. Das dürfte hier noch einigen anderen genauso gehen.

Die Frage ist jetzt, was du falsch machst und was wir anders machen. Wenn du das rausgefunden hast, wird Greylisting auch für dich hervorragend funktionieren. Wenn nicht, dann lass es einfach sein - aber poste dann hier nicht Aussagen wie "die halbe Welt ist nicht RFC-konform."

Erster Ansatzpunkt wäre z.B. eine ordentliche Whitelist. Ordentlich im Sinne von extern gemanaged und per update auf dem laufenden gehalten.
 
Last edited by a moderator:
casper99 said:
den Backup MX auf die selbe Greylisting Datenbank zugreifen lassen, um ein Umgehen des Greylisting
Click to expand...
Umgangen werde kann da nichts. Wenn der Backup-MX eine eigene Greylist-DB hat, wird eher mehr gelistet als weniger. Im worst-Case werden <Anzahl MXe>+1 Zustellversuche nötig. Wenn sie die DB teilen, max 2.

LinuxAdmin said:
führt auch zu einem "Single Point of Failure"
Click to expand...
In dem Fall nicht schimm. Ist der Policy-Daemon nicht erreichbar, wird einfach nicht gelistet, sondern angenommen. Der Schlimmste Fall ist also, dass Spams durchkommen, die sonst geblockt worden wären.
 
heinztoedter said:
Dann ein paar Klarstellungen,
Click to expand...
Damit meinte ich aber Fakten Fakten Fakten!
Auszüge aus Logfiles (denn dort kann man die IP mit der Absender-Domain vergleichen), die häufig von Dir erwähnte Fehlermeldung als Email (denn dort steht die exakte Fehlermeldung drin), etc.
Entweder um uns Deine These zu beweisen (denn das könnte ja für alle Interessant sein), oder damit wir Dir erklären können, wo Du einen (Denk-)Fehler hast und es alles nicht so ist, wie Du es Dir ausmahlst.

Zusatzinfo:
Wie Du oben erwähnst hast Du Plesk drauf. Daher:
a) Gibt es einige Installations-Probleme beim Plesk-Qmail-Greylisting. Evtl. ist Deine Installation nicht korrekt gelaufen.
b) Im Mailllog stehen die IP's und die Absender getrennt von einander.
c) Das Greylisting-Control-Panel ist zur korrekten Überprüfung nicht wirklich gut geeignet.

Ergo:
Ohne diese o.g. Fakten macht es überhaupt keinen Sinn hier weiter zu diskutieren.

huschi.
 
Das mit der Whitelist hatte ich ja schonmal angesprochen. Es gibt ja dnswl.org - Protect against false positives .

Wobei ich bisher auch gut ohne mit klar komme. Bisher hat sich noch kein Kunde beschwert.

Und das Emails von T-Online oder Amazon nicht ankommen, das kann ich auch nicht bestätigen. Dahingegend läuft alles einwandrei.

Suse 10.1, Plesk 8.3, Qmail-Patch 1.05

Fehlermeldungen in den Emails und Logs würd ich aber auch gerne mal sehen!
 
Meine Erfahrungen:
  • web.de, GMX, T-Online und andere große Provider kommen nach 7 Minuten durch
  • xemail.de dauert zwischen 50 und 80 Minuten
  • Spammer-IPs versuchen bis zu 3x innerhalb von 5 Minuten mit verschiedenen IPs (Greylisting wirkt)
  • gute Spammer warten zwischen 20 und 25 Minuten und schicken mit identischer IP (selten)

Greylisting plus Mailkonten bei "mailnull.com" plus GMAIL oder GMX Spam-Filter haben bei mir eine Rate von 98%. Es gibt keine False-Positives an meine Domains.

Gruß
Claus
 
Hallo Leute,

ich muss huschi recht geben, ich habe es soeben mal mit:

- t-online.de
- web.de
- gmx.de
- aol.com
- online.de
- versch. (deutsche) Unis
- HP/ Quimonda :-) / AMD
- versch. private Mailserver

probiert. Und alles war komform bzw. kam auch durch.

Evtl. wie bereits vorgeschlagen ein paar Logs dazu ?
 
Abropo Greylist, mir fällt dazu eine Frage ein.
Ich habe 2 Mx Einträge, auf Server 1 mit der Priorität 10 und z.B auf Server 2 mit 20.
Nun benutze ich auf Server 1 Greylisting. Der zweite Server ist ein Postfix minimal System, auf dem kein Greylist aktiv ist.
Wird nun versucht die Nachricht wiederholt an Srv 1 zu schicken oder landet sich gleich bei Srv 2.
Ich habs jetzt noch nicht ausprobiert, evtl. hatts hier schonma Jmd. gemacht.

Danke
 
Theoretisch sollte der 2. MX nur angesprochen werden, wenn der erste einen Totalausfall hat. Also überhaupt keine Connection annimmt oder mit permanent-Error antwortet.

Ich habe es mal eine Weile beobachtet. Und seltsamerweise passieren die seltsamsten Dinge. Konnte aber keine Regelmäßigkeit feststellen. Auch nicht MTA-Spezifisches. Selbst ein Postfix lieferte mal über den einen, mal über den anderen ein. Mal kam die Connection innerhalb von Sekunden auf den 2.MX; ein anderes mal nach 30 Minuten auf den selben.

Ich hab mir auch nicht viel Zeit genommen um das zu analysieren. Für mich war es lediglich wichtig, daß es nicht grundsätzlich ausgenutzt wird um dennoch Spam's einzuliefern.

huschi.
 
Komisch, meine Erfahrungen sind etwas anders: Auf meinem secondary-MX sehe ich im Greylisting-Log einige Hits, die vorher nicht auf dem primary-MX abgelehnt worden sind. Das deckt sich auch mit dem was ich vorher irgendwo gelesen hatte, dass es wohl Spammer gibt, die versuchen das Greylisting aus zu hebeln, in dem sie sich auch MX-Rechner connecten, die aufgrund ihrer Priorität wahrscheinlich Backup-MXe sind -- in der Hoffnung, dass die bei einem anderen Provider stehen, der kein Greylisting oder andere rigorose Test implementiert hat.

Viele Grüße,
LinuxAdmin
 
You must log in or register to reply here.
Back
Top