[postfix-users] mehrere restriction classes in einem Lookup?
Tach zusammen,
wenn ich "Features zu aktivieren" in restriction classes zusamenfasse - so ala:
restriction_classes = greylist, rblcheck
greylist = check_recipient_access = hash:/path/whitelist check_access = hash:/path/whitelist check_policy_service inet:127.0.0.1:4711
rblcheck = reject_rbl_client ix.dnsbl.manitu.net reject_rbl_client zen.spamhaus.org
smtpd_recipient_restrictions = .. check_recipient_access hash:/path/restrictions ..
würde das (vor allem das erste) gehen..? oder irgendwie anders?
# /path/restrictions: example.net greylist, rblcheck example.com greylist example.de rblcheck
oder muss man für jede einzelne Möglichkeit einer Restriction eine eigene Zeile check_recipient_access und verschiedene Tabellen machen?
Grüsse Christian
P.S. Und eigentlich ist hash:/path/restrictions in Wirklichkeit proxy:pgsql:/path/restrictions.cf ;-) Also so ungefähr: "Mach nen Lookup auf den Recipient - was hat der als Features aktiviert und gehe die der Reihe nach durch?"
* Christian Bricart christian@bricart.de:
Tach zusammen,
wenn ich "Features zu aktivieren" in restriction classes zusamenfasse - so ala:
restriction_classes = greylist, rblcheck
greylist = check_recipient_access = hash:/path/whitelist check_access = hash:/path/whitelist check_policy_service inet:127.0.0.1:4711
Falsche Syntax. greylist = check_recipient_access hash:/path/whitelist check_access hash:/path/whitelist check_policy_service inet:127.0.0.1:4711
Ralf Hildebrandt wrote:
[..] Falsche Syntax. greylist = check_recipient_access hash:/path/whitelist check_access hash:/path/whitelist check_policy_service inet:127.0.0.1:4711
argh - hilfe! ;-) wieso verbessern alle meinen schnell runtergeschriebenen Pseudocode, statt meine eigentliche Frage zu beantworten? ;-)))
SCNR Christian
Christian Bricart schrieb:
Ralf Hildebrandt wrote:
[..] Falsche Syntax. greylist = check_recipient_access hash:/path/whitelist check_access hash:/path/whitelist check_policy_service inet:127.0.0.1:4711
argh - hilfe! ;-) wieso verbessern alle meinen schnell runtergeschriebenen Pseudocode, statt meine eigentliche Frage zu beantworten? ;-)))
SCNR Christian
scnr: Vielleicht weil niemand nicht wissen kann dass das nicht copy n paste ist (was jeder wohl erwartet) ;-).
Christian Bricart schrieb:
restriction_classes = greylist, rblcheck
Das heist aber doch smtpd_restriction_classes
smtpd_restriction_classes (default: empty) User-defined aliases for groups of access restrictions. The aliases can be specified in smtpd_recipient_restrictions etc., and on the right-hand side of a Postfix access(5) table.
One major application is for implementing per-recipient UCE control. See the RESTRICTION_CLASS_README document for other examples
>>>>>http://www.postfix.org/RESTRICTION_CLASS_README.html<<<<<<<<<<<<<<<<
greylist = check_recipient_access = hash:/path/whitelist check_access = hash:/path/whitelist check_policy_service inet:127.0.0.1:4711
rblcheck = reject_rbl_client ix.dnsbl.manitu.net reject_rbl_client zen.spamhaus.org
smtpd_recipient_restrictions = .. check_recipient_access hash:/path/restrictions ..
würde das (vor allem das erste) gehen..? oder irgendwie anders?
Protecting internal email distribution lists We want to implement an internal email distribution list. Something like all@our.domain.com, which aliases to all employees. My first thought was to use the aliases map, but that would lead to "all" being accessible from the "outside", and this is not desired... :-)
Postfix can implement per-address access controls. What follows is based on the SMTP client IP address, and therefore is subject to IP spoofing.
/etc/postfix/main.cf: smtpd_recipient_restrictions = check_recipient_access hash:/etc/postfix/access ...the usual stuff...
/etc/postfix/access: all@my.domain permit_mynetworks,reject all@my.hostname permit_mynetworks,reject Specify dbm instead of hash if your system uses dbm files instead of db files. To find out what map types Postfix supports, use the command postconf -m.
# /path/restrictions: example.net greylist, rblcheck example.com greylist example.de rblcheck
Mit freundlichen Grüßen
Drießen
* Christian Bricart christian@bricart.de:
Uwe Driessen wrote:
Christian Bricart schrieb:
restriction_classes = greylist, rblcheck
Das heist aber doch smtpd_restriction_classes
schon klar - das war kein cut&Paste sondern runtergeschrieben ;-) aber danke ;-)
Aber ja, was du machen willst klappt so wie Du es planst...
Ralf Hildebrandt wrote:
- Christian Bricart christian@bricart.de:
Uwe Driessen wrote:
Christian Bricart schrieb:
restriction_classes = greylist, rblcheck
Das heist aber doch smtpd_restriction_classes
schon klar - das war kein cut&Paste sondern runtergeschrieben ;-) aber danke ;-)
Aber ja, was du machen willst klappt so wie Du es planst...
Also einfach ne Komma-separierte Liste von restriction classes zurückliefern, oder mehrere Zeilen mit je einem Wert..?
Christian
* Christian Bricart christian@bricart.de:
Also einfach ne Komma-separierte Liste von restriction classes zurückliefern, oder mehrere Zeilen mit je einem Wert..?
Komma-separierte Liste, am besten
foo.de a,b,c,d
ohne spaces.
Sagt mir, ob ich mich täusche, aber ist das so nicht "Unsinn"?
Christian Bricart schrieb:
restriction_classes = greylist, rblcheck
greylist = check_recipient_access = hash:/path/whitelist check_access = hash:/path/whitelist check_policy_service inet:127.0.0.1:4711
Wenn hier jemand in die Whitelists passt und die Whitelists ein OK liefern, wird dann nicht JEDER andere Check übersprungen?
rblcheck = reject_rbl_client ix.dnsbl.manitu.net reject_rbl_client zen.spamhaus.org
smtpd_recipient_restrictions = .. check_recipient_access hash:/path/restrictions ..
würde das (vor allem das erste) gehen..? oder irgendwie anders?
# /path/restrictions: example.net greylist, rblcheck example.com greylist example.de rblcheck
Also am Beispiel example.net: Die Whitelist würde bei einem OK verhindern, dass die RBL-Checks jemals durchgeführt werden, weil die Mail ja bereits da schon angenommen würde.
Ist das wirklich so beabsichtigt?
Außerdem finde ich die Reihenfolge erst Greylisting, danach RBL eher unpraktisch. Steht ein Absender auf einer RBL, dann würde er erst durch's Greylisting ausgebremst nur um dann später abgelehnt zu werden. Warum nicht gleich ablehnen?
Thomas
On Fri, May 09, 2008 at 01:19:40PM +0200, Thomas Schwenski wrote:
Außerdem finde ich die Reihenfolge erst Greylisting, danach RBL eher unpraktisch. Steht ein Absender auf einer RBL, dann würde er erst durch's Greylisting ausgebremst nur um dann später abgelehnt zu werden. Warum nicht gleich ablehnen?
Der Vorteil erst Greyisting, dann RBL liegt darin, dass es eine Weile dauert bis Clients in den RBLs dieser Welt auftauchen - es ist also immer gut, eine Weile zu warten - und wenn er nicht wiederkommt, spart man sich ein paar (recht teure) DNS lookups.
Auch ist es sinnvoll, low-delay-checks (greylistdb-lookup) vor high-delay-checks (DNS) zu machen - die high-delay-checks (DNS) stellen darueber hinaus einen DoS-Vektor dar.
Ein Weiterer Vorteil liegt darin, die Bandbreiten deines freundlichen RBL-Anbieters zu schonen.
On Fri, May 9, 2008 at 1:48 PM, Robert Felber r.felber@ek-muc.de wrote:
Der Vorteil erst Greyisting, dann RBL liegt darin, dass es eine Weile dauert bis Clients in den RBLs dieser Welt auftauchen - es ist also immer gut, eine Weile zu warten - [...]
Das Argument halte ich für wenig schlüssig. Denn ob vor oder nach den RBLs, er landet definitiv im Greylisting und muß ein zweites Mal wiederkommen. Sollte er in der Zwischenzeit auf einer RBL landen, würde er in beiden Konstellationen abgelehnt.
Nighthawk schrieb:
On Fri, May 9, 2008 at 1:48 PM, Robert Felber r.felber@ek-muc.de wrote:
Der Vorteil erst Greyisting, dann RBL liegt darin, dass es eine Weile dauert bis Clients in den RBLs dieser Welt auftauchen - es ist also immer gut, eine Weile zu warten - [...]
Das Argument halte ich für wenig schlüssig. Denn ob vor oder nach den RBLs, er landet definitiv im Greylisting und muß ein zweites Mal wiederkommen. Sollte er in der Zwischenzeit auf einer RBL landen, würde er in beiden Konstellationen abgelehnt.
Aber ich halte es für schlüssig
Greylisted Verzögerung von 5 min standart Trojaner, Wurm sonstiger scheiß kommt nicht wieder RBL wurde noch nicht befragt Entlastung der RBL Server bzw. Trafik Ersparnis
Spamer versucht 2 mal kurz hintereinander kommt erst in ein paar Stunden wieder In der Zeit kann er im besten Fall gelistet sein
Dabei es ist nicht von Bedeutung ob man RBL's so einträgt oder über pw abfragt
Anders herum wird die RBL 2 mal abgefragt einmal kann man sich sparen.
Lokale Test lasse ich auch soweit möglich vor den externen Tests laufen. Das macht bei mir zwar den Bock nicht fett aber bei einem Server der unter Dauerfeuer steht macht das dann schon ein paar Mchen am Tag aus die über externe Abfragen weniger benötigt werden.
Mit freundlichen Grüßen
Drießen
2008/5/10 Uwe Driessen driessen@fblan.de:
Nighthawk schrieb:
On Fri, May 9, 2008 at 1:48 PM, Robert Felber r.felber@ek-muc.de wrote:
Der Vorteil erst Greyisting, dann RBL liegt darin, dass es eine Weile dauert bis Clients in den RBLs dieser Welt auftauchen - es ist also immer gut, eine Weile zu warten - [...]
Das Argument halte ich für wenig schlüssig. Denn ob vor oder nach den RBLs, er landet definitiv im Greylisting und muß ein zweites Mal wiederkommen. Sollte er in der Zwischenzeit auf einer RBL landen, würde er in beiden Konstellationen abgelehnt.
Aber ich halte es für schlüssig
Greylisted Verzögerung von 5 min standart Trojaner, Wurm sonstiger scheiß kommt nicht wieder RBL wurde noch nicht befragt Entlastung der RBL Server bzw. Trafik Ersparnis
Ich habe absichtlich den gequoteten Text so kurz gefasst, daß eigentlich unmißverständlich zu sehen ist, worum es mir geht: Es wird garantiert in keiner der beiden Konstellationen auch nur ein Client abgelehnt, der in der anderen nicht abgelehnt würde. Damit ist Roberts erstes Argument für mich nicht schlüssig.
Den Rest kann man gerne so stehen lassen. Sowohl die Tatsache, daß Greylisting schneller, als eine DNS Abfrage ist, als auch das es einem die RBL Betreiber danken werden, ist wohl richtig.
* nighthawk nighthawk@gmail.com wrote:
On Fri, May 9, 2008 at 1:48 PM, Robert Felber r.felber@ek-muc.de wrote:
Der Vorteil erst Greyisting, dann RBL liegt darin, dass es eine Weile dauert bis Clients in den RBLs dieser Welt auftauchen - es ist also immer gut, eine Weile zu warten - [...]
Das Argument halte ich für wenig schlüssig. Denn ob vor oder nach den RBLs, er landet definitiv im Greylisting und muß ein zweites Mal wiederkommen. Sollte er in der Zwischenzeit auf einer RBL landen, würde er in beiden Konstellationen abgelehnt.
Als Wietse den stress-Patch für Postfix vorgestellt hat, gab es auf der ML da einige Diskussionen, wie man verfahren kann, wenn man z.B. regelmäßig an das Limit an smtpd-Prozessen gerät (damals gibg es IIRC um Botnetze). In einer derartigen Situation ist es ganz klar von Vorteil, die billigen (i.S.v. "wenig zeitaufwändig") Checks zuerst zu machen. Allerdings waren die beschriebenen Situationen wirklich Extremfälle, die so normalerweise nicht auftauchen.
Im Normalbetrieb ist dies jedoch kein zwingender _technischer_ Grund. Man mag jedoch argumentieren, daß die RBL-Betreiber einem evt. dankbar sind, wenn man nur die Hälfte der Abfragen generiert - wieder nur die technische Seite berücksichtigend.
Ciao Stefan
Stefan Förster schrieb:
- nighthawk nighthawk@gmail.com wrote:
On Fri, May 9, 2008 at 1:48 PM, Robert Felber r.felber@ek-muc.de wrote:
Der Vorteil erst Greyisting, dann RBL liegt darin, dass es eine Weile dauert bis Clients in den RBLs dieser Welt auftauchen - es ist also immer gut, eine Weile zu warten - [...]
Das Argument halte ich für wenig schlüssig. Denn ob vor oder nach den RBLs, er landet definitiv im Greylisting und muß ein zweites Mal wiederkommen. Sollte er in der Zwischenzeit auf einer RBL landen, würde er in beiden Konstellationen abgelehnt.
Als Wietse den stress-Patch für Postfix vorgestellt hat, gab es auf der ML da einige Diskussionen, wie man verfahren kann, wenn man z.B. regelmäßig an das Limit an smtpd-Prozessen gerät (damals gibg es IIRC um Botnetze). In einer derartigen Situation ist es ganz klar von Vorteil, die billigen (i.S.v. "wenig zeitaufwändig") Checks zuerst zu machen. Allerdings waren die beschriebenen Situationen wirklich Extremfälle, die so normalerweise nicht auftauchen.
Im Normalbetrieb ist dies jedoch kein zwingender _technischer_ Grund. Man mag jedoch argumentieren, daß die RBL-Betreiber einem evt. dankbar sind, wenn man nur die Hälfte der Abfragen generiert - wieder nur die technische Seite berücksichtigend.
Ich würde sogar schätzen das es durch dieses Vorgehen evtl. nur noch zwischen 10-25% sind die an externen Abfragen benötigt werden.
Aber auch nur technisch gesehen
Mit freundlichen Grüßen
Drießen
On Fri, May 09, 2008 at 10:45:52PM +0200, nighthawk wrote:
On Fri, May 9, 2008 at 1:48 PM, Robert Felber r.felber@ek-muc.de wrote:
Der Vorteil erst Greyisting, dann RBL liegt darin, dass es eine Weile dauert bis Clients in den RBLs dieser Welt auftauchen - es ist also immer gut, eine Weile zu warten - [...]
Das Argument halte ich für wenig schlüssig. Denn ob vor oder nach den RBLs, er landet definitiv im Greylisting und muß ein zweites Mal wiederkommen. Sollte er in der Zwischenzeit auf einer RBL landen, würde er in beiden Konstellationen abgelehnt.
So gesehen hast du recht, ja.
Thomas Schwenski wrote:
Sagt mir, ob ich mich täusche, aber ist das so nicht "Unsinn"?
Christian Bricart schrieb:
restriction_classes = greylist, rblcheck
greylist = check_recipient_access = hash:/path/whitelist check_access = hash:/path/whitelist check_policy_service inet:127.0.0.1:4711
Wenn hier jemand in die Whitelists passt und die Whitelists ein OK liefern, wird dann nicht JEDER andere Check übersprungen?
daher liefer diese Whitelisten auch maximal "DUNNO" und niemals "OK"... (es sei denn natürlich es ist wirklich OK ;-) - aber das ist eine andere Whitelist..)
Christian
Hallo Christian
Christian Bricart schrieb:
Thomas Schwenski wrote:
Sagt mir, ob ich mich täusche, aber ist das so nicht "Unsinn"?
Christian Bricart schrieb:
restriction_classes = greylist, rblcheck
greylist = check_recipient_access = hash:/path/whitelist check_access = hash:/path/whitelist check_policy_service inet:127.0.0.1:4711
Wenn hier jemand in die Whitelists passt und die Whitelists ein OK liefern, wird dann nicht JEDER andere Check übersprungen?
daher liefer diese Whitelisten auch maximal "DUNNO" und niemals "OK"... (es sei denn natürlich es ist wirklich OK ;-) - aber das ist eine andere Whitelist..)
Wenn die DUNNO liefern, dann macht er doch trotzdem Greylisting!?
Thomas
participants (8)
-
Christian Bricart -
Matthias Haegele -
nighthawk -
Ralf Hildebrandt -
Robert Felber -
Stefan Förster -
Thomas Schwenski -
Uwe Driessen