Hallo Liste,
ich möchte mehrere Mailadressen auf Gültigkeit prüfen, die Wahl fiel auf swaks:
swaks -t $mail_address -q RCPT
Auf der Kommandzeile sehe ich erwartungsgemäß die Kommunikation mit dem zuständigen Mailserver.
Aus einem Shell-Skript heraus gibt es allerdings eine Fehlermeldung:
:25...ying gmx.de :25:Error connecting to gmx.de *** IO::Socket::INET6: getaddrinfo: Name or service not known
Es sieht so aus, als ob der Vorgang 'finde den zuständigen MX heraus' da fehlschlägt - bei gmx müsste z.B. gmx.net (statt 'de') konnektiert werden.
Gibt es eine Möglichkeit, swaks per Shell-Skript für den beabsichtigten Zweck zu nutzen und wenn 'ja' wie?
Oder ist es für den Zweck 'Mehrfachverarbeitung' das falsche Werkzeug - was würde ich dann stattdessen nehmen?
Danke & Grüße,
Bernhard
Hi,
On 14. Jun 2021, at 12:36, bb bernhard.bittner@gmx.net wrote:
:25:Error connecting to gmx.de *** IO::Socket::INET6: getaddrinfo: Name or service not known
Da steht, dass DNS (Namensauflösung) nicht ging. D. h. da stimmt was mit den Netzwerkeinstellungen nicht.
Gruß,
Frank
Hallo Bernhard, Hallo Frank,
der versucht Ipv6 zu machen. GMX hat noch keine Ipv6-MX.
Zur Gegenprüfung: heise.de hat z.B. einen, da bekommt swaks zumindest die Verbindung hin.
swaks -t test@heise.de -q rcpt -6 === Trying relay.heise.de:25... === Connected to relay.heise.de. <- 220 relay.heise.de ESMTP. -> EHLO ### <- 250-relay.heise.de Hello ### [#ip6#] <- 250-SIZE 52428800 <- 250-8BITMIME <- 250-PIPELINING <- 250-STARTTLS <- 250 HELP -> MAIL FROM:<root@###> <- 250 OK -> RCPT TO:test@heise.de <** 550-Verification failed for <###> <** 550-Unrouteable address <** 550 Sender verify failed -> QUIT <- 221 relay.heise.de closing connection === Connection closed with remote host.
Zum enforcen von IPv4 entsprechend einfach -4 ans swaks verbaumeln.
Grüße,
Falk
On 6/14/21 1:05 PM, Frank Becker wrote:
Hi,
On 14. Jun 2021, at 12:36, bb bernhard.bittner@gmx.net wrote:
:25:Error connecting to gmx.de *** IO::Socket::INET6: getaddrinfo: Name or service not known
Da steht, dass DNS (Namensauflösung) nicht ging. D. h. da stimmt was mit den Netzwerkeinstellungen nicht.
Gruß,
Frank
Am 14.06.21 um 13:39 schrieb Falk Herzog:
Salute,
Hallo Bernhard, Hallo Frank,
der versucht Ipv6 zu machen. GMX hat noch keine Ipv6-MX.
Zur Gegenprüfung: heise.de hat z.B. einen, da bekommt swaks zumindest die Verbindung hin.
swaks -t test@heise.de -q rcpt -6 === Trying relay.heise.de:25... === Connected to relay.heise.de. <- 220 relay.heise.de ESMTP. -> EHLO ### <- 250-relay.heise.de Hello ### [#ip6#] <- 250-SIZE 52428800 <- 250-8BITMIME <- 250-PIPELINING <- 250-STARTTLS <- 250 HELP -> MAIL FROM:<root@###> <- 250 OK -> RCPT TO:test@heise.de <** 550-Verification failed for <###> <** 550-Unrouteable address <** 550 Sender verify failed -> QUIT <- 221 relay.heise.de closing connection === Connection closed with remote host.
Zum enforcen von IPv4 entsprechend einfach -4 ans swaks verbaumeln.
nope ('-4' hatte ich schon probiert, hätte ich dazuschreiben sollen) - das macht im Skript-Aufruf keinen Unterschied, gleicher Fehler.
Vielleicht ist ja swaks an der Stelle kaputt - ich hantiere mit Debian 9?
snip
B.
Am 14.06.21 um 13:05 schrieb Frank Becker:
Hallo zurück,
Hi,
On 14. Jun 2021, at 12:36, bb bernhard.bittner@gmx.net wrote:
:25:Error connecting to gmx.de *** IO::Socket::INET6: getaddrinfo: Name or service not known
Da steht, dass DNS (Namensauflösung) nicht ging. D. h. da stimmt was mit den Netzwerkeinstellungen nicht.
das mag auf den ersten Blick so aussehen - aber dann müsste ich ja unterschiedliche Netzwerkeinstellungen für Kommandozeile und Skript-Abarbeitung haben?
Das würde mich dann schon wundern...
B.
bb bernhard.bittner@gmx.net (Mo 14 Jun 2021 12:35:01 CEST):
Hallo Liste,
ich möchte mehrere Mailadressen auf Gültigkeit prüfen, die Wahl fiel auf swaks:
swaks -t $mail_address -q RCPT
Auf der Kommandzeile sehe ich erwartungsgemäß die Kommunikation mit dem zuständigen Mailserver.
…
Aus einem Shell-Skript heraus gibt es allerdings eine Fehlermeldung:
:25...ying gmx.de :25:Error connecting to gmx.de *** IO::Socket::INET6: getaddrinfo: Name or service not known Es sieht so aus, als ob der Vorgang 'finde den zuständigen MX heraus' da fehlschlägt - bei gmx müsste z.B. gmx.net (statt 'de') konnektiert werden.
Vermutlich im hast Du im Script die Perl-DNS-Library aus irgendwelchen Gründen nicht am Start.
Probier im Script und auf der Kommandozeile mal
perl -MNet::DNS -e 0
Ein guter Startpunkt ist dann weiter die Ausgabe von `perl -V` (besonders der Teil mit den Library-Pfaden) zu vergleichen, zwischen Script und normaler Kommandozeile.
Best regards from Dresden/Germany Viele Grüße aus Dresden Heiko Schlittermann -- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE -
Am 14.06.21 um 15:18 schrieb Heiko Schlittermann:
Moinmoin,
Vermutlich im hast Du im Script die Perl-DNS-Library aus irgendwelchen Gründen nicht am Start.
Probier im Script und auf der Kommandozeile mal
perl -MNet::DNS -e 0Ein guter Startpunkt ist dann weiter die Ausgabe von `perl -V` (besonders der Teil mit den Library-Pfaden) zu vergleichen, zwischen Script und normaler Kommandozeile.
die Ausgabe von `perl -V` war interessanterweise identisch, ebenso machte die Debian-Version keinen Unterschied.
Also konnte ich die These 'grundsätzliches Problem' wieder verwerfen :-).
Wie ich soeben herausgefunden habe, bestand die Ursache des Problems in der zu verarbeitenden Textdatei - die wird per 'readarray -t' eingelesen und war im DOS-Format - einmal dos2unix aufgerufen und schon ist das Problem verschwunden. Phew!
Danke & Grüße,
Bernhard
bb bernhard.bittner@gmx.net (Di 15 Jun 2021 07:24:32 CEST):
Ein guter Startpunkt ist dann weiter die Ausgabe von `perl -V` (besonders der Teil mit den Library-Pfaden) zu vergleichen, zwischen Script und normaler Kommandozeile.
die Ausgabe von `perl -V` war interessanterweise identisch, ebenso machte die Debian-Version keinen Unterschied.
Also konnte ich die These 'grundsätzliches Problem' wieder verwerfen :-).
Wie ich soeben herausgefunden habe, bestand die Ursache des Problems in der zu verarbeitenden Textdatei - die wird per 'readarray -t' eingelesen und war im DOS-Format - einmal dos2unix aufgerufen und schon ist das Problem verschwunden. Phew!
Und warum war das Problem nun im Script vorhanden und auf der Kommandozeile nicht?
Ich vermute, Du hast uns in der ursprünglichen Fragestellung wichtige Details unterschlagen. (Z.B. vermute ich jetzt, dass auf der Kommandozeile die Daten nicht aus der Textdatei kamen, im Script aber schon.)
Am 15.06.21 um 08:28 schrieb Heiko Schlittermann:
Hallo Heiko,
snip
Und warum war das Problem nun im Script vorhanden und auf der Kommandozeile nicht?
Ich vermute, Du hast uns in der ursprünglichen Fragestellung wichtige Details unterschlagen. (Z.B. vermute ich jetzt, dass auf der Kommandozeile die Daten nicht aus der Textdatei kamen, im Script aber schon.)
im Nachgang betrachtet genau das - die Dinge, die in meiner Problem-Vorstellung (noch) nicht relevant waren, sind's dann dann gewesen.
Achte ich beim nächsten Mal mehr drauf.
B.
lug-dd@mailman.schlittermann.de
-
bb -
Falk Herzog -
Frank Becker -
Heiko Schlittermann