[postfix-users] Dunno in restriction_classes
Hallo Liste,
Wie kann man Postfix mittels restriction_class dazu bringen, eine bestimmte Restriction auf alle Absender/Clienten anzuwenden, außer denen, die in einer access-Table eingetragen sind? Und natürlich das ganze so, dass nachfolgende Restrictions nicht betroffen sind.
Ich will das ganze u.A. dazu einsetzen bereits in Postfix ein Whitelist für z.B. die DynIP-Liste zu implementieren.
Geht das überhaupt?
Evtl. per * als Wildcard?
Thomas
Thomas Schwenski schrieb:
Hallo Liste,
Wie kann man Postfix mittels restriction_class dazu bringen, eine bestimmte Restriction auf alle Absender/Clienten anzuwenden, außer denen, die in einer access-Table eingetragen sind? Und natürlich das ganze so, dass nachfolgende Restrictions nicht betroffen sind.
Ich will das ganze u.A. dazu einsetzen bereits in Postfix ein Whitelist für z.B. die DynIP-Liste zu implementieren.
Geht das überhaupt?
Lade dir mal die aktuelle dynip runter und lies den Header durch da steht genau drinne wie ausnahmen dazu in der Datei selbst gemacht werden können.
Eigene User die sich anmelden müssen dürfen gar nicht bis zur Überprüfung durch dynip kommen.
Evtl. per * als Wildcard?
Mit freundlichen Grüßen
Drießen
Hallo Uwe,
Uwe Driessen schrieb:
Lade dir mal die aktuelle dynip runter und lies den Header durch da steht genau drinne wie ausnahmen dazu in der Datei selbst gemacht werden können.
Vielen Dank für den Hinweis, aber genau das möchte ich eben _nicht_.
Ich will das ganze u.A. dazu einsetzen bereits in Postfix ein Whitelist für z.B. die DynIP-Liste zu implementieren.
Ich habe hier einfach mal die DynIP-Liste exemplarisch für alles andere verwendet: - Greylisting - öffentliche Blacklists (z.B. zen.spamhaus.org) - unknown_hostname - ...
(Deshalb hatte ich auch "u.A." und "z.B." verwendet!)
Wie und dass man das bei Greylisting, PCRE-Maps außerhalb von Postfix machen kann weiß ich bereits.
Ich möchte aber gerne eine Whitelist zentral pflegen in der ich Attribute für die jeweiligen Checks habe (Flags) und je nachdem wie die Flags gesetzt sind wird der jeweilige Check übersprungen.
Geht das überhaupt?
Das Problem dabei ist, dass wenn ich z.B. für Greylisting eine eigene restriction_class anlege diese ja für _alle_ einliefernden Mailserver/Absender _außer_ denen auf der Liste gelten soll.
Die wenige Dokumentation zum Thema restriction_class geht aber den Weg, dass die Restriktionen der restriction_class nur für alle Mailserver/Absender gilt die _aufgelistet_ sind.
Eigene User die sich anmelden müssen dürfen gar nicht bis zur Überprüfung durch dynip kommen.
Schon klar, aber mir geht es ja um externe Mailserver.
Trotzdem Danke für Deinen Hilfsversuch.
Thomas
Thomas Schwenski schrieb:
Ich möchte aber gerne eine Whitelist zentral pflegen in der ich Attribute für die jeweiligen Checks habe (Flags) und je nachdem wie die Flags gesetzt sind wird der jeweilige Check übersprungen.
Geht das überhaupt?
Das Problem dabei ist, dass wenn ich z.B. für Greylisting eine eigene restriction_class anlege diese ja für _alle_ einliefernden Mailserver/Absender _außer_ denen auf der Liste gelten soll.
Beispiel selectives Greylisting
smtpd_restriction_classes = greylisting
greylisting = check_policy_service inet:127.0.0.1:60000 check_policy_service inet:127.0.0.1:12525, reject_rhsbl_sender dsn.rfc-ignorant.org
smtpd_recipient_restrictions = ....... check_client_access pcre:/etc/postfix/maps/dialups.grey, ........
/etc/postfix/maps/dialups.grey
/(-.+){4}$/ greylisting /(..+){4}$/ greylisting # everything with 3 or more dots/hyphens in the hostname ..... ..... .....
In deinem Fall dann
check_client_access pcre:liste_mit_ausnahmen
Liste_mit_ausnahmen :
/Absender1.de$/ ausnahme_white /Absender2.com$/ ausnahme_white ..... .....
smtpd_restriction_classes = ausnahme_white
ausnahme_white = Restriktion1 restriktion2 restriktion3 .......
Schickt absender1.de eine Mail dann wird an dieser Stelle die "normale" smtpd_recipient_restrictions verlassen und zur angegebenen Restriktion_Class gewechselt.
Meintest du so was?
Kannst auch Hash oder SQL oder was auch immer sonst für Tabellen benutzen.
Mit freundlichen Grüßen
Drießen
Meintest du so was?
Ja, genauso. Allerdings wäre bei mir die PCRE dann eher /.*/, da ich ja _alle_ z.B. greylisten will, außer denen, die gewhitelisted habe.
Die Variante hatte ich mir auch schon überlegt, allerdings hatte ich gehofft, dass ich ohne doppelte restriction_classes (je Restriktion) auskomme. Ich dachte an eine "Anti"-Map ala "führe die Prüfungen der restriction_class nur dann aus, wenn der Absender/Client _nicht_ auf der Liste steht".
Kannst auch Hash oder SQL oder was auch immer sonst für Tabellen benutzen.
Die Liste wäre MySQL oder Hash.
Wenn's keine Anti-Map gibt, dann muss ich das wohl auf diese Art lösen.
Danke für Deine Hilfe.
Thomas
Uwe Driessen schrieb:
Beispiel selectives Greylisting
smtpd_restriction_classes = greylisting
greylisting = check_policy_service inet:127.0.0.1:60000 check_policy_service inet:127.0.0.1:12525, reject_rhsbl_sender dsn.rfc-ignorant.org
smtpd_recipient_restrictions = ....... check_client_access pcre:/etc/postfix/maps/all, ........
/etc/postfix/maps/all
/.*/ greylisting
In deinem Fall dann check_client_access pcre:liste_mit_ausnahmen
Liste_mit_ausnahmen :
/Absender1.de$/ ausnahme_white /Absender2.com$/ ausnahme_white
smtpd_restriction_classes = ausnahme_white
ausnahme_white = Restriktion1 restriktion2 restriktion3 .......
Ahm - klappt doch nicht, außer ein DUNNO/OK innerhalb einer restriction_class gilt für die ganze Klasse.
Thomas
Thomas Schwenski schrieb:
Uwe Driessen schrieb:
Beispiel selectives Greylisting
smtpd_restriction_classes = greylisting
greylisting = check_policy_service inet:127.0.0.1:60000 check_policy_service inet:127.0.0.1:12525, reject_rhsbl_sender dsn.rfc-ignorant.org
smtpd_recipient_restrictions = ....... check_client_access pcre:/etc/postfix/maps/all, ........
/etc/postfix/maps/all
/.*/ greylisting
In deinem Fall dann check_client_access pcre:liste_mit_ausnahmen
Liste_mit_ausnahmen :
/Absender1.de$/ ausnahme_white /Absender2.com$/ ausnahme_white
smtpd_restriction_classes = ausnahme_white
ausnahme_white = Restriktion1 restriktion2 restriktion3 .......
Ahm - klappt doch nicht, außer ein DUNNO/OK innerhalb einer restriction_class gilt für die ganze Klasse.
Moment noch mal zum Anfang zurück
Restriktionen werden solange weitergeführt bis ein OK oder reject kommt (beendet die Prüfungen an diesem Punkt) Bei dunno wird mit der nächsten Prüfung weiter gemacht.
Jetzt weis ich nicht wie das mit den Verzweigungen ist Wird verzweigt und nach diesen Prüfungen zum Hauptbaum zurückgekehrt oder wird nach Beendigung der Verzweigung dann beendet und angenommen? (evtl. am Ende der Verzweigung ein permit)
Bei Beendigung nach dem Verweis in eine andere Restriktion_class musst du mit dem Whitelisting arbeiten können, wer whitegelistet ist hat nicht so viele Prüfungen. Alle die nicht im Whitelisting stehen wird bei dieser Restriktion nichts gemacht und der normale Restriktionbaum durchlaufen.
Sollte also funktionieren.
Mit freundlichen Grüßen
Drießen
Uwe Driessen schrieb:
Moment noch mal zum Anfang zurück
OK! Anforderung: Eine Reihe von Restriktionen so jeweils deselektiv durchgeführt werden. Also prinzipiell sollen alle E-Mails geprüft werden, außer dass für die jeweilige Restriktion und den jeweiligen Absender/Clienten(Mailserver)(/Empfänger) ein Whitelist-Eintrag existiert; dann soll diese eine Restriktionsprüfung übergangen werden.
Restriktionen werden solange weitergeführt bis ein OK oder reject kommt (beendet die Prüfungen an diesem Punkt) Bei dunno wird mit der nächsten Prüfung weiter gemacht.
Richtig.
Jetzt weis ich nicht wie das mit den Verzweigungen ist Wird verzweigt und nach diesen Prüfungen zum Hauptbaum zurückgekehrt oder wird nach Beendigung der Verzweigung dann beendet und angenommen? (evtl. am Ende der Verzweigung ein permit)
Da ich das auch nicht weiß hatte ich gepostet (sieht man noch am Betreff!)
Bei Beendigung nach dem Verweis in eine andere Restriktion_class musst du mit dem Whitelisting arbeiten können, wer whitegelistet ist hat nicht so viele Prüfungen. Alle die nicht im Whitelisting stehen wird bei dieser Restriktion nichts gemacht und der normale Restriktionbaum durchlaufen.
Wenn ein Permit nur die restriction_class beendet wird, dann ja. Aber ist das bei Permit such so?
Sollte also funktionieren.
Ja, wenn. Aber weißt Du sicher, dass es so ist? Oder steht's irgendwo dokumentiert?
Als Alternative könnte ich das ganze in einen Policy-Daemon packen, aber schöner wäre es wenn's ohne ginge.
Thomas
Thomas Schwenski schrieb:
Wenn ein Permit nur die restriction_class beendet wird, dann ja. Aber ist das bei Permit such so?
Nach einem permit wird angenommen und fertig.
Sollte also funktionieren.
Ja, wenn. Aber weißt Du sicher, dass es so ist? Oder steht's irgendwo dokumentiert?
Garantiert it das irgendwo dokumentiert
http://www.postfix.org/RESTRICTION_CLASS_README.html
Als Alternative könnte ich das ganze in einen Policy-Daemon packen, aber schöner wäre es wenn's ohne ginge.
Mit freundlichen Grüßen
Drießen
Uwe Driessen schrieb:
Thomas Schwenski schrieb:
Wenn ein Permit nur die restriction_class beendet wird, dann ja. Aber ist das bei Permit such so?
Nach einem permit wird angenommen und fertig.
Eben, deshalb funktioniert das eben nicht so, wie gewünscht. (Oder ich habe Dich misverstanden.)
Sollte also funktionieren.
Ja, wenn. Aber weißt Du sicher, dass es so ist? Oder steht's irgendwo dokumentiert?
Garantiert it das irgendwo dokumentiert
Dort sind nur die restriction_classes dokumentiert. Ich finde da aber kein Wort dazu, was eine Access-Map liefern muss, damit nur die restriction_class beendet wird aber die nächste smtpd_recipient_restriction abgearbeitet wird.
Als Alternative könnte ich das ganze in einen Policy-Daemon packen, aber schöner wäre es wenn's ohne ginge.
Ich bin noch so schlau wie zu Beginn.
Thomas
Hallo Thomas,
Am Donnerstag, 26. Juni 2008 schrieb Thomas Schwenski:
Ich finde da aber kein Wort dazu, was eine Access-Map liefern muss, damit nur die restriction_class beendet wird aber die nächste smtpd_recipient_restriction abgearbeitet wird.
das geht nicht. Eine restriction_class wird immer als Block abgearbeitet. Du musst deine Prüfungen auf mehrere restriction_classes verteilen und diese dann abhängig von deinen Bedingungen aufrufen.
Gruß, Gregor
Gregor Hermens schrieb:
Hallo Thomas,
Am Donnerstag, 26. Juni 2008 schrieb Thomas Schwenski:
Ich finde da aber kein Wort dazu, was eine Access-Map liefern muss, damit nur die restriction_class beendet wird aber die nächste smtpd_recipient_restriction abgearbeitet wird.
das geht nicht. Eine restriction_class wird immer als Block abgearbeitet. Du musst deine Prüfungen auf mehrere restriction_classes verteilen und diese dann abhängig von deinen Bedingungen aufrufen.
Genau das will ich ja:
Ich will eine restriction_class für Greylisting haben, eine für DynIP, eine für unknown_host, ...
Allerdings soll das ganze _deselektiv_ stattfinden, also es sollen _alle_ E-Mails den jeweiligen Prüfungen unterzogen werden, _außer_ der Absender/Client (im Sinne von einlieferndem Mailserver) steht auf einer Whitelist für diese Restriction.
Thomas
* Thomas Schwenski mailing-lists@thomasschwenski.de wrote:
Ich finde da aber kein Wort dazu, was eine Access-Map liefern muss, damit nur die restriction_class beendet wird aber die nächste smtpd_recipient_restriction abgearbeitet wird.
Diese Funktionalität existiert nicht.
das geht nicht. Eine restriction_class wird immer als Block abgearbeitet. Du musst deine Prüfungen auf mehrere restriction_classes verteilen und diese dann abhängig von deinen Bedingungen aufrufen.
Genau das will ich ja:
Die korrekte Antwort lautet: Schreibe Dir einen Policy-Service. Du bist auf einem guten Weg, Dir in den Fuß zu schießen, wenn Du das so umsetzen willst.
Ich will eine restriction_class für Greylisting haben, eine für DynIP, eine für unknown_host, ...
smtpd_restriction_classes = greylisting,dynip greylisting = check_policy_service foo:bar dynip = reject_rbl_client mumble
Allerdings soll das ganze _deselektiv_ stattfinden, also es sollen _alle_ E-Mails den jeweiligen Prüfungen unterzogen werden, _außer_ der Absender/Client (im Sinne von einlieferndem Mailserver) steht auf einer Whitelist für diese Restriction.
smtpd_recipiten_restrcitions = check_recipient_access pcre:/blubber/greylisitng.map check_recipient_access pcre:/blubber/dynip.map ...
greylisting.map: /aus@nahme.1/ dunno /aus@nahme.2/ dunno /./ greylisting
Ich sag's nochmal: Du bist auf dem allerbesten Weg, Dir einen wartungs- und verwaltungstechnischen Albtraum an die Backe zu binden. Wenn Du das alles wirklich umsetzen musst, solltest Du dringend darüber nachdenken, einen Policy-Service zu schreiben.
Ciao Stefan
Hallo Stefan,
Ich finde da aber kein Wort dazu, was eine Access-Map liefern muss, damit nur die restriction_class beendet wird aber die nächste smtpd_recipient_restriction abgearbeitet wird.
Diese Funktionalität existiert nicht.
Das ist mal eine eindeutige Aussage.
Die korrekte Antwort lautet: Schreibe Dir einen Policy-Service. Du bist auf einem guten Weg, Dir in den Fuß zu schießen, wenn Du das so umsetzen willst.
Das war mein Option für den Fall, dass es eben nicht so funktioniert, wie ich das mit restriction_classes vorgehabt hatte.
Ich will eine restriction_class für Greylisting haben, eine für DynIP, eine für unknown_host, ...
smtpd_restriction_classes = greylisting,dynip greylisting = check_policy_service foo:bar dynip = reject_rbl_client mumble
Allerdings soll das ganze _deselektiv_ stattfinden, also es sollen _alle_ E-Mails den jeweiligen Prüfungen unterzogen werden, _außer_ der Absender/Client (im Sinne von einlieferndem Mailserver) steht auf einer Whitelist für diese Restriction.
smtpd_recipiten_restrcitions = check_recipient_access pcre:/blubber/greylisitng.map check_recipient_access pcre:/blubber/dynip.map ...
greylisting.map: /aus@nahme.1/ dunno /aus@nahme.2/ dunno /./ greylisting
Das funktioniert, aber ich würde mich für die Ausahmen auf PCRE festlegen. Eine PCRE-MAP aus einer Hash oder MySQL-Tabelle zu erzeugen ist dabei kein Problem, aber PCRE würde ab einer gewissen Länge zur Performance-Verschwendung.
Ich sag's nochmal: Du bist auf dem allerbesten Weg, Dir einen wartungs- und verwaltungstechnischen Albtraum an die Backe zu binden.
Finde ich nicht: Eine MySQL-Datenbanktabelle als Backend in der der jeweilige Eintrag mit Flags für die einzelnen Restriktionen, die übersprungen werden sollen, versehen ist. Die dann entweder per Script in Hash oder PCRE (wobei Letzteres aus Performance-Gründen vermieden werden könnte) transformieren oder per proxy:mysql: auslesen lassen. Einmal konfiguriert ist das Ganze eigentlich unproblematisch meiner Meinung nach.
Und die Konfiguration ist ein einmaliger Mehraufwand.
Wenn Du das alles wirklich umsetzen musst, solltest Du dringend darüber nachdenken, einen Policy-Service zu schreiben.
Was ich, aufgrund der (mittlerweile durch Dich bestätigten) Einschränkungen von restriction_classes auch schon überlegt habe und letztendlich auch tun werde.
Thomas
Hallo Thomas,
Am Donnerstag, 26. Juni 2008 schrieb Thomas Schwenski:
Gregor Hermens schrieb:
das geht nicht. Eine restriction_class wird immer als Block abgearbeitet. Du musst deine Prüfungen auf mehrere restriction_classes verteilen und diese dann abhängig von deinen Bedingungen aufrufen.
Genau das will ich ja:
Ich will eine restriction_class für Greylisting haben, eine für DynIP, eine für unknown_host, ...
Allerdings soll das ganze _deselektiv_ stattfinden, also es sollen _alle_ E-Mails den jeweiligen Prüfungen unterzogen werden, _außer_ der Absender/Client (im Sinne von einlieferndem Mailserver) steht auf einer Whitelist für diese Restriction.
main.cf:
smptd_*_restrictions = ... check_recipient_access pcre:/etc/postfix/greylisting ...
/etc/postfix/greylisting:
/^kein.greylisting@example.com$/ DUNNO /^kein.greylisting@example.net$/ DUNNO /.*/ greylisting
Gruß, Gregor
Hallo Thomas,
Am Donnerstag, 26. Juni 2008 schrieb Gregor Hermens: main.cf:
smptd_*_restrictions = ... check_recipient_access hash:/etc/postfix/gl-hash,pcre:/etc/postfix/gl-pcre ...
/etc/postfix/gl-hash:
kein.greylisting@example.com DUNNO kein.greylisting@example.net DUNNO
/etc/postfix/gl-pcre
/.*/ greylisting
Du kannst deine Whitelist natürlich auf so viele verschiedene Maps wie nötig verteilen. Wichtig ist nur, daß die letzte Zeile der Letzten Map allen, die bis dahin durchgekommen sind, die restriction_class verpasst.
Gruß, Gregor
Thomas Schwenski schrieb:
Gregor Hermens schrieb:
Hallo Thomas,
Am Donnerstag, 26. Juni 2008 schrieb Thomas Schwenski:
Ich finde da aber kein Wort dazu, was eine Access-Map liefern muss, damit nur die restriction_class beendet wird aber die nächste smtpd_recipient_restriction abgearbeitet wird.
das geht nicht. Eine restriction_class wird immer als Block abgearbeitet. Du musst deine Prüfungen auf mehrere restriction_classes verteilen und diese dann abhängig von deinen Bedingungen aufrufen.
Genau das will ich ja:
Ich will eine restriction_class für Greylisting haben, eine für DynIP, eine für unknown_host, ...
Allerdings soll das ganze _deselektiv_ stattfinden, also es sollen _alle_ E-Mails den jeweiligen Prüfungen unterzogen werden, _außer_ der Absender/Client (im Sinne von einlieferndem Mailserver) steht auf einer Whitelist für diese Restriction.
Nö so nicht wenn dann
Recipient-restriktionen = ..... Check_sender_access = verzweigung zu Greylistung
Greylisting = ..... Check_sender_access = verzweigung zu dynip greylisting Verweis nach dynip
Dynip = ....... Check_sender_access = verzweigung zu pw Check dynip ..... Verweis zu pw vom rest
Pw = ....
Absendercheck = .....
Alle = ........
In den Ausnahmen dann jeweils eine Tabelle
Domain1.de verzweigung zu ......
Brauchst dann halt pro check eine eigene Datei oder in Mysql ein eigenes Feld das du dafür abfragst. Damit ginge dann auch das jemand vor dem Greylisting schon zur Prüfung für alle springt.
Bevor der eigentliche Check dann gemacht wird springt Postfix für die in der Ausnahme stehen zum nächsten Check. So kannst du es machen aber ob das sinnvoll ist wage ich mal zu bezweifeln.
Selectives Greylisting wie im ersten Beispiel beschrieben und die ausnahmen wie in der dynip an den Anfang mit einem dunno dahinter beendet den aktuellen check sei es nun Greylisting oder dynipcheck oder sonstiges
Bzw. bei Greylisting einfach nur bestimmte toplevel Domains durchschleusen.
Entweder hast du Server die aus einem DIALIN kommen dann ist es egal ob du die checks so abstrus ausbaust oder gleich in die Datei reinschreibst.
Vom Greylisting merkt der Kunde nach der 2. Mail eh nichts mehr.
Mit freundlichen Grüßen
Drießen
Uwe Driessen schrieb:
Recipient-restriktionen = ..... Check_sender_access = verzweigung zu Greylistung
Greylisting = ..... Check_sender_access = verzweigung zu dynip greylisting Verweis nach dynip
Dynip = ....... Check_sender_access = verzweigung zu pw Check dynip ..... Verweis zu pw vom rest
Pw = ....
Absendercheck = .....
Alle = ........
In den Ausnahmen dann jeweils eine Tabelle Domain1.de verzweigung zu ......
Brauchst dann halt pro check eine eigene Datei oder in Mysql ein eigenes Feld das du dafür abfragst.
Das war mir klar.
Damit ginge dann auch das jemand vor dem Greylisting schon zur Prüfung für alle springt.
Deine Variante würde sogar ohne pcre auskommen. Prima Idee - Danke.
Verunstaltet natürlich die smtpd_*_restrictions bis zur Unlesbarkeit für einen Uneingeweihten, aber das war zu erwarten.
Bevor der eigentliche Check dann gemacht wird springt Postfix für die in der Ausnahme stehen zum nächsten Check. So kannst du es machen aber ob das sinnvoll ist wage ich mal zu bezweifeln.
Jedem seine Anforderungen. Hier ist es eben so, dass Greylisting UND DynIP UND Blacklist gemacht werden müssen. Ich will aber lieber restriktiv Whitelisten, also einzelne Absender/Clients nur für die Checks Whitelisten, an denen sie scheitern, als gleich komplett durchzuwinken.
Selectives Greylisting wie im ersten Beispiel beschrieben und die ausnahmen wie in der dynip an den Anfang mit einem dunno dahinter beendet den aktuellen check sei es nun Greylisting oder dynipcheck oder sonstiges Bzw. bei Greylisting einfach nur bestimmte toplevel Domains durchschleusen.
Entweder hast du Server die aus einem DIALIN kommen dann ist es egal ob du die checks so abstrus ausbaust oder gleich in die Datei reinschreibst. Vom Greylisting merkt der Kunde nach der 2. Mail eh nichts mehr.
Eben, aber erst beim Greylisting weiß man ja, ob es die Erste oder eine Folgemail ist.
Danke für deinen Bauplan.
Thomas
On Behalf Of Thomas Schwenski schrieb:
Deine Variante würde sogar ohne pcre auskommen. Prima Idee - Danke.
Welche maps du dahinter hängst kommt auf den Inhalt an.
Ein
/Smtp\d.server.(com|de)$/ wird als Hash nicht funktionieren
Verunstaltet natürlich die smtpd_*_restrictions bis zur Unlesbarkeit für einen Uneingeweihten, aber das war zu erwarten.
Jap deswegen würde ich nach einem anderen Weg suchen. Entschärfen der dynip, explizites Whitelisten mit ok (und das nur als Ausnahme). wenn wirklich einer auf die schnauze fliegt dann stimmt meist mehr wie eine Sache am dem Server nicht.
Bevor der eigentliche Check dann gemacht wird springt Postfix für die in der Ausnahme stehen zum nächsten Check. So kannst du es machen aber ob das sinnvoll ist wage ich mal zu bezweifeln.
Jedem seine Anforderungen. Hier ist es eben so, dass Greylisting UND DynIP UND Blacklist gemacht werden müssen. Ich will aber lieber restriktiv Whitelisten, also einzelne Absender/Clients nur für die Checks Whitelisten, an denen sie scheitern, als gleich komplett durchzuwinken.
Nun ja das ist Geschmackssache wenn du wirklich weißt wer das ist dann kannst du Ihn auch gleich durchwinken ansonsten fängst du beim nächsten Problem wieder an den Check auszubauen.
Ich weis ja jetzt nicht um wie viele Adressen/Server es dabei geht die du so von den einzelnen Checks ausnehmen willst....
Eben, aber erst beim Greylisting weiß man ja, ob es die Erste oder eine Folgemail ist.
Ja und wo liegt dabei das Problem? Postgrey usw. verwalten das doch schön selber und Problemserver die bekannt sind das diese sich nicht an die Standards halten sind ja schon drin vermerkt. Wenn da noch welche dazu müssen dann trag die lieber im Greylisting dazu wie unter Postfix solche Konstrukte zu bilden.
Gib mal einige Beispiele welche Server wo hängen bleiben. Nicht jedes Problem muß auf dem eigenen Server behoben werden.
Mit freundlichen Grüßen
Drießen
Uwe Driessen schrieb:
Nun ja das ist Geschmackssache wenn du wirklich weißt wer das ist
dann > kannst du Ihn auch gleich durchwinken ansonsten fängst du beim
nächsten Problem wieder an den Check auszubauen.
Und das kann ich leider eben nicht, weil ich die Leute nicht kenne.
Ich weis ja jetzt nicht um wie viele Adressen/Server es dabei geht
die > du so von den einzelnen Checks ausnehmen willst....
Es hält sich (Dank des Arbeitsablaufes) in überschaubarem Rahmen (zwischen 50-100 aktiven Einträgen)
Ja und wo liegt dabei das Problem? Postgrey usw. verwalten das doch schön selber und Problemserver die bekannt sind das diese sich nicht an die Standards halten sind ja schon drin vermerkt. Wenn da noch welche dazu müssen dann trag die lieber im Greylisting dazu wie unter Postfix solche Konstrukte zu bilden.
Gib mal einige Beispiele welche Server wo hängen bleiben. Nicht jedes Problem muß auf dem eigenen Server behoben werden.
Das läuft in der Regel so ab, dass hier jemand mit etwas "unüblicher" Konfiguration aufschlägt. Im aktuellsten Fall war das eine Firma, die Ihre Mails über einen Internet-MX an eine Einwahlmailserver zustellen lassen, der wiederum aber versucht ausgehende Mails direkt an die Ziel-MX zu liefern und sich beim HELO mit Servername.local meldet.
Ich schick dann dem Absender und dessen Postmaster immer eine Fehlerbeschreibung und wie das Problem behoben werden könnte und setze die temporär auf eine Whitelist für ein bis 2 Wochen, damit die Kommunikation erstmal möglich ist.
Da ich selbst keine Kontrolle über die absendenden Mailserver habe und auch nichtmal Einblick über den Zustand von deren Konfiguration, überspringe ich lieber nur so wenig wie möglich Prüfungen.
Thomas
Thomas Schwenski schrieb:
Jedem seine Anforderungen. Hier ist es eben so, dass Greylisting UND DynIP UND Blacklist gemacht werden müssen. Ich will aber lieber restriktiv Whitelisten, also einzelne Absender/Clients nur für die Checks Whitelisten, an denen sie scheitern, als gleich komplett durchzuwinken.
Klar, jedem das Seine usw und wenn man mal eine Idee hat, will man das auch umsetzen - kenne ich. Aber gibt es dafür wirklich einen realen Anwendungsfall? Szenario: Ein Partner schreibt Dir, knallt aber leider gegen die Dynip-Liste. Du platzierst also ein Whitelisting für diese und wartest gespannt auf Deine Nachricht... aber, was ist das? Jetzt ist der auch noch bei Spamcop gelistet! Ist Dir die Nachricht dann nicht mehr wichtig, oder würdest Du doch nur das nächste Whitelisting einbauen? Sprich: Lohnt der Mehraufwand wirklich oder ist es vll doch so, dass man die Mails von jemandem, den man explizit freigibt nicht ohnehin unter allem Umständen bekommen möchte? All diese Maßnahmen wie Greylisting, Dynip oder dnsbls beziehen sich ja doch nur auf die Herkunft und sind daher nicht geeignet, gute und böse Mails von der selben Quelle zu unterscheiden.
Geschweige denn, dass 37 Ausnahmeprüfungen Dein System in größerem Maß belasten als eine gut formulierte PCRE Table.
Jan P. Kessler schrieb:
Geschweige denn, dass 37 Ausnahmeprüfungen Dein System in größerem Maß belasten als eine gut formulierte PCRE Table.
Deshalb werde ich das Ganze langfristig auch lieber mit einem Policy-Daemon umsetzen.
Klar, jedem das Seine usw und wenn man mal eine Idee hat, will man das auch umsetzen - kenne ich. Aber gibt es dafür wirklich einen realen Anwendungsfall? Szenario: Ein Partner schreibt Dir, knallt aber leider gegen die Dynip-Liste. Du platzierst also ein Whitelisting für diese und wartest gespannt auf Deine Nachricht... aber, was ist das? Jetzt ist der auch noch bei Spamcop gelistet! Ist Dir die Nachricht dann nicht mehr wichtig, oder würdest Du doch nur das nächste Whitelisting einbauen? Sprich: Lohnt der Mehraufwand wirklich oder ist es vll doch so, dass man die Mails von jemandem, den man explizit freigibt nicht ohnehin unter allem Umständen bekommen möchte? All diese Maßnahmen wie Greylisting, Dynip oder dnsbls beziehen sich ja doch nur auf die Herkunft und sind daher nicht geeignet, gute und böse Mails von der selben Quelle zu unterscheiden.
Prinzipiell hast Du Recht. Mails sollten in jedem Fall ankommen. Auch dass ich nur die Herkunft prüfe und nicht den Inhalt ist mir klar. Um den Inhalt kümmert sich dann ja noch Amavis/SpamAssassin/ClamAV.
Prinzipiell handelt es sich beim Großteil meiner Einträge auf der Whitelist aber auch nur um temporäre Einträge. Ein Lookup für den Absender/Client sollte da wohl nicht so viel mehr Last verursachen.
Für den Anfang werde ich es erstmal per restriction_class umsetzen und das dann gegen den Policy-Daemon austauschen.
Thomas
* "Jan P. Kessler" postfix@jpkessler.info wrote:
Thomas Schwenski schrieb:
Jedem seine Anforderungen. Hier ist es eben so, dass Greylisting UND DynIP UND Blacklist gemacht werden müssen. Ich will aber lieber restriktiv Whitelisten, also einzelne Absender/Clients nur für die Checks Whitelisten, an denen sie scheitern, als gleich komplett durchzuwinken.
Klar, jedem das Seine usw und wenn man mal eine Idee hat, will man das auch umsetzen - kenne ich. Aber gibt es dafür wirklich einen realen Anwendungsfall? Szenario: Ein Partner schreibt Dir, knallt aber leider gegen die Dynip-Liste. Du platzierst also ein Whitelisting für diese und wartest gespannt auf Deine Nachricht... aber, was ist das? Jetzt ist der auch noch bei Spamcop gelistet! Ist Dir die Nachricht dann nicht mehr wichtig, oder würdest Du doch nur das nächste Whitelisting einbauen?
Eigentlich sollte so eine Kommunikation zwischen den beteiligten Posthamstern stattfinden. Ein generelles Durchwinken von abuse@ und postmaster@ um genau das zu ermöglichen ist eigentlich noch gut in den Griff zu kriegen.
Ansonsten glaube ich, das Thomas entschlossen ist, daß so umzusetzen, weswegen ich nicht glaube, daß es lohnt, ihn da umsimmen zu wollen ;-)
Ciao Stefan
Stefan Förster schrieb:
- "Jan P. Kessler" postfix@jpkessler.info wrote:
Thomas Schwenski schrieb:
Jedem seine Anforderungen. Hier ist es eben so, dass Greylisting UND DynIP UND Blacklist gemacht werden müssen. Ich will aber lieber restriktiv Whitelisten, also einzelne Absender/Clients nur für die Checks Whitelisten, an denen sie scheitern, als gleich komplett durchzuwinken.
Klar, jedem das Seine usw und wenn man mal eine Idee hat, will man das auch umsetzen - kenne ich. Aber gibt es dafür wirklich einen realen Anwendungsfall? Szenario: Ein Partner schreibt Dir, knallt aber leider gegen die Dynip-Liste. Du platzierst also ein Whitelisting für diese und wartest gespannt auf Deine Nachricht... aber, was ist das? Jetzt ist der auch noch bei Spamcop gelistet! Ist Dir die Nachricht dann nicht mehr wichtig, oder würdest Du doch nur das nächste Whitelisting einbauen?
Eigentlich sollte so eine Kommunikation zwischen den beteiligten Posthamstern stattfinden. Ein generelles Durchwinken von abuse@ und postmaster@ um genau das zu ermöglichen ist eigentlich noch gut in den Griff zu kriegen.
So geschieht es hier. Da ich mich immer mit dem Absender und seinen Postmaster in Verbindung setze um (mit) denen das Problem und dessen mögliche Behebung zu (er)klären, sind es ja auch meist nur temporäre Einträge in der Whitelist.
Ansonsten glaube ich, das Thomas entschlossen ist, daß so umzusetzen, weswegen ich nicht glaube, daß es lohnt, ihn da umsimmen zu wollen ;-)
Psychologie Note 1 ;D
Ernsthaft: Ich werde das so umsetzen, da es momentan eine Verbesserung des status quo hier darstellt. Wenn ich es irgendwann mal wieder rausnehme habe ich eben meine Kenntnisse in Perl-Programmierung aufgefrischt und verbessert und auch noch ein schönes Tool entwickelt.
Das war das Wort zum Wochenende.
Thomas
participants (5)
-
Gregor Hermens -
Jan P. Kessler -
Stefan Förster -
Thomas Schwenski -
Uwe Driessen