wolfi3300
Anmeldungsdatum: 5. Juni 2006
Beiträge: 66
|
Ich bekomme seit heute keine Emails mehr zu GMX gesendet und habe schon 118 Mails in der Queue, die unmöglich rauswollen. Andere Server funktionieren. Über die Fehlermeldung finde ich auch nichts im Netz. Hat jemand eine Idee, an was das liegen kann? local error in processing (in reply to MAIL FROM command) May 30 22:33:15 u20mail postfix/smtp[1186160]: 5A0E6341CC2: to=<****>, relay=mx00.emig.gmx.net[212.227.15.9]:25, delay=46289, delays=46283/4.7/0.74/0.06, dsn=4.0.0, status=deferred (host mx00.emig.gmx.net[212.227.15.9] said: 451 Requested action aborted: local error in processing (in reply to MAIL FROM command))
May 30 22:33:15 u20mail postfix/smtp[1186161]: 5F949341CC3: host mx01.emig.gmx.net[212.227.17.5] said: 451 Requested action aborted: local error in processing (in reply to MAIL FROM command)
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 16818
|
Gibt es da wie bei sendmail einen verbose-Mode, bei dem man die SMTP-Transaktion sehen kann?
Relevant wäre da der envelope-Sender (Mail from).
|
sebix
Moderator, Webteam
Anmeldungsdatum: 14. April 2009
Beiträge: 5077
|
Das sieht mir nach einem Fehler auf der Empfaengerseite (GMX) aus. Dass die Fehlermeldung beim MAIL FROM kommt, ist unbedeutend. EDIT: Oder sie blockieren dich absichtlichen (Blockliste oder so)
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13293
|
wolfi3300 schrieb: Ich bekomme seit heute keine Emails mehr zu GMX gesendet ... May 30 22:33:15 u20mail postfix/smtp[1186160]: 5A0E6341CC2: to=<****>, relay=mx00.emig.gmx.net[212.227.15.9]:25, delay=46289, delays=46283/4.7/0.74/0.06, dsn=4.0.0, status=deferred (host mx00.emig.gmx.net[212.227.15.9] said: 451 Requested action aborted: local error in processing (in reply to MAIL FROM command))
Versuch mal mit dem Port 587 (statt 25). Z. B.:
...
May 31 07:58:33 yxyxyx sendEmail[3878]: INFO => Sending: MAIL FROM:<######@gmx.net>
May 31 07:58:33 yxyxyx sendEmail[3878]: SUCCESS => Received: 250 Requested mail action okay, completed
...
May 31 07:58:33 yxyxyx sendEmail[3878]: Email was sent successfully! From: <#####@gmx.net> To: <******@web.de> Subject: [my internal ip address] Server: [mail.gmx.net:587]
|
sebix
Moderator, Webteam
Anmeldungsdatum: 14. April 2009
Beiträge: 5077
|
lubux schrieb: Versuch mal mit dem Port 587 (statt 25). Z. B.:
Das wuerde ja implizieren/voraussetzten, dass er GMX als relay benutzt, also sich bei GMX authentifiziert und nicht als regulaerer Mailserver einfach Mails an GMX-Accounts sendet?
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13293
|
sebix schrieb: Das wuerde ja implizieren/voraussetzten, dass er GMX als relay benutzt, also sich bei GMX authentifiziert und nicht als regulaerer Mailserver einfach Mails an GMX-Accounts sendet?
Ja, ... aber der Titel seines Threads ist ja "Probleme mit gmx Server" und nicht Probleme mit einem GMX-Account. Aber wie immer wieder, hat der TE sein Problem hier nicht richtig beschrieben.
|
wolfi3300
(Themenstarter)
Anmeldungsdatum: 5. Juni 2006
Beiträge: 66
|
Ich habe versucht das jetzt über unseren Exchange Server gleich direkt zustellen zu lassen und nicht über unseren Postfix-Server als Smarthost. es kommt local error in processing. 2022-05-30T22:35:57.514Z,internet-connector,08DA428CC3AE2752,10,172.16.4.9:18862,212.227.15.9:25,*,E5B2E3B40231497A78F91AEF279E23F3AE7B9110,Received certificate Thumbprint
2022-05-30T22:35:57.514Z,internet-connector,08DA428CC3AE2752,11,172.16.4.9:18862,212.227.15.9:25,>,EHLO mail.XXXX.at,
2022-05-30T22:35:57.545Z,internet-connector,08DA428CC3AE2752,12,172.16.4.9:18862,212.227.15.9:25,<,250 gmx.net Hello mail.X.at [178.189.xxx.xxx] 8BITMIME SIZE 157286400,
2022-05-30T22:35:57.545Z,internet-connector,08DA428CC3AE2752,13,172.16.4.9:18862,212.227.15.9:25,*,,sending message with RecordId 59532541689886 and InternetMessageId <0e5cac7aa2084d7b8bbd1c47e6317ae5@amstetten.at>
2022-05-30T22:35:57.545Z,internet-connector,08DA428CC3AE2752,14,172.16.4.9:18862,212.227.15.9:25,>,MAIL FROM:<absender@XXXX.at> SIZE=5681,
2022-05-30T22:35:57.576Z,internet-connector,08DA428CC3AE2752,15,172.16.4.9:18862,212.227.15.9:25,<,451 Requested action aborted: local error in processing,
2022-05-30T22:35:57.592Z,internet-connector,08DA428CC3AE2752,16,172.16.4.9:18862,212.227.15.9:25,>,RSET,
2022-05-30T22:35:57.623Z,internet-connector,08DA428CC3AE2752,17,172.16.4.9:18862,212.227.15.9:25,<,250 OK, Bei der Mailwall von Ikarus bekamen wir auch eine Meldung, die ähnlich ist
said: 553 5.1.8 senderdomain not exist (in reply to MAIL FROM command)) Auch mit dem MAIL FROM. Aber mir scheint, dass das FROM eigentlich passt. Vor allem würden wir ja dann auch Probleme mit vielen anderen Servern haben und nicht nur mit GMX und Mailwall?
|
sebix
Moderator, Webteam
Anmeldungsdatum: 14. April 2009
Beiträge: 5077
|
Eure DNS-Server reagieren sehr langsam - 3 Sekunden fuer eine (leere) Antwort. Das koennte fuer GMX schon zu lange sein. Meine Recherchen vorhin haben auch schon langsame DNS-Server als Ursache fuer dieses Problem gezeigt.
|
wolfi3300
(Themenstarter)
Anmeldungsdatum: 5. Juni 2006
Beiträge: 66
|
DNS Server langsam? Oha! - welche hast du denn verwendet? Danke ich schau gleich mal, ob ich das nachvollziehen kann. Habe das Problem jetzt auch an Ikarus (mymailwall.com) gemeldet. Dort will sich ein Supportler das ansehen. Ich hoffe ich bekomme von dort auch noch Feedback, denn bei GMX erwischt man nicht wirklich wen ...
|
sebix
Moderator, Webteam
Anmeldungsdatum: 14. April 2009
Beiträge: 5077
|
wolfi3300 schrieb: DNS Server langsam?
Nicht nur langsam, sondern auch manchmal ein SERVFAIL, sehe ich gerade. 1.7s fuer die NS-Query. 3s hier lokal fuer die A-Query. Welcher NS-Server dafuer ausschlaggebend ist, weiss ich leider noch nicht, hab das Problem aber in verschiedenen Netzen, also wahrscheinlich nicht ein lokales Problem bei mir.
|
wolfi3300
(Themenstarter)
Anmeldungsdatum: 5. Juni 2006
Beiträge: 66
|
Habe gerade von einem anderen Unternehmen auch die Info bekommen, dass sie keine Emails zu MYMAILWALL und GMX rausbekommen. Dies wohl sogar über deren Office365 Outlook Microsoft Ausgang als auch Lokal. Mir scheint ich bin hier nicht der Einzige, der hier Probleme hat. Senkt meinen Puls schon mal etwas ☺ Habe jetzt mit dem Ikarus-Support (mymailwall) Kontakt aufgenommen und denen eine Email mit der Fehlermeldung gesendet. Bei GMX erreicht man nicht wirklich jemanden.
|
wolfi3300
(Themenstarter)
Anmeldungsdatum: 5. Juni 2006
Beiträge: 66
|
sebix schrieb: Eure DNS-Server reagieren sehr langsam - 3 Sekunden fuer eine (leere) Antwort. Das koennte fuer GMX schon zu lange sein. Meine Recherchen vorhin haben auch schon langsame DNS-Server als Ursache fuer dieses Problem gezeigt.
Dass die DNS Server langsam sind kann ich von meiner Seite nicht nachvollziehen. Ein DIG @localhost am DNS bringt mir eine Responsezeit von 10ms?
|
sebix
Moderator, Webteam
Anmeldungsdatum: 14. April 2009
Beiträge: 5077
|
Hier hab ich ein paar long running queries von zwei unterschiedlichen lokalen DNS Servern:
$ dig amstetten.at
; <<>> DiG 9.18.2 <<>> amstetten.at
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38056
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;amstetten.at. IN A
;; Query time: 3028 msec
;; SERVER: 10.0.0.138#53(10.0.0.138) (UDP)
;; WHEN: Tue May 31 08:58:32 CEST 2022
;; MSG SIZE rcvd: 41
$ dig mail.amstetten.at
; <<>> DiG 9.18.2 <<>> mail.amstetten.at
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 42819
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;mail.amstetten.at. IN A
;; Query time: 3024 msec
;; SERVER: 10.0.0.138#53(10.0.0.138) (UDP)
;; WHEN: Tue May 31 08:59:45 CEST 2022
;; MSG SIZE rcvd: 46
$ dig NS amstetten.at
; <<>> DiG 9.18.2 <<>> NS amstetten.at
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 23726
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;amstetten.at. IN NS
;; Query time: 1576 msec
;; SERVER: 10.0.0.138#53(10.0.0.138) (UDP)
;; WHEN: Tue May 31 08:53:53 CEST 2022
;; MSG SIZE rcvd: 41
$ dig amstetten.at NS
; <<>> DiG 9.11.5-P4-5.1+deb10u7-Debian <<>> amstetten.at NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3309
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 0a4f9db99e5be9b95fe0c6f86295bc16fba90b8a7c01c5ba (good)
;; QUESTION SECTION:
;amstetten.at. IN NS
;; ANSWER SECTION:
amstetten.at. 3600 IN NS dns2.amstetten.at.
amstetten.at. 3600 IN NS dns1.amstetten.at.
;; Query time: 1727 msec
;; SERVER: 213.239.209.8#53(213.239.209.8)
;; WHEN: Tue May 31 08:56:22 CEST 2022
;; MSG SIZE rcvd: 107
|
wolfi3300
(Themenstarter)
Anmeldungsdatum: 5. Juni 2006
Beiträge: 66
|
sebix schrieb: Hier hab ich ein paar long running queries von zwei unterschiedlichen lokalen DNS Servern:
Sehr eigenartig. Frage mich gerade wo hier ein Flaschenhals sein könnte? Ist das Problem zwangsweise bei uns? Vor allem, wenn er bei mir an der Maschine 10ms zeigt?
Die DNS Checker im Internet die ich gefunden habe zeigen leider keine Response-Zeiten an. Mal schauen, ob ich noch welche finde, die eine Zeit ausgeben. Anfrage von DNS2 in Richtung DNS1: (1 msec)
dig @dns1.amstetten.at amstetten.at
; <<>> DiG 9.11.3-1ubuntu1.17-Ubuntu <<>> @dns1.amstetten.at amstetten.at
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54946
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 9ab444a540a063e88ed61e006295d5b7a69599e7ee2b745c (good)
;; QUESTION SECTION:
;amstetten.at. IN A
;; ANSWER SECTION:
amstetten.at. 3600 IN A 178.189.113.165
;; AUTHORITY SECTION:
amstetten.at. 3600 IN NS dns2.amstetten.at.
amstetten.at. 3600 IN NS dns1.amstetten.at.
;; ADDITIONAL SECTION:
dns1.amstetten.at. 3600 IN A 178.189.113.173
dns2.amstetten.at. 3600 IN A 178.189.113.174
;; Query time: 1 msec
;; SERVER: 178.189.113.173#53(178.189.113.173)
;; WHEN: Tue May 31 10:45:43 CEST 2022
;; MSG SIZE rcvd: 155
|
sebix
Moderator, Webteam
Anmeldungsdatum: 14. April 2009
Beiträge: 5077
|
wolfi3300 schrieb: sebix schrieb: Hier hab ich ein paar long running queries von zwei unterschiedlichen lokalen DNS Servern:
Sehr eigenartig. Frage mich gerade wo hier ein Flaschenhals sein könnte? Ist das Problem zwangsweise bei uns? Vor allem, wenn er bei mir an der Maschine 10ms zeigt?
Das weiss ich auch nicht, aber eigenartig ist es. Ich kann das in mehreren Netzen mit mehreren Nameservern nachvollziehen. Hier zB die Ergebnisse des NS der TU Wien: 5s, SERVFAIL
$ dig amstetten.at @128.130.4.3
; <<>> DiG 9.16.23 <<>> amstetten.at @128.130.4.3
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60192
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: cc90316bf983a19e010000006295d642978b2c675f80bdd6 (good)
;; QUESTION SECTION:
;amstetten.at. IN A
;; Query time: 4968 msec
;; SERVER: 128.130.4.3#53(128.130.4.3)
;; WHEN: Tue May 31 10:48:02 CEST 2022
;; MSG SIZE rcvd: 69
$ dig MX amstetten.at @128.130.4.3
; <<>> DiG 9.16.23 <<>> MX amstetten.at @128.130.4.3
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 13570
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 49c9d75c2a7077a9010000006295d65f4964d3747be3df5a (good)
;; QUESTION SECTION:
;amstetten.at. IN MX
;; Query time: 4935 msec
;; SERVER: 128.130.4.3#53(128.130.4.3)
;; WHEN: Tue May 31 10:48:31 CEST 2022
;; MSG SIZE rcvd: 69 Die DNS Checker im Internet die ich gefunden habe zeigen leider keine Response-Zeiten an. Mal schauen, ob ich noch welche finde, die eine Zeit ausgeben.
Wichtig ist hier aber immer, dass das nicht-gecachte Ergebnisse sind. Sonst hast du immer Response-Zeiten von 0-30ms.
|