Diskussion:Greylisting

Eventueller Nachteil

Eventueller Nachteil:

Wie oft muessen Mailserver laut RFC eine das Ausliefern einer E-Mail probieren, wenn so ein "temporaerer Fehler" auftritt? Bzw. wie oft probieren sie es in der Praxis.

Was passiert, wenn dann beim zweiten Versuch mal ein echter temporaerer Fehler auftritt?

(nicht signierter Beitrag von 85.181.24.236 (Diskussion) 18:14, 28. August 2005 (CEST))

Unsere Erfahrungswerte: Bei täglich etwa 400 neuen IP's werden 10-20% akzeptiert. Die durchschnittliche Verzögerung beträgt etwa eine Stunde. Rund die Hälfte der akzeptierten IP's schafft es unter 1/2 Stunde, ein weiteres Drittel unter 2 Stunden, der Rest braucht länger. Nichtakzeptanz seriöser Absender ist sehr selten, kommt aber vor. Wir setzen einmal akzeptierte IP's auf eine Whitelist - ohne das wären die Zeitverzögerungen für uns unerträglich.

(nicht signierter Beitrag von 85.214.17.92 (Diskussion) 11:15, 9. November 2005 (CET))

Whitelisting großer Provider / Zustellungsdauer

Zwei Punkte sind aus meiner Sicht als technischer Leiter einer 40-Mann-Werbeagentur anzumerken:

a) Whitelisting großer Provider

Durch das Whitelisting großer Provider erhöht man erheblich die Menge Spam, die man bekommt, zumindest wenn man auf Basis der Absenderadressen und nicht auf Basis der IP-Adressen der absendenden IP-Adresse whitlistet. (Die Lösung dieses Problems ist SPF, das für uns im Übrigen sehr viel mehr tut als Greylisting.) Der Anteil des Spams von Mails, die Absender @aol, @msn oder @gmx haben, ist zumindest bei uns recht hoch, >30%.

Whitelisting ist für uns und fast alle Mail-Server-Admins, die ich kenne, eher ein Mittel zum Durchlassen wichtiger Kunden-Mail - wenn auch nur eine Mail eines großen Kunden im Spamfilter landet, ist das eine Katastrophe, und zwar vor allem aus imagetechnischen Gründen.

Dann gibt es natürlich noch die großen Kunden, deren Mailserver ständig auf diversen RBL landen, weil die Mailadmins vor allem aufgrund ihrer niedrigen Lohnforderungen ausgewählt wurden und entsprechend nicht in der Lage sind, ihre Server vernünftig einzurichten. Ich kenne mindestens zwei Mailserver-Architekturen großer internationaler Unternehmen, die von jedermann als Spam-Relay verwendet werden können (und auch ständig werden, daher die RBL-Einträge). Auch diese muß man whitelisten.

Mit dieser Vorgehensweise erreicht man jedoch genau das, auf das die Spammer hoffen, und offensichtlich mit Erfolg. Das Problem eines nichtzustellbaren Mails hat der Sender und nicht der Empfänger. Bei jedem halbwegs korrekten System wird der Sender über die negative Zustellung informiert und muß entsprechend handeln. Nimmt der Sender mit dem Empfänger Kontakt auf (z.B. telefonisch), kann man den Sender sehr wohl bitten, eine alternative Adresse zum Senden zu verwenden. Somit wird dieser den Unterschied sofort bemerken. Das ist mittlerweile auch eine übliche Vorgehensweise, da es, wie beschrieben, leider einige Provider gibt, die sich nicht ausreichend um ihre Systeme kümmern.

Weiters gibt es WEB-Tools (z.B. test.meinmail.info), die der Sender ausführen kann, um festzustellen, wie es um seinen Account steht und ggf. mit seinem Provider Kontakt aufnehmen kann (Beschwerde, Support-Ticket). Schließlich ist die Pflicht des Mailanbieters seinen Kunden ordentliche Leistung zu liefern.

Generell Whitelisten ist definitiv keine gute Idee, da damit auch das schlampige Behandeln der oben beschriebenen Provider akzeptiert wird, während andere (dem whitelistenden Mail-Admin unbekannte) sehr wohl danach trachten müssen, sauber zu bleiben.

--Martin xbt (Diskussion) 22:45, 8. Mai 2012 (CEST)

b) Zustellungsdauer

Die Anmerkung, daß E-Mail keine schnelle Zustellung garantiert führt im echten Leben nirgendwohin, weil die Praxis für die meisten Leute heutzutage anders aussieht - Maillaufzeiten von mehr als ein, zwei Minuten existieren im Geschäftsverkehr praktisch nicht (es sei denn, es geht um große Anhänge). Somit reagiert jeder Kunde (zu Recht!) verwundert, wenn er eine Antwort auf eine Mail geschrieben hat, eine Viertelstunde später anruft und zu hören bekommt, seine Mail sei noch nicht da. Wir haben nicht mehr 1994.

Glücklicher- und sinnvollerweise sind alle Mailserver, mit denen unser Server zu tun hat, auf Greylisting-Intervalle zwischen 30 und 180 Sekunden eingestellt. Somit stellt aus meiner persönlichen Sicht Greylisting keine wesentliche Verzögerung im Mailverkehr dar.

Ich überlasse es talentierteren Wikipedisten, den Artikel der Praxis angemessener zu formulieren. ;)

(nicht signierter Beitrag von 84.60.150.109 (Diskussion) 22:47, 15. Oktober 2006 (CEST))

Die 30 s Greylisting-Intervalle helfen leider gar nichts, weil im RFC 2821 unter Abschnitt 4.5.4.1 ausdrücklich empfohlen wird, das Retry-Intervall von temporär abgelehnten Mails auf mindestens 30 min. zu setzen. --132.180.194.66 14:14, 14. Dez. 2006 (CET)

Formulierungen

Der Artikel hört sich für mich nach einer Werbeschrift an oder nach einem Verkaufsgespräch. Zumal es sich leicht aushebeln lässt. Bitte etwas nüchterner/zurückhaltener formulieren und nicht wie das siebente Weltwunder anpreisen. Dank. Und bitte Leute unterschreibt eure Beiträge (indem ihr am Ende 4 Mal das Tilde-Zeichen hinschreibt. Das wird dann automatisch in eure Unterschrift umgewandelt). 217.88.7.35 13:42, 3. Nov. 2006 (CET)

Funktionsweise

Im Abschnitt Funktionsweise findet sich folgender Satzteil: Wurde eine E-Mail mit dieser Kombination von Adressen noch nie empfangen. Es müsste mal jemand verdeutlichen, ob mit Adressen diejenigen des Absenders oder des Empfängers gemeint sind. --Sammler05 19:40, 17. Dez. 2006 (CET)

Spams um 87% reduziert, Mails von GMX: ca. 7 Minuten

Ich wollte nur einen kurzen Beitrag zu Greylisting leisten: Ich liebe Greylisting, denn es reduziert meinen Spam auf 13% und meine Mails, die ich von GMX an meine Domain sende, sind nach rund 7 Minuten da. Ohne Greylisting brauchen sie 15 bis 30 Sekunden. Damit kann ich gut leben. Jeder, der einen eigenen dedizierten Server hat, sollte IMHO Greylisting einsetzen. Meine 2 Cent. ClausVB 02:09, 30. Jan. 2007 (CET)

Greylisting abstrakt betrachtet

Vielleicht sollte man erwähnen, dass das Verfahren nicht nur auf E-Mails beschränkt ist. Wir verwenden ein Greylisting-Verfahren auf unserem Enemy Territory-Server: jeder ankommende Spieler wird für 2 Minuten daran gehindert, mitzuspielen, wenn seine Spieler-GUID dem Server noch unbekannt ist. Nachdem der Spieler diese Zeit abgewartet hat, wird seine GUID in einer Textdatei gespeichert und er muss nie wieder warten. Wenn nun ein Cheater von dem Server gekickt wird, kommt er immer wieder mit neuen GUIDs zurück - und an genau der Stelle wird ihn das Greylisting in den Wahnsinn treiben. --Martin von Wittich 20:42, 21. Jan. 2008 (CET)

Erfolgsquote 99,9%

Seit Aktivierung von Greylisting erhalte ich praktisch kein Spam mehr - zudem spart es erheblich Systemlast ein.

(nicht signierter Beitrag von 89.247.220.99 (Diskussion) 20:24, 29. Januar 2008 (CET))

Ich hatte ähnlichen Erfolg mit Greylisting - seit etwa 2 Wochen bekomme ich jedoch jede Menge Angeboten für "tolle, billige Uhren" - in deutscher in in englischer Sprache. Wenn jemand ähnliche Erfahrung hat würde ich den Artikel gerne updaten. (nicht signierter Beitrag von 91.57.218.25 (Diskussion) 00:48, 30. Okt. 2010 (CEST))

Hauptnachteil Mailverzögerung

Für mich stellt sich die Mailverzögerung als Hauptnachteil dar. Und zwar richtig böse. Ich bin mir gewohnt Mails innerhalb weniger Minuten zu erhalten, und nicht innerhalb von Stunden. Greylisting ist etwas für Leute die bewusst Mailverzögerungen wollen. Nein Danke. Lieber mache ich Sender Verify.

(nicht signierter Beitrag von 84.73.41.86 (Diskussion) 17:27, 27. Februar 2008 (CET)

Anmerkung: Wenn man das richtig implementiert, gi bt es kaum noch Verzögerungen, da eine vernünftige grelisting Implemntierung eine auto-whiltelist hat.

(nicht signierter Beitrag von 83.171.172.35 (Diskussion) 00:39, 12. März 2009 (CET))

Ablehnung auch mit Heuristik möglich

Dies ist zumindest ungenau formuliert: auch bei einer heuristischen Überprüfung kann eine Mail nach der Übertragung der gesamten Daten (direkt nach der DATA-Phase) noch abgelehnt bzw. verweigert werden, die Verantwortung dafür zu übernehmen, z.B. mit '554 Sorry, message looks like SPAM to me'. --Zac67 10:58, 7. Sep. 2008 (CEST)

Greylisting RFC-konform?

Greylisting ist m.E. nicht RFC-konform. Aus http://www.ietf.org/rfc/rfc2821.txt:

     421 <domain> Service not available, closing transmission channel
        (This may be a reply to any command if the service knows it
        must shut down)
     450 Requested mail action not taken: mailbox unavailable
        (e.g., mailbox busy)
     451 Requested action aborted: local error in processing
     452 Requested action not taken: insufficient system storage

Mit einer dieser Meldungen muß der Server antworten, um eine Mail temporär abzulehnen. "Möchte die Mail im Moment nicht entgegennehmen" oder "unbekannter temporärer Fehler" sind nicht dabei, der Server muß also inkorrekt antworten. Eine Folge davon kann sein, daß wenn bei wiederholten Zustellversuchen tatsächlich ein temp. Fehler auftritt (was passieren kann und darf, dazu sind die 4xx-Codes schließlich im Protokoll vorgesehen) auch Mails von RFC-konformen Sendern nicht ankommen.

Wenn man schon schreibt, daß bestimmte Sender nicht RFC-konform oder gar "grob fehlkonfiguriert" sind, sollte IMHO auch erwähnt werden, daß Greylisting selbst nicht dem RFC entspricht. --Dc2 22:33, 14. Feb. 2009 (CET)

Die Aufzählung der Return Codes in Abschnitt 4.2.2 ist meiner Meinung nach nicht als erschöpfend und taxativ zu verstehen. Die Verfasser des RFCs haben wohl die – damals – häufigsten Fehler explizit angegeben, es war ihnen aber klar, dass es auch andere Ursachen geben kann, Mails abzuweisen. Abschnitt 4.2.1, Reply Code Severities and Theory im RFC verlangt nur: „the reply codes must strictly follow the specifications in this section“. Ein Return Code "458 All carrier pigeons are asleep, try again later" ist demnach RFC-konform. --Feldkurat Katz 23:25, 14. Feb. 2009 (CET)

Auch wieder richtig. Zu den 4xy-Returncodes allgemein schreibt das RFC aber doch recht eindeutig, daß es sich um temporäre Fehler (error condition) handeln muß.

   4yz   Transient Negative Completion reply
     The command was not accepted, and the requested action did not
     occur.  However, the error condition is temporary and the action
     may be requested again. [...]

Vielleicht sehe ich das ja zu eng, aber ein "alles i.O., aber ich will die mail gerade nicht annehmen" fällt für mich definitiv nicht in die Kategorie "error condition". --Dc2 17:42, 15. Feb. 2009 (CET)

Ich denke dieser Abschnitt ist falsch dargestellt. RFC2821 sieht sehr wohl vorübergehende Fehlerzustände (4yz Transient Negative Completion reply) vor. Und aus Sicht des Mailservers (und daran knüpft sich das Greylisting) sind negative Nachschlagevorgänge in internen Tabellen generell auch Fehlerzustände. Wie bzw. mit welcher Meldung dem Client das verkauft wird, ist m. E. völlig nebensächlich, da die Auswertung des Fehlerzustands nicht über den Text, sondern über den Fehlercode vorgenommen wird, und ein "451 Requested action aborted: error in processing" ist durchaus passend. --212.202.164.34 12:20, 21. Apr. 2010 (CEST)

Nach RFC5321 (Nachfolger von RFC2821) (http://tools.ietf.org/html/rfc5321) kann man auch

   450 Requested mail action not taken: mailbox unavailable 
       (e.g., mailbox busy or temporarily blocked for policy reasons) 

nehmen. -- Tgerke 10:08, 28. Apr. 2011 (CEST)

Anpassung der Spammer

Ist der Abschnitt noch aktuell? Um nicht häufig auf angekündigte, dringende E-Mails warten zu müssen, habe ich mein Greylisting versuchsweise abgeschaltet. Ergebnis: Kein erhäöhtes Spamaufkommen feststellbar. Gruß, --Anselm Rapp (Diskussion) 11:02, 18. Jun. 2018 (CEST)

Forwarder

Wenn zwischen Sender und Empfänger ein dummer Forwarder zwischengeschaltet ist, funktioniert das mit dem Zweitzustellversuch überhaupt? --Mueck (Diskussion) 18:14, 4. Nov. 2019 (CET)

Wenn sich der Forwarder standardkonform verhält, funktioniert der Zweitzustellversuch. Falls nicht, dann nicht. --Matthäus Wander 21:08, 3. Mär. 2023 (CET)

Weblinks

Mir will scheinen, als ob der Link zu www.greylisting.org nicht mehr wirklich korrekt ist. Es steht zwar noch was dazu, aber eigentlich ist das eine VPN-Spiele-Was-auch-immer-Schmiede, die die Domain (das Projekt?) übernommen hat, oder sehe ich das falsch. Snokie (Diskussion) 08:30, 28. Aug. 2023 (CEST)

Sehe ich auch so. Fast alle Inhalte sind weg. Da ist nur noch ein Feigenblatt übrig, was keinen Mehrwert zum Artikel bietet. --Matthäus Wander 08:46, 28. Aug. 2023 (CEST)