Fw: Absenderadresse überprüfen auf gültigkeit im Postfix
Sandy Drobic wrote:
Thomas Fankhauser wrote:
Hallo Allerseits,
Ich glaube mal gelesen zu haben, dass es mit Postfix möglich sein soll die Absender email Adresse zu überprüfen, befor die Mail angenommen wird.
Nun wollte ich dies im neuen Server einrichten, finde aber den Artikel nichtmehr.
Es gibt die möglichkeim mit VRFY, im gleichen zusammenhang las ich aber auch, dass diese Methode selten funktioniert.
Mache dich besser darauf gefasst, dass du eine Menge Probleme mit schlecht konfigurierten Systemen bekommen wirst. :-( Ich hatte reject_unverified_sender kurze Zeit im Einsatz, habe es dann nur noch selektiv verwendet auf seltsame Hostnamen (die mit den vielen Zahlen drin oder unknown oder mit dynamic|ppp|dialup etc.), hatte aber immer noch einige Fehlabweisungen und bin dann dazu übergegangen, Greylisting for dem reject_unverified_sender zu verwenden. (Cami's policyd hatte ich umkonfiguriert von defer_if_permit auf 450 Tempreject).
Vielen Dank Sandy, Um der Spamflut zu entkommen, bin ich an der Installation eines Mailservers der die eingehenden Mails möglichst mit hohen Treffern zurückweisen kann. Die jetzige Konfiguration läuft mit Sendmail und Spamassasin. Das Problem ist aber, dass SA auch echte Mails aussortiert. Diese Mails sind verloren weil der Absender nicht darüber informiert werden kann. Meine Überlegung war nun, dass ein zwischengeschalteter Mailserver (hab jetzt Postfix genommen, weil er hier immer so gerühmt wird). Dieser Postfix weiss aber nicht welche emailadressen auf dem Zielsystem gültig sind. Wenn er diese nun annimmt aber der Zielserver diese infolge 'user unknown' ablehnt, habe ich ein Problem. Darum erschien mir die überprüfung der emailadresse des Absenders als sehr gut. Mitlerweile muss ich gestehen ist dieser Lösungsansatz nicht gut. Selbstverständlich möchte ich nicht nur die reject_unverified_sender sondern so viele Regeln wie möglich einbauen. Da ich mich mit Postfix noch nicht so auskenne (habs heute installiert) bin ich für alle Hinweise dankbar. Bis jetzt funktioniert die Mailannahme wie gewünscht, nur halt noch ohne grosse Abwehr. Ich bin nur verwirrt warum postfix/qmgr sich fast eine Minute Zeit nimmt um die Mail dann auszuliefern. Eine möglichkeit besteht darin, die virtuser Datei des Zielsystems zu kopieren. Würdest du das so machen. Könnte Postfix so umgestellt werden, dass er die Verbindung zum Zielserver aufnimmt noch während die Verbinung vom Absender besteht? Somit sollte es doch möglich sein ein 'user unknown' weiterzureichen? Was meint ihr? Wie machen das andere?
Danach hat es praktisch keine Absender-Überprüfungen mehr gegeben. Also habe ich im Interesse einer stabilen und einfachen Konfiguration das Überprüfen der Absenderadresse herausgenommen.
Meine Empfehlung somit: verwende Greylisting, das führt zu erheblich weniger Problemen als Absender-Überprüfung.
Möchte ich auch machen, auch SPF1 -- Thomas
Ein Check, den du mal testen kannst, ist reject_unknown_sender_domain. Das weist eine Mail ab, wenn die Absender-Domain nicht existiert, eine Mail also nicht beantwortet werden kann. http://www.postfix.org/postconf.5.html#reject_unknown_sender_domain
Es gibt auch andere Checks, die einiges an Müll herausfischen.
-- 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
Thomas Fankhauser wrote:
Mache dich besser darauf gefasst, dass du eine Menge Probleme mit schlecht konfigurierten Systemen bekommen wirst. :-( Ich hatte reject_unverified_sender kurze Zeit im Einsatz, habe es dann nur noch selektiv verwendet auf seltsame Hostnamen (die mit den vielen Zahlen drin oder unknown oder mit dynamic|ppp|dialup etc.), hatte aber immer noch einige Fehlabweisungen und bin dann dazu übergegangen, Greylisting for dem reject_unverified_sender zu verwenden. (Cami's policyd hatte ich umkonfiguriert von defer_if_permit auf 450 Tempreject).
Vielen Dank Sandy, Um der Spamflut zu entkommen, bin ich an der Installation eines Mailservers der die eingehenden Mails möglichst mit hohen Treffern zurückweisen kann.
Greylisting ist im Augenblick ein hervorragendes Mittel gegen Spam, aber es sollte von anderen Methoden wie Blacklist etc. ergänzt werden.
Die jetzige Konfiguration läuft mit Sendmail und Spamassasin. Das Problem ist aber, dass SA auch echte Mails aussortiert. Diese Mails sind verloren weil der Absender nicht darüber informiert werden kann.
Dein Spamassassin macht dann Mist. Ich habe bei mir folgende Policy-Struktur: 1. alle erwünschten mails annehmen 2. soviel Spam wie möglich ablehnen mit Regeln, die Punkt 1. erlauben. 3. soviel wie möglich von dem als Spam erkennen, was noch durchkommt 4. erkannte Spams werden getaggt, aber nicht gelöscht.
Meine Ãberlegung war nun, dass ein zwischengeschalteter Mailserver (hab jetzt Postfix genommen, weil er hier immer so gerühmt wird). Dieser Postfix weiss aber nicht welche emailadressen auf dem Zielsystem gültig sind. Wenn er diese nun annimmt aber der Zielserver diese infolge 'user unknown' ablehnt, habe ich ein Problem.
Sehr gut gesehen. Backscatter sieht niemand gerne und viele Server sind deswegen schon auf den Blacklists gelandet.
Darum erschien mir die überprüfung der emailadresse des Absenders als sehr gut. Mitlerweile muss ich gestehen ist dieser Lösungsansatz nicht gut.
Wenn das ein Relay-Server ist, dann sollte er eine Empfängervalidierung vornehmen. Die beste Methode dafür ist, die Empfänger in Listen mit gültigen Empfängern nachzuschlagen. relay_domains = relay.example.com relay_recipient_maps = hash:/etc/postfix/relay_recipients /etc/postfix/relay_recipients: validuser@relay.example.com valid_user Die zweite, nicht so schöne Methode, ist die Empfängerverifizierung über reject_unverified_recipient. In dem Fall baut Postfix eine Verbindung zum Backend-Server auf und sondiert, ob dieser die Empfängeradresse annimmt. Wenn ja, dann nimmt Postfix die Mail an. Der Pferdefuß ist, dass der Backend-Server auch die Fähigkeit haben muss, im smtp Dialog gültige Empfänger von ungültigen zu unterscheiden. Außerdem muss er natürlich erreichbar sein, sonst funktioniert es nicht. Beides kann etwas gemildert werden, wenn man die Ergebnisse cached.
Selbstverständlich möchte ich nicht nur die reject_unverified_sender sondern so viele Regeln wie möglich einbauen. Da ich mich mit Postfix noch nicht so auskenne (habs heute installiert) bin ich für alle Hinweise dankbar.
Ich bin dagegen, soviele Regeln wie möglich einzubauen. (^-^) Verwende am besten erst einmal solide Regeln, die du verstehst, und baue dann die Konfiguration langsam aus.
Bis jetzt funktioniert die Mailannahme wie gewünscht, nur halt noch ohne grosse Abwehr. Ich bin nur verwirrt warum postfix/qmgr sich fast eine Minute Zeit nimmt um die Mail dann auszuliefern.
Sind alte Blacklists konfiguriert,die einen Timeout liefern, weil sie nicht mehr laufen?
Eine möglichkeit besteht darin, die virtuser Datei des Zielsystems zu kopieren. Würdest du das so machen. Könnte Postfix so umgestellt werden, dass er die Verbindung zum Zielserver aufnimmt noch während die Verbinung vom Absender besteht? Somit sollte es doch möglich sein ein 'user unknown' weiterzureichen?
Ja, siehe oben.
Was meint ihr? Wie machen das andere?
Eine Mischung aus Greylisting, RBLs, Client-Checks, HELO-Checks. Zeige doch mal die Ausgabe von "postconf -n", das zeigt die von den Default-Werten abweichend gesetzten Optionen.
Möchte ich auch machen, auch SPF1
SPF wird im Augenblick noch von so wenigen Servern überprüft, dass du dir den Einsatz im Augenblick sparen kannst. Das kommt erst ganz langsam in Fahrt, ebenso DK und DKIM. -- 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
Hallo, Am Mon, 12 Feb 2007, Sandy Drobic schrieb:
Thomas Fankhauser wrote: [..]
Möchte ich auch machen, auch SPF1
SPF wird im Augenblick noch von so wenigen Servern überprüft, dass du dir den Einsatz im Augenblick sparen kannst. Das kommt erst ganz langsam in Fahrt, ebenso DK und DKIM.
Ich hab gelesen, dass SPF im Moment fast nur Spammern verwendet wird... Go figure. -dnh -- RFC 882 put the dot in .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:
Thomas Fankhauser wrote:
Mache dich besser darauf gefasst, dass du eine Menge Probleme mit schlecht konfigurierten Systemen bekommen wirst. :-( Ich hatte reject_unverified_sender kurze Zeit im Einsatz, habe es dann nur noch selektiv verwendet auf seltsame Hostnamen (die mit den vielen Zahlen drin oder unknown oder mit dynamic|ppp|dialup etc.), hatte aber immer noch einige Fehlabweisungen und bin dann dazu übergegangen, Greylisting for dem reject_unverified_sender zu verwenden. (Cami's policyd hatte ich umkonfiguriert von defer_if_permit auf 450 Tempreject).
Vielen Dank Sandy, Um der Spamflut zu entkommen, bin ich an der Installation eines Mailservers der die eingehenden Mails möglichst mit hohen Treffern zurückweisen kann.
Greylisting ist im Augenblick ein hervorragendes Mittel gegen Spam, aber es sollte von anderen Methoden wie Blacklist etc. ergänzt werden.
Die jetzige Konfiguration läuft mit Sendmail und Spamassasin. Das Problem ist aber, dass SA auch echte Mails aussortiert. Diese Mails sind verloren weil der Absender nicht darüber informiert werden kann.
Dein Spamassassin macht dann Mist. Ich habe bei mir folgende Policy-Struktur:
1. alle erwünschten mails annehmen 2. soviel Spam wie möglich ablehnen mit Regeln, die Punkt 1. erlauben. 3. soviel wie möglich von dem als Spam erkennen, was noch durchkommt 4. erkannte Spams werden getaggt, aber nicht gelöscht.
Meine Ãberlegung war nun, dass ein zwischengeschalteter Mailserver (hab jetzt Postfix genommen, weil er hier immer so gerühmt wird). Dieser Postfix weiss aber nicht welche emailadressen auf dem Zielsystem gültig sind. Wenn er diese nun annimmt aber der Zielserver diese infolge 'user unknown' ablehnt, habe ich ein Problem.
Sehr gut gesehen. Backscatter sieht niemand gerne und viele Server sind deswegen schon auf den Blacklists gelandet.
Darum erschien mir die überprüfung der emailadresse des Absenders als sehr gut. Mitlerweile muss ich gestehen ist dieser Lösungsansatz nicht gut.
Wenn das ein Relay-Server ist, dann sollte er eine Empfängervalidierung vornehmen. Die beste Methode dafür ist, die Empfänger in Listen mit gültigen Empfängern nachzuschlagen. relay_domains = relay.example.com relay_recipient_maps = hash:/etc/postfix/relay_recipients
/etc/postfix/relay_recipients: validuser@relay.example.com valid_user
Die zweite, nicht so schöne Methode, ist die Empfängerverifizierung über reject_unverified_recipient. In dem Fall baut Postfix eine Verbindung zum Backend-Server auf und sondiert, ob dieser die Empfängeradresse annimmt. Wenn ja, dann nimmt Postfix die Mail an.
Der Pferdefuß ist, dass der Backend-Server auch die Fähigkeit haben muss, im smtp Dialog gültige Empfänger von ungültigen zu unterscheiden. Außerdem muss er natürlich erreichbar sein, sonst funktioniert es nicht.
Sendmail kann das.
Beides kann etwas gemildert werden, wenn man die Ergebnisse cached.
Selbstverständlich möchte ich nicht nur die reject_unverified_sender sondern so viele Regeln wie möglich einbauen. Da ich mich mit Postfix noch nicht so auskenne (habs heute installiert) bin ich für alle Hinweise dankbar.
Ich bin dagegen, soviele Regeln wie möglich einzubauen. (^-^) Verwende am besten erst einmal solide Regeln, die du verstehst, und baue dann die Konfiguration langsam aus.
Ich hab den Server gestern beobachtet, danach noch die Konfig
verändert. Heute bin ich erstaunt dass noch viel zu viele Mails
durchkommen. Scheinbar verstehe ich das Regelwerk noch nicht.
Die Mail mit diesem Header:
Received: from miaow.com (unknown [222.88.215.140])
by melinda.slogi.ch (Postfix) with SMTP id 3BC961743F5;
Wed, 14 Feb 2007 12:31:41 +0100 (CET)
Message-ID: <53d501c7506e$7dc3d840$1486f16a@annikakneffelufoq>
From: "Staci"
Bis jetzt funktioniert die Mailannahme wie gewünscht, nur halt noch ohne grosse Abwehr. Ich bin nur verwirrt warum postfix/qmgr sich fast eine Minute Zeit nimmt um die Mail dann auszuliefern.
Sind alte Blacklists konfiguriert,die einen Timeout liefern, weil sie nicht mehr laufen?
Eine möglichkeit besteht darin, die virtuser Datei des Zielsystems zu kopieren. Würdest du das so machen. Könnte Postfix so umgestellt werden, dass er die Verbindung zum Zielserver aufnimmt noch während die Verbinung vom Absender besteht? Somit sollte es doch möglich sein ein 'user unknown' weiterzureichen?
Ja, siehe oben.
Was meint ihr? Wie machen das andere?
Eine Mischung aus Greylisting, RBLs, Client-Checks, HELO-Checks.
Zeige doch mal die Ausgabe von "postconf -n", das zeigt die von den Default-Werten abweichend gesetzten Optionen.
Möchte ich auch machen, auch SPF1
SPF wird im Augenblick noch von so wenigen Servern überprüft, dass du dir den Einsatz im Augenblick sparen kannst. Das kommt erst ganz langsam in Fahrt, ebenso DK und DKIM.
-- 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
Am Mittwoch, 14. Februar 2007 13:15 schrieb Thomas Fankhauser:
Sandy Drobic wrote:
Der Pferdefuß ist, dass der Backend-Server auch die Fähigkeit haben muss, im smtp Dialog gültige Empfänger von ungültigen zu unterscheiden. Außerdem muss er natürlich erreichbar sein, sonst funktioniert es nicht.
Sendmail kann das.
Hallo! Sendmail ist imho ohnehin um Welten mächtiger und flexibler als Postfix. Für mich als langjährigen sendmail-Nutzer ist Postfix ein einziger Krampf. Da wo es interessant wird, ist die Konfiguration total umständlich im Gegensatz zu sendmail, wenn man dort das Prinzip einmal verstanden hat. Darum meine Frage: Warum nimmst Du nicht wieder sendmail? -- 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
Burkhard Schichtel wrote:
Am Mittwoch, 14. Februar 2007 13:15 schrieb Thomas Fankhauser:
Sandy Drobic wrote:
Der Pferdefuß ist, dass der Backend-Server auch die Fähigkeit haben muss, im smtp Dialog gültige Empfänger von ungültigen zu unterscheiden. Außerdem muss er natürlich erreichbar sein, sonst funktioniert es nicht. Sendmail kann das.
Hallo!
Sendmail ist imho ohnehin um Welten mächtiger und flexibler als Postfix. Für mich als langjährigen sendmail-Nutzer ist Postfix ein einziger Krampf. Da wo es interessant wird, ist die Konfiguration total umständlich im Gegensatz zu sendmail, wenn man dort das Prinzip einmal verstanden hat.
Grins! Das geht wohl jedem so, der sich einmal mühselig in ein Program eingearbeitet hat. Ich kriege Krämpfe, wenn ich nur versuche, herauszukriegen, wie etwas in Sendmail funktioniert. Bei Postfix habe ich diese Probleme nicht. Ich erkenne Sendmail-User, die Postfix konfigurieren, am schnellsten an der /etc/postfix/access, die für helo/recipient/sender/client checks überall gleichzeitig missbraucht wird. Halt wie gewohnt von Sendmail. (^-^) -- 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
Thomas Fankhauser wrote:
Die zweite, nicht so schöne Methode, ist die Empfängerverifizierung über reject_unverified_recipient. In dem Fall baut Postfix eine Verbindung zum Backend-Server auf und sondiert, ob dieser die Empfängeradresse annimmt. Wenn ja, dann nimmt Postfix die Mail an.
Der Pferdefuà ist, dass der Backend-Server auch die Fähigkeit haben muss, im smtp Dialog gültige Empfänger von ungültigen zu unterscheiden. AuÃerdem muss er natürlich erreichbar sein, sonst funktioniert es nicht.
Sendmail kann das.
Gut, dann kannst du reject_unverified_recipient verwenden.
Beides kann etwas gemildert werden, wenn man die Ergebnisse cached.
Selbstverständlich möchte ich nicht nur die reject_unverified_sender sondern so viele Regeln wie möglich einbauen. Da ich mich mit Postfix noch nicht so auskenne (habs heute installiert) bin ich für alle Hinweise dankbar.
Ich bin dagegen, soviele Regeln wie möglich einzubauen. (^-^) Verwende am besten erst einmal solide Regeln, die du verstehst, und baue dann die Konfiguration langsam aus.
Ich hab den Server gestern beobachtet, danach noch die Konfig verändert. Heute bin ich erstaunt dass noch viel zu viele Mails durchkommen. Scheinbar verstehe ich das Regelwerk noch nicht.
Die Mail mit diesem Header: Received: from miaow.com (unknown [222.88.215.140])
client_name: unknown helo: miaow.com ip: 222.88.215.140
sollte doch mit dieser Konfig im helo check abgewiesen werden.
relay_domains = digelec.com, daniels.ch smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_hostname, reject_invalid_hostname, permit smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, reject_unauth_destination, reject_unverified_recipient, reject_rbl_client zombie.dnsbl.sorbs.net, reject_rbl_client opm.blitzed.org, reject_rbl_client list.dsbl.org, reject_rbl_client sbl.spamhaus.org, reject_rbl_client blackholes.easynet.nl, reject_rbl_client unconfirmed.dsbl.org, reject_rbl_client dynablock.njabl.org, reject_rbl_client dialup.blacklist.jippg.org, reject_rbl_client cbl.abuseat.org,
Nein, "miaow.com" ist weder von reject_non_fqdn_helo_hostname noch von reject_invalid_helo_hostname erfasst. Meintest du vielleicht reject_unknown_client_hostname? Ich würde mit diesem Check leider einiges an erwünschter Mail ablehnen. Deine Konfig kann zusammengefasst werden zu: smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_rbl_client zombie.dnsbl.sorbs.net, reject_rbl_client list.dsbl.org, reject_rbl_client zen.spamhaus.org, reject_rbl_client dialup.blacklist.jippg.org reject_unverified_recipient In zen.spamhaus.org ist enthalten: cbl, sbl, xbl, dynalist, opm Damit werden nur die Mails abgeprüft, die hinter den Blacklists stehen. Du kannst das noch auf deine Relay_domains einschränken, wenn du statt reject_unverified_recipient diesen check verwendest: check_recipient_access hash:/etc/postfix/relay_verify /etc/postfix/relay_verify: digelec.com reject_unverified_recipient daniels.ch reject_unverified_recipient Cache das Ergebnis mit: address_verify_map = btree:/etc/postfix/verify_db Damit baut Postfix dann eine Datenbank mit bestätigten (und unbestätigten) Adressen auf. "postconf | grep verify" zeigt dir die Einstellungen.
permit smtpd_sasl_auth_enable = no smtpd_use_tls = no strict_8bitmime = no strict_rfc821_envelopes = no transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 virtual_alias_domains = hash:/etc/postfix/virtual virtual_alias_maps = hash:/etc/postfix/virtual ---------------------------------------------------------------------------
Der Server ist ein 10.2 ohne viel Einstellungen. DNS (Bind) läuft aber meiner meinung nach richtig.
Der zweite 'Fehler' den ich beobachte: 450 4.1.1
: Recipient address rejected: undeliverable address: host 80.238.212.230[80.238.212.230] said: 550 5.1.1 ... User unknown (in reply to RCPT TO command) sollte da der verify nicht ein 550 5.1.1 zurückgeben anstatt der 450? Können die Codes irgendwo eingestellt werden, oder ist dies ein Bug von verify?
unverified_recipient_reject_code = 550 Im Falle von Serverfehlern gibt Postfix automatisch ein 450 zurück.
Soweit gefällt mir Postfix ganz gut, ich glaube die Problemchen können noch gelöst werden.
Vielen Dank an alle die sich Zeit für mich nehmen!
-- 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:
Thomas Fankhauser wrote:
Die zweite, nicht so schöne Methode, ist die Empfängerverifizierung über reject_unverified_recipient. In dem Fall baut Postfix eine Verbindung zum Backend-Server auf und sondiert, ob dieser die Empfängeradresse annimmt. Wenn ja, dann nimmt Postfix die Mail an.
Der Pferdefuà ist, dass der Backend-Server auch die Fähigkeit haben muss, im smtp Dialog gültige Empfänger von ungültigen zu unterscheiden. AuÃerdem muss er natürlich erreichbar sein, sonst funktioniert es nicht.
Sendmail kann das.
Gut, dann kannst du reject_unverified_recipient verwenden.
Beides kann etwas gemildert werden, wenn man die Ergebnisse cached.
Selbstverständlich möchte ich nicht nur die reject_unverified_sender sondern so viele Regeln wie möglich einbauen. Da ich mich mit Postfix noch nicht so auskenne (habs heute installiert) bin ich für alle Hinweise dankbar.
Ich bin dagegen, soviele Regeln wie möglich einzubauen. (^-^) Verwende am besten erst einmal solide Regeln, die du verstehst, und baue dann die Konfiguration langsam aus.
Ich hab den Server gestern beobachtet, danach noch die Konfig verändert. Heute bin ich erstaunt dass noch viel zu viele Mails durchkommen. Scheinbar verstehe ich das Regelwerk noch nicht.
Die Mail mit diesem Header: Received: from miaow.com (unknown [222.88.215.140])
client_name: unknown helo: miaow.com ip: 222.88.215.140
sollte doch mit dieser Konfig im helo check abgewiesen werden.
relay_domains = digelec.com, daniels.ch smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_hostname, reject_invalid_hostname, permit smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, reject_unauth_destination, reject_unverified_recipient, reject_rbl_client zombie.dnsbl.sorbs.net, reject_rbl_client opm.blitzed.org, reject_rbl_client list.dsbl.org, reject_rbl_client sbl.spamhaus.org, reject_rbl_client blackholes.easynet.nl, reject_rbl_client unconfirmed.dsbl.org, reject_rbl_client dynablock.njabl.org, reject_rbl_client dialup.blacklist.jippg.org, reject_rbl_client cbl.abuseat.org,
Nein, "miaow.com" ist weder von reject_non_fqdn_helo_hostname noch von reject_invalid_helo_hostname erfasst. Meintest du vielleicht reject_unknown_client_hostname? Ich würde mit diesem Check leider einiges an erwünschter Mail ablehnen.
Deine Konfig kann zusammengefasst werden zu:
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_rbl_client zombie.dnsbl.sorbs.net, reject_rbl_client list.dsbl.org, reject_rbl_client zen.spamhaus.org, reject_rbl_client dialup.blacklist.jippg.org reject_unverified_recipient
Meinst du damit dass es nicht nötig ist, smtpd_recipient_restrictions, smtpd_helo_restrictions und smtpd_sender_restrictions zu brauchen. So dass nur eine dieser angegeben werden muss?
In zen.spamhaus.org ist enthalten: cbl, sbl, xbl, dynalist, opm
Damit werden nur die Mails abgeprüft, die hinter den Blacklists stehen. Du kannst das noch auf deine Relay_domains einschränken, wenn du statt reject_unverified_recipient diesen check verwendest:
Was bringt mir das für Vorteile?
check_recipient_access hash:/etc/postfix/relay_verify
/etc/postfix/relay_verify: digelec.com reject_unverified_recipient daniels.ch reject_unverified_recipient
Cache das Ergebnis mit: address_verify_map = btree:/etc/postfix/verify_db
Hab festgestellt dass bei jedem eintreffen einer Mail, der Postfix erst einen 450 4.4.1 Recipient address rejected: unverified address: Address verification in progress Fehler ausgibt. Damit ist doch auch gerade schon ein 'Greylisting' erreicht!?
Damit baut Postfix dann eine Datenbank mit bestätigten (und unbestätigten) Adressen auf.
"postconf | grep verify" zeigt dir die Einstellungen.
permit smtpd_sasl_auth_enable = no smtpd_use_tls = no strict_8bitmime = no strict_rfc821_envelopes = no transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 virtual_alias_domains = hash:/etc/postfix/virtual virtual_alias_maps = hash:/etc/postfix/virtual ---------------------------------------------------------------------------
Der Server ist ein 10.2 ohne viel Einstellungen. DNS (Bind) läuft aber meiner meinung nach richtig.
Der zweite 'Fehler' den ich beobachte: 450 4.1.1
: Recipient address rejected: undeliverable address: host 80.238.212.230[80.238.212.230] said: 550 5.1.1 ... User unknown (in reply to RCPT TO command) sollte da der verify nicht ein 550 5.1.1 zurückgeben anstatt der 450? Können die Codes irgendwo eingestellt werden, oder ist dies ein Bug von verify?
unverified_recipient_reject_code = 550
Funktioniert! Bin irgendwie gleichwohl erstaunt, wie einfach es eigentlich ist. Vorallem Lesbar. Mache mir aber dennoch Gedanken über die Aussage von Burkhard. -- Thomas
Im Falle von Serverfehlern gibt Postfix automatisch ein 450 zurück.
Soweit gefällt mir Postfix ganz gut, ich glaube die Problemchen können noch gelöst werden.
Vielen Dank an alle die sich Zeit für mich nehmen!
-- 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
Thomas Fankhauser wrote:
Deine Konfig kann zusammengefasst werden zu:
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_rbl_client zombie.dnsbl.sorbs.net, reject_rbl_client list.dsbl.org, reject_rbl_client zen.spamhaus.org, reject_rbl_client dialup.blacklist.jippg.org reject_unverified_recipient
Meinst du damit dass es nicht nötig ist, smtpd_recipient_restrictions,
smtpd_helo_restrictions und
smtpd_sender_restrictions zu brauchen. So dass nur eine dieser angegeben werden muss?
Es ist auf jeden Fall einfacher und du siehst die Reihenfolge der Checks. Ansonsten wird ei Sache etwas komplizierter: smtp Dialog läuft nach folgendem Muster ab: connect from... helo/ehlo mail from rcpt to data... Die in Postfix verfügbaren smtpd_*_restrictions sind analog dazu benannt: smtpd_client_restrictions smtpd_helo_restrictions smtpd_sender_restrictions smtpd_recipient_restrictions smtpd_data_restrictions smtpd_end_of_data_restrictions smtpd_recipient_restrictions hat als einzige die Vorgabe, dass dort "reject_unauth_destionation, reject etc." auftauchen muss. Alle anderen sind leer. Du kannst die Checks sehr präzise setzen mit der Auffächerung, aber auf Kosten einer komplizierteren Konfiguration. Der Default ist ohnehin, dass erst nach rcpt to der Client abgewiesen wird, da früher einige Clients Probleme damit hatten, direkt abgewiesen zu werden. Zusätzlich bekommt man die Absender/Empfänger/Helo-Angaben im Log. Jeder smtpd_*_restriction wird durchlaufen, bis entweder ein Check "OK/permit" oder "4xx/5xx/reject" Du hattest z.B. in smtpd_sender_restrictions permit_mynetworks vorgeschaltet, aber kein permit_sasl_authenticated. Dies stand aber bei smtpd_recipient_restrictions, wenn ich mich recht erinnere. Ich nehme an, das war nicht gewollt.
In zen.spamhaus.org ist enthalten: cbl, sbl, xbl, dynalist, opm
Damit werden nur die Mails abgeprüft, die hinter den Blacklists stehen. Du kannst das noch auf deine Relay_domains einschränken, wenn du statt reject_unverified_recipient diesen check verwendest:
Was bringt mir das für Vorteile?
Dass der Check nur für die Relay_domains verwendet wird, aber nicht für lokale Domains in $mydestination, wo Postfix die gültigen Empfänger aus /etc/passwd und /etc/aliases selbst bestimmen kann.
check_recipient_access hash:/etc/postfix/relay_verify
/etc/postfix/relay_verify: digelec.com reject_unverified_recipient daniels.ch reject_unverified_recipient
Cache das Ergebnis mit: address_verify_map = btree:/etc/postfix/verify_db
Hab festgestellt dass bei jedem eintreffen einer Mail, der Postfix erst einen 450 4.4.1 Recipient address rejected: unverified address: Address verification in progress Fehler ausgibt. Damit ist doch auch gerade schon ein 'Greylisting' erreicht!?
Greylisting verwendet ein anderes Prinzip, hier geht es um Empfängervalidierung. Greylistig prüft, ob der Client sich wie ein Server verhält. Eine ähnliche Funktion hat reject_unverified_sender, wo geprüft wird, ob der verantwortliche Server diese Absenderadresse als gültig kennt. Ich habe bei mir festgestellt, dass es eine Menge Ärger durch falsche Adressen gibt. -- 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:
Thomas Fankhauser wrote:
Die zweite, nicht so schöne Methode, ist die Empfängerverifizierung über reject_unverified_recipient. In dem Fall baut Postfix eine Verbindung zum Backend-Server auf und sondiert, ob dieser die Empfängeradresse annimmt. Wenn ja, dann nimmt Postfix die Mail an.
Der Pferdefuà ist, dass der Backend-Server auch die Fähigkeit haben muss, im smtp Dialog gültige Empfänger von ungültigen zu unterscheiden. AuÃerdem muss er natürlich erreichbar sein, sonst funktioniert es nicht.
Sendmail kann das.
Gut, dann kannst du reject_unverified_recipient verwenden.
Ich hab jetzt diese Konfig. die Mails sind drastisch gesunken. ;-)
address_verify_map = btree:/etc/postfix/verify_db
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
canonical_maps = hash:/etc/postfix/canonical
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/lib/postfix
debug_peer_level = 12
defer_transports =
disable_dns_lookups = no
disable_mime_output_conversion = no
html_directory = /usr/share/doc/packages/postfix/html
inet_protocols = all
mail_spool_directory = /var/mail
mailbox_command =
mailbox_size_limit = 0
mailbox_transport =
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
masquerade_classes = envelope_sender, header_sender, header_recipient
masquerade_exceptions = root
message_size_limit = 10240000
mydestination = $myhostname, localhost.$mydomain
myhostname = melinda.slogi.ch
mynetworks_style = host
newaliases_path = /usr/bin/newaliases
readme_directory = /usr/share/doc/packages/postfix/README_FILES
relay_domains = digelec.com, daniels.ch
relocated_maps = hash:/etc/postfix/relocated
sample_directory = /usr/share/doc/packages/postfix/samples
sender_canonical_maps = hash:/etc/postfix/sender_canonical
sendmail_path = /usr/sbin/sendmail
setgid_group = maildrop
smtp_sasl_auth_enable = no
smtp_use_tls = no
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_hostname,
reject_invalid_hostname, permit
smtpd_recipient_restrictions = reject_unauth_pipelining,
permit_sasl_authenticated, permit_mynetworks,
reject_unauth_destination, reject_invalid_hostname,
reject_non_fqdn_hostname, reject_non_fqdn_sender,
reject_non_fqdn_recipient, reject_rbl_client zombie.dnsbl.sorbs.net,
reject_rbl_client list.dsbl.org, reject_rbl_client zen.spamhaus.org,
reject_rbl_client dialup.blacklist.jippg.org,
reject_unverified_recipient
smtpd_sasl_auth_enable = no
smtpd_use_tls = no
strict_8bitmime = no
strict_rfc821_envelopes = no
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
unverified_recipient_reject_code = 550
virtual_alias_domains = hash:/etc/postfix/virtual
virtual_alias_maps = hash:/etc/postfix/virtual
Intressieren würde mich jetzt noch, wie Mails mit diesem Header
abgewiesen werden können.
Received: from [60.211.122.254] (unknown [60.211.122.254])
by melinda.slogi.ch (Postfix) with ESMTP id EC1C1174414
for
-- 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
Thomas Fankhauser wrote:
Sandy Drobic wrote:
Gut, dann kannst du reject_unverified_recipient verwenden.
Ich hab jetzt diese Konfig. die Mails sind drastisch gesunken. ;-)
Sehr schön.
smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_hostname, reject_invalid_hostname, permit smtpd_recipient_restrictions = reject_unauth_pipelining, permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_rbl_client zombie.dnsbl.sorbs.net, reject_rbl_client list.dsbl.org, reject_rbl_client zen.spamhaus.org, reject_rbl_client dialup.blacklist.jippg.org, reject_unverified_recipient
Die Checks reject_non_fqdn_hostname und reject_invalid_hostname tauchen auch in smtpd_recipient_restrictions auf, deshalb ist es nicht nötig, sie doppelt zu prüfen.
smtpd_sasl_auth_enable = no
Da bei dir smtp auth nicht aktiv ist, könntest du auch permit_sasl_authenticated herausnehmen. Häßlich wird es dann, wenn du Ausnahmen für falsch konfigurierte Server machen musst und deshalb vor deine Prüfungen eine Whitelist setzt. Dann musst du nämlich in jeder verwendeten smtpd_*_restrictions die Whitelist setzen. So reicht es dann, wenn du die Whitelist einmal setzt (nach reject_unauth_destination und vor deinen UCE-Checks).
Intressieren würde mich jetzt noch, wie Mails mit diesem Header abgewiesen werden können.
Received: from [60.211.122.254] (unknown [60.211.122.254]) by melinda.slogi.ch (Postfix) with ESMTP id EC1C1174414 for
; Thu, 15 Feb 2007 11:11:30 +0100 (CET) From: "copy" To: balmer@daniels.ch Subject: Approval process Date: Thu, 15 Feb 2007 18:12:29 -0800 Unknown ist ja wirklich nicht ernstzunehmen, oder?
Unknown bedeutet, dass es keinen reverse DNS Eintrag gibt oder dieser nicht übereinstimmt mit dem DNS-Eintrag. host 60.211.122.254 Host 254.122.211.60.in-addr.arpa not found: 3(NXDOMAIN) Leider habe ich genügend Clients, die normale Mails einliefern, aber keinen korrekten reverse DNS-Eintrag. Deshalb kann ich nicht darauf prüfen. Aber ich strafe alle unknown Clients mit Greylisting und testen gegen bl.spamcop.net (was ich bei normalen Servern nicht mache). Wenn du wirklich diese unknown Clients einfach treten willst, dann heisst der zugehörige Check: reject_unknown_client Ab Postfix 2.3 haben die Checks besser verständliche Namen: reject_non_fqdn_hostname -> reject_non_fqdn_helo_hostname reject_invalid_hostname -> reject_invalid_helo_hostname reject_unknown_client -> reject_unknown_client_hostname
Received: from sc6.lga.net.sg (unknown [203.92.123.227]) by melinda.slogi.ch (Postfix) with ESMTP id 8708C174414 for
; Thu, 15 Feb 2007 10:41:37 +0100 (CET) Received: from mail.lluna.org (port=2472 helo=vltpsxhg) by sc6.lga.net.sg with smtp id NTke-WR8S7-6Yj for apologizesgolnboo@daniels.ch; Thu, 15 Feb 2007 17:43:09 +0800 Message-ID: <000a01c750e5$b07e7980$00b4e9fc@vltpsxhg> From: "Randy Freeman" To: apologizesgolnboo@daniels.ch Subject: transnational rx drugstore. Date: Thu, 15 Feb 2007 17:43:09 +0800 Der Inhalt von beiden ist offensichtlich SPAM, am Header ist eigentlich nur die Received: Zeile die noch ein filtern zulässt. Aber wie?
Noch eine Frage zur Konfig, so wie ich Sandy verstanden habe, soll ich die Zeile mit den smtpd_helo_restrictions weglassen. Oder in die smtpd_recipient_restrictions kopieren?
Ja. Einfach smtpd_helo_restrictions = setzen. -- 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:
Thomas Fankhauser wrote:
Sandy Drobic wrote:
Gut, dann kannst du reject_unverified_recipient verwenden.
Ich hab jetzt diese Konfig. die Mails sind drastisch gesunken. ;-)
Sehr schön.
Danke erstmal!
smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_hostname, reject_invalid_hostname, permit smtpd_recipient_restrictions = reject_unauth_pipelining, permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_rbl_client zombie.dnsbl.sorbs.net, reject_rbl_client list.dsbl.org, reject_rbl_client zen.spamhaus.org, reject_rbl_client dialup.blacklist.jippg.org, reject_unverified_recipient
Die Checks reject_non_fqdn_hostname und reject_invalid_hostname tauchen auch in smtpd_recipient_restrictions auf, deshalb ist es nicht nötig, sie doppelt zu prüfen.
Ich blick nur nicht ganz durch, warum es die smtpd_*_restirctions gibt, wenn alles in einer einzelnen sein kann.
smtpd_sasl_auth_enable = no
Da bei dir smtp auth nicht aktiv ist, könntest du auch permit_sasl_authenticated herausnehmen.
Dies hatte ich drinn, weil ich verstanden habe dass mindestens eine Regel mit 'permit' drinn sein muss. Somit habe ich eine drinn, greifen kann sie aber nie. Als dann permit_mynetworks noch reinkam, hab ichs einfach drinngelassen (greift ja eh nie;-)
Häßlich wird es dann, wenn du Ausnahmen für falsch konfigurierte Server machen musst und deshalb vor deine Prüfungen eine Whitelist setzt. Dann musst du nämlich in jeder verwendeten smtpd_*_restrictions die Whitelist setzen.
So reicht es dann, wenn du die Whitelist einmal setzt (nach reject_unauth_destination und vor deinen UCE-Checks).
Unknown ist ja wirklich nicht ernstzunehmen, oder?
Unknown bedeutet, dass es keinen reverse DNS Eintrag gibt oder dieser nicht übereinstimmt mit dem DNS-Eintrag.
Aber sorry, wenn es nicht mal einen reverse DNS Eintrag gibt, dann ist doch wohl schon etwas faul. Jeder hinterletzte DialUp Account besitzt einen entsprechenden ptr Eintrag.
host 60.211.122.254 Host 254.122.211.60.in-addr.arpa not found: 3(NXDOMAIN)
Leider habe ich genügend Clients, die normale Mails einliefern, aber keinen korrekten reverse DNS-Eintrag. Deshalb kann ich nicht darauf prüfen.
Das sind aber Clients, nicht Server. Die Clients müssten sich in meinem Fall per SMTP-AUTH anmelden. Ist aber momentan noch nicht nötig, da diese direkt auf den Zielserver verbinden. Die Umstellung ist geplant, ich weiss nur noch nicht wann dieser Postfix soweit ist. Wenn der Name den der Server im EHLO angibt, nicht mit dem ptr der ip übereinstimmt, würde ich mir aber dennoch überlegen, den Empfang abzulehnen. Meines erachtens ist in dem Fall der Server bzw. DNS nicht fertig installiert. Mit entsprechender Fehlermeldung sollte eigentlich der Kunde letztendlich fähig sein, zu seinem Provider zu gehen und ihm diese Fehlermeldung aufzeigen. Meisst sind es die grossen Provider in Frankreich, die ihre Mailserver anders taufen als der DNS angibt.
Aber ich strafe alle unknown Clients mit Greylisting und testen gegen bl.spamcop.net (was ich bei normalen Servern nicht mache).
Wenn du wirklich diese unknown Clients einfach treten willst, dann heisst der zugehörige Check: reject_unknown_client
Ab Postfix 2.3 haben die Checks besser verständliche Namen:
reject_non_fqdn_hostname -> reject_non_fqdn_helo_hostname reject_invalid_hostname -> reject_invalid_helo_hostname reject_unknown_client -> reject_unknown_client_hostname
Das hab ich direkt grad geändert.
Noch eine Frage zur Konfig, so wie ich Sandy verstanden habe, soll ich die Zeile mit den smtpd_helo_restrictions weglassen. Oder in die smtpd_recipient_restrictions kopieren?
Ja. Einfach smtpd_helo_restrictions = setzen.
Das auch. Ich werds dann mal so lassen und weiter beobachten wie sich die Mails durchschlängeln. ;-) -- Thomas
-- 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
Thomas Fankhauser wrote:
smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_hostname, reject_invalid_hostname, permit smtpd_recipient_restrictions = reject_unauth_pipelining, permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_rbl_client zombie.dnsbl.sorbs.net, reject_rbl_client list.dsbl.org, reject_rbl_client zen.spamhaus.org, reject_rbl_client dialup.blacklist.jippg.org, reject_unverified_recipient
Die Checks reject_non_fqdn_hostname und reject_invalid_hostname tauchen auch in smtpd_recipient_restrictions auf, deshalb ist es nicht nötig, sie doppelt zu prüfen.
Ich blick nur nicht ganz durch, warum es die smtpd_*_restirctions gibt, wenn alles in einer einzelnen sein kann.
Da muss ich jetzt etwas weiter ausholen für. Ich glaube, ich hatte schon erwähnt, dass Postfix bei normaler Einstellung erst nach dem ersten rcpt to Befehl eine Rückmeldung an den Client gibt. Verantwortlich dafür ist: # postconf -d smtpd_delay_reject smtpd_delay_reject = yes Der Client hat somit schon die gesamten Envelope-Informationen übergeben und Postfix kann diese Daten loggen und anhand dieser Daten entscheiden, ob die Mail angenommen werden soll. Das ist deshalb Default, weil es Teil einer robusten Mailstruktur ist und für Analysen das Log aussagekräftig sein sollte. Da die Mailflut jedoch enorme Ausmaße angenommen hat, möchten stark belastete Mailserver die Verbindung so früh wie möglich abbrechen, sobald sie wissen, dass sie keine Mails von diesem Client annehmen möchten. Wenn du zum Beispiel versuchst, eine Mail direkt von einer dynamischen IP an GMX zu senden, dann wirst du feststellen, dass der Connect nicht bis zum Austausch des Envelopes anhält, sondern allein aufgrund deiner IP-Adresse die Verbindung abgebrochen wird. Bei Postfix würde dies verwirklicht mit folgender Konfiguration: main.cf: smtpd_delay_reject = no smdpd_client_restrictions = permit_mynetworks, check_client_access cbl:/etc/postfix/internal_blacklist, reject_rbl_client zen.spamhaus.org Damit wird direkt die Verbindung abgebrochen, wenn anhand der Client-IP ohnehin keine Mails entgegengenommen werden. Dies macht jedoch nur Sinn für einen stark belasteten Server.
smtpd_sasl_auth_enable = no
Da bei dir smtp auth nicht aktiv ist, könntest du auch permit_sasl_authenticated herausnehmen.
Dies hatte ich drinn, weil ich verstanden habe dass mindestens eine Regel mit 'permit' drinn sein muss. Somit habe ich eine drinn, greifen kann sie aber nie. Als dann permit_mynetworks noch reinkam, hab ichs einfach drinngelassen (greift ja eh nie;-)
Im Gegenteil. Niemand hat verlangt, dass eine Regel mit "permit" verwendet wird. für smtpd_recipient_restrictions reicht es, wenn dort ein "reject/reject_unauch_destination" steht. Der wichtige Punkt ist, dass du nicht zu einem offenen Relay wirst. Ob du auch wirklich die erwünschte Mail bekommst, ist nicht so kritisch. (^-^)
Unknown ist ja wirklich nicht ernstzunehmen, oder?
Unknown bedeutet, dass es keinen reverse DNS Eintrag gibt oder dieser nicht übereinstimmt mit dem DNS-Eintrag.
Aber sorry, wenn es nicht mal einen reverse DNS Eintrag gibt, dann ist doch wohl schon etwas faul. Jeder hinterletzte DialUp Account besitzt einen entsprechenden ptr Eintrag.
Nun, es gibt einige Provider (nicht unbedingt deutsche), die dafür berühmt waren, keine reverse DNS zu vergeben und behaupteten, dass diese auch nicht nötig wären. Viele chinesische Server haben damit zu kämpfen, aber auch die British Telecom war bekannt dafür, und Carlos von der englischen opensuse hatte berichtet, dass es nicht einfach ist, in Spanien eine saubere DNS-Konfiguration zu erhalten.
Leider habe ich genügend Clients, die normale Mails einliefern, aber keinen korrekten reverse DNS-Eintrag. Deshalb kann ich nicht darauf prüfen.
Das sind aber Clients, nicht Server. Die Clients müssten sich in meinem Fall per SMTP-AUTH anmelden. Ist aber momentan noch nicht nötig, da diese direkt auf den Zielserver verbinden. Die Umstellung ist geplant, ich weiss nur noch nicht wann dieser Postfix soweit ist.
Wortklauberei. Client ist in diesem Fall nur der Host, der gerade einliefert. Postfix hat einen smtpd Serverdaemon und einen smtp Clientdaemon. Auch die Parameter sind sauber mit smtpd_* und smtp_* für Server und Client getrennt.
Wenn der Name den der Server im EHLO angibt, nicht mit dem ptr der ip übereinstimmt, würde ich mir aber dennoch überlegen, den Empfang abzulehnen. Meines erachtens ist in dem Fall der Server bzw. DNS nicht fertig installiert. Mit entsprechender Fehlermeldung sollte eigentlich der Kunde letztendlich fähig sein, zu seinem Provider zu gehen und ihm diese Fehlermeldung aufzeigen. Meisst sind es die grossen Provider in Frankreich, die ihre Mailserver anders taufen als der DNS angibt.
Auch Yahoo, Google, Hotmail und 1und1 sind schon unangenehm aufgefallen. Ich habe aber auch sehr viele Server, die sich schlicht mit internen Hostnamen melden, welche extern gar nicht aufgelöst werden können. Wenn du nur eine kleine Site verwaltest mit ein paar hundert oder tausend Mails pro Tag, dann kannst du es dir vielleicht noch leisten, die Postmaster anzuschreiben (wenn diese Adresse nicht direkt nach /dev/null geleitet wird). Wenn du jeden Tag hunderte oder tausende von solchen Servern hast, dann kannst du das rein zeitlich nicht mehr. Nebenbei werden dir die zahlenden Kunden/Anwender innerhalb der Firma im Nacken sitzen, die diese Mails haben wollen. Deshalb findet man dafür andere Methoden, Spam abzulehnen. Greylisting ist ein hervorragendes Mittel, Spamzombies abzuweisen. Von solchen Spamzombies aus dynamischen IP-Bereichen kommt der Großteil des Spams. Inzwischen habe ich diese Spams bis auf einen verschwindend geringen Teil im Griff, jetzt kommt ein guter Teil des durchkommenden Spams von echten Servern, die nicht ganz korrekt eingerichtet sind (Backscatter, keine korrekte Authentifikation etc) oder auch von ausgenutzten Webmailern wie Hotmail, Yahoo und Google. Hier die Liste der letzten Rechner, die bei uns Spam eingeliefert haben. Dabei kann es sein, dass der Reverse-DNS nicht existiert. Mein Script hat das nicht mehr geprüft: IP Reverse DNS 200.121.182.185 client-200.121.182.185.speedy.net.pe 213.4.149.12 mailhost.terra.es 61.136.62.74 unknown 216.20.10.4 mailserv.mecnet.net 85.128.59.110 host-ip110-59.crowley.pl 207.115.20.70 flpi101.sbcis.sbc.com 207.115.36.44 nlpi015.sbcis.sbc.com 213.141.25.61 smtp1.artelecom.pt 83.110.21.200 auh-b13756.alshamil.net.ae 12.19.116.73 unknown 65.54.246.97 bay0-omc1-s25.bay0.hotmail.com 212.47.13.186 paegas.mail-atlas.net 65.54.246.218 bay0-omc3-s18.bay0.hotmail.com 62.193.249.37 wpc4343.amenworld.com 86.63.74.38 student.pwsz.pila.pl 213.191.85.38 mail.daybyday.de. 69.94.32.67 anoopam.anoopam-mission.org 69.94.66.57 server.decktherails.com 167.206.4.197 mta2.srv.hcvlny.cv.net 207.159.120.61 nn7.excitenetwork.com 24.235.238.7 d235-238-7.home1.cgocable.net 193.164.133.199 rbi0045.giga-dns.com 124.147.37.246 web3102.mail.kcd.yahoo.co.jp 216.40.35.67 fr3.webmaillogin.com 212.47.13.186 paegas.mail-atlas.net 202.8.85.179 fuji.hamthai.com 217.146.182.133 web28113.mail.ukl.yahoo.com 202.83.112.198 mail-hub.becom.com.au 81.15.224.238 lebork-exatel-2.leb.vectranet.pl 203.216.249.197 web2912.mail.tnz.yahoo.co.jp 85.214.29.180 globalhostingservice.de 65.54.246.165 bay0-omc2-s29.bay0.hotmail.com 65.54.246.224 bay0-omc3-s24.bay0.hotmail.com 58.88.60.19 p1019-ipbf13imazuka.yamagata.ocn.ne.jp Da ist nicht mehr viel dynamisches dabei. Das einzige, was dagegen jetzt helfen würde, ist ein Pre-Queue-Filter, der erst schaut, ob es Spam ist und erst danach über die Annahme der Mail entscheidet. Das ist aber erheblich weniger robust als ein After-Queue-Filter wie Amavis. -- 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)
-
Burkhard Schichtel
-
David Haller
-
Sandy Drobic
-
Thomas Fankhauser