Re: Greylisting
Am 11.07.2017 um 17:51 schrieb Joachim Fahrner: > Hallo, > in letzter Zeit habe ich mich an Roberts Vorschlag gehalten und > Greylisting nur selektiv angewandt (Dialin-IPs usw.). > Langsam komme ich ins Grübeln, ob ich das nicht doch generell wieder für > alles aktivieren soll. Ich bekomme in letzter Zeit häufig Spam und > Phishing von "echten" Mailservern (wurden die gehackt?), naja gehacked wurde nicht der Server, sondern die Ktos für die > Greylisting nicht angewandt wurde, und die auch (noch) auf keiner > Blacklist waren. Kurze Zeit später findet man die dann auch auf manchen > Blacklists. Das heisst: die ziehen ihre Aktionen in kürzester Zeit über > (gehackte?) Server durch, und suchen sich dann wieder einen anderen > "unverbrauchten" Server. hm, typisch waere eher man bringt Ktos grosser mail provider unter seine Kontrolle die senden dann eben von div ips, voellig normal > Hier würde Greylisting enorm helfen, das verzögert die Zustellung, und > beim nächsten Versuch steigt die Wahrscheinlichkeit, dass sie von einer > Blacklist registriert wurden. koennte klappen, hab ich aber so fast nie erlebt und z.B google und co ist bei mir grundsaetzlich gewhitelistet ( alles andere produziert zuviel support jobs ), das muss der content filter eben richtentut er auch > > Was meint ihr? das es da nicht viel Neues drueber zu sagen gibt .? > > Jochen > Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG, 80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Greylisting
Am 2017-07-11 19:23, schrieb Walter H.: in welchen Ländern sind diese "echten" Mailserver? Quer über die Welt verteilt. Zuletzt kam die hier: Received: from mu-mail3.massey.ac.nz (mu-mail3.massey.ac.nz [130.123.129.187])
Re: Greylisting
On 11.07.2017 17:51, Joachim Fahrner wrote: Langsam komme ich ins Grübeln, ob ich das nicht doch generell wieder für alles aktivieren soll. Ich bekomme in letzter Zeit häufig Spam und Phishing von "echten" Mailservern (wurden die gehackt?), für die Greylisting nicht angewandt wurde, in welchen Ländern sind diese "echten" Mailserver? mich wundert es nur, bei meinem Mailserver - ok diese Domain kräht kein Hahn vom Dach - sieht Logwatch typischerweise so aus: 259 *Warning: Pre-queue content-filter connection overload -- 256 After AUTH 256 unknown 2 After CONNECT 2 unknown 1 After RCPT 1 unknown 1 Reject relay denied - 1 50.246.210.5750-246-210-57-static.hfc.comcastbusiness.net 1cookie.nick2...@outlook.com 1 Reject HELO/EHLO 1 Host not found 1 67.244.24.104cpe-67-244-24-104.nyc.res.rr.com 1192.168.0.155 1 Reject unknown client host -- 1 unknown 1 192.168.98.169 1...@tea.com 1eax...@yahoo.com 21040 Connections lost 21039 After AUTH 21039 cpe-67-244-24-104.nyc.res.rr.com 1 After RCPT 1 cpe-67-244-24-104.nyc.res.rr.com 2 Sent via SMTP --- 2 meine.1te.Domain 1 calcbox-worker 1calc...@vhost.mail 1 vhost-root 1root 3 Timeout (inbound) --- 3 After AUTH 3 cpe-67-244-24-104.nyc.res.rr.com 2 Hostname verification errors 2 Address not listed for hostname 1 89.248.160.12serv-kobrekim.com 1 139.162.99.243 scan.security.ipip.net 2 Host offered TLS 2 smtp.vom.Webhoster demnach nur gescheiterte Versuche diesen als Relay zu vergewaltigen ... smime.p7s Description: S/MIME Cryptographic Signature
Greylisting
Hallo, in letzter Zeit habe ich mich an Roberts Vorschlag gehalten und Greylisting nur selektiv angewandt (Dialin-IPs usw.). Langsam komme ich ins Grübeln, ob ich das nicht doch generell wieder für alles aktivieren soll. Ich bekomme in letzter Zeit häufig Spam und Phishing von "echten" Mailservern (wurden die gehackt?), für die Greylisting nicht angewandt wurde, und die auch (noch) auf keiner Blacklist waren. Kurze Zeit später findet man die dann auch auf manchen Blacklists. Das heisst: die ziehen ihre Aktionen in kürzester Zeit über (gehackte?) Server durch, und suchen sich dann wieder einen anderen "unverbrauchten" Server. Hier würde Greylisting enorm helfen, das verzögert die Zustellung, und beim nächsten Versuch steigt die Wahrscheinlichkeit, dass sie von einer Blacklist registriert wurden. Was meint ihr? Jochen
Re: Selektives Greylisting
Am 23.03.2017 um 09:27 schrieb Joachim Fahrner: > Hallo Liste, > ich bin wieder mal am Tuning meiner Konfiguration ;-) > Vor einiger Zeit hatte ich mal blind Roberts selektives Greylisting > übernommen, wie hier beschrieben: > https://sys4.de/de/blog/2013/10/09/selektive-rbl-spf-greylisting-checks-mit-smtpd_restriction_classes/ > > > Jetzt habe ich die Beschreibung nochmal genauer gelesen, und dabei ist > mir etwas aufgefallen: > In smtpd_client_restrictions wird zuerst mynetworks und > sasl_authenticated erlaubt. > Als nächstes werden die 3 access Tabellen geprüft, und bei Treffern die > 3 Klassen ausgeführt. Diese beginnen jeweils wieder mit > permit_mynetworks und permit_sasl_authenticated. Ist das nicht doppelt > gemoppelt? mynetwork und sasl_authenticated müsste doch schon ganz am > Anfang mit permit die client_restrictions verlassen haben. > Oder hab ich da was falsch verstanden? > > Jochen > > doppelt moppeln verhindert dass wenn du z.b spaeter mal in smtpd_client_restrictions drueber was einschiebst du permit_mynetworks und permit_sasl_authenticated unbeabsichtigt overridest denk dran das ist kein vollstaendige config sondern soll nur demonstrieren wie man Selektives Greylisting umsetzen "kann" du kannst das nach belieben aendern, aus meiner sicht ist die hauptsache dass man es etwas inteligenter macht als einfach auf alles draufzuhaun Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG, 80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
AW: Greylisting - Whitelist
Im Auftrag von Mein Papierkorb > > Bin gerade ein wenig überrascht diese Antwort zu lesen. > Ich auch Denn aus eigener Erfahrung reichen oft schon 5 Minuten aus ob eine Neue noch nicht erkannte Trojaner/Viren Mail auf Blacklisten landet und nicht im Postfach der Kunden und dort unter umständen ganze Netzwerke verseuchen. Kommunikation ja. Kommunikation mit wem auch immer. Aber jede Kommunikation erfordert Regel auf beiden Seiten. Schnelle Kommunikation wo immer Möglich. Aber bitte auch mit einem gewissen maß an Sicherheit. Spammails sind zwar unangenehm aber die tun nicht weh. (mache klären auf, manche erweitern unseren Horizont und viele verhelfen zu einem besseren Stand von was auch immer :-)) Und wenn greylisting im Monat nur eine Seuche mehr aus den Kundennetzen fernhält dann rechnet sich das schon für die Kunden. Aber halt da verdiene ich ja auch dran (ein Schelm wer böses dabei denkt) > Warum nicht die Dienste beider Techniken nutzen? Selectives Greylisting für bekannte toplevelspamdomains immer, Postscreen für die Doofen, greylisting für die gehackten und manches andere für die immer wieder kehrenden > Bin damit sehr zufrieden und meine Kunden auch. > Zeitkritische Mails (z.B. während eines Telefonats) erhält man ja > ohnehin i.d.R. von bekannten Kontakten, sodass Greylisting die auch > sofort durchlässt. Me too > Und ob z.B. die Anfrage eines neuen Kunden, oder die Bestellbestätigung > von dem neuen Onlineshop mal 5-10 Minuten eher oder später reinkommt... Na sowas darf doch gar nicht sein :-)) Kunden die es schon mal erwischt hat haben da in der Regel ein ganz anderes Verständnis zu. Ich kann das jetzt nicht sagen wieviel das wirklich ausmacht. Ich merke allerdings das ich sehr wenig mit verseuchten Rechnern bei meinen Mailkunden zu tun habe. Den Umsatz mit der Datenwiederherstellung und Reinigung mache ich in der Regel bei Kunden anderer Maildienste. Mit freundlichen Grüßen Uwe Drießen -- Software & Computer Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner ! Uwe Drießen Lembergstraße 33 67824 Feilbingert Tel.: 06708660045
Re: Greylisting - Whitelist
Am 18.02.2016 um 18:30 schrieb lst_ho...@kwsoft.de: >> sorry ein Daemon mehr, machts nichts zuverlaessiger, >> und postfix logs sind ausreichend smtp con doku, sie werden durch >> greylisting evtl nur fetter. Wenn man ansonsten ein gut konfiguriertes >> System hat kann man dieser Tage locker auf greylisting verzichten, und >> allgem Geschwindigkeit ist durchaus ein Faktor der zaehlt. > > "Zuverlässig" im Sinne von zuverlässiger Zustellung nicht als Software > Stack. Wir haben mal mit Postscreen als Ersatz für Greylisting > experiementiert, allerdings war der Aufwand das System richtig > einzustellen und zu Dokumentieren größer als jeder Vorteil der möglich > gewesen wäre. Das liegt aber wahrscheinlich daran das wir mit > Greylisting die letzten 10 Jahre keine Probleme hatten und die > Spamreduktion für unseren Mailflow riesig ist. Ich bin mir bewusst das > das in anderen Situation auch anderst sein kann, aber ich sehe kein > generelles Problem mit Greylisting im Gegensatz zu manch anderen > abstrusen Maßnahmen zur Spam Reduktion. > > Gruß > > Andi Naja du vertagst halt die Entscheidung ob jemand bei dir Muell abladen darf in der Hoffnung dass er sich es spaeter anders ueberlegt und dich nicht mehr belaestigt indem du ihm erzaehlst du haettest grade keine Zeit, ich setze "eher" drauf so schnell und "billig" wie moeglich die ungewollte Lieferung gleich abzulehnen. Technisch gesagt fuer einfachen Bots reicht postscreen allemal. Alle anderen Bots sind mittlerweile komplette smtp engines die jedes Greylisting passieren. Postscreen kombiniert mit selektiven RBLS ,Postfix Rejects und Miltern reicht also allemal und es senkt die Faelle in denen der Bot wiederkommt denn wenn es ernst wird kaempft man um jeden freien smtp slot. Im besondereen Faellen benutze ich mittlerweile knallhart firewalling. Greylisting laeuft bei mir nur noch aus "romantischen" Gruenden. siehe https://sys4.de/de/blog/2013/10/09/selektive-rbl-spf-greylisting-checks-mit-smtpd_restriction_classes/ https://sys4.de/de/blog/2012/12/28/botnets-mit-rsyslog-und-iptables-recent-modul-abwehren/ https://sys4.de/de/blog/2015/11/07/abwehr-des-botnets-pushdo-cutwail-ehlo-ylmf-pc-mit-iptables-string-recent-smtp/ https://sys4.de/de/blog/2014/01/05/spambot-auswertung-mit-geoip/ Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Greylisting - Whitelist
Zitat von Robert Schetterer <r...@sys4.de>: Am 18.02.2016 um 16:51 schrieb lst_ho...@kwsoft.de: Zitat von Patrick Ben Koetter <p...@sys4.de>: * Mein Papierkorb <meinpapierkorb...@gmail.com>: Bin gerade ein wenig überrascht diese Antwort zu lesen. Warum nicht die Dienste beider Techniken nutzen? Ich will Kommunikation ermöglichen und nicht verhindern. Also baue ich Plattformen, die so permissiv wie möglich und nicht so restriktiv wie möglich sind. Die im Greylisting prinzipbedingte Verzögerung beim Mailaustausch verschlechtert in meinen Augen die Kommunikation so sehr, dass ich die Methode nicht generell einsetzen möchte. Sie mag durch vorheriges Training und regelmäßige Konversation im Alltag hinnehmbar sein, weil dann Mechanismen für Whitelisting vom Greylisting greifen. Im Erstkontakt verzögert Greylisting jedoch die Zustellung und damit die Kommunikation. Das mag in Privatkommunikation nicht stören. In den Geschäftsumfeldern, wo ständig wechselnde Kontakte die Regel sind, führt Greylisting jedoch zu einer erheblichen Beeinträchtigung der Kommunikationsqualität. Die Beeinträchtigung wird so unangenehm empfunden, dass die Kommunikationsteilnehmer auf andere Dienste/Medien ausweichen. Nebenbei: Diese Beeinträchtigung war u.a. ausschlaggebend für Ralf Hildebrandts Idee eines "gewichtenden Session Filter" gewesen, den Robert Felber dann als policyd-weight umgesetzt hat. "Alles nur nicht Greylisting!" Mit der Aufgabe war Robert damals unterwegs. Ich schalte erstmal Greylisting vor, und das, was dann durchkommt, geht durch die blacklist-Prüfung. Bin damit sehr zufrieden und meine Kunden auch. Zeitkritische Mails (z.B. während eines Telefonats) erhält man ja ohnehin i.d.R. von bekannten Kontakten, sodass Greylisting die auch sofort durchlässt. Und ob z.B. die Anfrage eines neuen Kunden, oder die Bestellbestätigung von dem neuen Onlineshop mal 5-10 Minuten eher oder später reinkommt... Dafür hab ich dann ca 80% weniger Spam im Postfach - meine Kunden und ich finden das super. Habe noch keinen gehabt, der von Greylisting wieder weg wollte - mehr kann ich dazu nicht sagen. Die, denen wir Greylisting ausreden konnten und denen wir stattdessen die Methoden von postscreen schmackhaft machen konnten, haben sich nacher aber auch nicht beschwert, dass ihre Mailbox nun mehr Spam enthielt. Sie haben aber berichtet, dass E-Mail jetzt "wieder viel schneller ist". Für mich bedeutet das: Wenn ich auf Greylisting verzichten kann, dann verzichte ich. Dafür erhalte ich die Unmittelbarkeit der Kommunikation zurück, die E-Mail für mich und viele Andere so wertvoll macht. Ich steigere die Qualität des Dienstes. Irgendwann im Kampf gegen Spam sind viele Leute über das Ziel hinausgeschossen. Sie haben Methoden eingebaut, die wesentliche Werte des Dienstes "E-Mail" einschränken oder gar entfernen. Greylisting und Methoden wie TMDA gehören für mich - persönlich - in diese Kategorie. Ich will Kommunikation ermöglichen. Ich will sie nicht verhindern. my 2ct p@rick E-Mail war schon immer Store-and-Forward, wenn ich eine direkte Reaktion brauchen rufe ich an. Die "Qualität" des Dienstes E-Mail an der Geschwindkeit zu messen ist IMHO etwas seltsam, ich nehm da lieber Zuverlässigkeit und Dokumentierbarkeit. sorry ein Daemon mehr, machts nichts zuverlaessiger, und postfix logs sind ausreichend smtp con doku, sie werden durch greylisting evtl nur fetter. Wenn man ansonsten ein gut konfiguriertes System hat kann man dieser Tage locker auf greylisting verzichten, und allgem Geschwindigkeit ist durchaus ein Faktor der zaehlt. "Zuverlässig" im Sinne von zuverlässiger Zustellung nicht als Software Stack. Wir haben mal mit Postscreen als Ersatz für Greylisting experiementiert, allerdings war der Aufwand das System richtig einzustellen und zu Dokumentieren größer als jeder Vorteil der möglich gewesen wäre. Das liegt aber wahrscheinlich daran das wir mit Greylisting die letzten 10 Jahre keine Probleme hatten und die Spamreduktion für unseren Mailflow riesig ist. Ich bin mir bewusst das das in anderen Situation auch anderst sein kann, aber ich sehe kein generelles Problem mit Greylisting im Gegensatz zu manch anderen abstrusen Maßnahmen zur Spam Reduktion. Gruß Andi smime.p7s Description: S/MIME Cryptographic Signature
Re: Greylisting - Whitelist
Am 18.02.2016 um 16:51 schrieb lst_ho...@kwsoft.de: > > Zitat von Patrick Ben Koetter <p...@sys4.de>: > >> * Mein Papierkorb <meinpapierkorb...@gmail.com>: >>> Bin gerade ein wenig überrascht diese Antwort zu lesen. >>> >>> Warum nicht die Dienste beider Techniken nutzen? >> >> Ich will Kommunikation ermöglichen und nicht verhindern. Also baue ich >> Plattformen, die so permissiv wie möglich und nicht so restriktiv wie >> möglich >> sind. >> >> Die im Greylisting prinzipbedingte Verzögerung beim Mailaustausch >> verschlechtert in meinen Augen die Kommunikation so sehr, dass ich die >> Methode >> nicht generell einsetzen möchte. >> >> Sie mag durch vorheriges Training und regelmäßige Konversation im Alltag >> hinnehmbar sein, weil dann Mechanismen für Whitelisting vom Greylisting >> greifen. Im Erstkontakt verzögert Greylisting jedoch die Zustellung >> und damit >> die Kommunikation. >> >> Das mag in Privatkommunikation nicht stören. In den >> Geschäftsumfeldern, wo >> ständig wechselnde Kontakte die Regel sind, führt Greylisting jedoch >> zu einer >> erheblichen Beeinträchtigung der Kommunikationsqualität. Die >> Beeinträchtigung >> wird so unangenehm empfunden, dass die Kommunikationsteilnehmer auf >> andere >> Dienste/Medien ausweichen. >> >> Nebenbei: Diese Beeinträchtigung war u.a. ausschlaggebend für Ralf >> Hildebrandts Idee eines "gewichtenden Session Filter" gewesen, den Robert >> Felber dann als policyd-weight umgesetzt hat. "Alles nur nicht >> Greylisting!" >> Mit der Aufgabe war Robert damals unterwegs. >> >> >>> Ich schalte erstmal Greylisting vor, und das, was dann durchkommt, >>> geht durch die blacklist-Prüfung. >>> >>> Bin damit sehr zufrieden und meine Kunden auch. >>> Zeitkritische Mails (z.B. während eines Telefonats) erhält man ja >>> ohnehin i.d.R. von bekannten Kontakten, sodass Greylisting die auch >>> sofort durchlässt. >>> Und ob z.B. die Anfrage eines neuen Kunden, oder die >>> Bestellbestätigung von dem neuen Onlineshop mal 5-10 Minuten eher >>> oder später reinkommt... >>> Dafür hab ich dann ca 80% weniger Spam im Postfach - meine Kunden >>> und ich finden das super. >>> Habe noch keinen gehabt, der von Greylisting wieder weg wollte - >>> mehr kann ich dazu nicht sagen. >> >> Die, denen wir Greylisting ausreden konnten und denen wir stattdessen die >> Methoden von postscreen schmackhaft machen konnten, haben sich nacher >> aber >> auch nicht beschwert, dass ihre Mailbox nun mehr Spam enthielt. Sie >> haben aber >> berichtet, dass E-Mail jetzt "wieder viel schneller ist". >> >> Für mich bedeutet das: Wenn ich auf Greylisting verzichten kann, dann >> verzichte ich. Dafür erhalte ich die Unmittelbarkeit der Kommunikation >> zurück, >> die E-Mail für mich und viele Andere so wertvoll macht. Ich steigere die >> Qualität des Dienstes. >> >> Irgendwann im Kampf gegen Spam sind viele Leute über das Ziel >> hinausgeschossen. Sie haben Methoden eingebaut, die wesentliche Werte des >> Dienstes "E-Mail" einschränken oder gar entfernen. >> >> Greylisting und Methoden wie TMDA gehören für mich - persönlich - in >> diese >> Kategorie. Ich will Kommunikation ermöglichen. Ich will sie nicht >> verhindern. >> >> my 2ct >> >> p@rick > > E-Mail war schon immer Store-and-Forward, wenn ich eine direkte Reaktion > brauchen rufe ich an. Die "Qualität" des Dienstes E-Mail an der > Geschwindkeit zu messen ist IMHO etwas seltsam, ich nehm da lieber > Zuverlässigkeit und Dokumentierbarkeit. sorry ein Daemon mehr, machts nichts zuverlaessiger, und postfix logs sind ausreichend smtp con doku, sie werden durch greylisting evtl nur fetter. Wenn man ansonsten ein gut konfiguriertes System hat kann man dieser Tage locker auf greylisting verzichten, und allgem Geschwindigkeit ist durchaus ein Faktor der zaehlt. > > Gruß > > Andi > > > Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Greylisting - Whitelist
Am 18.02.2016 um 15:27 schrieb Mein Papierkorb: > Bin gerade ein wenig überrascht diese Antwort zu lesen. > > Warum nicht die Dienste beider Techniken nutzen? > > Ich schalte erstmal Greylisting vor, und das, was dann durchkommt, geht > durch die blacklist-Prüfung. > > Bin damit sehr zufrieden und meine Kunden auch. > Zeitkritische Mails (z.B. während eines Telefonats) erhält man ja > ohnehin i.d.R. von bekannten Kontakten, sodass Greylisting die auch > sofort durchlässt. > Und ob z.B. die Anfrage eines neuen Kunden, oder die Bestellbestätigung > von dem neuen Onlineshop mal 5-10 Minuten eher oder später reinkommt... > Dafür hab ich dann ca 80% weniger Spam im Postfach - meine Kunden und > ich finden das super. > Habe noch keinen gehabt, der von Greylisting wieder weg wollte - mehr > kann ich dazu nicht sagen. > > Gruß, > Markus Siehe meine vorherige Antwort, postscreen ist so erfolgreich dass greylisting nur noch so selten zum Zug kommt dass man es auch weglassen kann auf meinen systemen > > > Am 18.02.2016 um 15:01 schrieb Patrick Ben Koetter: >> * Marco Dickert <ma...@misterunknown.de>: >>> On 2016-02-18 13:56:13, Patrick Ben Koetter wrote: >>>> Auf alleinstehenden Hosts verwenden wir lokale, statische Maps. >>>> Auf Systemen, die z.B. in einem Performancecluster zusammenarbeiten, >>>> verwenden >>>> wir eigene "DNS Black-/Whitelisten" innerhalb der Plattform. >>> Habt ihr Statistiken über die "Erfolgsquote" von Greylisting? Mich >>> würde mal >>> interessieren, wie effektiv das ist. >> Wir haben keine aktuellen Statistiken mehr. Grund ist: Wir vermeiden >> Greylisting wo immer möglich. Und das ist seit postscreen in der Regel >> fast >> immer möglich. >> >> p@rick >> > Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Greylisting - Whitelist
* Mein Papierkorb <meinpapierkorb...@gmail.com>: > Bin gerade ein wenig überrascht diese Antwort zu lesen. > > Warum nicht die Dienste beider Techniken nutzen? Ich will Kommunikation ermöglichen und nicht verhindern. Also baue ich Plattformen, die so permissiv wie möglich und nicht so restriktiv wie möglich sind. Die im Greylisting prinzipbedingte Verzögerung beim Mailaustausch verschlechtert in meinen Augen die Kommunikation so sehr, dass ich die Methode nicht generell einsetzen möchte. Sie mag durch vorheriges Training und regelmäßige Konversation im Alltag hinnehmbar sein, weil dann Mechanismen für Whitelisting vom Greylisting greifen. Im Erstkontakt verzögert Greylisting jedoch die Zustellung und damit die Kommunikation. Das mag in Privatkommunikation nicht stören. In den Geschäftsumfeldern, wo ständig wechselnde Kontakte die Regel sind, führt Greylisting jedoch zu einer erheblichen Beeinträchtigung der Kommunikationsqualität. Die Beeinträchtigung wird so unangenehm empfunden, dass die Kommunikationsteilnehmer auf andere Dienste/Medien ausweichen. Nebenbei: Diese Beeinträchtigung war u.a. ausschlaggebend für Ralf Hildebrandts Idee eines "gewichtenden Session Filter" gewesen, den Robert Felber dann als policyd-weight umgesetzt hat. "Alles nur nicht Greylisting!" Mit der Aufgabe war Robert damals unterwegs. > Ich schalte erstmal Greylisting vor, und das, was dann durchkommt, > geht durch die blacklist-Prüfung. > > Bin damit sehr zufrieden und meine Kunden auch. > Zeitkritische Mails (z.B. während eines Telefonats) erhält man ja > ohnehin i.d.R. von bekannten Kontakten, sodass Greylisting die auch > sofort durchlässt. > Und ob z.B. die Anfrage eines neuen Kunden, oder die > Bestellbestätigung von dem neuen Onlineshop mal 5-10 Minuten eher > oder später reinkommt... > Dafür hab ich dann ca 80% weniger Spam im Postfach - meine Kunden > und ich finden das super. > Habe noch keinen gehabt, der von Greylisting wieder weg wollte - > mehr kann ich dazu nicht sagen. Die, denen wir Greylisting ausreden konnten und denen wir stattdessen die Methoden von postscreen schmackhaft machen konnten, haben sich nacher aber auch nicht beschwert, dass ihre Mailbox nun mehr Spam enthielt. Sie haben aber berichtet, dass E-Mail jetzt "wieder viel schneller ist". Für mich bedeutet das: Wenn ich auf Greylisting verzichten kann, dann verzichte ich. Dafür erhalte ich die Unmittelbarkeit der Kommunikation zurück, die E-Mail für mich und viele Andere so wertvoll macht. Ich steigere die Qualität des Dienstes. Irgendwann im Kampf gegen Spam sind viele Leute über das Ziel hinausgeschossen. Sie haben Methoden eingebaut, die wesentliche Werte des Dienstes "E-Mail" einschränken oder gar entfernen. Greylisting und Methoden wie TMDA gehören für mich - persönlich - in diese Kategorie. Ich will Kommunikation ermöglichen. Ich will sie nicht verhindern. my 2ct p@rick > Am 18.02.2016 um 15:01 schrieb Patrick Ben Koetter: > >* Marco Dickert <ma...@misterunknown.de>: > >>On 2016-02-18 13:56:13, Patrick Ben Koetter wrote: > >>>Auf alleinstehenden Hosts verwenden wir lokale, statische Maps. > >>>Auf Systemen, die z.B. in einem Performancecluster zusammenarbeiten, > >>>verwenden > >>>wir eigene "DNS Black-/Whitelisten" innerhalb der Plattform. > >>Habt ihr Statistiken über die "Erfolgsquote" von Greylisting? Mich würde mal > >>interessieren, wie effektiv das ist. > >Wir haben keine aktuellen Statistiken mehr. Grund ist: Wir vermeiden > >Greylisting wo immer möglich. Und das ist seit postscreen in der Regel fast > >immer möglich. > > > >p@rick > > > -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Greylisting - Whitelist
Bin gerade ein wenig überrascht diese Antwort zu lesen. Warum nicht die Dienste beider Techniken nutzen? Ich schalte erstmal Greylisting vor, und das, was dann durchkommt, geht durch die blacklist-Prüfung. Bin damit sehr zufrieden und meine Kunden auch. Zeitkritische Mails (z.B. während eines Telefonats) erhält man ja ohnehin i.d.R. von bekannten Kontakten, sodass Greylisting die auch sofort durchlässt. Und ob z.B. die Anfrage eines neuen Kunden, oder die Bestellbestätigung von dem neuen Onlineshop mal 5-10 Minuten eher oder später reinkommt... Dafür hab ich dann ca 80% weniger Spam im Postfach - meine Kunden und ich finden das super. Habe noch keinen gehabt, der von Greylisting wieder weg wollte - mehr kann ich dazu nicht sagen. Gruß, Markus Am 18.02.2016 um 15:01 schrieb Patrick Ben Koetter: * Marco Dickert <ma...@misterunknown.de>: On 2016-02-18 13:56:13, Patrick Ben Koetter wrote: Auf alleinstehenden Hosts verwenden wir lokale, statische Maps. Auf Systemen, die z.B. in einem Performancecluster zusammenarbeiten, verwenden wir eigene "DNS Black-/Whitelisten" innerhalb der Plattform. Habt ihr Statistiken über die "Erfolgsquote" von Greylisting? Mich würde mal interessieren, wie effektiv das ist. Wir haben keine aktuellen Statistiken mehr. Grund ist: Wir vermeiden Greylisting wo immer möglich. Und das ist seit postscreen in der Regel fast immer möglich. p@rick
Re: Greylisting - Whitelist
* Marco Dickert <ma...@misterunknown.de>: > On 2016-02-18 13:56:13, Patrick Ben Koetter wrote: > > Auf alleinstehenden Hosts verwenden wir lokale, statische Maps. > > Auf Systemen, die z.B. in einem Performancecluster zusammenarbeiten, > > verwenden > > wir eigene "DNS Black-/Whitelisten" innerhalb der Plattform. > > Habt ihr Statistiken über die "Erfolgsquote" von Greylisting? Mich würde mal > interessieren, wie effektiv das ist. Wir haben keine aktuellen Statistiken mehr. Grund ist: Wir vermeiden Greylisting wo immer möglich. Und das ist seit postscreen in der Regel fast immer möglich. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Greylisting - Whitelist
On 2016-02-18 13:56:13, Patrick Ben Koetter wrote: > Auf alleinstehenden Hosts verwenden wir lokale, statische Maps. > Auf Systemen, die z.B. in einem Performancecluster zusammenarbeiten, verwenden > wir eigene "DNS Black-/Whitelisten" innerhalb der Plattform. Habt ihr Statistiken über die "Erfolgsquote" von Greylisting? Mich würde mal interessieren, wie effektiv das ist. -- Marco Dickert ma...@misterunknown.de https://misterunknown.de signature.asc Description: Digital signature
Greylisting - Whitelist
Hallo liebe Postfixler! Verwendet ihr eigentlich auch postgrey und wenn ja, kann man hier eine Online-Whitelist einbinden, die ständig aktualisiert wird. Greylisting ist an und für sich ja eine Gute Sache, allerdings tauchen Probleme auf wenn mir Absender aus Serverfarmen (z.B. Office 365) etwas senden wollen, da nach dem ersten Zustellversuch und temp. Abweisung ja ein anderer Mailserver aus dieser Farm versucht mir diese zuzustellen, somit bekommt der dann wieder eine temp. Unzustellbarkeitsmeldung (450 4.2.0) usw Das kann eine Mailzustellung dann schon erheblich verzögern. Was macht ihr dagegen? Pflegt Ihr die postgrey_whitelist_clients.local selber? -- vg, Andi
[postfix-users] Bare Newline Test (was: postscreen eine Art von greylisting?)
Hallo, angeregt durch den Artikel im Linux-Magazin 08/11 spiele ich grade mit Postscreen auf einem Testserver (Debian Squeeze mit Postfix aus Squeeze Backports) rum. On Thu, Jun 30, 2011 at 08:49:40AM +0200, Tobias Koopmann wrote: nachdem ich mich ein wenig in postscreen eingelesen habe, stellt sich mich die Frage, ob es sinnvoll ist zusätzlich zu postscreen noch greylisting zu fahren. Das habe ich mich auch erstmal gefragt. Postscreen zumindest mit den deep_protocol_tests kann nach erfolgreichen Tests die Verbindung nicht an den smtpd weitergeben und weist den client mit nem 4xxer Code ab. Soweit ich die Doku unter http://www.postfix.org/postconf.5.html#postscreen_bare_newline_enable verstehe gilt dies nicht für den Bare Newline Test. Dieser bricht die Verbindung danach _immer_ mit einem 450er ab, egal ob der Test bestanden wurde oder nicht. Wie er sich verhält falls der Test nicht bestanden wurde, hängt dann von postscreen_bare_newline_action ab. Schön nachvollziehen kann man das mit folgenden (nicht für die Praxis gedachten :-) Settings: postscreen_bare_newline_enable = yes postscreen_bare_newline_action = drop postscreen_bare_newline_ttl = 1s Geht man mit Telnet auf Port 25, sendet es immer richtige Newlines. Also habe ich nc (netcat) genommen und das HELO mal nur mit Ctrl-M und mal nur mit Ctrl-J beendet. Und bin wie erwartet sofort mit 521 5.5.1 Protocol error rausgeflogen. Wenn ich dann aber mit swaks[1] teste (das definitiv korrekte Newlines schickt und ja auch nicht sofort rausfliegt), kommt immer der 450er. Sobald ich aber postscreen_bare_newline_enable = no setze, kommt swaks wieder durch und kann Mails versenden. [1] http://www.jetmore.org/john/code/swaks/ Was ich aber nicht verstehe: Warum endet der Bare Newline Test immer mit einem 450er? Gibt es irgendeinen logischen Grund dafür? (Der sich mir dann aber momentan nicht erschließt. ;-) Oder ist das momentan einfach eine Einschränkung in der Implementation? Also für mein Verständnis auch eine Art von Greylist, dessen Entscheidung meiner Meinung nach auf besseren Prüfungen beruht als der des Triplets beim greylisting. Wie die meisten anderen Antworten schon zeigten, gibt es einige Unterschiede zum Greylisting, die es nicht zum vollständigen Ersatz im Sinne des Greylistings machen. Mit freundlichem Gruss, Axel Beckert -- Axel Beckert beck...@phys.ethz.ch support: +41 44 633 26 68 IT Services Group, HPT D 16 voice: +41 44 633 41 89 Departement of Physics, ETH Zurich CH-8093 Zurich, Switzerlandhttp://nic.phys.ethz.ch/ ___ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
[postfix-users] postscreen eine Art von greylisting?
Hallo Liste, nachdem ich mich ein wenig in postscreen eingelesen habe, stellt sich mich die Frage, ob es sinnvoll ist zusätzlich zu postscreen noch greylisting zu fahren. Postscreen zumindest mit den deep_protocol_tests kann nach erfolgreichen Tests die Verbindung nicht an den smtpd weitergeben und weist den client mit nem 4xxer Code ab. Also für mein Verständnis auch eine Art von Greylist, dessen Entscheidung meiner Meinung nach auf besseren Prüfungen beruht als der des Triplets beim greylisting. Macht es also Sinn wenn man postscreen mit deep_protocol_tests einsetzt auf z.B. postgrey zu verzichten, wie sieht ihr das? -- Mit freundlichen Grüßen, Tobias Koopmann -- ...and I will promise to go on as long as you want me to, and I will dream along and help to make it real for you, too... (the mirror the lie - Motorpsycho) -- ___ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Re: [postfix-users] postscreen eine Art von greylisting?
Zitat von Tobias Koopmann tob...@koopmann-mail.de: Hallo Liste, nachdem ich mich ein wenig in postscreen eingelesen habe, stellt sich mich die Frage, ob es sinnvoll ist zusätzlich zu postscreen noch greylisting zu fahren. Postscreen zumindest mit den deep_protocol_tests kann nach erfolgreichen Tests die Verbindung nicht an den smtpd weitergeben und weist den client mit nem 4xxer Code ab. Also für mein Verständnis auch eine Art von Greylist, dessen Entscheidung meiner Meinung nach auf besseren Prüfungen beruht als der des Triplets beim greylisting. Macht es also Sinn wenn man postscreen mit deep_protocol_tests einsetzt auf z.B. postgrey zu verzichten, wie sieht ihr das? Ist ähnlich aber nicht gleich. Postscreen testet ob das SMTP Protokoll eingehalten wird und falls ja lässt den nächsten Versuch passieren *unabhängig* davon wann der nächste Versuch auftritt. Greylisting arbeitet üblicherweise nur zeitbasiert d.h. unabhängig davon ob das Protokoll eingehalten wird, wird die Verbindung erst nach einer gewissen Zeit weiter gereicht. Postscreen ist wirkungslos gegen Bots die das Protokoll einhalten und Greylisting ist wirkungslos gegen Sender die über einen längeren Zeitraum Retrys machen. Gruß Andreas smime.p7s Description: S/MIME Cryptographic Signature ___ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Re: [postfix-users] postscreen eine Art von greylisting?
Postscreen ist wirkungslos gegen Bots die das Protokoll einhalten und Greylisting ist wirkungslos gegen Sender die über einen längeren Zeitraum Retrys machen. Ich setze postscreen mit deep_... ein. Ich habe Wietses Idee aufgegriffen und einen zweiten MX-RR auf den selben Mailsevrer gesetzt, was grundsätzlich nicht verboten ist. Daher wird ein Client, der durch postscreen ein 4xx erhält sofort auf den 2ten MX wechseln und landet also erneut auf dem Mailserver, der nun den Client passieren lässt. Ergänzt läuft bei mir ein selektives Greylisting, bei dem alle Toplevel-Domains, die nicht .com, .info, .net, .org, .de sind mit einem Delay von tatsächlich einer Stunde. Warum? Weil mein Server i.d.R. nur deutschsprachig eingesetzt ist. Vorteil: eine Stunde reicht dann doch aus, damit Clients evtl. bereits anderswo so negativ aufgefallen sind, dass sie auf Blacklisten gelandet sind. Diese kommen dann auch nach der Stunde nicht durch. Auswertungen des Logs haben gezeigt, dass dies tatsächlich real funktioniert. Die Idee war übrigens von Uwe ;-) Thx noch mal an dieser Stelle. LG Christian -- Roessner-Network-Solutions Bachelor of Science Informatik 50°34.725'N, 08°40.904'O, Nahrungsberg 81, 35390 Giessen F: +49 641 5879091, M: +49 176 93118939 USt-IdNr.: DE225643613 http://www.roessner-network-solutions.com signature.asc Description: OpenPGP digital signature ___ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
[postfix-users] Greylisting nach Inbetriebnahme des Postfix Servers
Hallo, ich habe gestern abend den Postfix server in Betrieb genommen. Es funktioniert alles ganz gut soweit. Der Server hat eine neue externe IP und einen neuen Hostnamen, er löste den alten ab (auch Postfix). Es ist ein reines Mailgateway für Internet mail (nur outbound). Nur ein Problem habe ich mit Greylisting. Manche Server (wenige im Vergleich zu der Masse an mails) listen den Server mit z.B. 450 4.2.0 Recipient address rejected: Greylisted (in reply to RCPT TO command) 451 Greylisted, please try again in 180 seconds (in reply to RCPT TO command)) said: 450 4.7.1 Client host rejected: Greylisted for 00:03:59 hours:minutes:seconds Nur die Frage: Kann man das greylisting vermeiden (da manche mails rejected werden), bzw. gibt es Postfix Parameter, um dies zu vermeiden. Danke Martin Crown Gabelstapler GmbH Co. KG www.crown.com Registergericht Regensburg HR A6730, Sitz Roding Komplementär: Crown Gabelstapler Verwaltungs GmbH Registergericht Regensburg HRB 8854, Sitz Roding Geschäftsführer der Komplementärgesellschaft: Kenneth Dufford, Walter Weinzettl ___ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Re: [postfix-users] Greylisting nach Inbetriebnahme des Postfix Servers
Zitat von martin.spie...@crown.com: Hallo, ich habe gestern abend den Postfix server in Betrieb genommen. Es funktioniert alles ganz gut soweit. Der Server hat eine neue externe IP und einen neuen Hostnamen, er löste den alten ab (auch Postfix). Es ist ein reines Mailgateway für Internet mail (nur outbound). Nur ein Problem habe ich mit Greylisting. Manche Server (wenige im Vergleich zu der Masse an mails) listen den Server mit z.B. 450 4.2.0 Recipient address rejected: Greylisted (in reply to RCPT TO command) 451 Greylisted, please try again in 180 seconds (in reply to RCPT TO command)) said: 450 4.7.1 Client host rejected: Greylisted for 00:03:59 hours:minutes:seconds Nur die Frage: Kann man das greylisting vermeiden (da manche mails rejected werden), bzw. gibt es Postfix Parameter, um dies zu vermeiden. Greylisting ist kein Reject sondern ein try again later (4xx reply codes). Postfix als Sender macht den Retry automatisch, es gibt nichts weiter zu tun. Fall wirklich mails die von euch verschikct werden abgelehnt (rejected) werden sollt der Grund in den Logfiles stehen. Gruß Andreas smime.p7s Description: S/MIME Cryptographic Signature ___ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
[postfix-users] RBL in Kombination mit Greylisting
Hallo, wir sind momentan dabei unseren Spamfilter zu erweitern. Hierfür wollen wir eine Kombination aus RBLs und Greylisting benutzen. Hierbei sollen Emails die via RBL getagt wurden an das Greylisting weitergereicht werden. Bisher habe ich die möglichkeit gefunden dies mithilfe von postfwd und postgrey zu realiesieren. Meine Frage ist nun ob es nicht auch einfacher geht. Zum Beispiel so das nur ein Script zum Einsatz kommt. Wir verwenden zurzeit Postfix in der Aktuellen Version zusammen mit amavis+clamav und spammassasin. Freue mich Antwort. Mit freundlichen Grüßen Andreas Rehmer teltarif.de Onlineverlag GmbH Alt-Moabit 96c, 10559 Berlin Tel: +49 (0)30 453 081-0 Fax: +49 (0)30 453 081-11 Mail: mailto:[EMAIL PROTECTED] WWW: http://www.teltarif.de !!! Achtung wir sind umgezogen !!! Beachten Sie bitte die neue Adresse und die neuen Durchwahlen. Geschäftsführer: Kai Petzke, Martin Müller eingetragen beim Amtsgericht Berlin-Charlottenburg, HRB 70507 Umsatzsteuer-ID: DE201038407 Behalten Sie den Durchblick im Tarifdschungel: Der DSL-Rechner von teltarif verrät Ihnen kostenlos den für Sie passenden DSL-Tarif. Sparen Sie bares Geld http://www.teltarif.de/dslrechner/ ___ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Re: [postfix-users] RBL in Kombination mit Greylisting
Hallo, wir sind momentan dabei unseren Spamfilter zu erweitern. Hierfür wollen wir eine Kombination aus RBLs und Greylisting benutzen. Hierbei sollen Emails die via RBL getagt wurden an das Greylisting weitergereicht werden. Bisher habe ich die möglichkeit gefunden dies mithilfe von postfwd und postgrey zu realiesieren. Meine Frage ist nun ob es nicht auch einfacher geht. Zum Beispiel so das nur ein Script zum Einsatz kommt. Wir verwenden zurzeit Postfix in der Aktuellen Version zusammen mit amavis+clamav und spammassasin. Wo ist das Problem - Du lässt die Mails erst von gängigen RBL's prüfen und dann verwendest Du greylisting. Zusätzlich könntest Du anstatt der RBL's policy-d-weight einsetzen - dann verlässt Du dich nicht auf eine RBL sondern lässt die RBL's gewichtet zu. ___ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users Und wo kann ich das deiner Meinung nach Problemlos machen?? Das ist ja meine Frage. Mit freundlichen Grüßen Andreas Rehmer ___ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Re: [postfix-users] RBL in Kombination mit Greylisting
Andreas Rehmer schrieb: Hallo, wir sind momentan dabei unseren Spamfilter zu erweitern. Hierfür wollen wir eine Kombination aus RBLs und Greylisting benutzen. Hierbei sollen Emails die via RBL getagt wurden an das Greylisting weitergereicht werden. Bisher habe ich die möglichkeit gefunden dies mithilfe von postfwd und postgrey zu realiesieren. Meine Frage ist nun ob es nicht auch einfacher geht. Zum Beispiel so das nur ein Script zum Einsatz kommt. Wo ist das Problem - Du lässt die Mails erst von gängigen RBL's prüfen und dann verwendest Du greylisting. Ich glaube, Ihr versteht Euch falsch. Wenn ich das recht interpretiere, will der OP Greylisting auf Basis der Ergebnisse von DNSBL Lookups machen. Wenn also z.B. der Lookup bei spamhaus 127.0.0.10 oder .11 ergibt, soll Greylisting zum Zuge kommen. Und leider nein, mir ist sonst kein Tool bekannt, dass beides kombinieren würde. Das war ja auch einer der Gründe für die Entwicklung von postfwd. Gruß, Jan ___ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Re: [postfix-users] RBL in Kombination mit Greylisting
* Andreas Rehmer [EMAIL PROTECTED]: Wo ist das Problem - Du lässt die Mails erst von gängigen RBL's prüfen und dann verwendest Du greylisting. Zusätzlich könntest Du anstatt der RBL's policy-d-weight einsetzen - dann verlässt Du dich nicht auf eine RBL sondern lässt die RBL's gewichtet zu. Und wo kann ich das deiner Meinung nach Problemlos machen?? Das ist ja meine Frage. smtpd_recipient_restrictions = ... reject_unauth_destination, ... reject_rbl_clientbl.spamcop.net reject_rbl_clientpsbl.surriel.com ... check_policy_service inet:127.0.0.1:10031 -- Ralf Hildebrandt ([EMAIL PROTECTED]) [EMAIL PROTECTED] Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.arschkrebs.de SMTP is not Calvin Ball. If you make up your own rules about forwarding please do not be surprised that other people ignore them. ___ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Re: [postfix-users] RBL in Kombination mit Greylisting
On Mon, Aug 04, 2008 at 04:19:01PM +0200, Jan P. Kessler wrote: wir sind momentan dabei unseren Spamfilter zu erweitern. Hierfür wollen wir eine Kombination aus RBLs und Greylisting benutzen. Hierbei sollen Emails die via RBL getagt wurden an das Greylisting weitergereicht werden. Bisher habe ich die möglichkeit gefunden dies mithilfe von postfwd und postgrey zu realiesieren. Meine Frage ist nun ob es nicht auch einfacher geht. Zum Beispiel so das nur ein Script zum Einsatz kommt. Wo ist das Problem - Du lässt die Mails erst von gängigen RBL's prüfen und dann verwendest Du greylisting. Ich glaube, Ihr versteht Euch falsch. Wenn ich das recht interpretiere, will der OP Greylisting auf Basis der Ergebnisse von DNSBL Lookups machen. Wenn also z.B. der Lookup bei spamhaus 127.0.0.10 oder .11 ergibt, soll Greylisting zum Zuge kommen. Und leider nein, mir ist sonst kein Tool bekannt, dass beides kombinieren würde. Das war ja auch einer der Gründe für die Entwicklung von postfwd. Policyd-weight kann das mit Hilfe von $dnsbl_checks_only = 1; und als $MAXDNSBLMSG = rc:greylisting; (ja, man muss dazu noch pbl und sbl-xbl getrennt abfragen) Setzt voraus, dass es eine postfix restriction class mit dem namen greylisting gibt - damit kann man dann x-beliebigen greylister ansprechen. Eine andere Moeglichkeit waere ueber DEFER_STRING (siehe http://blog.waja.info/2007/08/03/conditional-greylisting/) Wenn man DEFER_* clever einsetzt, kann man so ziemlich viele Sachen fuer selectives Greylisting machen - aber das artet dann in nonsense aus. Aber - IMHO ist das wertlos. Eine regexp table auf den host/helo name reicht als Selektionskriterium voellig aus. Du verlierst durch RBL selektion gegenueber regexp selektion mehr, als du gewinnst (im philosophischen Sinne). -- Robert Felber (PGP: 896CF30B) Munich, Germany ___ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Re: [postfix-users] RBL in Kombination mit Greylisting
Original-Nachricht Datum: Mon, 04 Aug 2008 16:19:01 +0200 Von: Jan P. Kessler [EMAIL PROTECTED] An: Mailing-Liste der deutschsprachigen Postfix Gemeinschaft postfix-users@de.postfix.org Betreff: Re: [postfix-users] RBL in Kombination mit Greylisting Andreas Rehmer schrieb: Hallo, wir sind momentan dabei unseren Spamfilter zu erweitern. Hierfür wollen wir eine Kombination aus RBLs und Greylisting benutzen. Hierbei sollen Emails die via RBL getagt wurden an das Greylisting weitergereicht werden. Bisher habe ich die möglichkeit gefunden dies mithilfe von postfwd und postgrey zu realiesieren. Meine Frage ist nun ob es nicht auch einfacher geht. Zum Beispiel so das nur ein Script zum Einsatz kommt. Wo ist das Problem - Du lässt die Mails erst von gängigen RBL's prüfen und dann verwendest Du greylisting. Ich glaube, Ihr versteht Euch falsch. Wenn ich das recht interpretiere, will der OP Greylisting auf Basis der Ergebnisse von DNSBL Lookups machen. Wenn also z.B. der Lookup bei spamhaus 127.0.0.10 oder .11 ergibt, soll Greylisting zum Zuge kommen. Und leider nein, mir ist sonst kein Tool bekannt, dass beides kombinieren würde. Gross (http://code.google.com/p/gross/) kann das. Das Ding ist verdammt schnell und kann über SJSMS (Sun Java System Messaging Server), Milter oder Postfix Policy angesprochen werden. Das war ja auch einer der Gründe für die Entwicklung von postfwd. Gruß, Jan ___ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Re: [postfix-users] RBL in Kombination mit Greylisting
Hallo Liste, vielen Dank für die Hilfe an Jan und alle anderen, genau sowas habe ich gesucht. Gruß Andreas Hallo, wir sind momentan dabei unseren Spamfilter zu erweitern. Hierfür wollen wir eine Kombination aus RBLs und Greylisting benutzen. Hierbei sollen Emails die via RBL getagt wurden an das Greylisting weitergereicht werden. Bisher habe ich die möglichkeit gefunden dies mithilfe von postfwd und postgrey zu realiesieren. Meine Frage ist nun ob es nicht auch einfacher geht. Zum Beispiel so das nur ein Script zum Einsatz kommt. Wo ist das Problem - Du lässt die Mails erst von gängigen RBL's prüfen und dann verwendest Du greylisting. Ich glaube, Ihr versteht Euch falsch. Wenn ich das recht interpretiere, will der OP Greylisting auf Basis der Ergebnisse von DNSBL Lookups machen. Wenn also z.B. der Lookup bei spamhaus 127.0.0.10 oder .11 ergibt, soll Greylisting zum Zuge kommen. Und leider nein, mir ist sonst kein Tool bekannt, dass beides kombinieren würde. Gross (http://code.google.com/p/gross/) kann das. Das Ding ist verdammt schnell und kann über SJSMS (Sun Java System Messaging Server), Milter oder Postfix Policy angesprochen werden. Das war ja auch einer der Gründe für die Entwicklung von postfwd. Gruß, Jan ___ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users ___ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
