RBL spamhaus.org bei postfix einrichten
Hallo zusammen, ich habe u.a. folgende Restrictions eingestellt: smtpd_helo_restrictions = permit_mynetworks, reject_unauth_pipelining, reject_non_fqdn_hostname smtpd_recipient_restrictions = permit_mynetworks, permit_auth_destination, reject_invalid_hostname, reject_unknown_client_hostname, reject_rbl_client zen.spamhaus.org, reject Jetzt sehe ich in den Logs ständig folgendes: Helo command rejected: need fully-qualified hostname Warum aber zeigt Postfix nie an, wenn es aufgrund der anderen Restrictions mal eine Mail ablehnt? Insbesondere die RBL müßte doch häufig wirksam werden, oder? Aber auch reject_invalid_hostname sehe ich nie. Warum? -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
ich habe u.a. folgende Restrictions eingestellt:
smtpd_helo_restrictions = permit_mynetworks, reject_unauth_pipelining, reject_non_fqdn_hostname
smtpd_recipient_restrictions = permit_mynetworks, permit_auth_destination, reject_invalid_hostname, reject_unknown_client_hostname, reject_rbl_client zen.spamhaus.org, reject
Jetzt sehe ich in den Logs ständig folgendes:
Helo command rejected: need fully-qualified hostname
Warum aber zeigt Postfix nie an, wenn es aufgrund der anderen Restrictions mal eine Mail ablehnt? Insbesondere die RBL müßte doch häufig wirksam werden, oder? Aber auch reject_invalid_hostname sehe ich nie. Warum?
Such im Log nach "false-positives". Zeig Beispiele dafür. Alles andere ist spekulieren. -- Andreas -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andreas Winkelmann, Mittwoch, 17. September 2008 14:19:
Such im Log nach "false-positives". Zeig Beispiele dafür. Alles andere ist spekulieren.
Wie kann ich nach false-positives suchen? Ich weiß ja nicht, was zen.spamhaus.org geantwortet hat, bzw. ob es überhaupt gefragt wird. OK, ich kann einen dump auf das Interface machen... läuft grad... ...OK, ich sehe: spamhaus wird gefragt. Jetzt wüßte ich nur noch gerne, wann eine Mail abgelehnt wird aufgrund der Antwort von spamhaus. Kann man das irgendwie den Logfiles entnehmen, notiert postfix das? -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Moin moin, Andre Tann schrieb:
Andreas Winkelmann, Mittwoch, 17. September 2008 14:19:
Such im Log nach "false-positives". Zeig Beispiele dafür. Alles andere ist spekulieren.
Wie kann ich nach false-positives suchen? Ich weiß ja nicht, was zen.spamhaus.org geantwortet hat, bzw. ob es überhaupt gefragt wird. OK, ich kann einen dump auf das Interface machen... läuft grad...
...OK, ich sehe: spamhaus wird gefragt. Jetzt wüßte ich nur noch gerne, wann eine Mail abgelehnt wird aufgrund der Antwort von spamhaus. Kann man das irgendwie den Logfiles entnehmen, notiert postfix das?
Ja such mal im /ver/log/mail nach 'blocked using zen.spamhaus.org' mfg max
Markus Heinze, Mittwoch, 17. September 2008 15:37:
Ja such mal im /ver/log/mail nach 'blocked using zen.spamhaus.org'
# grep "zen.spamhaus.org" /var/log/mail # grep postfix /var/log/mail | wc -l 29007 Das kann doch gar nicht sein, daß bei der Menge an Log-Einträgen kein einziger wegen spamhaus abgelehnt wurde...? Da lohnt sich doch der DNS-Aufwand gar nicht. Übrigens hab ich das Logfile resettet, als ich heute morgen die spamhaus-Regel eingeführt habe, daher sind es "nur" 29k Zeilen. -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Moin moin, Andre Tann schrieb:
Markus Heinze, Mittwoch, 17. September 2008 15:37:
Ja such mal im /ver/log/mail nach 'blocked using zen.spamhaus.org'
# grep "zen.spamhaus.org" /var/log/mail # grep postfix /var/log/mail | wc -l 29007
Das kann doch gar nicht sein, daß bei der Menge an Log-Einträgen kein einziger wegen spamhaus abgelehnt wurde...? Da lohnt sich doch der DNS-Aufwand gar nicht.
Welcher Aufwand ?? Das erledigt doch jemand anderes für Dich. Damit so etwas halbwegs vernünftige Ergebnisse liefert solltest du mehrere RBL's verwenden, z.B. 'ix.dnsbl.manitu.net' und 'bl.spamcop.net' ... ggf. noch einen eigenen intern um die DNS-Queries zu minimieren, so mach ich dies jedenfalls.
Übrigens hab ich das Logfile resettet, als ich heute morgen die spamhaus-Regel eingeführt habe, daher sind es "nur" 29k Zeilen.
Mein log ist ca. 1GB pro Tag, bei minimalem Loglevel also sind 29k nicht erwähneswert, selbst wenn es heut morgen resettet wurde ;) lg max
Andre Tann wrote:
Hallo zusammen,
ich habe u.a. folgende Restrictions eingestellt:
smtpd_helo_restrictions = permit_mynetworks, reject_unauth_pipelining, reject_non_fqdn_hostname
smtpd_recipient_restrictions = permit_mynetworks, permit_auth_destination, reject_invalid_hostname, reject_unknown_client_hostname, reject_rbl_client zen.spamhaus.org, reject
Hast du im Ernst dort als letztes REJECT stehen bei smtpd_recipient_restrictions? Dann ist es nicht möglich, dir aus dem Internet eine Mail zu schicken.
Jetzt sehe ich in den Logs ständig folgendes:
Helo command rejected: need fully-qualified hostname
Warum aber zeigt Postfix nie an, wenn es aufgrund der anderen Restrictions mal eine Mail ablehnt? Insbesondere die RBL müßte doch häufig wirksam werden, oder? Aber auch reject_invalid_hostname sehe ich nie. Warum?
Weil der Check nicht getriggert wird. Die Checks werden der Reihe nach durchlaufen, bis ein Check entweder permit oder 4xx/5xx/reject triggert. Damit man aussagekräftige Angaben im Lob bei abgewiesenen Mails stehen hat, wird der Reject erst nach dem RCPT TO wirksam in der normalen Einstellung. default: smtpd_delay_reject = yes Reihenfolge: smtpd_client_restrictions smtpd_helo_restrictions smtpd_sender_restrictions smtpd_recipient_restrictions smtpd_data_restrictions smtpd_end_of_data_restrictions Bisher hast du also offenbar nur Spambots gehabt, die keinen FQDN verwenden. Von den Wellen hatte ich auch schon einige. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Sandy Drobic wrote:
Andre Tann wrote:
Hallo zusammen,
ich habe u.a. folgende Restrictions eingestellt:
smtpd_helo_restrictions = permit_mynetworks, reject_unauth_pipelining, reject_non_fqdn_hostname
smtpd_recipient_restrictions = permit_mynetworks, permit_auth_destination, reject_invalid_hostname, reject_unknown_client_hostname, reject_rbl_client zen.spamhaus.org, reject
Hast du im Ernst dort als letztes REJECT stehen bei smtpd_recipient_restrictions? Dann ist es nicht möglich, dir aus dem Internet eine Mail zu schicken.
Habe gerade gesehen, dass es etwas schräger ist: permit_auth_destination gibt ein "permit" zurück, wenn die Empfängerdomain bei deinem Server gelistet ist. Danach wird kein Check mehr ausgeführt. Dahinter kommen nur noch Checks, welche Mails ablehnen, gefolgt von einem totalen Reject. Die einzigen Mails, die nach permit_auth_destination noch abgewiesen werden, sind Relay-Versuche von Spammern. Häßlich daran ist, dass keine Prüfung auf ungültige Empfänger in deiner Domain so vorgenommen werden. Ohne einen Catch-All wirst du so zur Backscatter-Schleuder. Ich hoffe, der Server hängt so nicht direkt im Internet. Die übliche Reihenfolge ist: smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination reject_non_fqdn_hostname reject_invalid_hostname reject_unknown_client_hostname reject_rbl_client zen.spamhaus.org Auf den Eintrag in smtpd_helo_restrictions kannst du dann komplett verzichten. Es gibt noch einiges anderes, was man machen kann, aber das ist -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Sandy Drobic, Montag, 22. September 2008 21:51:
Habe gerade gesehen, dass es etwas schräger ist: permit_auth_destination gibt ein "permit" zurück, wenn die Empfängerdomain bei deinem Server gelistet ist. Danach wird kein Check mehr ausgeführt. Dahinter kommen nur noch Checks, welche Mails ablehnen, gefolgt von einem totalen Reject. Die einzigen Mails, die nach permit_auth_destination noch abgewiesen werden, sind Relay-Versuche von Spammern.
Ja, ich hab schon gemerkt, daß meine Reihenfolge nicht ganz optimal war.
Häßlich daran ist, dass keine Prüfung auf ungültige Empfänger in deiner Domain so vorgenommen werden. Ohne einen Catch-All wirst du so zur Backscatter-Schleuder. Ich hoffe, der Server hängt so nicht direkt im Internet.
Er hing schon so im Internet, aber nach ein paar Stunden hab ich's dann gemerkt und neu justiert.
Die übliche Reihenfolge ist:
smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination reject_non_fqdn_hostname reject_invalid_hostname reject_unknown_client_hostname reject_rbl_client zen.spamhaus.org
Ja, so hab ichs jetzt im Prinzip auch. Andere Reihenfolge, aber egal.
Auf den Eintrag in smtpd_helo_restrictions kannst du dann komplett verzichten. Es gibt noch einiges anderes, was man machen kann, aber das ist
...? Wenn ich mal ein bißchen Zeit übrig hab, dann möchte ich ohnehin mal ein offenes Relay bzw. einen Honeypot bauen und schauen, was Leute so auf einen Server einliefern, der nirgends als mx auftaucht. Und vielleicht experimentiere ich bei dieser Gelegenheit auch noch mit Teergruben. Und bei diesem Experiment sind zusätzliche Ideen natürlich willkommen! -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andre Tann wrote:
Sandy Drobic, Montag, 22. September 2008 21:51:
Habe gerade gesehen, dass es etwas schräger ist: permit_auth_destination gibt ein "permit" zurück, wenn die Empfängerdomain bei deinem Server gelistet ist. Danach wird kein Check mehr ausgeführt. Dahinter kommen nur noch Checks, welche Mails ablehnen, gefolgt von einem totalen Reject. Die einzigen Mails, die nach permit_auth_destination noch abgewiesen werden, sind Relay-Versuche von Spammern.
Ja, ich hab schon gemerkt, daß meine Reihenfolge nicht ganz optimal war.
Gerade die Reihenfolge ist extrem wichtig, sowohl für die Funktionalität als auch die Sicherheit.
Die übliche Reihenfolge ist:
smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination reject_non_fqdn_hostname reject_invalid_hostname reject_unknown_client_hostname reject_rbl_client zen.spamhaus.org
Ja, so hab ichs jetzt im Prinzip auch. Andere Reihenfolge, aber egal.
Grins! Gerade die Reihenfolge ist eben nicht egal. (^-^) Warum bei einer externen RBL nachfragen, wenn die Mail ohnehin schon von einem internen und sehr schnellem Check wie reject_non_fqdn_helo_hostname schon erschlagen wird. reject_unknown_client_hostname ist übrigens ein ziemlich rabiater Check, der meistens auch ein paar erwünschte Mails ablehnt.
Auf den Eintrag in smtpd_helo_restrictions kannst du dann komplett verzichten. Es gibt noch einiges anderes, was man machen kann, aber das ist
...?
Time Limit, es war Zeit zum Schlafen. (^-^)
Wenn ich mal ein bißchen Zeit übrig hab, dann möchte ich ohnehin mal ein offenes Relay bzw. einen Honeypot bauen und schauen, was Leute so auf einen Server einliefern, der nirgends als mx auftaucht. Und vielleicht experimentiere ich bei dieser Gelegenheit auch noch mit Teergruben. Und bei diesem Experiment sind zusätzliche Ideen natürlich willkommen!
Was ist der Sinn solcher Tätigkeit. Normalerweise setzt man einen Honeypot und ähnliches auf, um die Einbruchsmethoden der Hacker zu studieren und möglichst vielleicht noch unbekannte Schädlinge für Analysezwecke zu erwischen. Ich glaube nicht, dass du in dieser Branche tätig bist. Teergruben basteln ist eine Methode, die aus der zeit stammt, wo Spammer noch häufig eigene Server hatten. Heutzutage mieten die ein Botnetz mit 10.000 Zombies und pusten ihre Spams millionenfach durch die Gegend. Ob du da einen oder zwei Zombies mit ein oder zwei Prozessen beschäftigst, merken die nicht einmal, nicht einmal der eine Zombie, der einen Prozess bei dir hängen hat. Das tut dir erheblich mehr weh als dem Spammer, da du weniger Ressourcen hast als der Spammer. Setze deine Energie lieber für etwas produktives ein. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Sandy Drobic, Dienstag, 23. September 2008 10:03:
Ja, so hab ichs jetzt im Prinzip auch. Andere Reihenfolge, aber egal.
Grins! Gerade die Reihenfolge ist eben nicht egal. (^-^)
Jaja, weiß ich doch jetzt ... ;)
Warum bei einer externen RBL nachfragen, wenn die Mail ohnehin schon von einem internen und sehr schnellem Check wie reject_non_fqdn_helo_hostname schon erschlagen wird.
Logo. Seit mein Postfix von draußen erreichbar ist, langweilt sich mein named plötzlich nicht mehr. Also hier meine Reihenfolge: smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination reject_non_fqdn_hostname reject_invalid_hostname reject_non_fqdn_recipient reject_invalid_hostname reject_unknown_client reject_rbl_client dnsbl.sorbs.net reject_rbl_client zen.spamhaus.org reject_rbl_client bl.spamcop.net permit Ist das genehm so?
reject_unknown_client_hostname ist übrigens ein ziemlich rabiater Check, der meistens auch ein paar erwünschte Mails ablehnt.
Och, bis jetzt hat sich noch niemand beschwert. Wieso überhaupt rabiat? Entweder es setzt einer sein System ordentlich auf, dann gibts kein Problem. Oder aber er muß halt nachbessern, wie ich...
Ich glaube nicht, dass du in dieser Branche tätig bist.
Hm. Ich dachte bisher eigentlich schon. Wie kommst Du zu diesem Schluß? Nur weil ich mich nicht genauso gut auskenne mit Postfix wie Du? -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andre Tann wrote:
Logo. Seit mein Postfix von draußen erreichbar ist, langweilt sich mein named plötzlich nicht mehr.
Ich nehme an, du hast Amavisd-new mit eingebunden? Der fragt natürlich eine Menge RBLs ab für jede Mail.
Also hier meine Reihenfolge:
smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination reject_non_fqdn_hostname reject_invalid_hostname reject_non_fqdn_recipient reject_invalid_hostname
doppelt
reject_unknown_client reject_rbl_client dnsbl.sorbs.net reject_rbl_client zen.spamhaus.org reject_rbl_client bl.spamcop.net permit
Ist das genehm so?
Ja, kein Problem. das letzte "permit" ist im Grunde überflüssig, weil Default, schadet aber auch nicht und macht die Aktion sichtbar. Wenn du später Erweiterungen wie einen Policy-Daemon einsetzen willst, sollte vor dem Aufruf der Policy-Daemons ein reject_unlisted_recipient stehen. Im Prinzip sollte direkt nach reject_unauth_destination auch ein reject_unlisted_recipient kommen. Sinn des ganzen ist es, die Annahme von ungültigen Empfängern und damit das Annehmen von nicht zustellbaren Mails zu verhindern. Früher oder später wirst du nicht verhindern können, eine Whitelist zu führen, um ein paar kaputte Clients zu erlauben. Wenn dann nicht vor der Whitelist schon die Prüfung auf ungültige Empfänger stattfindet, dann kann dieser client Backscatter verursachen.
reject_unknown_client_hostname ist übrigens ein ziemlich rabiater Check, der meistens auch ein paar erwünschte Mails ablehnt.
Och, bis jetzt hat sich noch niemand beschwert. Wieso überhaupt rabiat? Entweder es setzt einer sein System ordentlich auf, dann gibts kein Problem. Oder aber er muß halt nachbessern, wie ich...
Es gibt häufig Fälle, wo dies nicht möglich ist. Dies habe ich insbesondere von chinesischen und spanischen Mailadmins in Klagen gehört. In Deutschland ist dies normalerweise kein Problem, das stimmt. Es gibt auch viele Fälle von Fehlkonfiguration, wo es gerade in Firmenhierarchien nicht so einfach ist, etwas zu ändern. Gerade große Konzerne sind in dieser Hinsicht sehr träge nach dem Motto "wir haben kein Problem, das Problem muss auf deiner Seite sein". Die sitzen das einfach aus.
Ich glaube nicht, dass du in dieser Branche tätig bist.
Hm. Ich dachte bisher eigentlich schon. Wie kommst Du zu diesem Schluß? Nur weil ich mich nicht genauso gut auskenne mit Postfix wie Du?
Vorsicht, das war etwas zu rabiat gekürzt. Damit meine ich nicht die Sysadmin/SMTP-Branche, sondern die Sicherheits-Branche. In dieser Schiene rechne ich die Experten für Firewall-Sicherheit, Programmierer von Antiviren-Software und sonstige Security-Experten. Ich betrachte mich auch nicht als zugehörig. (^-^) Auch ich habe schlicht nicht die Zeit, mich in dieses Gebiet einzuarbeiten. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Sandy Drobic, Dienstag, 23. September 2008 11:03:
Ich nehme an, du hast Amavisd-new mit eingebunden? Der fragt natürlich eine Menge RBLs ab für jede Mail.
Ja, den hab ich eingebunden. Das war aber auch schon vorher der Fall, als postfix noch paradiesisch hinter einer Firewall saß.
Ja, kein Problem. das letzte "permit" ist im Grunde überflüssig, weil Default, schadet aber auch nicht und macht die Aktion sichtbar.
Ja, ich finds ganz schön so, weil man die Logik explizit sehen kann, wenn man die main.cf studiert, und nicht die Default-Werte wissen muß.
Wenn du später Erweiterungen wie einen Policy-Daemon einsetzen willst, sollte vor dem Aufruf der Policy-Daemons ein reject_unlisted_recipient stehen. Im Prinzip sollte direkt nach reject_unauth_destination auch ein reject_unlisted_recipient kommen.
Mit einem policyd hab ich mich noch nicht beschäftigt, daher weiß ich auch nicht, ob er genügend Vorteile bringt, daß sich das Aufsetzen lohnt. Im Moment läuft der Server ganz gut, ich beobachte das mal.
Sinn des ganzen ist es, die Annahme von ungültigen Empfängern und damit das Annehmen von nicht zustellbaren Mails zu verhindern. Früher oder später wirst du nicht verhindern können, eine Whitelist zu führen, um ein paar kaputte Clients zu erlauben. Wenn dann nicht vor der Whitelist schon die Prüfung auf ungültige Empfänger stattfindet, dann kann dieser client Backscatter verursachen.
Ich verstehe, und werde das im Auge behalten.
Vorsicht, das war etwas zu rabiat gekürzt. Damit meine ich nicht die Sysadmin/SMTP-Branche, sondern die Sicherheits-Branche. In dieser Schiene rechne ich die Experten für Firewall-Sicherheit, Programmierer von Antiviren-Software und sonstige Security-Experten. Ich betrachte mich auch nicht als zugehörig. (^-^)
Nein, zur Security-Branche gehöre ich gewiß nicht. Ich wollte meine Honigtöpfe und Teergruben auch nicht bauen, um in vorderster Front zu forschen, sondern einfach um mit smtp zu hantieren und mehr zu verstehen. Viele Grüße! -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andre Tann wrote:
Sandy Drobic, Dienstag, 23. September 2008 11:03:
Wenn du später Erweiterungen wie einen Policy-Daemon einsetzen willst, sollte vor dem Aufruf der Policy-Daemons ein reject_unlisted_recipient stehen. Im Prinzip sollte direkt nach reject_unauth_destination auch ein reject_unlisted_recipient kommen.
Mit einem policyd hab ich mich noch nicht beschäftigt, daher weiß ich auch nicht, ob er genügend Vorteile bringt, daß sich das Aufsetzen lohnt. Im Moment läuft der Server ganz gut, ich beobachte das mal.
Das kommt im Wesentlichen auch auf dein Spamaufkommen an. Allein mit guten Postfix-Einstellungen sollte man etwa 90% des Spams bereits abweisen können, ohne viele False Positives. reject_unknown_client_hostname etwa kann ich nicht einsetzen, da dieser zuviele gewünschte Mails ablehnen würde in meinem Fall (viele internationale Mails aus vielen verschiedenen Ländern), gleiches gilt für reject_unknown_helo_hostname. Wenn du jetzt die Rate noch höher schrauben willst, dann brauchst du Daemons für Greylisting und ähnliches.
Vorsicht, das war etwas zu rabiat gekürzt. Damit meine ich nicht die Sysadmin/SMTP-Branche, sondern die Sicherheits-Branche. In dieser Schiene rechne ich die Experten für Firewall-Sicherheit, Programmierer von Antiviren-Software und sonstige Security-Experten. Ich betrachte mich auch nicht als zugehörig. (^-^)
Nein, zur Security-Branche gehöre ich gewiß nicht. Ich wollte meine Honigtöpfe und Teergruben auch nicht bauen, um in vorderster Front zu forschen, sondern einfach um mit smtp zu hantieren und mehr zu verstehen.
Um SMTP besser zu verstehen, würde ich eher mit SMTP arbeiten und versuchen, es zu optimieren. Was mir viel geholfen hat in diesem Bereich waren die beiden RFCs 2821 und 2822. Wenn du dir diese beiden RFCs durchgelesen hast, und zwar mehrfach, dann hast du tatsächlich eine bessere Vorstellung davon, was SMTP eigentlich leisten soll und wie die Mechanismen dafür aussehen. Dazu dann ein Buch über Postfix/Imap und das Lesen in der Postfix-Mailingliste. Peer Heinlein betreibt eine deutsche Mailingliste für Postfix, in der aber auch Fragen zu Imapservern und Amavisd-new nicht fehl am Platze sind. Bist du da nicht auch schon drin?!? Die englische Liste ist einiges rigider, Eigenleistung ist gefragt und die Beachtung des DEBUG_README. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Sorry für PM... Sandy Drobic, Dienstag, 23. September 2008 19:11:
Das kommt im Wesentlichen auch auf dein Spamaufkommen an. Allein mit guten Postfix-Einstellungen sollte man etwa 90% des Spams bereits abweisen können, ohne viele False Positives. reject_unknown_client_hostname etwa kann ich nicht einsetzen, da dieser zuviele gewünschte Mails ablehnen würde in meinem Fall (viele internationale Mails aus vielen verschiedenen Ländern), gleiches gilt für reject_unknown_helo_hostname.
Ich verstehe zwar nicht, warum es in anderen Ländern schwieriger ist, die DNS-Einträge vernünftig hinzubekommen. Aber vielleicht ist es das ja auch gar nicht, und es siegt einfach die Macht des Faktischen.
Wenn du jetzt die Rate noch höher schrauben willst, dann brauchst du Daemons für Greylisting und ähnliches.
Zu Greylisting hab ich mir jetzt einiges durchgelesen. Aber die Wirksamkeit scheint in letzter Zeit merklich nachgelassen zu haben, wogegen die Nachteile schon spürbar sein können, gerade wenn die Mails von großen Providern mit vielen Maschinen kommen. Das wäre dann auch nicht schön.
Um SMTP besser zu verstehen, würde ich eher mit SMTP arbeiten und versuchen, es zu optimieren. Was mir viel geholfen hat in diesem Bereich waren die beiden RFCs 2821 und 2822. Wenn du dir diese beiden RFCs durchgelesen hast, und zwar mehrfach, dann hast du tatsächlich eine bessere Vorstellung davon, was SMTP eigentlich leisten soll und wie die Mechanismen dafür aussehen.
Das ist ein guter Tip.
Dazu dann ein Buch über Postfix/Imap und das Lesen in der Postfix-Mailingliste. Peer Heinlein betreibt eine deutsche Mailingliste für Postfix, in der aber auch Fragen zu Imapservern und Amavisd-new nicht fehl am Platze sind. Bist du da nicht auch schon drin?!?
Bin drin. Hab auch das Postfixbuch, allerdings in einer nicht ganz aktuellen Auflage. Vielleicht sollte ich hier nochmal nachlegen, denn es bleiben einige Fragen ungeklärt, und manches ist auch ungenau beschrieben, zB wieso NFS zur Anbindung eines Backends ungeeignet sein soll. Nicht daß ich vorhätte, solche Größenordnungen zu realisieren. Aber ich hatte mich kürzlich mit Jungs von EMC unterhalten, und die meinten, sie würden öfter ganze Schränke (auch) über NFS anbinden, das sei kein Problem. Und bei einem Schrank im Vollausbau brennt es ja mal richtig. Wieso also Heinlein NFS als ungeeignet betrachtet für die Anbindung des Backends, und vor allem, wieso er es als unzuverlässig einstuft, konnten sie sich auch nicht recht erklären.
gefragt und die Beachtung des DEBUG_README.
Danach muß ich auch mal suchen, das könnte hilfreich sein. -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andre Tann wrote:
Sorry für PM...
Sandy Drobic, Dienstag, 23. September 2008 19:11:
Das kommt im Wesentlichen auch auf dein Spamaufkommen an. Allein mit guten Postfix-Einstellungen sollte man etwa 90% des Spams bereits abweisen können, ohne viele False Positives. reject_unknown_client_hostname etwa kann ich nicht einsetzen, da dieser zuviele gewünschte Mails ablehnen würde in meinem Fall (viele internationale Mails aus vielen verschiedenen Ländern), gleiches gilt für reject_unknown_helo_hostname.
Ich verstehe zwar nicht, warum es in anderen Ländern schwieriger ist, die DNS-Einträge vernünftig hinzubekommen. Aber vielleicht ist es das ja auch gar nicht, und es siegt einfach die Macht des Faktischen.
Teilweise hast du einfach nicht die Wahl zwischen Providern, weil es nur einen gibt und der sich nicht drum schert, ob du einen Reverse-DNS-Eintrag haben möchtest oder nicht. Hier in Deutschland hat man eher die Qual der Wahl.
Wenn du jetzt die Rate noch höher schrauben willst, dann brauchst du Daemons für Greylisting und ähnliches.
Zu Greylisting hab ich mir jetzt einiges durchgelesen. Aber die Wirksamkeit scheint in letzter Zeit merklich nachgelassen zu haben, wogegen die Nachteile schon spürbar sein können, gerade wenn die Mails von großen Providern mit vielen Maschinen kommen. Das wäre dann auch nicht schön.
Wenn du Greylisting selektiv anwendest, sind normale Server nicht davon betroffen. Ich verwende Greylisting z.B. für Clients mit vielen Zahlen im Hostnahmen, oder Clients, die bestimmte Strings im Hostnamen haben, die auf dynamische Adressen hindeuten.
Dazu dann ein Buch über Postfix/Imap und das Lesen in der Postfix-Mailingliste. Peer Heinlein betreibt eine deutsche Mailingliste für Postfix, in der aber auch Fragen zu Imapservern und Amavisd-new nicht fehl am Platze sind. Bist du da nicht auch schon drin?!?
Bin drin. Hab auch das Postfixbuch, allerdings in einer nicht ganz aktuellen Auflage. Vielleicht sollte ich hier nochmal nachlegen, denn es bleiben einige Fragen ungeklärt, und manches ist auch ungenau beschrieben, zB wieso NFS zur Anbindung eines Backends ungeeignet sein soll. Nicht daß ich vorhätte, solche Größenordnungen zu realisieren. Aber ich hatte mich kürzlich mit Jungs von EMC unterhalten, und die meinten, sie würden öfter ganze Schränke (auch) über NFS anbinden, das sei kein Problem. Und bei einem Schrank im Vollausbau brennt es ja mal richtig. Wieso also Heinlein NFS als ungeeignet betrachtet für die Anbindung des Backends, und vor allem, wieso er es als unzuverlässig einstuft, konnten sie sich auch nicht recht erklären.
Es geht nicht um die Leistung, sondern um das Locking. Mehrere Anwendungen müssen sich darüber einig sein, welche Verfahren für's Locking verwendet werden: - Postfix - der Imapserver - Virenscanner etc. Hier stehen einige Details dazu: http://www.postfix.org/NFS_README.html Probleme können insbesondere auftreten, wenn man Mails im MBOX-Format ablegt, bei Maildir hat sich vieles entkrampft. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (4)
-
Andre Tann -
Andreas Winkelmann -
Markus Heinze -
Sandy Drobic