Hallo zusammen, ich möchte einen postfix server als backup MX für eine Domain benutzen. Sprich, wenn der erste MX der Domain ausgefallen ist, soll Postfix alles annehmen und sobald der MX wieder da ist, alles ausliefern. Ich habe bereits etwas gegoogelt, bin mir aber nicht sicher ob das nun eine Art Relay oder vielmehr ein Proxy ist.... Vielleicht hat ja jemand auch schon ein paar passende main.cf Zeilen für mich, anhand derer ich mich in das Thema einarbeiten kann. thx :) -- 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
Stefan König wrote:
Hallo zusammen,
ich möchte einen postfix server als backup MX für eine Domain benutzen. Sprich, wenn der erste MX der Domain ausgefallen ist, soll Postfix alles annehmen und sobald der MX wieder da ist, alles ausliefern. Ich habe bereits etwas gegoogelt, bin mir aber nicht sicher ob das nun eine Art Relay oder vielmehr ein Proxy ist....
Vielleicht wäre es am besten, wenn du noch einmal genau überlegst, ob ein Backup-MX wirklich eine gute Idee ist. Im allgemeinen ist es kaum noch notwendig. Wie funktioniert Backup-MX: ------------------------------------------ - die zuständigen Mailserver für eine Domain werden mit einer Priorität im DNS eingetragen. Ein normaler einliefernder Server versucht der Reihe nach, diese Server anzusprechen, angefangen mit dem MX mit der höchsten Priorität (der niedrigsten Zahl: in MX 10 mail.example.com in MX 20 backup-mx.example.com - Wenn ein Client eine Mail beim Backup-MX einliefert, nimmt dieser die Mail (sofern die Policy auf dem Backup-MX dies erlaubt) erst an. Er hat damit die Verantwortung für die Mail. Danach versucht er, die Mail gemäß den normalen Regeln (suche nach dem höchsten MX-Eintrag) an den ersten MX zuzustellen. - Sobald der erste MX wieder online ist und der Backup-MX dies im Zuge seiner Zustellversuche merkt, werden die Mails an den primären MX zugestellt. ------------------------------------------ Soweit die Theorie, jetzt kommen wir zur Realität und zu "Best practise for Mailservers". 1. Ein Mailserver sollte nur die Mails annehmen, die er auch zustellen kann (sonst werden die Mails nur an den meist gefälschten Absender gebounced und landen als Backscatter bei genervten Dritten). Im Klartext: es dürfen keine Mails an ungültige Empfänger angenommen werden. 2. Die Abweisung von ungültigen Empfängern muss während des SMTP-Dialoges stattfinden in der RCPT TO Anweisung, später kann nicht mehr REJECTed werden, dann wird gebounced, und Bouncen ist böse. 3. Die Prüfungen, welche Emails angenommen und welche abgewiesen werden, müssen auf beiden Servern die gleichen sein. Eine Email, welche der Backup-MX angenommen hat, darf vom ersten MX nicht mehr abgewiesen werden, sonst haben wir wieder Backscatter: Bouncen ist böse. Nur, wenn du alle drei Punkte erfüllen kannst, solltest du einen Backup-MX in Erwägung ziehen. PHBs verkünden oft, dass ein Backup-MX zur "Steigerung der Verfügbarkeit" Pflicht sei, aber in Wirklichkeit leidet die Qualität meistens, wenn ein Backup-MX eingeführt wird. Bedenke immer, dass eine Mail auch von den externen einliefernden Servern solange gespeichert wird, bis der primäre (oder einzige MX) wieder online ist. Erst, wenn die Downtime des Servers länger als ein Tag ist, gehen die ersten Mails als nicht zustellbar an den Absender zurück. Und auch dies ist gegen die RFCs, die verlangen, dass die Zustellung mehrere Tage versucht wird. -- 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 [12.06.2008]:
Stefan König wrote:
Hallo zusammen,
ich möchte einen postfix server als backup MX für eine Domain benutzen. Sprich, wenn der erste MX der Domain ausgefallen ist, soll Postfix alles annehmen und sobald der MX wieder da ist, alles ausliefern. Ich habe bereits etwas gegoogelt, bin mir aber nicht sicher ob das nun eine Art Relay oder vielmehr ein Proxy ist....
Vielleicht wäre es am besten, wenn du noch einmal genau überlegst, ob ein Backup-MX wirklich eine gute Idee ist. Im allgemeinen ist es kaum noch notwendig.
Backup-MXs werden auch von Spammern missbraucht. denn wenn der erste MX die Mail nicht annimmt, versuchen einige Spammer ihren Müll bei einem evtl. vorhandenen Backup-MX ab zu kippen. Bye Michael -- Wer schlank ist, ist zu doof zum Essen. _____________________________________________________________________________ http://macbyte.info/ Mobile Loadavg.: 0.42 1.10 0.79 http://dattuxi.de/ Registered Linux User #228306 Linux 2.6.24-18 x86_64 ICQ #151172379 -- 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 schrieb:
Stefan König wrote:
Hallo zusammen,
ich möchte einen postfix server als backup MX für eine Domain benutzen. Sprich, wenn der erste MX der Domain ausgefallen ist, soll Postfix alles annehmen und sobald der MX wieder da ist, alles ausliefern. Ich habe bereits etwas gegoogelt, bin mir aber nicht sicher ob das nun eine Art Relay oder vielmehr ein Proxy ist....
Vielleicht wäre es am besten, wenn du noch einmal genau überlegst, ob ein Backup-MX wirklich eine gute Idee ist. Im allgemeinen ist es kaum noch notwendig.
Wie funktioniert Backup-MX: ------------------------------------------
- die zuständigen Mailserver für eine Domain werden mit einer Priorität im DNS eingetragen. Ein normaler einliefernder Server versucht der Reihe nach, diese Server anzusprechen, angefangen mit dem MX mit der höchsten Priorität (der niedrigsten Zahl:
in MX 10 mail.example.com in MX 20 backup-mx.example.com
- Wenn ein Client eine Mail beim Backup-MX einliefert, nimmt dieser die Mail (sofern die Policy auf dem Backup-MX dies erlaubt) erst an. Er hat damit die Verantwortung für die Mail. Danach versucht er, die Mail gemäß den normalen Regeln (suche nach dem höchsten MX-Eintrag) an den ersten MX zuzustellen.
- Sobald der erste MX wieder online ist und der Backup-MX dies im Zuge seiner Zustellversuche merkt, werden die Mails an den primären MX zugestellt.
------------------------------------------
Soweit die Theorie, jetzt kommen wir zur Realität und zu "Best practise for Mailservers".
1. Ein Mailserver sollte nur die Mails annehmen, die er auch zustellen kann (sonst werden die Mails nur an den meist gefälschten Absender gebounced und landen als Backscatter bei genervten Dritten). Im Klartext: es dürfen keine Mails an ungültige Empfänger angenommen werden.
2. Die Abweisung von ungültigen Empfängern muss während des SMTP-Dialoges stattfinden in der RCPT TO Anweisung, später kann nicht mehr REJECTed werden, dann wird gebounced, und Bouncen ist böse.
3. Die Prüfungen, welche Emails angenommen und welche abgewiesen werden, müssen auf beiden Servern die gleichen sein. Eine Email, welche der Backup-MX angenommen hat, darf vom ersten MX nicht mehr abgewiesen werden, sonst haben wir wieder Backscatter: Bouncen ist böse.
Nur, wenn du alle drei Punkte erfüllen kannst, solltest du einen Backup-MX in Erwägung ziehen. PHBs verkünden oft, dass ein Backup-MX zur "Steigerung der Verfügbarkeit" Pflicht sei, aber in Wirklichkeit leidet die Qualität meistens, wenn ein Backup-MX eingeführt wird.
Bedenke immer, dass eine Mail auch von den externen einliefernden Servern solange gespeichert wird, bis der primäre (oder einzige MX) wieder online ist.
Erst, wenn die Downtime des Servers länger als ein Tag ist, gehen die ersten Mails als nicht zustellbar an den Absender zurück. Und auch dies ist gegen die RFCs, die verlangen, dass die Zustellung mehrere Tage versucht wird.
Danke für den Beitrag. Ich persönlich halte das ja auch für unnötig, da normalerweise bei Ausfall eines MX die Mail dann eben später zugestellt wird. Aber "da das schon immer so war, soll das jetzt auch zukünftig so gemacht werden!". Dass in der Q mal eben 30.000 bounce mails festhängen, interessiert da keinen. Wenn der Server neu gemacht wird, sind die ja weg ;) Natürlich sollen alle Einstellungen übernommen werden. Ahja. Nun denn, wir sind uns einig, das ist meist Unsinn, zumal die Haupt-MXe von Kunden betrieben werden und man auf deren Einstellungen keinen Zugriff hat. D.h. der Backup-MX muss erstmal allen Schrott annehmen. Was wieder zu einem SPAM/Bounce/etc Problem führt... -- 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
Stefan König, Donnerstag, 12. Juni 2008 15:48:
Dass in der Q mal eben 30.000 bounce mails festhängen, interessiert da keinen. Wenn der Server neu gemacht wird, sind die ja weg ;)
Seit wann führt ein rcpostfix restart zum Löschen der Queues? -- 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 schrieb:
Stefan König, Donnerstag, 12. Juni 2008 15:48:
Dass in der Q mal eben 30.000 bounce mails festhängen, interessiert da keinen. Wenn der Server neu gemacht wird, sind die ja weg ;)
Seit wann führt ein rcpostfix restart zum Löschen der Queues?
rcpostfix restart && postsuper -d ALL haha. nein. auf dem alten rechner läuft exim4. -- 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
Stefan König wrote:
Danke für den Beitrag. Ich persönlich halte das ja auch für unnötig, da normalerweise bei Ausfall eines MX die Mail dann eben später zugestellt wird. Aber "da das schon immer so war, soll das jetzt auch zukünftig so gemacht werden!". Dass in der Q mal eben 30.000 bounce mails festhängen, interessiert da keinen. Wenn der Server neu gemacht wird, sind die ja weg ;) Natürlich sollen alle Einstellungen übernommen werden. Ahja.
Nun denn, wir sind uns einig, das ist meist Unsinn, zumal die Haupt-MXe von Kunden betrieben werden und man auf deren Einstellungen keinen Zugriff hat. D.h. der Backup-MX muss erstmal allen Schrott annehmen. Was wieder zu einem SPAM/Bounce/etc Problem führt...
So ist es leider. Das einzige, was du tun kannst, ist folgendes: - verwende reject_unverified_recipient für die Domains, für die dein Server Backup-MX sein soll und cache dieses Ergebnis für eine angemessen lange Zeit. - setze einen gemäßigten Spamschutz ein als allgemeine Einstellung - treffe eine Vereinbarung, dass Mails, welche dein Server annimmt, von den Endkunden auch angenommen werden müssen Optional: - setze smtpd_restriction_classes ein für Domains mit besonderen Einstellungen - wenn die Hardware-Leistung des Servers ausreicht und das Mailvolumen nicht zu groß ist: verwende einen Proxy_filter für Spam-/Virenfilterung. -- 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 schrieb:
Stefan König wrote:
Danke für den Beitrag. Ich persönlich halte das ja auch für unnötig, da normalerweise bei Ausfall eines MX die Mail dann eben später zugestellt wird. Aber "da das schon immer so war, soll das jetzt auch zukünftig so gemacht werden!". Dass in der Q mal eben 30.000 bounce mails festhängen, interessiert da keinen. Wenn der Server neu gemacht wird, sind die ja weg ;) Natürlich sollen alle Einstellungen übernommen werden. Ahja.
Nun denn, wir sind uns einig, das ist meist Unsinn, zumal die Haupt-MXe von Kunden betrieben werden und man auf deren Einstellungen keinen Zugriff hat. D.h. der Backup-MX muss erstmal allen Schrott annehmen. Was wieder zu einem SPAM/Bounce/etc Problem führt...
So ist es leider. Das einzige, was du tun kannst, ist folgendes:
- verwende reject_unverified_recipient für die Domains, für die dein Server Backup-MX sein soll und cache dieses Ergebnis für eine angemessen lange Zeit.
- setze einen gemäßigten Spamschutz ein als allgemeine Einstellung
- treffe eine Vereinbarung, dass Mails, welche dein Server annimmt, von den Endkunden auch angenommen werden müssen
Genau da liegt auch das Problem, das ist "nicht gewünscht". Der MX soll tunlichst nur das weiterleiten was auch gewollt ist.
Optional:
- setze smtpd_restriction_classes ein für Domains mit besonderen Einstellungen
- wenn die Hardware-Leistung des Servers ausreicht und das Mailvolumen nicht zu groß ist: verwende einen Proxy_filter für Spam-/Virenfilterung.
Hardware reicht aus, kein Problem. Das ganze Projekt bereitet mir jedoch aus den genannten Gründen Bauchschmerzen. Das ganze macht einfach keinen Sinn.... anyway, thx! -- 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
Stefan König wrote:
So ist es leider. Das einzige, was du tun kannst, ist folgendes:
- verwende reject_unverified_recipient für die Domains, für die dein Server Backup-MX sein soll und cache dieses Ergebnis für eine angemessen lange Zeit.
- setze einen gemäßigten Spamschutz ein als allgemeine Einstellung
- treffe eine Vereinbarung, dass Mails, welche dein Server annimmt, von den Endkunden auch angenommen werden müssen
Genau da liegt auch das Problem, das ist "nicht gewünscht". Der MX soll tunlichst nur das weiterleiten was auch gewollt ist.
Definiere "gewollt"... Üblicherweise nimmt man an, dass eine Mail gewollt ist, wenn: - der Empfänger gültig ist - die Absenderdomain existiert (also eine Antwort möglich ist) - die Mail kein Spam oder Virus ist
Optional:
- setze smtpd_restriction_classes ein für Domains mit besonderen Einstellungen
- wenn die Hardware-Leistung des Servers ausreicht und das Mailvolumen nicht zu groß ist: verwende einen Proxy_filter für Spam-/Virenfilterung.
Hardware reicht aus, kein Problem.
Dann auf jeden Fall einen Proxy_filter konfigurieren, damit Spam/Viren direkt abgewiesen werden können.
Das ganze Projekt bereitet mir jedoch aus den genannten Gründen Bauchschmerzen. Das ganze macht einfach keinen Sinn....
Da hilft nur, so lange die Spezifikationen festzuklopfen, bis man eine brauchbare Policy anwenden kann oder sagen muss, dass das Projekt nicht funktionieren KANN. Ohne handfeste Angaben, wie entschieden wird, welche Mails angenommen werden sollen und welche nicht, kann dies nicht funktionieren. Es gibt immer wieder mal bockbeinige Kunden, die verlangen, dass ja keine Spams angenommen werden, aber auf keinen Fall eine erwünschte Mail abgelehnt wird. Außerdem darf man natürlich keine Mails an ungültige Empfänger annehmen, aber eine Liste der gültigen Adressen will der Kunde "aus Sicherheitsgründen" nicht liefern, und so weiter... Irgendwann kommt man an den Punkt, wo man lieber auf so einen Kunden verzichtet als den Support und Ärger am Telefon in Kauf zu 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 schrieb:
Stefan König wrote:
So ist es leider. Das einzige, was du tun kannst, ist folgendes:
- verwende reject_unverified_recipient für die Domains, für die dein Server Backup-MX sein soll und cache dieses Ergebnis für eine angemessen lange Zeit.
- setze einen gemäßigten Spamschutz ein als allgemeine Einstellung
- treffe eine Vereinbarung, dass Mails, welche dein Server annimmt, von den Endkunden auch angenommen werden müssen
Genau da liegt auch das Problem, das ist "nicht gewünscht". Der MX soll tunlichst nur das weiterleiten was auch gewollt ist.
Definiere "gewollt"...
Üblicherweise nimmt man an, dass eine Mail gewollt ist, wenn: - der Empfänger gültig ist - die Absenderdomain existiert (also eine Antwort möglich ist) - die Mail kein Spam oder Virus ist
So würde ich das auch definieren.
Optional:
- setze smtpd_restriction_classes ein für Domains mit besonderen Einstellungen
- wenn die Hardware-Leistung des Servers ausreicht und das Mailvolumen nicht zu groß ist: verwende einen Proxy_filter für Spam-/Virenfilterung.
Hardware reicht aus, kein Problem.
Dann auf jeden Fall einen Proxy_filter konfigurieren, damit Spam/Viren direkt abgewiesen werden können.
Sprich Spam bzw Viren noch vor der Q ablehnen. Proxy_filter sagt mir jetzt aus dem Stegreif nichts, ich habe mal etwas mit einem Milter experimentiert, aber das nicht weiter verfolgt. Hast Du nähere Infos bzw. einen guten link zur hand?
Das ganze Projekt bereitet mir jedoch aus den genannten Gründen Bauchschmerzen. Das ganze macht einfach keinen Sinn....
Da hilft nur, so lange die Spezifikationen festzuklopfen, bis man eine brauchbare Policy anwenden kann oder sagen muss, dass das Projekt nicht funktionieren KANN.
Ohne handfeste Angaben, wie entschieden wird, welche Mails angenommen werden sollen und welche nicht, kann dies nicht funktionieren.
Es gibt immer wieder mal bockbeinige Kunden, die verlangen, dass ja keine Spams angenommen werden, aber auf keinen Fall eine erwünschte Mail abgelehnt wird. Außerdem darf man natürlich keine Mails an ungültige Empfänger annehmen, aber eine Liste der gültigen Adressen will der Kunde "aus Sicherheitsgründen" nicht liefern, und so weiter...
Irgendwann kommt man an den Punkt, wo man lieber auf so einen Kunden verzichtet als den Support und Ärger am Telefon in Kauf zu nehmen.
Ja das alte Lied. Ich habe ja nichts mit Support am Hut, höre aber hie und da von Kunden die "schreien" wenn erwünschte Mails nicht ankommen weil die Absender oder deren Server in irgendeiner Blacklist stehen, aber genauso jammern, wenn man auf diese Blacklists verzichtet.... -- 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
Stefan König wrote:
Genau da liegt auch das Problem, das ist "nicht gewünscht". Der MX soll tunlichst nur das weiterleiten was auch gewollt ist.
Definiere "gewollt"...
Üblicherweise nimmt man an, dass eine Mail gewollt ist, wenn: - der Empfänger gültig ist - die Absenderdomain existiert (also eine Antwort möglich ist) - die Mail kein Spam oder Virus ist
So würde ich das auch definieren.
Also - reject_unverified_recipient oder relay_recipient_maps - reject_unknown_senderdomain - amavisd-new als proxy_filter
Dann auf jeden Fall einen Proxy_filter konfigurieren, damit Spam/Viren direkt abgewiesen werden können.
Sprich Spam bzw Viren noch vor der Q ablehnen. Proxy_filter sagt mir jetzt aus dem Stegreif nichts, ich habe mal etwas mit einem Milter experimentiert, aber das nicht weiter verfolgt. Hast Du nähere Infos bzw. einen guten link zur hand?
- Postfix bekommt einen connect auf dem smtpd - es wird Client-IP/Client_reverse_DNS/HELO/envelope sender/envelope recipient geprüft Wenn die Mail bis dahin nicht abgewiesen wurde, dann geht die eigentliche Mail (header mit Mailbody) direkt durchgeschleift von Postfix an den proxy_filter. Falls dieser die Mail abweist, wird Postfix die Mail ebenfalls abweisen. Der Unterschied ist, dass im normalen Setup Postfix die Mail erst komplett annimmt und danach erst in den content_filter gibt. Die Mail ist dann schon angenommen und damit in deiner Verantwortung. Nachteil ist, dass wegen der sofortigen Filterung Vorsorge getroffen werden muss, dass die Filterung nicht zu einem Timeout führt. Deshalb muss die Konfiguration etwas sorgfältiger auf die Hardware abgestimmt werden.
Ich habe ja nichts mit Support am Hut, höre aber hie und da von Kunden die "schreien" wenn erwünschte Mails nicht ankommen weil die Absender oder deren Server in irgendeiner Blacklist stehen, aber genauso jammern, wenn man auf diese Blacklists verzichtet....
Man kann immer eine Whitelist zur Verfügung stellen, damit Mails von diesen Clients/Absendern immer angenommen werden, aber das erfordert vom Kunden, dass diese Listen auch gepflegt werden. Spambekämpfung ist nicht trivial, erst recht nicht, wenn man als Provider für viele unterschiedliche Kunden und Bedürfnisse herhalten muss. -- 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 schrieb:
Stefan König wrote:
Genau da liegt auch das Problem, das ist "nicht gewünscht". Der MX soll tunlichst nur das weiterleiten was auch gewollt ist.
Definiere "gewollt"...
Üblicherweise nimmt man an, dass eine Mail gewollt ist, wenn: - der Empfänger gültig ist - die Absenderdomain existiert (also eine Antwort möglich ist) - die Mail kein Spam oder Virus ist
So würde ich das auch definieren.
Also - reject_unverified_recipient oder relay_recipient_maps - reject_unknown_senderdomain - amavisd-new als proxy_filter
Dann auf jeden Fall einen Proxy_filter konfigurieren, damit Spam/Viren direkt abgewiesen werden können.
Sprich Spam bzw Viren noch vor der Q ablehnen. Proxy_filter sagt mir jetzt aus dem Stegreif nichts, ich habe mal etwas mit einem Milter experimentiert, aber das nicht weiter verfolgt. Hast Du nähere Infos bzw. einen guten link zur hand?
- Postfix bekommt einen connect auf dem smtpd - es wird Client-IP/Client_reverse_DNS/HELO/envelope sender/envelope recipient geprüft
Wenn die Mail bis dahin nicht abgewiesen wurde, dann geht die eigentliche Mail (header mit Mailbody) direkt durchgeschleift von Postfix an den proxy_filter. Falls dieser die Mail abweist, wird Postfix die Mail ebenfalls abweisen.
Der Unterschied ist, dass im normalen Setup Postfix die Mail erst komplett annimmt und danach erst in den content_filter gibt. Die Mail ist dann schon angenommen und damit in deiner Verantwortung.
Nachteil ist, dass wegen der sofortigen Filterung Vorsorge getroffen werden muss, dass die Filterung nicht zu einem Timeout führt. Deshalb muss die Konfiguration etwas sorgfältiger auf die Hardware abgestimmt werden.
In der Postfix before-Q Filter Doku http://www.postfix.org/SMTPD_PROXY_README.html ist so ein Konstrukt beschrieben. Ich werde das ganze mal Testweise auf einer VM laufen lassen.... -- 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 schrieb:
Stefan König wrote:
Genau da liegt auch das Problem, das ist "nicht gewünscht". Der MX soll tunlichst nur das weiterleiten was auch gewollt ist.
Definiere "gewollt"...
Üblicherweise nimmt man an, dass eine Mail gewollt ist, wenn: - der Empfänger gültig ist - die Absenderdomain existiert (also eine Antwort möglich ist) - die Mail kein Spam oder Virus ist
So würde ich das auch definieren.
Also - reject_unverified_recipient oder relay_recipient_maps - reject_unknown_senderdomain - amavisd-new als proxy_filter
Dann auf jeden Fall einen Proxy_filter konfigurieren, damit Spam/Viren direkt abgewiesen werden können.
Sprich Spam bzw Viren noch vor der Q ablehnen. Proxy_filter sagt mir jetzt aus dem Stegreif nichts, ich habe mal etwas mit einem Milter experimentiert, aber das nicht weiter verfolgt. Hast Du nähere Infos bzw. einen guten link zur hand?
- Postfix bekommt einen connect auf dem smtpd - es wird Client-IP/Client_reverse_DNS/HELO/envelope sender/envelope recipient geprüft
Wenn die Mail bis dahin nicht abgewiesen wurde, dann geht die eigentliche Mail (header mit Mailbody) direkt durchgeschleift von Postfix an den proxy_filter. Falls dieser die Mail abweist, wird Postfix die Mail ebenfalls abweisen.
Der Unterschied ist, dass im normalen Setup Postfix die Mail erst komplett annimmt und danach erst in den content_filter gibt. Die Mail ist dann schon angenommen und damit in deiner Verantwortung.
Nachteil ist, dass wegen der sofortigen Filterung Vorsorge getroffen werden muss, dass die Filterung nicht zu einem Timeout führt. Deshalb muss die Konfiguration etwas sorgfältiger auf die Hardware abgestimmt werden.
Ich habe ja nichts mit Support am Hut, höre aber hie und da von Kunden die "schreien" wenn erwünschte Mails nicht ankommen weil die Absender oder deren Server in irgendeiner Blacklist stehen, aber genauso jammern, wenn man auf diese Blacklists verzichtet....
Man kann immer eine Whitelist zur Verfügung stellen, damit Mails von diesen Clients/Absendern immer angenommen werden, aber das erfordert vom Kunden, dass diese Listen auch gepflegt werden.
Spambekämpfung ist nicht trivial, erst recht nicht, wenn man als Provider für viele unterschiedliche Kunden und Bedürfnisse herhalten muss.
Hallo Sandy, ich komme nochmal auf das Thema zurück, da Du ja offenbar Postfix in und auswendig kennst ;) Gibts es eine Möglickeit mit Postfix eine Mailadresse before-queue zu verifizieren und zwar nicht über das verify Kommando im smtp dialog? Es gibt eine komerzielle Lösung für windows, die als proxy smtp fungiert und bei eintreffen einer mail zb für test@example.com beim hinterlegten haupt MX einen smtp dialog startet und mit rcpt to: prüft, ob diese adresse dort existiert. dies macht er nur beim ersten einreffen einer mail für diesen user. ich hoffe es ist ersichtlich was ich meine :) btw an alle die es interessiert: ich habe meine milter experimente wieder aufgenommen, MIMEDefang arbeitet soweit recht ordentlich und ist gut zu konfigurieren udn einzubinden -- 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
Stefan König wrote:
Hallo Sandy, ich komme nochmal auf das Thema zurück, da Du ja offenbar Postfix in und auswendig kennst ;)
Postfix macht einfach Spaß. (^-^)
Gibts es eine Möglickeit mit Postfix eine Mailadresse before-queue zu verifizieren und zwar nicht über das verify Kommando im smtp dialog? Es gibt eine komerzielle Lösung für windows, die als proxy smtp fungiert und bei eintreffen einer mail zb für test@example.com beim hinterlegten haupt MX einen smtp dialog startet und mit rcpt to: prüft, ob diese adresse dort existiert. dies macht er nur beim ersten einreffen einer mail für diesen user.
Genau dies macht reject_unverified_recipient. Dabei kann sehr präzise eingestellt werden, wie lange ein positives oder negatives Ergebnis gecached wird. Details dazu stehen unter: http://www.postfix.org/ADDRESS_VERIFICATION_README.html Dies sind die Defaultwerte: address_verify_map = address_verify_negative_cache = yes address_verify_negative_expire_time = 3d address_verify_negative_refresh_time = 3h address_verify_poll_count = 3 address_verify_poll_delay = 3s address_verify_positive_expire_time = 31d address_verify_positive_refresh_time = 7d address_verify_relay_transport = $relay_transport address_verify_relayhost = $relayhost address_verify_sender = $double_bounce_sender Eine Beispielkonfig wäre: /etc/postfix/main.cf: # wo wird die db für den address cache abgelegt: address_verify_map = btree:/etc/postfix/address_verify # soll gespeichert werden, ob eine Adresse NICHT existiert: address_verify_negative_cache = yes # Wenn yes für negativ, wie lange: address_verify_negative_expire_time = 3d # Nach welcher Zeit soll das negative Ergebnis frühestens überprüft werden: address_verify_negative_refresh_time = 3h # Wie viele Probemails maximal schicken: address_verify_poll_count = 3 # Wie lange maximal warten auf eine Antwort: address_verify_poll_delay = 3s # 3 x 3 Sekunden entspricht max. 9 Sekunden, in denen der Backendserver # reagieren muss, sonst gibt es einen Tempfehler # Wie lange soll eine positive Antwort gespeicher werden: address_verify_positive_expire_time = 31d # nach welcher Zeit soll das positive Ergebnis frühestens überprüft werden: address_verify_positive_refresh_time = 7d # Welche Absenderadresse soll verwendet werden: address_verify_sender = $double_bounce_sender # # smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination reject_unverified_recipient Das war's schon. Du solltest nur darauf achten, dass nur deine eigenen Domains überprüft werden, da sonst auch externe Empfänger überprüft werden. Einige Server reagieren darauf allergisch mit einem Temp-Blacklisten. Dies macht z.B. die Telekom, wenn man innerhalb von 24 Stunden mehr als 40 nicht vorhandene Empfänger bei denen versucht. Dann bist du plötzlich für 24 Stunden gesperrt. Deshalb immer reject_unverified_recipient immer nur nach reject_unauth_destination, dann können es nur noch die eigenen Domains sein. Voraussetzung ist natürlich, dass der Backendserver auch imstande ist, ungültige Empfänger während des RCPT TO abzuweisen. Exchange kann das noch nicht lange, ältere Versionen haben einfach alles geschluckt und dann später gebounced. :-/
btw an alle die es interessiert: ich habe meine milter experimente wieder aufgenommen, MIMEDefang arbeitet soweit recht ordentlich und ist gut zu konfigurieren udn einzubinden
Bei welchem Maildurchsatz mit welcher Hardware? -- 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 schrieb:
Stefan König wrote:
Hallo Sandy, ich komme nochmal auf das Thema zurück, da Du ja offenbar Postfix in und auswendig kennst ;)
Postfix macht einfach Spaß. (^-^)
Gibts es eine Möglickeit mit Postfix eine Mailadresse before-queue zu verifizieren und zwar nicht über das verify Kommando im smtp dialog? Es gibt eine komerzielle Lösung für windows, die als proxy smtp fungiert und bei eintreffen einer mail zb für test@example.com beim hinterlegten haupt MX einen smtp dialog startet und mit rcpt to: prüft, ob diese adresse dort existiert. dies macht er nur beim ersten einreffen einer mail für diesen user.
Genau dies macht reject_unverified_recipient. Dabei kann sehr präzise eingestellt werden, wie lange ein positives oder negatives Ergebnis gecached wird.
Details dazu stehen unter: http://www.postfix.org/ADDRESS_VERIFICATION_README.html
Dies sind die Defaultwerte: address_verify_map = address_verify_negative_cache = yes address_verify_negative_expire_time = 3d address_verify_negative_refresh_time = 3h address_verify_poll_count = 3 address_verify_poll_delay = 3s address_verify_positive_expire_time = 31d address_verify_positive_refresh_time = 7d address_verify_relay_transport = $relay_transport address_verify_relayhost = $relayhost address_verify_sender = $double_bounce_sender
Eine Beispielkonfig wäre:
/etc/postfix/main.cf: # wo wird die db für den address cache abgelegt: address_verify_map = btree:/etc/postfix/address_verify # soll gespeichert werden, ob eine Adresse NICHT existiert: address_verify_negative_cache = yes # Wenn yes für negativ, wie lange: address_verify_negative_expire_time = 3d # Nach welcher Zeit soll das negative Ergebnis frühestens überprüft werden: address_verify_negative_refresh_time = 3h # Wie viele Probemails maximal schicken: address_verify_poll_count = 3 # Wie lange maximal warten auf eine Antwort: address_verify_poll_delay = 3s # 3 x 3 Sekunden entspricht max. 9 Sekunden, in denen der Backendserver # reagieren muss, sonst gibt es einen Tempfehler # Wie lange soll eine positive Antwort gespeicher werden: address_verify_positive_expire_time = 31d # nach welcher Zeit soll das positive Ergebnis frühestens überprüft werden: address_verify_positive_refresh_time = 7d # Welche Absenderadresse soll verwendet werden: address_verify_sender = $double_bounce_sender # # smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination reject_unverified_recipient
Das war's schon.
Du solltest nur darauf achten, dass nur deine eigenen Domains überprüft werden, da sonst auch externe Empfänger überprüft werden. Einige Server reagieren darauf allergisch mit einem Temp-Blacklisten. Dies macht z.B. die Telekom, wenn man innerhalb von 24 Stunden mehr als 40 nicht vorhandene Empfänger bei denen versucht. Dann bist du plötzlich für 24 Stunden gesperrt.
Deshalb immer reject_unverified_recipient immer nur nach reject_unauth_destination, dann können es nur noch die eigenen Domains sein.
Voraussetzung ist natürlich, dass der Backendserver auch imstande ist, ungültige Empfänger während des RCPT TO abzuweisen. Exchange kann das noch nicht lange, ältere Versionen haben einfach alles geschluckt und dann später gebounced. :-/
danke für die postfix hints
btw an alle die es interessiert: ich habe meine milter experimente wieder aufgenommen, MIMEDefang arbeitet soweit recht ordentlich und ist gut zu konfigurieren udn einzubinden
Bei welchem Maildurchsatz mit welcher Hardware?
nicht besonders viel, ca. 6000 mailkonten mit ca 8 msg/min receive , 1 msg/min send an gültigen mails. hauptsächlicher traffic entsteht durch spam. 100k-200k rejects am tag, 0.xx spam mails schlüpfen momentan noch durch pro min... :/ hardware gibt es nicht ;) es ist eine VM auf einem ESX cluster. -- 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
Stefan König wrote:
btw an alle die es interessiert: ich habe meine milter experimente wieder aufgenommen, MIMEDefang arbeitet soweit recht ordentlich und ist gut zu konfigurieren udn einzubinden
Bei welchem Maildurchsatz mit welcher Hardware?
nicht besonders viel, ca. 6000 mailkonten mit ca 8 msg/min receive , 1 msg/min send an gültigen mails. hauptsächlicher traffic entsteht durch spam. 100k-200k rejects am tag, 0.xx spam mails schlüpfen momentan noch durch pro min... :/ hardware gibt es nicht ;) es ist eine VM auf einem ESX cluster.
Je nachdem, was für Mailkonten das sind, kann man da vielleicht noch etwas machen. Gemischtladen für viele unterschiedliche Kunden ist immer recht schwierig, aber bei einer Reject-Rate von 90-95% müsste noch etwas drin sein. Auch eine VM hat zugewiesene Ressourcen. (^-^) -- 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 schrieb:
Stefan König wrote:
btw an alle die es interessiert: ich habe meine milter experimente wieder aufgenommen, MIMEDefang arbeitet soweit recht ordentlich und ist gut zu konfigurieren udn einzubinden
Bei welchem Maildurchsatz mit welcher Hardware?
nicht besonders viel, ca. 6000 mailkonten mit ca 8 msg/min receive , 1 msg/min send an gültigen mails. hauptsächlicher traffic entsteht durch spam. 100k-200k rejects am tag, 0.xx spam mails schlüpfen momentan noch durch pro min... :/ hardware gibt es nicht ;) es ist eine VM auf einem ESX cluster.
Je nachdem, was für Mailkonten das sind, kann man da vielleicht noch etwas machen. Gemischtladen für viele unterschiedliche Kunden ist immer recht schwierig, aber bei einer Reject-Rate von 90-95% müsste noch etwas drin sein.
Auch eine VM hat zugewiesene Ressourcen. (^-^)
ja hat sie *g* 2GB ram, 1 CPU, 50GB HDD auf einer 10k upm sata lun. reservietr bekommt sie 1ghz cpu takt und 1gb ram fest. davon nutzt sie rund 200-600mhz sowie 700mb ram. über die nacht hat auch der bayes filter bisschen was zu futtern bekommen, spam ist runter auf 0.32/min tendenz fallend, bounce 0.06/min ebenso fallend. das ganze funktioniert ja erstaunilch gut :) bisher hat glaub ich auch noch kein kunde geschriehen :) -- 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 schrieb:
Stefan König wrote:
Hallo Sandy, ich komme nochmal auf das Thema zurück, da Du ja offenbar Postfix in und auswendig kennst ;)
Postfix macht einfach Spaß. (^-^)
Gibts es eine Möglickeit mit Postfix eine Mailadresse before-queue zu verifizieren und zwar nicht über das verify Kommando im smtp dialog? Es gibt eine komerzielle Lösung für windows, die als proxy smtp fungiert und bei eintreffen einer mail zb für test@example.com beim hinterlegten haupt MX einen smtp dialog startet und mit rcpt to: prüft, ob diese adresse dort existiert. dies macht er nur beim ersten einreffen einer mail für diesen user.
Genau dies macht reject_unverified_recipient. Dabei kann sehr präzise eingestellt werden, wie lange ein positives oder negatives Ergebnis gecached wird.
Details dazu stehen unter: http://www.postfix.org/ADDRESS_VERIFICATION_README.html
Dies sind die Defaultwerte: address_verify_map = address_verify_negative_cache = yes address_verify_negative_expire_time = 3d address_verify_negative_refresh_time = 3h address_verify_poll_count = 3 address_verify_poll_delay = 3s address_verify_positive_expire_time = 31d address_verify_positive_refresh_time = 7d address_verify_relay_transport = $relay_transport address_verify_relayhost = $relayhost address_verify_sender = $double_bounce_sender
Eine Beispielkonfig wäre:
/etc/postfix/main.cf: # wo wird die db für den address cache abgelegt: address_verify_map = btree:/etc/postfix/address_verify # soll gespeichert werden, ob eine Adresse NICHT existiert: address_verify_negative_cache = yes # Wenn yes für negativ, wie lange: address_verify_negative_expire_time = 3d # Nach welcher Zeit soll das negative Ergebnis frühestens überprüft werden: address_verify_negative_refresh_time = 3h # Wie viele Probemails maximal schicken: address_verify_poll_count = 3 # Wie lange maximal warten auf eine Antwort: address_verify_poll_delay = 3s # 3 x 3 Sekunden entspricht max. 9 Sekunden, in denen der Backendserver # reagieren muss, sonst gibt es einen Tempfehler # Wie lange soll eine positive Antwort gespeicher werden: address_verify_positive_expire_time = 31d # nach welcher Zeit soll das positive Ergebnis frühestens überprüft werden: address_verify_positive_refresh_time = 7d # Welche Absenderadresse soll verwendet werden: address_verify_sender = $double_bounce_sender # # smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination reject_unverified_recipient
Das war's schon.
Du solltest nur darauf achten, dass nur deine eigenen Domains überprüft werden, da sonst auch externe Empfänger überprüft werden.
So ich wollte heute mal etwas experimentieren, nud genau diese Frage stelle ich mir gerade. Es muss doch eine Liste konfiguriert werden, welche Domains er verified.
Deshalb immer reject_unverified_recipient immer nur nach reject_unauth_destination, dann können es nur noch die eigenen Domains sein.
-- 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
Stefan König wrote:
smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination reject_unverified_recipient
Das war's schon.
Du solltest nur darauf achten, dass nur deine eigenen Domains überprüft werden, da sonst auch externe Empfänger überprüft werden.
So ich wollte heute mal etwas experimentieren, nud genau diese Frage stelle ich mir gerade. Es muss doch eine Liste konfiguriert werden, welche Domains er verified.
Deshalb immer reject_unverified_recipient immer nur nach reject_unauth_destination, dann können es nur noch die eigenen Domains sein.
Hier steht die Antwort doch schon. (^-^) Wenn du das pro Domain machen möchtest, dann kannst du dies auch so verwirklichen: /etc/postfix/main.cf: smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination check_recipient_access hash:/etc/postfix/domains_to_verify /etc/postfix/domains_to_verify: example.com reject_unverified_recipient example2.com reject_unverified_recipient Natürlich "postmap hash:/etc/postfix/domains_to_verify" und "postfix reload" nicht vergessen. -- 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 schrieb:
Stefan König wrote:
smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination reject_unverified_recipient
Das war's schon.
Du solltest nur darauf achten, dass nur deine eigenen Domains überprüft werden, da sonst auch externe Empfänger überprüft werden.
So ich wollte heute mal etwas experimentieren, nud genau diese Frage stelle ich mir gerade. Es muss doch eine Liste konfiguriert werden, welche Domains er verified.
Deshalb immer reject_unverified_recipient immer nur nach reject_unauth_destination, dann können es nur noch die eigenen Domains sein.
Hier steht die Antwort doch schon. (^-^)
Das habe ich wohl gelesen und auch in der Doku nachgeschaut, aber so richtig schlau geworden bin ich nicht draus *g* wenn ich alle unauth destinations rejecte, was sidn denn dann auth_destinations? ich steh aufm schlauch. geht das evtl über den mx record in den zonen?
Wenn du das pro Domain machen möchtest, dann kannst du dies auch so verwirklichen:
/etc/postfix/main.cf: smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination check_recipient_access hash:/etc/postfix/domains_to_verify
/etc/postfix/domains_to_verify: example.com reject_unverified_recipient example2.com reject_unverified_recipient
Natürlich "postmap hash:/etc/postfix/domains_to_verify" und "postfix reload" nicht vergessen.
ok, das ist die listenversion die ich mir dachte :) -- 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
Stefan König wrote:
Sandy Drobic schrieb:
Stefan König wrote:
smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination reject_unverified_recipient
Das war's schon.
Du solltest nur darauf achten, dass nur deine eigenen Domains überprüft werden, da sonst auch externe Empfänger überprüft werden.
So ich wollte heute mal etwas experimentieren, nud genau diese Frage stelle ich mir gerade. Es muss doch eine Liste konfiguriert werden, welche Domains er verified.
Deshalb immer reject_unverified_recipient immer nur nach reject_unauth_destination, dann können es nur noch die eigenen Domains sein.
Hier steht die Antwort doch schon. (^-^)
Das habe ich wohl gelesen und auch in der Doku nachgeschaut, aber so richtig schlau geworden bin ich nicht draus *g* wenn ich alle unauth destinations rejecte, was sidn denn dann auth_destinations? ich steh aufm schlauch.
Du musst dir nur vor Augen führen, wie Postfix die Checks durchführt und was die Checks genau machen: Postfix geht die Checks strikt in der Reihenfolge durch, in der sie aufgeführt sind. Postfix evaluiert die Checks so lange, bis einer dieser Checks entweder "OK/permit" oder "4xx/5xx/reject" zurückmeldet. Alle Checks danach werden nicht mehr ausgewertet. permit_mynetworks: OK wenn client in $mynetworks, sonst DUNNO (nächster Check) reject_unauth_destination: DUNNO wenn Empfängerdomain von Postfix verwaltet, sonst reject dies gilt für: - mydestination - relay_domains - virtual_mailbox_domains - virtual_alias_domains es gibt auch ein permit_auth_destination, das gibt ein "permit" zurück, wenn die Domain bekannt ist. Aus Sicherheitsgründen wird dies möglichst nicht verwendet. reject_unverified_recipient: DUNNO, wenn der empfänger verifiziert wird, sonst 550/450. Kurz: Check meldet: OK: Mail wird angenommen 4xx/5xx/reject: Mail/Empfänger wird abgewiesen DUNNO: nächster Check wird ausgewertet
geht das evtl über den mx record in den zonen?
Na sicher. Du setzt für deine Domain den MX auf meinen Server, und mein Server soll den Krempel dann brav annehmen? Nö, lieber nicht. (^-^) Siehe oben. Es gibt zwar ein "permit_mx_backup", welches die Mail annimmt, wenn der Server als Backup_MX eingetragen ist, aber aus Sicherheitsgründen sollte dies möglichst nicht verwendet werden. -- 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 schrieb:
Stefan König wrote:
Sandy Drobic schrieb:
Stefan König wrote:
smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination reject_unverified_recipient
Das war's schon.
Du solltest nur darauf achten, dass nur deine eigenen Domains überprüft werden, da sonst auch externe Empfänger überprüft werden.
So ich wollte heute mal etwas experimentieren, nud genau diese Frage stelle ich mir gerade. Es muss doch eine Liste konfiguriert werden, welche Domains er verified.
Deshalb immer reject_unverified_recipient immer nur nach reject_unauth_destination, dann können es nur noch die eigenen Domains sein.
Hier steht die Antwort doch schon. (^-^)
Das habe ich wohl gelesen und auch in der Doku nachgeschaut, aber so richtig schlau geworden bin ich nicht draus *g* wenn ich alle unauth destinations rejecte, was sidn denn dann auth_destinations? ich steh aufm schlauch.
Du musst dir nur vor Augen führen, wie Postfix die Checks durchführt und was die Checks genau machen:
Postfix geht die Checks strikt in der Reihenfolge durch, in der sie aufgeführt sind. Postfix evaluiert die Checks so lange, bis einer dieser Checks entweder "OK/permit" oder "4xx/5xx/reject" zurückmeldet. Alle Checks danach werden nicht mehr ausgewertet.
permit_mynetworks: OK wenn client in $mynetworks, sonst DUNNO (nächster Check)
reject_unauth_destination: DUNNO wenn Empfängerdomain von Postfix verwaltet, sonst reject dies gilt für: - mydestination - relay_domains - virtual_mailbox_domains - virtual_alias_domains
es gibt auch ein permit_auth_destination, das gibt ein "permit" zurück, wenn die Domain bekannt ist. Aus Sicherheitsgründen wird dies möglichst nicht verwendet.
reject_unverified_recipient: DUNNO, wenn der empfänger verifiziert wird, sonst 550/450.
Kurz: Check meldet: OK: Mail wird angenommen 4xx/5xx/reject: Mail/Empfänger wird abgewiesen DUNNO: nächster Check wird ausgewertet
geht das evtl über den mx record in den zonen?
Na sicher. Du setzt für deine Domain den MX auf meinen Server, und mein Server soll den Krempel dann brav annehmen? Nö, lieber nicht. (^-^) Siehe oben.
Es gibt zwar ein "permit_mx_backup", welches die Mail annimmt, wenn der Server als Backup_MX eingetragen ist, aber aus Sicherheitsgründen sollte dies möglichst nicht verwendet werden.
Das ist mir prinzipiell schon klar, aber: reject_unauth_destination: DUNNO wenn Empfängerdomain von Postfix verwaltet, sonst reject dies gilt für: - mydestination - relay_domains - virtual_mailbox_domains - virtual_alias_domains dann muss ja doch irgendwie eine liste von gültigen domains existieren.... ich drehe mich im kreis :) -- 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
Stefan König wrote:
Das ist mir prinzipiell schon klar, aber:
reject_unauth_destination: DUNNO wenn Empfängerdomain von Postfix verwaltet, sonst reject dies gilt für: - mydestination - relay_domains - virtual_mailbox_domains - virtual_alias_domains
dann muss ja doch irgendwie eine liste von gültigen domains existieren.... ich drehe mich im kreis :)
Vielleicht ist dein Problem, dass es mehrere Listen von gültigen Domains gibt? Genau die, die ich aufgeführt habe? Ansonsten verstehe ich einfach nicht, was nun dein Problem ist? Ich habe deutlich das Gefühl, dass du ein Problem machst, wo gar keines 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 schrieb:
Stefan König wrote:
Das ist mir prinzipiell schon klar, aber:
reject_unauth_destination: DUNNO wenn Empfängerdomain von Postfix verwaltet, sonst reject dies gilt für: - mydestination - relay_domains - virtual_mailbox_domains - virtual_alias_domains
dann muss ja doch irgendwie eine liste von gültigen domains existieren.... ich drehe mich im kreis :)
Vielleicht ist dein Problem, dass es mehrere Listen von gültigen Domains gibt? Genau die, die ich aufgeführt habe? Ansonsten verstehe ich einfach nicht, was nun dein Problem ist? Ich habe deutlich das Gefühl, dass du ein Problem machst, wo gar keines ist. (^-^)
Mein Problem ist, dass ich davon ausgegangen bin, dass irgendwo eine Liste existieren muss, die die Domanis enthält, für die der backup MX mails annimmt und für die er die konten verifziert. dich habe ich dann so verstanden, dass dem nicht so ist, man das jedoch so machen KANN. daher meine veriwrrung :) -- 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
Stefan König wrote:
Vielleicht ist dein Problem, dass es mehrere Listen von gültigen Domains gibt? Genau die, die ich aufgeführt habe? Ansonsten verstehe ich einfach nicht, was nun dein Problem ist? Ich habe deutlich das Gefühl, dass du ein Problem machst, wo gar keines ist. (^-^)
Mein Problem ist, dass ich davon ausgegangen bin, dass irgendwo eine Liste existieren muss, die die Domanis enthält, für die der backup MX mails annimmt und für die er die konten verifziert. dich habe ich dann so verstanden, dass dem nicht so ist, man das jedoch so machen KANN. daher meine veriwrrung :)
In deinem Fall wäre das relay_domains für den Backup MX. Etwas tückisch in diesem Fall ist, dass die Voreinstellung auf $mydestination lautet mit dem Ergebnis, dass alle Domains in $mydestination lokale Domains sind, aber alle SUBdomains von $mydestination automatisch zu relay_domains werden. -- 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 schrieb:
Stefan König wrote:
Vielleicht ist dein Problem, dass es mehrere Listen von gültigen Domains gibt? Genau die, die ich aufgeführt habe? Ansonsten verstehe ich einfach nicht, was nun dein Problem ist? Ich habe deutlich das Gefühl, dass du ein Problem machst, wo gar keines ist. (^-^)
Mein Problem ist, dass ich davon ausgegangen bin, dass irgendwo eine Liste existieren muss, die die Domanis enthält, für die der backup MX mails annimmt und für die er die konten verifziert. dich habe ich dann so verstanden, dass dem nicht so ist, man das jedoch so machen KANN. daher meine veriwrrung :)
In deinem Fall wäre das relay_domains für den Backup MX. Etwas tückisch in diesem Fall ist, dass die Voreinstellung auf $mydestination lautet mit dem Ergebnis, dass alle Domains in $mydestination lokale Domains sind, aber alle SUBdomains von $mydestination automatisch zu relay_domains werden.
Muss nochmal darauf zurück kommen. ich würde gerne vermeiden, eine riesige Domainliste zu pflegen. Bei Exim hat man ja zB die Möglichkeit mit domainlist relay_to_domains = @mx_any automatisch für alle Domains, in denen der Server als MX eingetragen ist, Mails zu relayen. Ist Dir so ein Konstrukt auch für Postfix bekannt? Den Nameserver kontrolliere ich zwar auch selbst, von daher könnte ich auch manuell den MX aus den Zonen holen, aber .... Grüße -- 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
Stefan König wrote:
Muss nochmal darauf zurück kommen. ich würde gerne vermeiden, eine riesige Domainliste zu pflegen. Bei Exim hat man ja zB die Möglichkeit mit domainlist relay_to_domains = @mx_any automatisch für alle Domains, in denen der Server als MX eingetragen ist, Mails zu relayen. Ist Dir so ein Konstrukt auch für Postfix bekannt? Den Nameserver kontrolliere ich zwar auch selbst, von daher könnte ich auch manuell den MX aus den Zonen holen, aber ....
http://www.postfix.org/postconf.5.html#permit_mx_backup Schau dir aber bitte genau den Passus bezüglich der Einstellung an, dass es sich wirklich um einen BACKUP_MX handelt und nicht etwa um den primären MX. Mir persönlich wäre das ein Greuel, schließlich kann ja JEDER auf seinem eigenen DNS-Server eintragen, dass dein Server der Backup MX sei... Dies wird auch gerne gemacht, indem für die Spammerdomain als MX 127.0.0.1 eingetragen wird. :-(( -- 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 schrieb:
Stefan König wrote:
Muss nochmal darauf zurück kommen. ich würde gerne vermeiden, eine riesige Domainliste zu pflegen. Bei Exim hat man ja zB die Möglichkeit mit domainlist relay_to_domains = @mx_any automatisch für alle Domains, in denen der Server als MX eingetragen ist, Mails zu relayen. Ist Dir so ein Konstrukt auch für Postfix bekannt? Den Nameserver kontrolliere ich zwar auch selbst, von daher könnte ich auch manuell den MX aus den Zonen holen, aber ....
http://www.postfix.org/postconf.5.html#permit_mx_backup
Schau dir aber bitte genau den Passus bezüglich der Einstellung an, dass es sich wirklich um einen BACKUP_MX handelt und nicht etwa um den primären MX.
Mir persönlich wäre das ein Greuel, schließlich kann ja JEDER auf seinem eigenen DNS-Server eintragen, dass dein Server der Backup MX sei...
Dies wird auch gerne gemacht, indem für die Spammerdomain als MX 127.0.0.1 eingetragen wird. :-((
Ja der Haken an der Sache ist mir auch eingefallen... Ich neige langsam aber sicher dazu über einen Cronjob mir alle x Minuten eine Liste der gültigen Domains aus den Zonenfiles des Nameservers zu erzeugen. Hm. Man muss nachdenken, was man tun kan! :) -- 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
Stefan König wrote:
http://www.postfix.org/postconf.5.html#permit_mx_backup
Schau dir aber bitte genau den Passus bezüglich der Einstellung an, dass es sich wirklich um einen BACKUP_MX handelt und nicht etwa um den primären MX.
Mir persönlich wäre das ein Greuel, schließlich kann ja JEDER auf seinem eigenen DNS-Server eintragen, dass dein Server der Backup MX sei...
Dies wird auch gerne gemacht, indem für die Spammerdomain als MX 127.0.0.1 eingetragen wird. :-((
Ja der Haken an der Sache ist mir auch eingefallen... Ich neige langsam aber sicher dazu über einen Cronjob mir alle x Minuten eine Liste der gültigen Domains aus den Zonenfiles des Nameservers zu erzeugen. Hm. Man muss nachdenken, was man tun kan! :)
Ist auf jeden Fall sauberer und sicherer. -- 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 schrieb:
Stefan König wrote:
http://www.postfix.org/postconf.5.html#permit_mx_backup
Schau dir aber bitte genau den Passus bezüglich der Einstellung an, dass es sich wirklich um einen BACKUP_MX handelt und nicht etwa um den primären MX.
Mir persönlich wäre das ein Greuel, schließlich kann ja JEDER auf seinem eigenen DNS-Server eintragen, dass dein Server der Backup MX sei...
Dies wird auch gerne gemacht, indem für die Spammerdomain als MX 127.0.0.1 eingetragen wird. :-((
Ja der Haken an der Sache ist mir auch eingefallen... Ich neige langsam aber sicher dazu über einen Cronjob mir alle x Minuten eine Liste der gültigen Domains aus den Zonenfiles des Nameservers zu erzeugen. Hm. Man muss nachdenken, was man tun kan! :)
Ist auf jeden Fall sauberer und sicherer.
Nun ist mir noch ein Haken aufgefallen. Auf den MXen läuft qmail und das scheint (generell oder in dieser Konfiguration) im SMTP Dialog eMails für nicht existierende Konten garnicht abzulehnen! Argh! Nimmt alles an und bounced dann.... Wenn ich recht erinnere, ist das das große qmail Problem und nicht abstellbar..... -- 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
Stefan König wrote:
Sandy Drobic schrieb:
Stefan König wrote:
http://www.postfix.org/postconf.5.html#permit_mx_backup
Schau dir aber bitte genau den Passus bezüglich der Einstellung an, dass es sich wirklich um einen BACKUP_MX handelt und nicht etwa um den primären MX.
Mir persönlich wäre das ein Greuel, schließlich kann ja JEDER auf seinem eigenen DNS-Server eintragen, dass dein Server der Backup MX sei...
Dies wird auch gerne gemacht, indem für die Spammerdomain als MX 127.0.0.1 eingetragen wird. :-((
Ja der Haken an der Sache ist mir auch eingefallen... Ich neige langsam aber sicher dazu über einen Cronjob mir alle x Minuten eine Liste der gültigen Domains aus den Zonenfiles des Nameservers zu erzeugen. Hm. Man muss nachdenken, was man tun kan! :)
Ist auf jeden Fall sauberer und sicherer.
Nun ist mir noch ein Haken aufgefallen. Auf den MXen läuft qmail und das scheint (generell oder in dieser Konfiguration) im SMTP Dialog eMails für nicht existierende Konten garnicht abzulehnen! Argh! Nimmt alles an und bounced dann.... Wenn ich recht erinnere, ist das das große qmail Problem und nicht abstellbar.....
Es gab dafür einen Patch, wenn ich mich recht erinnere. QMail ungepatcht hat in der Tat ohne Patch keine Recipient Validation. :-(( http://www.lifewithqmail.org/lwq.html#smtp-reject Steht bei QMail unter "Advanced Configuration" (^-°) Bei Postfix ist das "Standard Configuration". Grins! Wenn die Struktur aber nicht zu kompliziert ist, wäre es vielleicht einfacher, QMail direkt durch Postfix zu ersetzen. Oder ist das wieder so eine Plesk-Installation? -- 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 schrieb:
Es gab dafür einen Patch, wenn ich mich recht erinnere. QMail ungepatcht hat in der Tat ohne Patch keine Recipient Validation. :-((
http://www.lifewithqmail.org/lwq.html#smtp-reject
Steht bei QMail unter "Advanced Configuration" (^-°) Bei Postfix ist das "Standard Configuration".
Grins! Wenn die Struktur aber nicht zu kompliziert ist, wäre es vielleicht einfacher, QMail direkt durch Postfix zu ersetzen. Oder ist das wieder so eine Plesk-Installation?
Wo kaufst Du Deine Glaskugeln? :) Es ist in der Tat ein Plesk System. Sogar eine aktuelle 8er Version. Der Witz ist, wenn der Mailserver mail.example.com im Plesk deaktiviert ist, dann nimmt der PleskServer die Mails für diese Domain an. Und zwar alle! Wenn der Server aktiviert ist, dann rejected er ordnungsgemäß. Das führt natürlich das Projekt "Backup MX" ad absurdum (und erklärt gleichzeitig, wieso der "alte" Backup enifach blind alles angenommen hat) Ohje :) -- 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
Stefan König wrote:
Sandy Drobic schrieb:
Es gab dafür einen Patch, wenn ich mich recht erinnere. QMail ungepatcht hat in der Tat ohne Patch keine Recipient Validation. :-((
http://www.lifewithqmail.org/lwq.html#smtp-reject
Steht bei QMail unter "Advanced Configuration" (^-°) Bei Postfix ist das "Standard Configuration".
Grins! Wenn die Struktur aber nicht zu kompliziert ist, wäre es vielleicht einfacher, QMail direkt durch Postfix zu ersetzen. Oder ist das wieder so eine Plesk-Installation?
Wo kaufst Du Deine Glaskugeln? :) Es ist in der Tat ein Plesk System. Sogar eine aktuelle 8er Version.
Weil das meiner Erfahrung nach ein häufiger Grund ist, QMail einzusetzen. Warum sonst sollte man einen MTA mit derart herben Macken sonst in einer Produktiv-Umgebung einsetzen?
Der Witz ist, wenn der Mailserver mail.example.com im Plesk deaktiviert ist, dann nimmt der PleskServer die Mails für diese Domain an. Und zwar alle! Wenn der Server aktiviert ist, dann rejected er ordnungsgemäß. Das führt natürlich das Projekt "Backup MX" ad absurdum (und erklärt gleichzeitig, wieso der "alte" Backup enifach blind alles angenommen hat) Ohje :)
Bleargh! Dann wirst du wohl um das Patchen kaum herumkommen. Teste besser, ob die gepatchte Version dann noch mit dem Plesk noch läuft. -- 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 schrieb:
In deinem Fall wäre das relay_domains für den Backup MX. Etwas tückisch in diesem Fall ist, dass die Voreinstellung auf $mydestination lautet mit dem Ergebnis, dass alle Domains in $mydestination lokale Domains sind, aber alle SUBdomains von $mydestination automatisch zu relay_domains werden.
Hi Sandy, muss das nochmal hoch holen, bin mal wieder am experimentieren. Habe hier jetzt mal testweise ein System, dass einen mailproxy darstellen soll, als MX für eine Domain example.com eingetragen. Über relay_domains teile ich Postfix mit, dass er für example.com relayen soll. Weiterhin smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unverified_recipient Das logischerweise dumme an der Sache ist, dass er den Empfänger verifizieren will und dazu den MX in der zuständigen Zone ausliest. Das ist ja folglich er selbst und ich erhalte natürlich ein "Recipient address rejected: undeliverable address: mail for example.com loops back to myself;" Finde in der Doku leider nichts, was darauf schließen lässt, dass ich explizit festlegen kann, dass er mails für example.com auch direkt bei example.com verifiziert/ausliefert und nicht den zuständigen MX fragt. Weisst Du das aus dem stegreif? Danke :) -- 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
Stefan König schrieb:
Sandy Drobic schrieb:
In deinem Fall wäre das relay_domains für den Backup MX. Etwas tückisch in diesem Fall ist, dass die Voreinstellung auf $mydestination lautet mit dem Ergebnis, dass alle Domains in $mydestination lokale Domains sind, aber alle SUBdomains von $mydestination automatisch zu relay_domains werden.
Hi Sandy,
muss das nochmal hoch holen, bin mal wieder am experimentieren. Habe hier jetzt mal testweise ein System, dass einen mailproxy darstellen soll, als MX für eine Domain example.com eingetragen. Über relay_domains teile ich Postfix mit, dass er für example.com relayen soll.
Weiterhin smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unverified_recipient
Das logischerweise dumme an der Sache ist, dass er den Empfänger verifizieren will und dazu den MX in der zuständigen Zone ausliest. Das ist ja folglich er selbst und ich erhalte natürlich ein "Recipient address rejected: undeliverable address: mail for example.com loops back to myself;"
Finde in der Doku leider nichts, was darauf schließen lässt, dass ich explizit festlegen kann, dass er mails für example.com auch direkt bei example.com verifiziert/ausliefert und nicht den zuständigen MX fragt.
Weisst Du das aus dem stegreif?
Danke :)
Um mir meine Frage fast selbst zu beantworten: transport_maps = hash:/etc/postfix/transport ? -- 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
Stefan König schrieb:
Stefan König schrieb:
Sandy Drobic schrieb:
In deinem Fall wäre das relay_domains für den Backup MX. Etwas tückisch in diesem Fall ist, dass die Voreinstellung auf $mydestination lautet mit dem Ergebnis, dass alle Domains in $mydestination lokale Domains sind, aber alle SUBdomains von $mydestination automatisch zu relay_domains werden.
Hi Sandy,
muss das nochmal hoch holen, bin mal wieder am experimentieren. Habe hier jetzt mal testweise ein System, dass einen mailproxy darstellen soll, als MX für eine Domain example.com eingetragen. Über relay_domains teile ich Postfix mit, dass er für example.com relayen soll.
Weiterhin smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unverified_recipient
Das logischerweise dumme an der Sache ist, dass er den Empfänger verifizieren will und dazu den MX in der zuständigen Zone ausliest. Das ist ja folglich er selbst und ich erhalte natürlich ein "Recipient address rejected: undeliverable address: mail for example.com loops back to myself;"
Finde in der Doku leider nichts, was darauf schließen lässt, dass ich explizit festlegen kann, dass er mails für example.com auch direkt bei example.com verifiziert/ausliefert und nicht den zuständigen MX fragt.
Weisst Du das aus dem stegreif?
Danke :)
Um mir meine Frage fast selbst zu beantworten: transport_maps = hash:/etc/postfix/transport ?
Da hab ich mich wohl zu früh gefreut :) postmap -q example.com spuckt zwar smtp:[zielserver.example.com] aus, aber postfix ignoriert es mal ganz frech und behauptet nach wie vor, es gäbe einen loop auf sich selbst. hier mal meine postconf -n, steh mal wieder auf dem schlauch. address_verify_map = btree:/etc/postfix/address_verify address_verify_negative_cache = yes address_verify_negative_expire_time = 3d address_verify_negative_refresh_time = 3h address_verify_poll_count = 3 address_verify_poll_delay = 3s address_verify_positive_expire_time = 31d address_verify_positive_refresh_time = 7d address_verify_sender = $double_bounce_sender alias_maps = hash:/etc/aliases biff = no canonical_maps = hash:/etc/postfix/canonical command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/lib/postfix debug_peer_level = 2 defer_transports = disable_dns_lookups = no disable_mime_output_conversion = no html_directory = /usr/share/doc/packages/postfix/html inet_interfaces = all inet_protocols = all mail_owner = postfix 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_domains = masquerade_exceptions = root message_size_limit = 10240000 milter_default_action = tempfail mydestination = localhost, localhost.$mydomain, spamhole.example.com mydomain = spamhole.example.com myhostname = spamhole.example.com mynetworks = 127.0.0.0/8 newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/packages/postfix/README_FILES relay_domains = example.com relayhost = 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_client_restrictions = smtpd_helo_required = no smtpd_helo_restrictions = smtpd_milters = unix:/var/spool/MIMEDefang/mimedefang.sock smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, permit_mynetworks, reject_unauth_destination, reject_unverified_recipient, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, check_helo_access hash:/etc/postfix/block_helo_own_ip, check_sender_mx_access cidr:/etc/postfix/sender_mx_blocked reject_rbl_client ix.dnsbl.manitu.net, reject_unknown_sender_domain smtpd_sasl_auth_enable = no smtpd_sender_restrictions = hash:/etc/postfix/access 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 -- 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
Stefan König schrieb:
Stefan König schrieb:
Stefan König schrieb:
Sandy Drobic schrieb:
In deinem Fall wäre das relay_domains für den Backup MX. Etwas tückisch in diesem Fall ist, dass die Voreinstellung auf $mydestination lautet mit dem Ergebnis, dass alle Domains in $mydestination lokale Domains sind, aber alle SUBdomains von $mydestination automatisch zu relay_domains werden.
Hi Sandy,
muss das nochmal hoch holen, bin mal wieder am experimentieren. Habe hier jetzt mal testweise ein System, dass einen mailproxy darstellen soll, als MX für eine Domain example.com eingetragen. Über relay_domains teile ich Postfix mit, dass er für example.com relayen soll.
Weiterhin smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unverified_recipient
Das logischerweise dumme an der Sache ist, dass er den Empfänger verifizieren will und dazu den MX in der zuständigen Zone ausliest. Das ist ja folglich er selbst und ich erhalte natürlich ein "Recipient address rejected: undeliverable address: mail for example.com loops back to myself;"
Finde in der Doku leider nichts, was darauf schließen lässt, dass ich explizit festlegen kann, dass er mails für example.com auch direkt bei example.com verifiziert/ausliefert und nicht den zuständigen MX fragt.
Weisst Du das aus dem stegreif?
Danke :)
Um mir meine Frage fast selbst zu beantworten: transport_maps = hash:/etc/postfix/transport ?
Da hab ich mich wohl zu früh gefreut :) postmap -q example.com spuckt zwar smtp:[zielserver.example.com] aus, aber postfix ignoriert es mal ganz frech und behauptet nach wie vor, es gäbe einen loop auf sich selbst.
hier mal meine postconf -n, steh mal wieder auf dem schlauch. [...]
sorry wenn ich hier die Liste zu-spamme, aber vielleicht ist es für den ein oder anderen dennoch interessant. Bin dem Problem auf der Spur, postfix meldet keinen loop wenn ich zB an vorname.nachname@example.com versende. Dann stellt er brav den in der transport definierten next hop zu. sende ich allerdings (wie die ganze zeit) an admin@example.com, dann meldet er wieder den loop. Das ist mir jettz völlig unverständlich, da es keinen alias "admin" auf dem system gibt (auch keinen virtual). Bis auf diese Adresse scheint(!) alles zu funktionieren, möchte aber erst wissen, wieso er das für einen loop auf sich selbst hält. Hat diesbezüglich jemand eine Idee? Danke! -- 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 -
Michael Raab -
Sandy Drobic -
Stefan König