Reply's werden abgewiesen
Hallo postfix-Mailingliste,
wir haben einen Kommunikationspartner, der E-Mails nur über eine verschlüsselte Leitung empfängt. Das habe ich 2013 auch mit einer super Anleitung hier aus der Liste hinbekommen. Danke!
Das ganze läuft jetzt - wie gesagt - auch schon seit 2013. Was jetzt allerdings (neuerdings?) aufgefallen ist, Mails an diese Firma werden anstandslos zugestellt, nur wenn wir auf eine E-Mail von denen Antworten, wird diese dann abgewiesen:
Final-Recipient: rfc822; abc@example.com Original-Recipient: rfc822;abc@example.com Action: failed Status: 5.7.1 Remote-MTA: dns; mailin1.example.com Diagnostic-Code: smtp; 554 5.7.1 Client host rejected: cannot find your hostname, [123.456.789.123]
Ich habe mich jetzt schon an den "postmaster" der Firma gewandt. Aber vielleicht könntet Ihr mir noch einen kleinen Hinweis/Link etc. geben, was ich ggfs. noch kontrollieren könnte, bzw. wo es bei meiner Konfiguration noch hapern könnte?
Neue Mails werden mit dsn=2.0.0 status=sent zugestellt. Replys werden mit dsn=5.7.1 status=bounced (host ... said: 554 5.7.1 Client host rejected: cannot find your hostname, (in reply to RCPT TO command)) abgewiesen.
Vielleicht wisst Ihr aus Eurer Erfahrung / dem beschriebenen Verhalten ja, das ich bestimmt "dies-oder-das" vergessen habe zu konfigurieren?
Viele Grüße, Susanne Jäckel.
* Susanne Jaeckel susanne.jaeckel@lucke-edv.de:
Hallo postfix-Mailingliste,
wir haben einen Kommunikationspartner, der E-Mails nur über eine verschlüsselte Leitung empfängt. Das habe ich 2013 auch mit einer super Anleitung hier aus der Liste hinbekommen. Danke!
Das ganze läuft jetzt - wie gesagt - auch schon seit 2013. Was jetzt allerdings (neuerdings?) aufgefallen ist, Mails an diese Firma werden anstandslos zugestellt, nur wenn wir auf eine E-Mail von denen Antworten, wird diese dann abgewiesen:
Final-Recipient: rfc822; abc@example.com Original-Recipient: rfc822;abc@example.com Action: failed Status: 5.7.1 Remote-MTA: dns; mailin1.example.com Diagnostic-Code: smtp; 554 5.7.1 Client host rejected: cannot find your hostname, [123.456.789.123]
*GRMBL* immer diese Geheimhaltung von Dingen, die man wahrscheinlich eh im vorbeigehen recherchieren kann...
Ich nehme jetzt einfach mal an in diesem Fällen wird Euer Mailserver abgewiesen:
p@x1:~$ dig MX lucke-edv.de +short 10 mail.lucke-edv.de.
p@x1:~$ dig mail.lucke-edv.de. +short 193.158.105.179
p@x1:~$ dig -x 193.158.105.179 +short mail.neue-it-projekte.de. mail.lucke-edv.com. mail.lucke-edv.de.
Wenn meine Annahme richtig ist, dann habt ihr ein Mehrdeutigkeitsproblem. Euer A-Record löst reverse in 3 Namen auf: mail.neue-it-projekte.de., mail.lucke-edv.com. und mail.lucke-edv.de..
Er sollte nur auf den Hostnamen auflösen, auf den euer A-Record läuft und mit Euer Server sich auch im HELO-Namen meldet.
Das *muss* jetzt aber noch nicht die Lösung sein. Dafür wäre es hilfreich, wenn Du LOG liefern könntest, das einen gescheiterten Zustellversuch abbildet.
p@rick
Am 05.10.2016 um 12:03 schrieb Patrick Ben Koetter:
- Susanne Jaeckel susanne.jaeckel@lucke-edv.de:
Hallo postfix-Mailingliste,
wir haben einen Kommunikationspartner, der E-Mails nur über eine verschlüsselte Leitung empfängt. Das habe ich 2013 auch mit einer super Anleitung hier aus der Liste hinbekommen. Danke!
Das ganze läuft jetzt - wie gesagt - auch schon seit 2013. Was jetzt allerdings (neuerdings?) aufgefallen ist, Mails an diese Firma werden anstandslos zugestellt, nur wenn wir auf eine E-Mail von denen Antworten, wird diese dann abgewiesen:
Final-Recipient: rfc822; abc@example.com Original-Recipient: rfc822;abc@example.com Action: failed Status: 5.7.1 Remote-MTA: dns; mailin1.example.com Diagnostic-Code: smtp; 554 5.7.1 Client host rejected: cannot find your hostname, [123.456.789.123]
*GRMBL* immer diese Geheimhaltung von Dingen, die man wahrscheinlich eh im vorbeigehen recherchieren kann...
Sorry! Wirklich!
Das die IP auf die 3 Namen auflöst, war mir bekannt, aber leider nicht bewußt, das das ein Fehler ist. Inzwischen hat mich der Postmaster auch auf das gleiche Problem hingewiesen.
Nameserver Änderung ist beantragt und sollte dann im laufe des Tages behoben sein.
Vielen Dank!
Ich nehme jetzt einfach mal an in diesem Fällen wird Euer Mailserver abgewiesen:
p@x1:~$ dig MX lucke-edv.de +short 10 mail.lucke-edv.de.
p@x1:~$ dig mail.lucke-edv.de. +short 193.158.105.179
p@x1:~$ dig -x 193.158.105.179 +short mail.neue-it-projekte.de. mail.lucke-edv.com. mail.lucke-edv.de.
Wenn meine Annahme richtig ist, dann habt ihr ein Mehrdeutigkeitsproblem. Euer A-Record löst reverse in 3 Namen auf: mail.neue-it-projekte.de., mail.lucke-edv.com. und mail.lucke-edv.de..
Er sollte nur auf den Hostnamen auflösen, auf den euer A-Record läuft und mit Euer Server sich auch im HELO-Namen meldet.
Das *muss* jetzt aber noch nicht die Lösung sein. Dafür wäre es hilfreich, wenn Du LOG liefern könntest, das einen gescheiterten Zustellversuch abbildet.
p@rick
Der Vollständigkeit halber aber trotz allem noch die Zeilen aus dem Log-File, aber wie gesagt, das Problem sollte ja gelöst sein / sich in der Lösung befinden, bis die Nameserver upgedated wurden!
Oct 5 10:40:35 mail amavis[10526]: (10526-17) Passed CLEAN {RelayedOutbound}, LOCAL [192.168.2.61]:46625 susanne.jaeckel@lucke-edv.de -> abc@example.de, Queue-ID: 8158851011CC, Message-ID: 157553a8-491f-af8e-e603-13573658d247@lucke-edv.de, mail_id: h1LpYDihJwW0, Hits: -2.899, size: 10141, queued_as: 7E2D951011D9, 11971 ms Oct 5 10:40:35 mail postfix/smtp[13107]: 8158851011CC: to=abc@example.de, relay=127.0.0.1[127.0.0.1]:10024, delay=12, delays=0.07/0.01/0/12, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 7E2D951011D9) Oct 5 10:40:35 mail postfix/smtp[13113]: Untrusted TLS connection established to mailin1.example.de[123.123.123.123]:25: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) Oct 5 10:40:35 mail postfix/smtp[13113]: 7E2D951011D9: to=abc@example.de, relay=mailin1.example.de[123.123.123.123]:25, delay=0.37, delays=0.04/0.01/0.23/0.09, dsn=5.7.1, status=bounced (host mailin1.example.de[123.123.123.123] said: 554 5.7.1 Client host rejected: cannot find your hostname, [193.158.105.179] (in reply to RCPT TO command))
Danke noch einmal!
Susanne.
* Susanne Jaeckel susanne.jaeckel@lucke-edv.de:
Am 05.10.2016 um 12:03 schrieb Patrick Ben Koetter:
- Susanne Jaeckel susanne.jaeckel@lucke-edv.de:
Hallo postfix-Mailingliste,
wir haben einen Kommunikationspartner, der E-Mails nur über eine verschlüsselte Leitung empfängt. Das habe ich 2013 auch mit einer super Anleitung hier aus der Liste hinbekommen. Danke!
Das ganze läuft jetzt - wie gesagt - auch schon seit 2013. Was jetzt allerdings (neuerdings?) aufgefallen ist, Mails an diese Firma werden anstandslos zugestellt, nur wenn wir auf eine E-Mail von denen Antworten, wird diese dann abgewiesen:
Final-Recipient: rfc822; abc@example.com Original-Recipient: rfc822;abc@example.com Action: failed Status: 5.7.1 Remote-MTA: dns; mailin1.example.com Diagnostic-Code: smtp; 554 5.7.1 Client host rejected: cannot find your hostname, [123.456.789.123]
*GRMBL* immer diese Geheimhaltung von Dingen, die man wahrscheinlich eh im vorbeigehen recherchieren kann...
Sorry! Wirklich!
Das die IP auf die 3 Namen auflöst, war mir bekannt, aber leider nicht bewußt, das das ein Fehler ist.
Es ist nicht wirklich ein Fehler. Mir ist kein RFC bekannt, welches ausdrücklich eine eindeutige Reverse-Auflösung einfordert. Gemeinhin gilt es heute aber als Best Practise, auf einen Match zwischen A- und PTR-Record bei MXen zu prüfen.
Dazu auch noch: Laut RFC muss ein Server keinen MX-Record haben, um E-Mail senden oder empfangen zu dürfen. Ein A-Record ist sogar explizit gestattet.
Dennoch filtern Viele auf Basis dieser Kriterien. Aus meiner Sicht Worst Practices Spam-paranoider Postmaster, die ihr "Mailproblem" nicht mit weniger, toleranteren Methoden in den Griff bekommen.
Recht haben hilft hier natürlich nicht. Wenn Du brauchbare und zuverlässige Zustellraten erzielen willst, musst Du Dich auch den Anforderungen der Anti-Spam Esoterik beugen.
Ich persönlich bin der Meinung E-Mailserver dienen der Kommunikation. Ich konfiguriere sie so, dass sie diese ermöglichen und nicht verhindern wollen.
Grüsse
p@rick
Hallo Patrick,
Am 05.10.2016 um 20:19 schrieb Patrick Ben Koetter p@sys4.de:
Es ist nicht wirklich ein Fehler. Mir ist kein RFC bekannt, welches ausdrücklich eine eindeutige Reverse-Auflösung einfordert. Gemeinhin gilt es heute aber als Best Practise, auf einen Match zwischen A- und PTR-Record bei MXen zu prüfen.
Dazu auch noch: Laut RFC muss ein Server keinen MX-Record haben, um E-Mail senden oder empfangen zu dürfen. Ein A-Record ist sogar explizit gestattet.
Dennoch filtern Viele auf Basis dieser Kriterien. Aus meiner Sicht Worst Practices Spam-paranoider Postmaster, die ihr "Mailproblem" nicht mit weniger, toleranteren Methoden in den Griff bekommen.
Recht haben hilft hier natürlich nicht. Wenn Du brauchbare und zuverlässige Zustellraten erzielen willst, musst Du Dich auch den Anforderungen der Anti-Spam Esoterik beugen.
Ich persönlich bin der Meinung E-Mailserver dienen der Kommunikation. Ich konfiguriere sie so, dass sie diese ermöglichen und nicht verhindern wollen.
magst uns vielleicht mal ein Beispiel einer gute und dennoch toleranten Postifx Einstellung hier posten (ich prüf z.Bsp. auch den Reverse-Pointer) also: smtpd_helo_restrictions smtpd_sender_restrictions smtpd_recipient_restrictions smtpd_Client_restrictions
wär neugierig auf eine gute Konfiguration :-)
Dank und Gruss Matthias
Am 06.10.2016 um 10:47 schrieb Matthias Schmidt:
Hallo Patrick,
Am 05.10.2016 um 20:19 schrieb Patrick Ben Koetter p@sys4.de:
Es ist nicht wirklich ein Fehler. Mir ist kein RFC bekannt, welches ausdrücklich eine eindeutige Reverse-Auflösung einfordert. Gemeinhin gilt es heute aber als Best Practise, auf einen Match zwischen A- und PTR-Record bei MXen zu prüfen.
Dazu auch noch: Laut RFC muss ein Server keinen MX-Record haben, um E-Mail senden oder empfangen zu dürfen. Ein A-Record ist sogar explizit gestattet.
Dennoch filtern Viele auf Basis dieser Kriterien. Aus meiner Sicht Worst Practices Spam-paranoider Postmaster, die ihr "Mailproblem" nicht mit weniger, toleranteren Methoden in den Griff bekommen.
Recht haben hilft hier natürlich nicht. Wenn Du brauchbare und zuverlässige Zustellraten erzielen willst, musst Du Dich auch den Anforderungen der Anti-Spam Esoterik beugen.
Ich persönlich bin der Meinung E-Mailserver dienen der Kommunikation. Ich konfiguriere sie so, dass sie diese ermöglichen und nicht verhindern wollen.
magst uns vielleicht mal ein Beispiel einer gute und dennoch toleranten Postifx Einstellung hier posten (ich prüf z.Bsp. auch den Reverse-Pointer) also: smtpd_helo_restrictions smtpd_sender_restrictions smtpd_recipient_restrictions smtpd_Client_restrictions
wär neugierig auf eine gute Konfiguration :-)
Dank und Gruss Matthias
dein urspruengliches Problem bezieht sich auf
http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostnam...
d.h in der MX Praxis ueberprueft fast jeder heut zu Tage ob der Sender einen gueltigen ptr Eintrag im DNS hat, weil es aber auch mal sein kann dass dein dns nicht gut funktioniert ist der Standard fuer eine Ablehnung aus diesem check ein 4X Fehler ( tmp reject ), wenn du deinem DNS vertraust kannst du daraus auch einen 5X ( reject ) machen.
Die Steigerung dieses checks ist, nicht nur zu ueberpruefen ob ein ptr vorhanden ist sondern ob der auch noch gleich dem forward A DNS Eintrag des Senders ist. Das wird nicht empfohlen ,es fuehrt in der Praxis zu zu vielen Fehlern ( wie du selbst bemerkt hast )
Ein Mittelding sind z.b Policy Server wie http://www.policyd-weight.org/ die eine fortgeschrittene Logik zu Klassifizierung dieses Checks verwenden.
Bei den anderen checks kann man eine "best practice" veroeffentlichen ( vielfach im www zu finden ) aber das Feintuning muss am Ende immer der postmaster im Laufe der Zeit durch log Analyse vornehmen.
Wie Patrick schon schrieb, muss man sich als Sender teilweise auf sehr "esoterische" Filtermethoden einstellen.
Als Empfaenger sollte man dagagen darauf achten nur wirklich Sinnvolles einzusetzen. Im Zweifel sollte man den Datenaustausch besser nicht behindern bis man genau weiss was man tut.
Mail, vor allem als Dienst fuer Dritte ,ist im Jahre 2016 eben kein Nebenjob was man hi und da wegen der gestiegenen Komplexitaet sicher auch bedauern kann und darf.
Best Regards MfG Robert Schetterer
Am 06.10.2016 um 19:00 schrieb Robert Schetterer rs@sys4.de:
Am 06.10.2016 um 10:47 schrieb Matthias Schmidt:
Hallo Patrick,
Am 05.10.2016 um 20:19 schrieb Patrick Ben Koetter p@sys4.de:
Es ist nicht wirklich ein Fehler. Mir ist kein RFC bekannt, welches ausdrücklich eine eindeutige Reverse-Auflösung einfordert. Gemeinhin gilt es heute aber als Best Practise, auf einen Match zwischen A- und PTR-Record bei MXen zu prüfen.
Dazu auch noch: Laut RFC muss ein Server keinen MX-Record haben, um E-Mail senden oder empfangen zu dürfen. Ein A-Record ist sogar explizit gestattet.
Dennoch filtern Viele auf Basis dieser Kriterien. Aus meiner Sicht Worst Practices Spam-paranoider Postmaster, die ihr "Mailproblem" nicht mit weniger, toleranteren Methoden in den Griff bekommen.
Recht haben hilft hier natürlich nicht. Wenn Du brauchbare und zuverlässige Zustellraten erzielen willst, musst Du Dich auch den Anforderungen der Anti-Spam Esoterik beugen.
Ich persönlich bin der Meinung E-Mailserver dienen der Kommunikation. Ich konfiguriere sie so, dass sie diese ermöglichen und nicht verhindern wollen.
magst uns vielleicht mal ein Beispiel einer gute und dennoch toleranten Postifx Einstellung hier posten (ich prüf z.Bsp. auch den Reverse-Pointer) also: smtpd_helo_restrictions smtpd_sender_restrictions smtpd_recipient_restrictions smtpd_Client_restrictions
wär neugierig auf eine gute Konfiguration :-)
Dank und Gruss Matthias
dein urspruengliches Problem
war das Problem des OT, nicht meins ;-)
ich hatte nach einem best of practice Vorschlag von Patrick gefragt, im Gegensatz zu "Worst Practices Spam-paranoider Postmaster” da man von ihm immer was lernen kann ;-)
Grüsse Matthias
bezieht sich auf
http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostnam...
d.h in der MX Praxis ueberprueft fast jeder heut zu Tage ob der Sender einen gueltigen ptr Eintrag im DNS hat, weil es aber auch mal sein kann dass dein dns nicht gut funktioniert ist der Standard fuer eine Ablehnung aus diesem check ein 4X Fehler ( tmp reject ), wenn du deinem DNS vertraust kannst du daraus auch einen 5X ( reject ) machen.
Die Steigerung dieses checks ist, nicht nur zu ueberpruefen ob ein ptr vorhanden ist sondern ob der auch noch gleich dem forward A DNS Eintrag des Senders ist. Das wird nicht empfohlen ,es fuehrt in der Praxis zu zu vielen Fehlern ( wie du selbst bemerkt hast )
Ein Mittelding sind z.b Policy Server wie http://www.policyd-weight.org/ die eine fortgeschrittene Logik zu Klassifizierung dieses Checks verwenden.
Bei den anderen checks kann man eine "best practice" veroeffentlichen ( vielfach im www zu finden ) aber das Feintuning muss am Ende immer der postmaster im Laufe der Zeit durch log Analyse vornehmen.
Wie Patrick schon schrieb, muss man sich als Sender teilweise auf sehr "esoterische" Filtermethoden einstellen.
Als Empfaenger sollte man dagagen darauf achten nur wirklich Sinnvolles einzusetzen. Im Zweifel sollte man den Datenaustausch besser nicht behindern bis man genau weiss was man tut.
Mail, vor allem als Dienst fuer Dritte ,ist im Jahre 2016 eben kein Nebenjob was man hi und da wegen der gestiegenen Komplexitaet sicher auch bedauern kann und darf.
Best Regards MfG Robert Schetterer
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG, 80333 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Es ist nicht wirklich ein Fehler. Mir ist kein RFC bekannt, welches ausdrücklich eine eindeutige Reverse-Auflösung einfordert. Gemeinhin gilt es heute aber als Best Practise, auf einen Match zwischen A- und PTR-Record bei MXen zu prüfen.
http://www.faqs.org/rfcs/rfc1912.html 2.1 Inconsistent, Missing, or Bad Data
Every Internet-reachable host should have a name. The consequences of this are becoming more and more obvious. Many services available on the Internet will not talk to you if you aren't correctly registered in the DNS.
Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain. If a host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one). Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all. Also, PTR records must point back to a valid A record, not a alias defined by a CNAME. It is highly recommended that you use some software which automates this checking, or generate your DNS data from a database which automatically creates consistent data.
Gruß, Magnus
Am 06.10.2016 um 11:04 schrieb Magnus Wagner:
Es ist nicht wirklich ein Fehler. Mir ist kein RFC bekannt, welches ausdrücklich eine eindeutige Reverse-Auflösung einfordert. Gemeinhin gilt es heute aber als Best Practise, auf einen Match zwischen A- und PTR-Record bei MXen zu prüfen.
http://www.faqs.org/rfcs/rfc1912.html 2.1 Inconsistent, Missing, or Bad Data
Every Internet-reachable host should have a name. The consequences of this are becoming more and more obvious. Many services available on the Internet will not talk to you if you aren't correctly registered in the DNS.
Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain.
man beachte das "should"
If a
host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one).
ja das ist "manchmal" von Vorteil, aber der client "wuerfelt" sich halt dann einen davon aus, bei mx nicht von Vorteil, real besser "einen" ptr Eintrag der auch den forward matched ( und moeglichst auch das helo usw )
Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all.
Passiert in der Praxis
Also,
PTR records must point back to a valid A record, not a alias defined by a CNAME. It is highly recommended that you use some software which automates this checking, or generate your DNS data from a database which automatically creates consistent data.
Jo Cnames sind des Teufels *g
Gruß, Magnus
Best Regards MfG Robert Schetterer
Am 06.10.2016 um 11:04 schrieb Magnus Wagner:
http://www.faqs.org/rfcs/rfc1912.html 2.1 Inconsistent, Missing, or Bad Data
Every Internet-reachable host should have a name. The consequences of this are becoming more and more obvious. Many services available on the Internet will not talk to you if you aren't correctly registered in the DNS.
Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain.
man beachte das "should"
Macht man's nicht braucht man einen guten Grund(RFC2119). 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
Welcher sollte das sein?
Magnus
Am 06.10.2016 um 12:00 schrieb Magnus Wagner:
Am 06.10.2016 um 11:04 schrieb Magnus Wagner:
http://www.faqs.org/rfcs/rfc1912.html 2.1 Inconsistent, Missing, or Bad Data
Every Internet-reachable host should have a name. The consequences of this are becoming more and more obvious. Many services available on the Internet will not talk to you if you aren't correctly registered in the DNS.
Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain.
man beachte das "should"
Macht man's nicht braucht man einen guten Grund(RFC2119).
Was heisst hier "brauchen", vor wem solltest du dich fuerchten rfcs sind Empfehlungen bzw Vereinbarungen, wenn du das nicht einhaelst ist es halt "dein" Problem
- SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
Welcher sollte das sein?
also ich kann aus dem Stand nur wenig an den Haaren herbeiziehen
z.b ich moechte in diesem Punkt so anonym sein wie moeglich...
Magnus
Best Regards MfG Robert Schetterer
participants (5)
-
Magnus Wagner -
Matthias Schmidt -
Patrick Ben Koetter -
Robert Schetterer -
Susanne Jaeckel