Hallo zusammen,
ich habe von meinem Hoster eine Abuse-Message bekommen, die meinen Server betrifft und habe im Log die Stelle gefunden, um die es geht. Offenbar hat mein Server eine Mail an bounce@gmx.net geschickt, was GMX dann offenbar gemeldet hat. Ich bin kein Experte und habe da gerade ein Problem zu verstehen, was genau da passiert ist:
*** Feb 8 13:44:40 mail postfix/smtpd[22650]: warning: hostname 43392.vm.hostglobal.ws does not resolve to address 109.237.100.107 Feb 8 13:44:40 mail postfix/smtpd[22650]: connect from unknown[109.237.100.107] Feb 8 13:44:40 mail postgrey[739]: action=pass, reason=triplet found, client_name=unknown, client_address=109.237.100.107/32, sender=bounce@gmx.net, recipient=XXX(nicht existentes Postfach) Feb 8 13:44:40 mail postfix/smtpd[22650]: D9AFE421BD8: client=unknown[109.237.100.107] Feb 8 13:44:40 mail postfix/cleanup[22804]: D9AFE421BD8: message-id=<> Feb 8 13:44:40 mail postfix/qmgr[1358]: D9AFE421BD8: from=bounce@gmx.net, size=2129, nrcpt=1 (queue active) Feb 8 13:44:40 mail postfix/lmtp[22805]: D9AFE421BD8: to=XXX(nicht existentes Postfach), relay=127.0.0.1[127.0.0.1]:24, delay=0.24, delays=0.22/0.01/0.01/0.01, dsn=5.1.1, status=bounced (host 127.0.0.1[127.0.0.1] said: 550 5.1.1 <XXX(nicht existentes Postfach)> User doesn't exist: XXX(nicht existentes Postfach) (in reply to RCPT TO command)) Feb 8 13:44:40 mail postfix/cleanup[22804]: F1670421EC3: message-id=20220208124440.F1670421EC3@XXXmailserver Feb 8 13:44:40 mail postfix/bounce[22807]: D9AFE421BD8: sender non-delivery notification: F1670421EC3 Feb 8 13:44:40 mail postfix/qmgr[1358]: F1670421EC3: from=<>, size=4333, nrcpt=1 (queue active) Feb 8 13:44:40 mail postfix/qmgr[1358]: D9AFE421BD8: removed Feb 8 13:44:41 mail postfix/smtpd[22650]: disconnect from unknown[109.237.100.107] ehlo=1 mail=1 rcpt=1 bdat=1 quit=1 commands=5 Feb 8 13:44:41 mail postfix/smtp[22808]: F1670421EC3: to=bounce@gmx.net, relay=mx00.emig.gmx.net[212.227.15.9]:25, delay=0.51, delays=0/0.01/0.18/0.32, dsn=2.0.0, status=sent (250 Requested mail action okay, completed: id=1Mvr6b-1o96Xa0lOx-00snH3) Feb 8 13:44:41 mail postfix/qmgr[1358]: F1670421EC3: removed ***
1) Offenbar versucht ein unbekannter nicht-GMX-Server als angeblicher "bounce@gmx.net" eine Mail an ein Postfach auf meinem Server einzuliefern, das nicht existiert.
2) Mein Mailserver gibt daraufhin den Fehler 550 5.1.1 zurück.
3) Ich vermute das Problem entsteht in der vorletzten Zeile. Verstehe ich das richtig, dass mein Server eine Rückmeldung (Empfänger existiert nicht) an bounce@gmx.net versendet? Dies sollte er vermutlich unter diesen Umständen nicht tun. Gehe ich richtig in der Annahme, dass ich meinen Server so umkonfigurieren muss, dass er die Kommunikation wegen des warnings in Zeile1 besser umgehend beenden sollte, um die Mail an bounce@gmx.net zu verhindern? Welches wäre die richtige Anweisung dafür in der main.cf? Oder ist es eine andere Stelle, an der mein Server falsch reagiert?
Vielen Dank vorab! Gruß Markus
Papierkorb wrote:
Offenbar versucht ein unbekannter nicht-GMX-Server als angeblicher "bounce@gmx.net" eine Mail an ein Postfach auf meinem Server einzuliefern, das nicht existiert.
Genau, offenbar ein Spammer von Hostglobal, aus dem Netz (109.237.96.0 - 109.237.103.255)nehm ich gar nix an.
Mein Mailserver gibt daraufhin den Fehler 550 5.1.1 zurück.
Nein. Dein Mailserver nimmt die Mail entgegen und beim lokalen verteilen (lmtp) tritt dieser Fehler auf.
Ich vermute das Problem entsteht in der vorletzten Zeile. Verstehe ich das richtig, dass mein Server eine Rückmeldung (Empfänger existiert nicht) an bounce@gmx.net versendet?
Genau. Backscatter.
Dies sollte er vermutlich unter diesen Umständen nicht tun. Gehe ich richtig in der Annahme, dass ich meinen Server so umkonfigurieren muss, dass er die Kommunikation wegen des warnings in Zeile1 besser umgehend beenden sollte, um die Mail an bounce@gmx.net zu verhindern? Welches wäre die richtige Anweisung dafür in der main.cf?
reject_unauth_destination an geigneter Stelle. Wie sehen denn deine smtpd_recipient_restrictions (bzw smtpd_client_restrictions etc) aus?
Am 09.02.2022 um 17:35 schrieb Juergen Dollinger:
Papierkorb wrote:
Offenbar versucht ein unbekannter nicht-GMX-Server als angeblicher "bounce@gmx.net" eine Mail an ein Postfach auf meinem Server einzuliefern, das nicht existiert.
Genau, offenbar ein Spammer von Hostglobal, aus dem Netz (109.237.96.0 - 109.237.103.255)nehm ich gar nix an.
Mein Mailserver gibt daraufhin den Fehler 550 5.1.1 zurück.
Nein. Dein Mailserver nimmt die Mail entgegen und beim lokalen verteilen (lmtp) tritt dieser Fehler auf.
Ich vermute das Problem entsteht in der vorletzten Zeile. Verstehe ich das richtig, dass mein Server eine Rückmeldung (Empfänger existiert nicht) an bounce@gmx.net versendet?
Genau. Backscatter.
Dies sollte er vermutlich unter diesen Umständen nicht tun. Gehe ich richtig in der Annahme, dass ich meinen Server so umkonfigurieren muss, dass er die Kommunikation wegen des warnings in Zeile1 besser umgehend beenden sollte, um die Mail an bounce@gmx.net zu verhindern? Welches wäre die richtige Anweisung dafür in der main.cf?
reject_unauth_destination an geigneter Stelle. Wie sehen denn deine smtpd_recipient_restrictions (bzw smtpd_client_restrictions etc) aus?
Hallo nochmal,
ich habe mich nochmal ein wenig mit der Thematik beschäftigt und hoffentlich eine Lösung gefunden:
Ich habe nun nach dem "permit_mynetworks" ein "reject_unverified_recipient" hinzugefügt, und dem Postfix eine verify-Datenbank gegeben. Das Prozedere habe ich aus dem Postfix-Buch Seiten 331-335 "Dynamische Empfänger-Verifizierung" übernommen. Es scheint auch zu laufen, wie beabsichtigt - Mails an existierende Empfänger kommen rein, Mails an nicht existierende Empfänger werden mit einer 5xx-Meldung rejected. Eine Bounce-Mail geht nicht mehr raus. So weit, so gut!
Zwei Fragen hätte ich noch: 1) Macht es dennoch Sinn ein "reject_unauth_destination" zu setzen? Wenn ja, für welchen Fall?
2) Du schriebst, dass Du bestimmte IP-Bereiche generell blockst. Finde ich gut, weil meine RBLs müssen ganz schön viel rausfiltern und es wäre ja besser, wenn man ausserdem noch bekannte Spamschleuder-Netze von vornherein blocken würde. Gibt es dort mehr oder weniger öffentliche Vorlagen, oder hast Du die selbst recherchiert?
Vielen Dank vorab & Gruß Markus
Ich schrieb:
reject_unauth_destination an geigneter Stelle.
Ich muss mich da wohl korrigieren. Ich dachte immer mein postfix lehnt Mails an nicht existente Benutzer wegen reject_unauth_destination ab, aber da wird nur die Domain geprueft wie man in der Doku nachlesen kann.
Waere nett zu wissen, warum das bei mir trotzdem funktioniert. reject_unverified_recipient hab ich nirgendwo explizit gesetzt.
Hallo Jürgen,
On 11.02.22 01:44, Juergen Dollinger wrote:
Ich muss mich da wohl korrigieren. Ich dachte immer mein postfix lehnt Mails an nicht existente Benutzer wegen reject_unauth_destination ab, aber da wird nur die Domain geprueft wie man in der Doku nachlesen kann.
Waere nett zu wissen, warum das bei mir trotzdem funktioniert. reject_unverified_recipient hab ich nirgendwo explizit gesetzt.
hängt natürlich von Deiner Config ab. Aber wenn Postfix in den üblichen Maps wie z. B. virtual_alias_maps eine Empfängeradresse 'foo@example.com' nicht findet und auch kein catch-all-Eintrag vorhanden ist, wird die Mail abgewiesen.
Vermutlich hast Du in Deinem Log Einträge von abgewiesenen Mails wie:
550 5.1.1 foo@example.com: Recipient address rejected: User unknown in local recipient table 550 5.1.1 foo@example.com: Recipient address rejected: User unknown in virtual mailbox table 550 5.1.1 foo@example.com: Recipient address rejected: User unknown in virtual alias table 550 5.1.1 foo@example.com: Recipient address rejected: User unknown in relay recipient table
Das Verhalten ist beispielsweise für lokale Empfänger ist hier beschrieben:
http://www.postfix.org/LOCAL_RECIPIENT_README.html
"If a local username or address is not listed in $local_recipient_maps, then the Postfix SMTP server will reject the address with "User unknown in local recipient table"."
oder für Virtual Alias/Mailbox Domains:
http://www.postfix.org/VIRTUAL_README.html
"[...] the /etc/postfix/virtual file contains the virtual aliases. [...] Mail for all other addresses in example.com is rejected with the error message "User unknown"."
"[...] The virtual_mailbox_maps parameter specifies the lookup table with all valid recipient addresses. [...] other mail for example.com is rejected with "User unknown" by the Postfix SMTP server."
Viele Grüße Markus
Markus Winkler wrote:
Alles was du schreibst stimmt offenbar.
http://www.postfix.org/LOCAL_RECIPIENT_README.html http://www.postfix.org/VIRTUAL_README.html
So viele READMEs, ich hatte mich auf ADDRESS_VERIFICATION_README.html gestuerzt ohne recht schlau draus zu werden. Darauf war ich gestossen weil 'Papierkorb' von reject_unverified_recipient sprach.
Bleibt die urspruengliche Frage warum das bei 'Papierkorb' nicht funktioniert hat.
Auf jeden Fall hab ich in dem thread einiges gelernt.
Hi,
So viele READMEs, ich hatte mich auf ADDRESS_VERIFICATION_README.html
gestuerzt ohne recht schlau draus zu werden. Darauf war ich gestossen weil 'Papierkorb' von reject_unverified_recipient sprach.
Bleibt die urspruengliche Frage warum das bei 'Papierkorb' nicht
funktioniert hat.
Ohne es jetzt noch mal quer gelesen zu haben, ich glaube Papierkorb hat alle conditions in den recipient restrictions drin.
Das ist dann ganz hinten in der Kette der Abarbeitung versammelt. Wird ja manchmal empfohlen um das detailreichste Log zu haben.
Bin ich anderer Meinung, aus verschiedenen Gründen. Einer davon ist das evtl. weiter vorne unwillentlich die Mail schon ein OK erfährt.
# Postfix verarbeitet die restrictions (Beschränkungsphasen) in folgender Reihenfolge: # smtpd_client_restrictions # smtpd_helo_restrictions # smtpd_sender_restrictions # smtpd_recipient_restrictions # smtpd_data_restrictions
Greets, Ludi
On 12.02.2022 09:35, Ludi Cree wrote:
# Postfix verarbeitet die restrictions (Beschränkungsphasen) in folgender Reihenfolge: # smtpd_client_restrictions # smtpd_helo_restrictions # smtpd_sender_restrictions # smtpd_recipient_restrictions # smtpd_data_restrictions
das geht mit dem SMTP-Protokoll einher ...
smtpd_client_restriction greift beim Verbindungsaufbau ... smtpd_helo_restriction greift beim 'HELO' bzw. 'EHLO' smtpd_sender_restriction greift beim 'MAIL FROM' smtpd_recipient_restriction greift beim 'RCPT TO' und smtpd_data_restriction greift beim 'DATA'
in dem Zusammenhang muss man auch folgendes Setting, welches per default auf yes gesetzt ist bringen ...
www.postfix.org/postconf.5.html#smtpd_delay_reject
ich hab das bei mir auf 'no' gesetzt; mich juckt es nicht im geringsten, den Empfänger (die Empfangsadresse) zu kennen, wenn ich bereits vorher weiß, dass der Absender eine SPAM-Schleuder ist;
Grüße, Walter
Walter H. wrote:
in dem Zusammenhang muss man auch folgendes Setting, welches per default auf yes gesetzt ist bringen ...
www.postfix.org/postconf.5.html#smtpd_delay_reject
ich hab das bei mir auf 'no' gesetzt; mich juckt es nicht im geringsten, den Empfänger (die Empfangsadresse) zu kennen, wenn ich bereits vorher weiß, dass der Absender eine SPAM-Schleuder ist;
Hab ich auf yes gesetzt, denn ein Spammer darf sich ruhig Muehe geben um zu erfahren, dass mir schon seine IP nicht gefallen hat. Ausserdem langweilt sich mein Server sonst :) Aber anfangs hat mich das ziemlich verwirrt. Aus dem gleichen Grund hab ich den gld (greylisting) ueberredet DEFER statt defer_if_permit zurueckzuliefern.
On 11.02.22 22:35, Juergen Dollinger wrote:
Bleibt die urspruengliche Frage warum das bei 'Papierkorb' nicht funktioniert hat.
Da kann man nur raten, weil wir nach wie vor nicht die _komplette_ Config und auch nicht die eingesetzte Postfix-Version kennen.
Die zu empfangenden Domains könnten ja beispielsweise per 'relay_domains' behandelt werden. Wenn in diesem Szenario keine Map mit gültigen Empfängern definiert ist (relay_recipient_maps - und per default ist dieser Parameter leer), nimmt Postfix Mails für _jede_ denkbare Mailadresse dieser Domain an.
Erst beim Weiterreichen der Mail (LMTP an [127.0.0.1]:24) wird dann festgestellt, dass es diesen Empfänger gar nicht gibt:
Feb 8 13:44:40 mail postfix/lmtp[22805]: D9AFE421BD8: to=XXX(nicht existentes Postfach), relay=127.0.0.1[127.0.0.1]:24, delay=0.24, delays=0.22/0.01/0.01/0.01, dsn=5.1.1, status=bounced (host 127.0.0.1[127.0.0.1] said: 550 5.1.1 <XXX(nicht existentes Postfach)> User doesn't exist: XXX(nicht existentes Postfach) (in reply to RCPT TO command))
und ein Bounce generiert (was man eben nicht will).
Das (oder auch eine vergleichbare mit z. B. Virtual Mailbox Domains) wäre m. E. eine durchaus denkbare Konstellation auf Markus' Server, die zu dem ursprünglichen Verhalten geführt haben könnte. Aber wie gesagt: alles reine Spekulation. ;-)
Schönes WE und viele Grüße Markus
Am 12.02.2022 um 10:41 schrieb Markus Winkler:
On 11.02.22 22:35, Juergen Dollinger wrote:
Bleibt die urspruengliche Frage warum das bei 'Papierkorb' nicht funktioniert hat.
Da kann man nur raten, weil wir nach wie vor nicht die _komplette_ Config und auch nicht die eingesetzte Postfix-Version kennen.
Die zu empfangenden Domains könnten ja beispielsweise per 'relay_domains' behandelt werden. Wenn in diesem Szenario keine Map mit gültigen Empfängern definiert ist (relay_recipient_maps - und per default ist dieser Parameter leer), nimmt Postfix Mails für _jede_ denkbare Mailadresse dieser Domain an.
Erst beim Weiterreichen der Mail (LMTP an [127.0.0.1]:24) wird dann festgestellt, dass es diesen Empfänger gar nicht gibt:
Feb 8 13:44:40 mail postfix/lmtp[22805]: D9AFE421BD8: to=XXX(nicht existentes Postfach), relay=127.0.0.1[127.0.0.1]:24, delay=0.24, delays=0.22/0.01/0.01/0.01, dsn=5.1.1, status=bounced (host 127.0.0.1[127.0.0.1] said: 550 5.1.1 <XXX(nicht existentes Postfach)> User doesn't exist: XXX(nicht existentes Postfach) (in reply to RCPT TO command))
und ein Bounce generiert (was man eben nicht will).
Das (oder auch eine vergleichbare mit z. B. Virtual Mailbox Domains) wäre m. E. eine durchaus denkbare Konstellation auf Markus' Server, die zu dem ursprünglichen Verhalten geführt haben könnte. Aber wie gesagt: alles reine Spekulation. ;-)
Schönes WE und viele Grüße Markus
Servus zusammen,
ja, genauso war es: bei mir im Postfix sind lediglich die Relay-Domains und die virtuellen Aliase definiert, nicht die gültigen Empfänger / Postfächer. Genau deshalb kam es zu dem Problem. Gut kombiniert, Watson! ;-) Meine Postfächer sind lediglich im Dovecot angelegt und ich hab natürlich keine Lust die gleichen Daten doppelt in Postfix zu pflegen. Nun halte ich mich gerne an das Postfix-Buch, und dort stieß ich dann auf S.331 (Dynamische Empfänger-Verifzierung), wo leicht verständlich die Nutzung von reject_unverified_recipients beschrieben wird. Für meine config erschien mir das ziemlich passend. Für das Log und vermeintlich menschliche Absender kann man dann noch individuelle Reject-Codes und -Messages definieren - was will man mehr?!
Danke für euren Input und eure Hilfestellung!
Euch ein schönes Wochenende!
Es grüßt Papierkorbs Markus
Hallo Markus,
On 09.02.22 08:52, Papierkorb wrote:
Offenbar versucht ein unbekannter nicht-GMX-Server als angeblicher "bounce@gmx.net" eine Mail an ein Postfach auf meinem Server einzuliefern, das nicht existiert.
Genau.
Mein Mailserver gibt daraufhin den Fehler 550 5.1.1 zurück.
Ja, aber nicht an den einliefernden Client - das ist das Problem. ;-)
Ich vermute das Problem entsteht in der vorletzten Zeile. Verstehe ich das richtig, dass mein Server eine Rückmeldung (Empfänger existiert nicht) an bounce@gmx.net versendet?
Die Vermutung ist richtig, Dein Server produziert Backscatter ...
Dies sollte er vermutlich unter diesen Umständen nicht tun.
... und das sollte er unter _gar keinen_ Umständen tun. ;-)
Gehe ich richtig in der Annahme, dass ich meinen Server so umkonfigurieren muss, dass er die Kommunikation wegen des warnings in Zeile1 besser umgehend beenden sollte, um die Mail an bounce@gmx.net zu verhindern?
Auch da liegst Du richtig.
Welches wäre die richtige Anweisung dafür in der main.cf? Oder ist es eine andere Stelle, an der mein Server falsch reagiert?
Schicke mal bitte die Ausgaben von
- postconf -n - postconf -M
Dann weiß man, wie Deine Configs aussehen und könnte helfen. ;-)
Eigentlich geht's aber schon damit los:
Feb 8 13:44:40 mail postfix/smtpd[22650]: connect from unknown[109.237.100.107]
So jemand darf von vornherein gar keine Mail einliefern. Punkt. ;-)
Viele Grüße Markus
Am 09.02.2022 um 18:40 schrieb Markus Winkler:
Schicke mal bitte die Ausgaben von
- postconf -n
- postconf -M
smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_sasl_authenticated, permit_tls_clientcerts, permit_mynetworks, check_sender_access hash:/etc/postfix/absender_kontrolle, check_policy_service inet:127.0.0.1:10023, reject_rbl_client b.barracudacentral.org, reject_rbl_client ix.dnsbl.manitu.net, reject_rbl_client bl.spamcop.net, reject_rbl_client ubl.unsubscore.com, reject_unauth_destination, permit
Feb 8 13:44:40 mail postfix/smtpd[22650]: connect from unknown[109.237.100.107]
So jemand darf von vornherein gar keine Mail einliefern. Punkt. ;-)
Welche Maßnahmen könntest Du dazu empfehlen?
Gruß, Markus
Papierkorb wrote:
smtpd_recipient_restrictions = check_sender_access hash:/etc/postfix/absender_kontrolle, reject_unauth_destination, permit
Hast du in /etc/postfix/absender_kontrolle sowas wie bounce@gmx.net OK stehen? Sonst muesste doch reject_unauth_destination wirken.
Hallo Markus,
On 10.02.22 08:55, Papierkorb wrote:
smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_sasl_authenticated, permit_tls_clientcerts, permit_mynetworks, check_sender_access hash:/etc/postfix/absender_kontrolle, check_policy_service inet:127.0.0.1:10023, reject_rbl_client b.barracudacentral.org, reject_rbl_client ix.dnsbl.manitu.net, reject_rbl_client bl.spamcop.net, reject_rbl_client ubl.unsubscore.com, reject_unauth_destination, permit
Feb 8 13:44:40 mail postfix/smtpd[22650]: connect from unknown[109.237.100.107]
So jemand darf von vornherein gar keine Mail einliefern. Punkt. ;-)
Welche Maßnahmen könntest Du dazu empfehlen?
wie in den anderen Antworten schon genannt, würde ich 'reject_unknown_client_hostname' empfehlen.
In einem Setup vor langer Zeit war ich zunächst sehr vorsichtig und hatte das erst mal mit:
warn_if_reject reject_unknown_client_hostname
eine Weile beobachtet. Schließlich habe ich das aber doch aktiviert, da ich mittlerweile Mails von solchen Systemen einfach nichts mehr annehmen will. Wer DNS nicht korrekt einstellt, hat keine Mails zu versenden. IMHO. ;-) (Und für die allerseltensten Ausnahmen kann man ja immer noch eine individuelle Whitelist führen. ;-))
Das ist aber immer eine sehr individuelle Sache. Es gibt Umgebungen, da kann man nicht ganz so hart rangehen. Dann könnte man ggf. den Einsatz von Policy Daemons in Betracht ziehen, die solche Checks oft ebenfalls durchführen, das Ergebnis aber nicht als alleiniges k.o.-Kriterium werten, sondern zusammen mit anderen Checks berücksichtigen. Aus diesem Grund verwende ich übrigens auch die Blacklists (wie oben in Deiner Config) nicht mehr direkt in den Restrictions, sondern nur noch mit Policy Daemons - ein Server ist schnell mal unverschuldet auf eine Blacklist geraten und wird dann nicht gleich _nur_ deswegen rejected.
Aber wie gesagt: Das ist ganz klar eine Ermessensfrage.
Der von Jürgen erwähnte, nicht ganz so harte Check 'reject_unknown_reverse_client_hostname' bringt aus _meiner_ Sicht übrigens nicht so dolle viel, weil eben doch die meisten Hoster irgendeinen(!) Dummy-PTR-Record für ihre ganzen IP-Adressen setzen. Damit schadet dieser Check zwar nicht, bringt aber auch keine entscheidende Verbesserung. IMHO. ;-)
Dazu noch eine Anmerkung:
- Macht es dennoch Sinn ein "reject_unauth_destination" zu setzen? Wenn ja, für welchen Fall?
Aus meiner Sicht: ja. Weil: Damit werden unberechtigte Clients mit Mails an Domains, für die der Server nicht zuständig ist, gleich rejected und man spart sich weitere Prüfungen.
Viele Grüße Markus
Markus Winkler wrote:
wie in den anderen Antworten schon genannt, würde ich 'reject_unknown_client_hostname' empfehlen.
Ich hab da mal drueber nachgedacht und reject_unknown_client_hostname ne Chance gegeben. In der Tat wird noch mehr Muell dadurch abgelehnt obwohl das meiste noch an den nachfolgenden checks gescheitert waere.
Positiv ist mir das bei 185.173.176.123 aufgefallen, was definitif ein Spammer war, inzwischen eh auf meiner persoenlichen blacklist.
Aber einen hab ich der dran scheitert wo ich mir nicht sicher bin ob das ein Spammer ist: from=no-reply@email-europa.com ipadresse: 185.151.31.123 123.31.151.185.in-addr.arpa domain name pointer mail.email-europa.eu. mail.email-europa.eu has address 103.224.182.242 aber: mail.email-europa.com has address 185.151.31.123
Und weil DNS Probleme nur einen temporaeren SMTP Fehler gibt, probierts der immer wieder.
Mal sehn wer zuerst die Geduld verliert :)
Der von Jürgen erwähnte, nicht ganz so harte Check 'reject_unknown_reverse_client_hostname' bringt aus _meiner_ Sicht übrigens nicht so dolle viel, weil eben doch die meisten Hoster irgendeinen(!) Dummy-PTR-Record für ihre ganzen IP-Adressen setzen. Damit schadet dieser
Welcher hoster hat nen Dummy-PTR-Record der nicht wieder zurueck aufloest? Waer ja mal ne einfache Anti-Spam Massnahme. Wenns der hoster macht dann klappt das meist besser als beim Spammer.
Hi,
Feb 8 13:44:40 mail postfix/smtpd[22650]: warning: hostname 43392.vm.hostglobal.ws does not resolve to address 109.237.100.107 Feb 8 13:44:40 mail postfix/smtpd[22650]: connect from unknown[109.237.100.107] Feb 8 13:44:40 mail postgrey[739]: action=pass,
Zunächst mal wäre der mit reject_unknown_client_hostname gar nicht erst durchgekommen. Würde ich empfehlen in den client restrictions zu setzen.
Dann:
/hostglobal.plus/ REJECT Spam /hostglobal.ws/ REJECT Spam
in pcre header checks.
Ich garantiere dir du verpasst nichts. Der Laden hat m.E. keinen einzigen nicht-kriminellen Kunden.
Greets, Ludi
Ludi Cree wrote:
Hi,
Feb 8 13:44:40 mail postfix/smtpd[22650]: warning: hostname 43392.vm.hostglobal.ws does not resolve to address 109.237.100.107 Feb 8 13:44:40 mail postfix/smtpd[22650]: connect from unknown[109.237.100.107] Feb 8 13:44:40 mail postgrey[739]: action=pass,
Zunächst mal wäre der mit reject_unknown_client_hostname gar nicht erst durchgekommen. Würde ich empfehlen in den client restrictions zu setzen.
Warum postfix oft schreibt "connect from unknown", obwohl die IP im DNS aufloest, so auch hier (109.237.100.107 loest zu 43392.vm.hostglobal.ws auf), versteh ich auch nicht. So haette reject_unknown_client_hostname hier nicht gegriffen. Darueber hinaus halte ich reject_unknown_client_hostname fuer eine zu starke Forderung und verwende selbst nur reject_unknown_reverse_client_hostname.
10.02.22, 15:16 +0100, Juergen Dollinger:
Ludi Cree wrote:
Hi,
Feb 8 13:44:40 mail postfix/smtpd[22650]: warning: hostname 43392.vm.hostglobal.ws does not resolve to address 109.237.100.107 Feb 8 13:44:40 mail postfix/smtpd[22650]: connect from unknown[109.237.100.107] Feb 8 13:44:40 mail postgrey[739]: action=pass,
Zunächst mal wäre der mit reject_unknown_client_hostname gar nicht erst durchgekommen. Würde ich empfehlen in den client restrictions zu setzen.
Warum postfix oft schreibt "connect from unknown", obwohl die IP im DNS aufloest, so auch hier (109.237.100.107 loest zu 43392.vm.hostglobal.ws auf), versteh ich auch nicht.
Weil die Vorwärtsauflösung dieses Namens nicht wieder dieselbe IP zurück gibt, sondern eine andere:
| $ host 109.237.100.107 | 107.100.237.109.in-addr.arpa domain name pointer 43392.vm.hostglobal.ws. | $ host 43392.vm.hostglobal.ws | 43392.vm.hostglobal.ws has address 109.237.96.112
109.237.100.107 <> 109.237.96.112
So haette reject_unknown_client_hostname hier nicht gegriffen.
Doch, wegen "3)" aus postconf(5):
reject_unknown_client_hostname (with Postfix < 2.3: reject_unknown_client) Reject the request when 1) the client IP address->name mapping fails, or 2) the name->address mapping fails, or 3) the name->address mapping does not match the client IP address. This is a stronger restriction than the reject_unknown_reverse_client_hostname feature, which triggers only under condition 1) above.
Hi,
ich sehe mit reject_unknown_client_hostname praktisch keine false positives auch über eine lange Zeit.
Wenn postfix schreibt connect from unknown greift diese condition.
Die eingeschränkte reverse Variante halte ich für zu schwach.
Aber jeder nach seinem Mailaufkommen.
Greets, Ludi
-----Ursprüngliche Nachricht----- Von: postfix-users postfix-users-bounces+ludicree=gmail.com@de.postfix.org Im Auftrag von Juergen Dollinger Gesendet: Donnerstag, 10. Februar 2022 15:16 An: postfix-users@de.postfix.org Betreff: Re: Verständnisfrage
Ludi Cree wrote:
Hi,
Feb 8 13:44:40 mail postfix/smtpd[22650]: warning: hostname 43392.vm.hostglobal.ws does not resolve to address 109.237.100.107 Feb 8 13:44:40 mail postfix/smtpd[22650]: connect from unknown[109.237.100.107] Feb 8 13:44:40 mail postgrey[739]: action=pass,
Zunächst mal wäre der mit reject_unknown_client_hostname gar nicht erst durchgekommen. Würde ich empfehlen in den client restrictions zu
setzen.
Warum postfix oft schreibt "connect from unknown", obwohl die IP im DNS aufloest, so auch hier (109.237.100.107 loest zu 43392.vm.hostglobal.ws auf), versteh ich auch nicht. So haette reject_unknown_client_hostname hier nicht gegriffen. Darueber hinaus halte ich reject_unknown_client_hostname fuer eine zu starke Forderung und verwende selbst nur reject_unknown_reverse_client_hostname.
-- \ J. Dollinger FAW/n Ulm |zeitnot@irc| http://www.home.pages.de/~zeitnot/ \ "What're quantum mechanics?" -- "I don't know. People who / \ repair quantums, I suppose." (Terry Pratchett, Eric) /
Hallo Jürgen,
On 10.02.22 15:16, Juergen Dollinger wrote:
Feb 8 13:44:40 mail postfix/smtpd[22650]: warning: hostname 43392.vm.hostglobal.ws does not resolve to address 109.237.100.107 Feb 8 13:44:40 mail postfix/smtpd[22650]: connect from unknown[109.237.100.107]
Zunächst mal wäre der mit reject_unknown_client_hostname gar nicht erst durchgekommen. Würde ich empfehlen in den client restrictions zu setzen.
Warum postfix oft schreibt "connect from unknown", obwohl die IP im DNS aufloest, so auch hier (109.237.100.107 loest zu 43392.vm.hostglobal.ws auf), versteh ich auch nicht.
deshalb, weil sie eben nicht _komplett_ aufgelöst werden kann:
$ host 109.237.100.107 107.100.237.109.in-addr.arpa domain name pointer 43392.vm.hostglobal.ws.
aber:
$ host 43392.vm.hostglobal.ws 43392.vm.hostglobal.ws has address 109.237.96.112
(genau das steht übrigens auch oben im Log)
--> 109.237.100.107 <-> 109.237.96.112
http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname "... the name->address mapping does not match the client IP address."
Daher:
So haette reject_unknown_client_hostname hier nicht gegriffen.
doch, hätte es. ;-)
Viele Grüße Markus
participants (6)
-
Juergen Dollinger -
Ludi Cree -
Markus Schönhaber -
Markus Winkler -
Papierkorb -
Walter H.