Hallo,
ich bin gerade dabei mein FHEM von einem Raspi 3 mit Debian (jessie) auf Rapsi 4 mit Debian (buster) umzustellen.
Das klappt in großen Teilen auch ganz gut. Nun wollte ich auch meine Alarme umstellen. Dabei verwende ich notify's so wie in der FHEM Wiki (https://wiki.fhem.de/wiki/E-Mail_senden) beschrieben.
Nur wollen die Mails nicht verschickt werden.
Ich habe das Paket installiert
sudo apt-get update
sudo apt-get install sendemail libio-socket-ssl-perl libnet-ssleay-perl perl
und in meiner 99_myUtils.pm folgenden Code hinzugefügt
sub
DebianMail
{
my $rcpt = shift;
my $subject = shift;
my $text = shift;
# my $attach = shift;
my $ret = "";
my $sender = "fhem\@XXXXX.de";
my $konto = "fhem\@XXXXX.de";
my $passwrd = "XXXXX";
my $provider = "mail.XXXXX.de:587";
Log 1, "sendEmail RCP: $rcpt";
Log 1, "sendEmail Subject: $subject";
Log 1, "sendEmail Text: $text";
# Log 1, "sendEmail Anhang: $attach";
$ret .= qx(sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text' -s '$provider' -xu '$konto' -xp '$passwrd' -o tls=auto -o message-charset=utf-8);
$ret =~ s,[\r\n]*,,g; # remove CR from return-string
Log 1, "sendEmail returned: $ret";
}
Nur leider bekomme ich dann im Log folgende Meldung:
2021.03.24 15:20:26 1: sendEmail RCP: xxxx@xxxxxxx.de
2021.03.24 15:20:26 1: sendEmail Subject: FHEM Notify ESPEasy_ESP_07_ESP07 presence: present
2021.03.24 15:20:26 1: sendEmail Text: Device: ESPEasy_ESP_07_ESP07
Event: presence: present
2021.03.24 15:20:32 1: sendEmail returned: Mar 24 15:20:32 fhem sendEmail[2538]: ERROR => TLS setup failed: SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Ich habe natürlich auch schon überprüft ob in der /usr/bin/sendEmail der richtige Eintrag steht
if (! IO::Socket::SSL->start_SSL($SERVER, SSL_version => 'SSLv23:!SSLv2')) {
Reboots, updates sowie manuelles versenden hat leider nicht zum Erfolg geführt.
Hab ich vielleicht ein Paket vergessen zu installiert?
Bitte um Hilfe
Gunter
Hallo Gunter,
Du hast wirklich ein so altes System? Welches? Von welchem Provider reden wir?
Gruß Otto
Never change a running system ;D
Kein bekannter Provider. Es ist "web-service4u.de", aber die selben Einstellungen funktionieren prima auf dem Raspi3
Habe es gerade mit meinem G-Mail Konto probiert mit dem selben Fehler
Mar 24 16:27:31 fhem2021 sendemail[2890]: ERROR => TLS setup failed: SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Weil Du es schriebst ...
routines:tls_process_server_certificate:certificate verify failed
Er erkennt da Zertifikat als nicht gültig. Da es kein bekannter Profider ist .... mal bei dem geguckt und der hat direkt eine Info dazu:
https://web-service4u.de/faq/242-beim-e-mailversand-undoder-e-mailempfang-ueber-mein-e-mailprogramm-erhalte-ich-eine-zertifikatswarnung?catid=51%3Aemail (https://web-service4u.de/faq/242-beim-e-mailversand-undoder-e-mailempfang-ueber-mein-e-mailprogramm-erhalte-ich-eine-zertifikatswarnung?catid=51%3Aemail)
Höchstwahrscheinlich hat Dein altes System einfach zertifikate nicht geprüft, so das es nicht aufgefallen ist. Aktuelle Systeme machen es im Standard
Zitat von: Gunter1710 am 24 März 2021, 16:17:49
Never change a running system ;D
Naja irgendwann ist man dann raus. Ich vermute wie Werner, deine Zertifikate sind zu alt.
Ich weiß drei Fragen sind häufig zuviel - aber "so altes System?
Welches?"
FHEM sagt
Latest Revision: 19155
Zertifikate habe ich keine installiert
Dein Problem hat mit FHEM wenig zu tun, Du hast ein Problem mit deinem Betriebssystem!
Das ist zu alt und da sind die Zertifikate ev. veraltet.
Was bekommst Du in der FHEM Kommandozeile zurück?
{qx(cat /etc/os-release)}
Und die ca-certificates
{qx(apt-cache policy ca-certificates)}
Hast Du Dir den Link durchgelesen, den ich gepostet hatte?
Das würde mich jetzt schon wundern :o
Wie gesagt, es ist ein Raspi 4 mit Betriebssystem neu installiert von vor einer Woche inkl.
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
mit heute durchgeführtem
# System aktualisieren
apt-get update
apt-get upgrade
#Neustart
reboot
Zitat von: Wernieman am 24 März 2021, 20:04:25
Hast Du Dir den Link durchgelesen, den ich gepostet hatte?
Ja, hab ich.
In der Zwischenzeit hab ich aber auf GMail umgestellt
sub
DebianMail
{
my $rcpt = shift;
my $subject = shift;
my $text = shift;
# my $attach = shift;
my $ret = "";
my $sender = "xxxxx\@gmail.com";
my $konto = "xxxxx@\gmail.com";
my $passwrd = "xxxxx";
my $provider = "smtp.gmail.com:587";
Log 1, "sendEmail RCP: $rcpt";
Log 1, "sendEmail Subject: $subject";
Log 1, "sendEmail Text: $text";
# Log 1, "sendEmail Anhang: $attach";
$ret .= qx(sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text' -s '$provider' -xu '$konto' -xp '$passwrd' -o tls=auto -o message-charset=utf-8);
$ret =~ s,[\r\n]*,,g; # remove CR from return-string
Log 1, "sendEmail returned: $ret";
}
Der Fehler bleibt der gleiche
:-\
ZitatDas würde mich jetzt schon wundern :o
Wie gesagt, es ist ein Raspi 4 mit Betriebssystem neu installiert von vor einer Woche inkl.
Und woher sollten wir das wissen? :'( :'(
sendEmail gibt es mMn seit Jahren nicht mehr. -> sendemail - deswegen war ich Der Meinung dein System ist alt. Auch TLS ist seit Jahren kein Problem.
Ich vermute Du hast Unsinn bei der Umstellung gebaut (Restore).
Mein Tipp: Mach ein neues System und teste eine neue debianmail Routine laut Wiki. Geht ja alles auf Kommandozeile und braucht erstmal kein FHEM
Ich habe es so gemacht wie im FHEM Wiki beschrieben unter E-Mail senden (https://wiki.fhem.de/wiki/E-Mail_senden)
Da wird sendemail verwendet.
Wenn es was neuere gibt, dann gerne mir den Link dazu schicken
hast Du nicht! Dein Text:
Zitat$ret .= qx(sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text' -s '$provider' -xu '$konto' -xp '$passwrd' -o tls=auto -o message-charset=utf-8);
Wiki
https://wiki.fhem.de/wiki/E-Mail_senden#Raspberry_Pi
Ich hab nun meine "sub DebianMail" aus der 99_myUtils gelöscht und gegen die aus dem Wiki Eintrag ersetzt
sub DebianMail
{
my $rcpt = shift;
my $subject = shift;
my $text = shift;
my $attach = shift;
my $ret = "";
my $error;
my $konto = "xxxxx@\gmail.com";
my $passwrd = "xxxxx";
my $from = $konto; # or use different KeyValue if konto is not the from email address
my $provider = "smtp.gmail.com:587"; # smtp.domain.tld:port see provider documentation
#Log 1, "sendEmail RCP: $rcpt";
#Log 1, "sendEmail Subject: $subject";
#Log 1, "sendEmail Text: $text";
#Log 1, "sendEmail Anhang: $attach";
if (not defined($attach)){$attach=''}
$ret .= qx(sendemail -f '$from' -t '$rcpt' -u '$subject' -m '$text' -a '$attach' -s '$provider' -xu '$konto' -xp '$passwrd' -o tls=auto -o message-charset=utf-8);
$ret =~ s,[\r\n]*,,g; # remove CR from return-string
Log 1, "sendemail returned: $ret";
}
Wenn ich nun folegndes in FEHM eingebe
{DebianMail("email\@gmx.de","Subject","Text")}
Bekomme ich dieses Ergebnis
2021.03.24 20:40:40 1: sendemail returned: Mar 24 20:40:40 fhem2021 sendemail[586]: ERROR => TLS setup failed: SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Ich denke: Du hast irgendwas im System verhunzt
4 Schritte:
Zitat von: Otto123 am 24 März 2021, 20:11:31
Mein Tipp: Mach ein neues System und teste eine neue debianmail Routine laut Wiki. Geht ja alles auf Kommandozeile und braucht erstmal kein FHEM
sudo apt-get update
sudo apt-get install sendemail libio-socket-ssl-perl libnet-ssleay-perl perlZitatMan kann die korrekte Funktion im Terminal (ohne {qx()} ) oder auch in der FHEM Kommandozeile testen
{qx(sendemail -f "Ab\@send.er" -t "Emp\@faeng.er" -u 'subject' -m 'text' -a 'DateinameOderLeer' -s 'smtpFQDN' -xu 'MailUser' -xp 'PasswortOhneKlammeraffen')}
Der Meinung bin ich nun auch. Irgendwas hat wohl bei der Debain Installation nicht richtig funktioniert.
Ich werde am Wochenende eine neue SDcard reinstecken und wieder von vorne anfangen.
Danke an @Otto123 und @Wernieman für eure Mühe.
Ich werde über mein Erfolg/Misserfolg berichten :D
Kommando zurück!
Die angesprochenen Root Zertifikate fehlen offenbar komplett :-[
Lösung:
sudo apt install ca-certificates
Mein Befehl aus Beitrag #7 hätte Dir das Problem gezeigt :)
Allerdings will ich gleich anmerken: gmail ist per default nicht verwendbar, Du musst erst die erweiterte Sicherheit abschalten.
Edit: Habe das Wiki ergänzt
Zitat von: Otto123 am 24 März 2021, 22:14:58
Kommando zurück!
Die angesprochenen Root Zertifikate fehlen offenbar komplett :-[
Lösung:
sudo apt install ca-certificates
Mein Befehl aus Beitrag #7 hätte Dir das Problem gezeigt :)
Allerdings will ich gleich anmerken: gmail ist per default nicht verwendbar, Du musst erst die erweiterte Sicherheit abschalten.
Edit: Habe das Wiki ergänzt
Danke
Otto123, aber auch das hat alles nicht geholfen. Ich vermute bei der Installation meines Rapsi 4 ist irgend etwas grundlegendes schief gelaufen. Nachdem ich eine neue SDcard verwendet habe und alles noch mal neu installiert habe geht es nun.
Danke noch mal für deine Hilfe!!!!
Schön das es funktioniert. 👍
Aber immerhin hatte ich genau den gleichen Fehler und in diesem System fehlten besagte ca-certificates. Bei einem anderen Problem hatte ich das auch schon mal ...
Es gibt offenbar Systeme wo die in der Grundinstallation nicht dabei sind.
Ich war neugierig und habe es mir angeguckt:
Mein Raspbian Buster fluppt perfekt mit Gmail, wenn die Sicherheitseinstellung bei Google geändert wird. Und in Sachen Crypto-Stack ist das auch alles "State of art":
Mar 25 11:57:51 sauerberry sendemail[15466]: SUCCESS => Received: 220 2.0.0 Ready to start TLS
Mar 25 11:57:51 sauerberry sendemail[15466]: DEBUG => TLS: Using cipher: TLS_AES_256_GCM_SHA384
Mar 25 11:57:51 sauerberry sendemail[15466]: DEBUG => TLS: Using version: TLSv1_3
Mar 25 11:57:51 sauerberry sendemail[15466]: DEBUG => TLS session initialized :)
(Die Zeile mit dem TLSv1_3 habe ich aus Neugier in den Source von sendemail gepackt.)
Hi, ich hänge mich mal hier mit ran.
Ich habe seit 28.10.21 den gleichen Fehler:
2021.11.02 00:10:02 1: sendEmail returned: Nov 02 00:10:02 raspberrypi sendEmail[30437]: ERROR => TLS setup failed: SSL connect attempt failed error:1416F086:SSL
Am 28.10. um 00:10 wurde noch eine Mail versendet, am gleichen Tag gegen 20:00 kam dann der Fehler.
Von mir wurde nichts verändert. Ca-Certifikates sind aktuell.
Die Mails werden mit den gleichen Einstellungen von OMV (Debian Buster), OpenWRT und Windows weiterhin problemlos versendet.
Nur bei Raspbian funktioniert es nicht mehr.
Getestet auf meiner Prod mit aktuellem Stretch, auf der Dev. mit älterem Stretch und mit aktuellem Buster. Alle die gleiche ca-certifikates Version (20200601~deb9u2, bzw. 20200601~deb10u2).
OMV verwendet auch die 20200601~deb10u2.
Ich habe aktuell einen anderen Mailaccount eingerichtet, das funktioniert.
Ich würde gerne verstehen, warum das nicht mehr funktioniert.
Ist es möglich, dass Raspbian ein älteres Zertifikat verwendet, das abgelaufen ist. Kann es überhaupt unterschiedliche Zertifikate für den Account geben?
Danke und Grüße
Bernd
Hallo Bernd,
Es klingt schon nach einem abgelaufenen Zertifikat. ;)
Ein anderer Account = andere Domäne?
Ich bin nicht sicher, ob einzelne Rootzertifikate alt sein könnten / beim update nicht ersetzt sein könnten.
Hab es nicht probiert -> https://de.godaddy.com/blog/ssl-cert-check-erkennt-ablaufende-ssl-zertifikate/
Gruß Otto
Hallo Otto,
ja, andere Domain.
Danke für den Link, das werde ich mir anschauen.
Wenn das Zertifikat wirklich abgelaufen ist, dann heißt das, dass Debian und Raspbian, trotz gleicher Version, unterschiedliche Zertifikate ausrollen!?
ich würde eher vermuten, das eventuell bei einem update der Zertifikate was passieren kann?
Raspian baut auf Debian auf .. kann aber trotzdem unterschiedliche Pakete enthalten. Ich vermute aber auch, das Du Recht hast, bezüglich Zertifikat.
Von welcher Problemdomain reden wir eigentlich?
Zitat von: Wernieman am 03 November 2021, 09:29:34
Von welcher Problemdomain reden wir eigentlich?
Arcor, bzw. aktuell Vodafone
Bei beiden
mail.arcor.de:587
smtp.vodafonemail.de:587
Vodafone gibt den Port mit 465 an, das hat bei mir nie funktioniert.
Die ca-certifikates habe ich auch schon mit --reinstall erneuert, trotz reboot keine Änderung.
Gucke ich mir heute Abend (hoffentlich) an ...
Ich habe das Script getestet:
sudo ./ssl-cert-check -s mail.arcor.de -p 587
Host Status Expires Days
----------------------------------------------- ------------ ------------ ----
mail.arcor.de:587 Expiring Nov 19, 2021 16
sudo ./ssl-cert-check -i -s smtp.vodafonemail.de -p 587
Host Issuer Status Expires Days
----------------------------------- ----------------- -------- ----------- ----
smtp.vodafonemail.de:587 Sectigo Limited Expiring Nov 19 2021 16
sudo ./ssl-cert-check -s smtp.vodafonemail.de -p 465
Host Status Expires Days
----------------------------------------------- ------------ ------------ ----
smtp.vodafonemail.de:465 Expiring Nov 19, 2021 16
6
Da existiert sogar PORT 465 und es gilt noch 16 Tage.
Bei der Abfrage vom Verzeichnis wird leider nur ein Ergebnis angezeigt. Da ich keinen Namen Sectigo Limited bzw. Vodafone zuordnen kann und über 134 Zertifikate einzeln abzufragen mir zu viel ist, lass ich das mal so stehen.
sudo ./ssl-cert-check -d /etc/ssl/certs/*.pem
Host Status Expires Days
----------------------------------------------- ------------ ------------ ----
FILE:/etc/ssl/certs/ACCVRAIZ1.pem Valid Dec 31, 2030 3345
ZitatAdd a "-d" option to specify a directory or file mask pattern -- Marcel Pennewiss
::)
./ssl-cert-check -d /etc/ssl/certs/ |grep Expired ;)
Zitat von: Otto123 am 03 November 2021, 19:56:02
::)
./ssl-cert-check -d /etc/ssl/certs/ |grep Expired ;)
FILE:/etc/ssl/certs/5cf9d536.0 Expired Mar 17, 2021 -231
FILE:/etc/ssl/certs/QuoVadis_Root_CA.pem Expired Mar 17, 2021 -231
FILE:/etc/ssl/certs/Staat_der_Nederlanden_Root_CA_-_G2.pem Expired Mar 25, 2020 -588
FILE:/etc/ssl/certs/12d55845.0 Expired Sep 30, 2021 -34
FILE:/etc/ssl/certs/3d441de8.0 Expired Mar 25, 2020 -588
FILE:/etc/ssl/certs/DST_Root_CA_X3.pem Expired Sep 30, 2021 -34
FILE:/etc/ssl/certs/9c2e7d30.0 Expired Apr 6, 2021 -211
FILE:/etc/ssl/certs/080911ac.0 Expired Mar 17, 2021 -231
FILE:/etc/ssl/certs/5c44d531.0 Expired Mar 25, 2020 -588
FILE:/etc/ssl/certs/2e5ac55d.0 Expired Sep 30, 2021 -34
FILE:/etc/ssl/certs/Sonera_Class_2_Root_CA.pem Expired Apr 6, 2021 -211
FILE:/etc/ssl/certs/a7605362.0 Expired Apr 6, 2021 -211Keins, das einen direkten Bezug zum 28.10.21 aufweist.
Danke, ich hatte mich an die readme.md vom Github gehalten
Check all certificates with file pattern "/etc/haproxy/ssl/*.pem"
$ ssl-cert-check -d "/etc/haproxy/ssl/*.pem"
Host Status Expires Days
----------------------------------------------- ------------ ------------ ----
FILE:/etc/haproxy/ssl/example1.org.pem Valid Jan 6 2017 78
FILE:/etc/haproxy/ssl/example2.org.pem Valid Jan 1 2017 73
FILE:/etc/haproxy/ssl/example3.org.pem Valid Jan 6 2017 78
mit " " funktioniert es bei mir gleich gar nicht ::) da werd ich ihm mal einen Hinweis geben. Die Hilfe gibt den richtigen Syntax aus.
Ja ich weiß, die Ausgabe hilft jetzt nicht. War ein Versuch "im Dunkeln" :) mal sehen ob Werner noch eine Idee hat.
Aktuell leider keine ... bin aber auch etwas müde heute ...
@Otto:
Ja, mit den " " funktioniert es nicht und eine Liste wird auch nicht erzeugt, wie im Bsp.
@Wernieman:
Kein Problem, momentan funktioniert es ja mit einer anderen Domain.
Schön wäre es halt, wenn es mit der Alten wieder funktionieren würde.
Wieso guckst Du eigentlich beim haproxy nach den SSL? sendEmail guckt dort bestimmt nicht rein ...
Zitat von: Wernieman am 03 November 2021, 21:29:39
Wieso guckst Du eigentlich beim haproxy nach den SSL? sendEmail guckt dort bestimmt nicht rein ...
Das ist das Bsp aus Github, ich war direkt unter /etc/ssl/certs/ ;)
kannst Du mal
1. /etc/ssl wegsichern (mv)
2. ca-cert neu installieren?
2. Ich weiß gar nicht, wie genau das Modul heißt ....
Zitat von: Wernieman am 03 November 2021, 22:34:02
kannst Du mal
1. /etc/ssl wegsichern (mv)
2. ca-cert neu installieren?
2. Ich weiß gar nicht, wie genau das Modul heißt ....
zu 1. das sind nur Links, die Dateien liegen unter /usr/share/ca-certifikates/
Ich sicher Beides
zu 2. ca-certifikates
...heute Abend...
Es ging mir darum, es wirklich mal neu zu bauen. Deshalb eben nicht nur sichern (backup), sondern verschieben ...
Zitat von: Wernieman am 04 November 2021, 08:17:55
Es ging mir darum, es wirklich mal neu zu bauen. Deshalb eben nicht nur sichern (backup), sondern verschieben ...
Sorry, das meinte ich ja.
Also "2 Dumme" der gleiche Gedanke ;D
Mir ist es ansonsten ein Rätsel, was hier passiert ...
Moin,
das Script kann viel mehr :) Teste bitte mal so
./ssl-cert-check -s smtp.vodafonemail.de -p 587
Bei mir kommt da in allen Systemen
Host Status Expires Days
----------------------------------------------- ------------ ------------ ----
smtp.vodafonemail.de:587 Expiring Nov 19, 2021 15
Was auch nicht mehr lang hin ist.
Gruß Otto
Zitat von: Otto123 am 04 November 2021, 09:57:48
Moin,
das Script kann viel mehr :) Teste bitte mal so
./ssl-cert-check -s smtp.vodafonemail.de -p 587
Bei mir kommt da in allen Systemen
Host Status Expires Days
----------------------------------------------- ------------ ------------ ----
smtp.vodafonemail.de:587 Expiring Nov 19, 2021 15
Was auch nicht mehr lang hin ist.
Gruß Otto
Habe ich schon in #29.
Das Zertifikat gilt nur ein Jahr. Laut Browserauskunft der Webseite.
Zitat von: Wernieman am 04 November 2021, 09:46:12
Also "2 Dumme" der gleiche Gedanke ;D
Mir ist es ansonsten ein Rätsel, was hier passiert ...
Ich teste heute Abend, habe jedoch keine große Hoffnung, da 3 Raspis mit Raspbian Stretch und Buster das gleiche Verhalten zeigen.
Das Problem mit Browsern ist:
1. Gucken sie auf Websides und nicht auf "Spezialports"
2. Werden sie mit eigenen Stammzertifikaten ausgeliefert
Es kann also sein, das der Browser O.K. anzeigt, das Betriebsystem aber nicht, da dieses eben NICHT die Browser Zertifikate nutzen kann.
Zitat von: frober am 04 November 2021, 10:26:32
Habe ich schon in #29.
Das Zertifikat gilt nur ein Jahr. Laut Browserauskunft der Webseite.
Sorry, war gestern Abend offenbar nicht konzentriert genug beim lesen. Mein Focus lag darauf die lokalen liegenden CA Zertifikate zu testen, der Befehl testet ja offenbar die Serverzertifikate. Aber offenbar nicht deren Vertrauenswürdigkeit im System? Das müsste man doch irgendwie machen und anzeigen können, der mail befehl macht es ja auch :)
Zitat von: Wernieman am 04 November 2021, 10:32:11
Das Problem mit Browsern ist:
1. Gucken sie auf Websides und nicht auf "Spezialports"
2. Werden sie mit eigenen Stammzertifikaten ausgeliefert
Es kann also sein, das der Browser O.K. anzeigt, das Betriebsystem aber nicht, da dieses eben NICHT die Browser Zertifikate nutzen kann.
Das ist klar.
Das Browserzertifikat hat das gleiche Ablaufdatum, daher habe ich es einfach Mal angenommen :D
Zitat von: Otto123 am 04 November 2021, 10:35:58
Sorry, war gestern Abend offenbar nicht konzentriert genug beim lesen. Mein Focus lag darauf die lokalen liegenden CA Zertifikate zu testen, der Befehl testet ja offenbar die Serverzertifikate. Aber offenbar nicht deren Vertrauenswürdigkeit im System? Das müsste man doch irgendwie machen und anzeigen können, der mail befehl macht es ja auch :)
Das vermute ich auch, nur wie kann man das testen? Vor allem, wieso funktioniert es noch auf Debian?
Bringt es etwas, mit diff die ca-certifikates-Ordner zu vergleichen?
Debian X86 oder ARM?
Zitat von: Wernieman am 04 November 2021, 10:49:35
Debian X86 oder ARM?
ARM auf einem Zyxel NSA325 mit OMV
OMV benutzt postfix und nicht sendemail. Soweit ich das gerade gelesen habe.
Kann das Problem mit sendemail zusammen hängen.
Eigentlich nicht ....
so ein f**k >:(
Funktioniert wieder, muss man nicht verstehen...
TLS=auto hatte ich die ganze Zeit benutzt, mit TLS=no funktioniert es nun :o
Also sendEmail auf Debian installiert -> gleicher Fehler
Postfix auf dem Testsystem installiert, da bin ich mit der Konfig auf die schnelle nicht zurecht gekommen.
Dann bin ich zufällig auf ssmtp gestoßen, was auf meine Router läuft und funktioniert. In der Konfig ist mir dann aufgefallen, dass TLS aus kommentiert ist.
Warum TLS=auto nicht mehr funktioniert ???
Danke für eure Unterstützung
P.S. das verschieben und neu installieren der Zertifikate hatte nichts gebracht.
Damit ist jetzt das Verschlüsseln des Transportprotokols nicht mehr möglich. Kann sein, das es in Zukunft nicht mehr funktioniert, da eigentlich die Anbieter immer mehr auf TLS setzen. Würde jetzt "die Schuld" beim Anbieter suchen ...
Zitat von: Wernieman am 05 November 2021, 08:29:08
Damit ist jetzt das Verschlüsseln des Transportprotokols nicht mehr möglich. Kann sein, das es in Zukunft nicht mehr funktioniert, da eigentlich die Anbieter immer mehr auf TLS setzen. Würde jetzt "die Schuld" beim Anbieter suchen ...
Das vermute ich auch, der Anbieter hat da die letzten Jahre, gerade mit der Migration der alten Domain, immer wieder etwas verändert. Ich beobachte weiter, vieleicht funktioniert auto irgend wann wieder.
Witzig ist, das auf OMV mit Postfix TLS=auto immer noch funktioniert ::)
Hallo,
ich versuche grade sendEmail zum laufen zu bekommen mit GMX.
https://wiki.fhem.de/wiki/E-Mail_senden (https://wiki.fhem.de/wiki/E-Mail_senden)
Ich versuchen zunächset aus der Commandline eine Mail zu senden mit:
sendEmail -vv -f 'User@gmx.net' -t 'empfänger@gmail.com' -u 'subject' -m 'body' -s 'mail.gmx.net:587' -xu 'user@gmx.net' -xp 'Password' -o tls=yes
Ergebniss davon ist:
Nov 05 14:46:44 fhem2021 sendEmail[1172]: DEBUG => Connecting to mail.gmx.net:587
Nov 05 14:46:44 fhem2021 sendEmail[1172]: DEBUG => My IP address is: 192.168.23.555
Nov 05 14:46:44 fhem2021 sendEmail[1172]: DEBUG => evalSMTPresponse() - Found SMTP success code: 220
Nov 05 14:46:44 fhem2021 sendEmail[1172]: SUCCESS => Received: 220 gmx.net (mrgmx105) Nemesis ESMTP Service ready
Nov 05 14:46:44 fhem2021 sendEmail[1172]: INFO => Sending: EHLO fhem
Nov 05 14:46:44 fhem2021 sendEmail[1172]: DEBUG => evalSMTPresponse() - Found SMTP success code: 250
Nov 05 14:46:44 fhem2021 sendEmail[1172]: SUCCESS => Received: 250-gmx.net Hello fhem [109.250.4.191], 250-8BITMIME, 250-SIZE 69920427, 250 STARTTLS
Nov 05 14:46:44 fhem2021 sendEmail[1172]: DEBUG => The remote SMTP server supports TLS :)
Nov 05 14:46:44 fhem2021 sendEmail[1172]: DEBUG => Starting TLS
Nov 05 14:46:44 fhem2021 sendEmail[1172]: INFO => Sending: STARTTLS
Nov 05 14:46:44 fhem2021 sendEmail[1172]: DEBUG => evalSMTPresponse() - Found SMTP success code: 220
Nov 05 14:46:44 fhem2021 sendEmail[1172]: SUCCESS => Received: 220 OK
invalid SSL_version specified at /usr/share/perl5/IO/Socket/SSL.pm line 658.
In diesem File in dieser Zeile steht:
${*$self}{'_SSL_ctx'} = IO::Socket::SSL::SSL_Context->new($arg_hash)
or return;
Den Tip aus dem Wiki mit der Zeil 1907 in /usr/bin/sendEmail have ich überprüft aber das ist schon jetzt so wie im wiki beschrieben.
Was mach ich falsch?
Gruß
Christian
Hallo Christian,
welches System hast Du?
Gruß Otto
Hello Otto,
hab dieses:
cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
und der Kernel:
Linux FHEM 5.10.60-v7+ #1449 SMP Wed Aug 25 15:00:01 BST 2021 armv7l GNU/Linux
Gruß
Christian
Guten Morgen Christian,
ich hatte das vorige Woche auf einem Buster System probiert: sendemail läuft beimir OOTB ohne jede Änderung oder Manipulation, mit einem GMX Postfach.
Ich kann das nicht nachstellen.
Kommt noch mehr Information wenn Du sendemail mit -vvv startest?
Welche Version zeigt sendemail -h
Gruß Otto
Hallo Otto,
das Ergebnis von sendEmail -vv usw. hatte ich einen Beitrag vor deiner Frage nach dem system das ich habe gepostet.
Version von sendemail-1.56
Muss ich noch irgendwelchen Einstellungen in GMX machen?
Gruß
Christian
Hast du es mal mit Port 465 (SSL) oder TLS=auto getestet?
Hi,
hab es mit
sendEmail -vv -f 'User@gmx.net' -t 'empfänger@gmail.com' -u 'subject' -m 'body' -s 'mail.gmx.net:465' -xu 'user@gmx.net' -xp 'Password' -o tls=auto
getestet und das Ergebniss ist:
Nov 09 08:58:40 fhem2021 sendEmail[17929]: DEBUG => Connecting to mail.gmx.net:465
Nov 09 08:58:40 fhem2021 sendEmail[17929]: DEBUG => My IP address is: 192.168.10.211
Nov 09 08:58:50 fhem2021 sendEmail[17929]: ERROR => mail.gmx.net:465 returned a zero byte response to our query.
Gruß
Christian
Hallo Christian,
alle reden von 2G - ich sprach von 3V und nicht von 2V - glaub mir bei -vvv kommt es detailierter. Kann aber sein es wird nicht informativer :)
Hast Du irgendwas "präventiv verbogen" / geändert oder läuft dein Test in einem System so wie es aus der Box kommt?
Ist Dein System so aufgesetzt oder von einer älteren Version "hochgezogen" auf Buster?
Gruß Otto
Hallo Otto,
das system war kein Upgrade ist aber mit dem wachsen von fhem gewachsen.
Das ganze mit 3Vs (auch mit tls=yes der gleiche Fehler):
sendEmail -vvv -f 'User@gmx.net' -t 'empfänger@gmail.com' -u 'subject' -m 'body' -s 'mail.gmx.net:587' -xu 'user@gmx.net' -xp 'Password' -o tls=auto
Ergebnis:
Nov 09 11:52:43 fhem2021 sendEmail[23890]: DEBUG => Assigned $opt{} key/value: tls => auto
Nov 09 11:52:43 fhem2021 sendEmail[23890]: DEBUG => Connecting to mail.gmx.net:587
Nov 09 11:52:43 fhem2021 sendEmail[23890]: DEBUG => My IP address is: 192.168.178.211
Nov 09 11:52:44 fhem2021 sendEmail[23890]: DEBUG => evalSMTPresponse() - Checking for SMTP success or error status in the message: 220 gmx.net (mrgmx104) Nemesis ESMTP Service ready
Nov 09 11:52:44 fhem2021 sendEmail[23890]: DEBUG => evalSMTPresponse() - Found SMTP success code: 220
Nov 09 11:52:44 fhem2021 sendEmail[23890]: SUCCESS => Received: 220 gmx.net (mrgmx104) Nemesis ESMTP Service ready
Nov 09 11:52:44 fhem2021 sendEmail[23890]: INFO => Sending: EHLO fhem2021
Nov 09 11:52:44 fhem2021 sendEmail[23890]: DEBUG => evalSMTPresponse() - Checking for SMTP success or error status in the message: 250-gmx.net Hello fhem2021 [109.250.4.191], 250-8BITMIME, 250-SIZE 69920427, 250 STARTTLS
Nov 09 11:52:44 fhem2021 sendEmail[23890]: DEBUG => evalSMTPresponse() - Found SMTP success code: 250
Nov 09 11:52:44 fhem2021 sendEmail[23890]: SUCCESS => Received: 250-gmx.net Hello fhem2021 [109.250.4.191], 250-8BITMIME, 250-SIZE 69920427, 250 STARTTLS
Nov 09 11:52:44 fhem2021 sendEmail[23890]: DEBUG => The remote SMTP server supports TLS :)
Nov 09 11:52:44 fhem2021 sendEmail[23890]: DEBUG => Starting TLS
Nov 09 11:52:44 fhem2021 sendEmail[23890]: INFO => Sending: STARTTLS
Nov 09 11:52:44 fhem2021 sendEmail[23890]: DEBUG => evalSMTPresponse() - Checking for SMTP success or error status in the message: 220 OK
Nov 09 11:52:44 fhem2021 sendEmail[23890]: DEBUG => evalSMTPresponse() - Found SMTP success code: 220
Nov 09 11:52:44 fhem2021 sendEmail[23890]: SUCCESS => Received: 220 OK
invalid SSL_version specified at /usr/share/perl5/IO/Socket/SSL.pm line 658.
Das ganze mit port 465:
sendEmail -vvv -f 'User@gmx.net' -t 'empfänger@gmail.com' -u 'subject' -m 'body' -s 'mail.gmx.net:465' -xu 'user@gmx.net' -xp 'Password' -o tls=auto
und dessen Ergebnis:
Nov 09 11:53:37 fhem2021 sendEmail[23920]: DEBUG => Assigned $opt{} key/value: tls => auto
Nov 09 11:53:37 fhem2021 sendEmail[23920]: DEBUG => Connecting to mail.gmx.net:465
Nov 09 11:53:37 fhem2021 sendEmail[23920]: DEBUG => My IP address is: 192.168.178.211
Nov 09 11:53:47 fhem2021 sendEmail[23920]: ERROR => mail.gmx.net:465 returned a zero byte response to our query.
Gruß
Christian
Und mit Port 587 und TLS=auto?
Evtl. auch TLS weg lassen.
Laut Webseite:
ZitatSteht in einem Programm "STARTTLS" nicht zur Verfügung, nutzen Sie bitte das Protokoll "TLS". Existiert auch hierfür keine Option, genügt es, die Option "Verschlüsselung" zu aktivieren. Alternativ können Sie für den Postausgangsserver auch Port 465 mit der Verschlüsselung "SSL" nutzen.
Ich glaube nicht an falsches Port oder so, bei mir geht es genau so. Nur mein Empfänger ist ein gmx.de und nicht gmx.net, der Server ist aber der Gleiche. Funktioniert auch mit tls=auto:
@Christian Kannst Du nicht mal auf einem anderen System testen - damit wir wissen ob Dein Aufruf/Deine Adressen stimmen?
sendEmail -vvv -f 'xxx@gmx.de' -t 'xxx@gmail.com' -u 'subject' -m 'body' -s 'mail.gmx.net:587' -xu 'xxx@gmx.de' -xp 'xxx' -o tls=yes
Nov 09 12:33:43 raspib3plus sendEmail[11249]: DEBUG => Assigned $opt{} key/value: tls => yes
Nov 09 12:33:43 raspib3plus sendEmail[11249]: DEBUG => Connecting to mail.gmx.net:587
Nov 09 12:33:43 raspib3plus sendEmail[11249]: DEBUG => My IP address is: 192.168.56.187
Nov 09 12:33:43 raspib3plus sendEmail[11249]: DEBUG => evalSMTPresponse() - Checking for SMTP success or error status in the message: 220 gmx.net (mrgmx004) Nemesis ESMTP Service ready
Nov 09 12:33:43 raspib3plus sendEmail[11249]: DEBUG => evalSMTPresponse() - Found SMTP success code: 220
Nov 09 12:33:43 raspib3plus sendEmail[11249]: SUCCESS => Received: 220 gmx.net (mrgmx004) Nemesis ESMTP Service ready
Nov 09 12:33:43 raspib3plus sendEmail[11249]: INFO => Sending: EHLO raspib3plus
Nov 09 12:33:43 raspib3plus sendEmail[11249]: DEBUG => evalSMTPresponse() - Checking for SMTP success or error status in the message: 250-gmx.net Hello raspib3plus [156.67.137.58], 250-8BITMIME, 250-SIZE 69920427, 250 STARTTLS
Nov 09 12:33:43 raspib3plus sendEmail[11249]: DEBUG => evalSMTPresponse() - Found SMTP success code: 250
Nov 09 12:33:43 raspib3plus sendEmail[11249]: SUCCESS => Received: 250-gmx.net Hello raspib3plus [156.67.137.58], 250-8BITMIME, 250-SIZE 69920427, 250 STARTTLS
Nov 09 12:33:43 raspib3plus sendEmail[11249]: DEBUG => The remote SMTP server supports TLS :)
Nov 09 12:33:43 raspib3plus sendEmail[11249]: DEBUG => Starting TLS
Nov 09 12:33:43 raspib3plus sendEmail[11249]: INFO => Sending: STARTTLS
Nov 09 12:33:43 raspib3plus sendEmail[11249]: DEBUG => evalSMTPresponse() - Checking for SMTP success or error status in the message: 220 OK
Nov 09 12:33:43 raspib3plus sendEmail[11249]: DEBUG => evalSMTPresponse() - Found SMTP success code: 220
Nov 09 12:33:43 raspib3plus sendEmail[11249]: SUCCESS => Received: 220 OK
Nov 09 12:33:43 raspib3plus sendEmail[11249]: DEBUG => TLS: Using cipher: TLS_AES_256_GCM_SHA384
Nov 09 12:33:43 raspib3plus sendEmail[11249]: DEBUG => TLS session initialized :)
Nov 09 12:33:43 raspib3plus sendEmail[11249]: INFO => Sending: EHLO raspib3plus
Nov 09 12:33:43 raspib3plus sendEmail[11249]: DEBUG => evalSMTPresponse() - Checking for SMTP success or error status in the message: 250-gmx.net Hello raspib3plus [156.67.137.58], 250-8BITMIME, 250-AUTH LOGIN PLAIN, 250 SIZE 69920427
Nov 09 12:33:43 raspib3plus sendEmail[11249]: DEBUG => evalSMTPresponse() - Found SMTP success code: 250
Nov 09 12:33:43 raspib3plus sendEmail[11249]: SUCCESS => Received: 250-gmx.net Hello raspib3plus [156.67.137.58], 250-8BITMIME, 250-AUTH LOGIN PLAIN, 250 SIZE 69920427
Nov 09 12:33:43 raspib3plus sendEmail[11249]: DEBUG => SMTP-AUTH: Using LOGIN authentication method
Nov 09 12:33:43 raspib3plus sendEmail[11249]: INFO => Sending: AUTH LOGIN
Nov 09 12:33:43 raspib3plus sendEmail[11249]: DEBUG => evalSMTPresponse() - Checking for SMTP success or error status in the message: 334 VXNlcm5hbWU6
Nov 09 12:33:43 raspib3plus sendEmail[11249]: DEBUG => evalSMTPresponse() - Found SMTP success code: 334
Nov 09 12:33:43 raspib3plus sendEmail[11249]: SUCCESS => Received: 334 VXNlcm5hbWU6
Nov 09 12:33:43 raspib3plus sendEmail[11249]: INFO => Sending: aGVpbnotb3R0by5rbGFzQGdteC5kZQ==
Nov 09 12:33:43 raspib3plus sendEmail[11249]: DEBUG => evalSMTPresponse() - Checking for SMTP success or error status in the message: 334 UGFzc3dvcmQ6
Nov 09 12:33:43 raspib3plus sendEmail[11249]: DEBUG => evalSMTPresponse() - Found SMTP success code: 334
Nov 09 12:33:43 raspib3plus sendEmail[11249]: SUCCESS => Received: 334 UGFzc3dvcmQ6
Nov 09 12:33:43 raspib3plus sendEmail[11249]: INFO => Sending: SGVPdEtsR21EZTEyMzQ=
Nov 09 12:33:43 raspib3plus sendEmail[11249]: DEBUG => evalSMTPresponse() - Checking for SMTP success or error status in the message: 235 Authentication succeeded
Nov 09 12:33:43 raspib3plus sendEmail[11249]: DEBUG => evalSMTPresponse() - Found SMTP success code: 235
Nov 09 12:33:43 raspib3plus sendEmail[11249]: SUCCESS => Received: 235 Authentication succeeded
Nov 09 12:33:43 raspib3plus sendEmail[11249]: DEBUG => User authentication was successful (Method: LOGIN)
Nov 09 12:33:43 raspib3plus sendEmail[11249]: INFO => Sending: MAIL FROM:<xxx@gmx.de>
Nov 09 12:33:44 raspib3plus sendEmail[11249]: DEBUG => evalSMTPresponse() - Checking for SMTP success or error status in the message: 250 Requested mail action okay, completed
Nov 09 12:33:44 raspib3plus sendEmail[11249]: DEBUG => evalSMTPresponse() - Found SMTP success code: 250
Nov 09 12:33:44 raspib3plus sendEmail[11249]: SUCCESS => Received: 250 Requested mail action okay, completed
Nov 09 12:33:44 raspib3plus sendEmail[11249]: INFO => Sending: RCPT TO:<xxx@gmail.com>
Nov 09 12:33:44 raspib3plus sendEmail[11249]: DEBUG => evalSMTPresponse() - Checking for SMTP success or error status in the message: 250 OK
Nov 09 12:33:44 raspib3plus sendEmail[11249]: DEBUG => evalSMTPresponse() - Found SMTP success code: 250
Nov 09 12:33:44 raspib3plus sendEmail[11249]: SUCCESS => Received: 250 OK
Nov 09 12:33:44 raspib3plus sendEmail[11249]: INFO => Sending: DATA
Nov 09 12:33:44 raspib3plus sendEmail[11249]: DEBUG => evalSMTPresponse() - Checking for SMTP success or error status in the message: 354 Start mail input; end with <CRLF>.<CRLF>
Nov 09 12:33:44 raspib3plus sendEmail[11249]: DEBUG => evalSMTPresponse() - Found SMTP success code: 354
Nov 09 12:33:44 raspib3plus sendEmail[11249]: SUCCESS => Received: 354 Start mail input; end with <CRLF>.<CRLF>
Nov 09 12:33:44 raspib3plus sendEmail[11249]: INFO => Sending message body
Nov 09 12:33:44 raspib3plus sendEmail[11249]: Setting content-type: text/plain
Nov 09 12:33:44 raspib3plus sendEmail[11249]: DEBUG => evalSMTPresponse() - Checking for SMTP success or error status in the message: 250 Requested mail action okay, completed: id=1M4JqV-1mkgUw4AWv-000OT3
Nov 09 12:33:44 raspib3plus sendEmail[11249]: DEBUG => evalSMTPresponse() - Found SMTP success code: 250
Nov 09 12:33:44 raspib3plus sendEmail[11249]: SUCCESS => Received: 250 Requested mail action okay, completed: id=1M4JqV-1mkgUw4AWv-000OT3
Nov 09 12:33:44 raspib3plus sendEmail[11249]: Generating a detailed exit message
Nov 09 12:33:44 raspib3plus sendEmail[11249]: Email was sent successfully! From: <xxx@gmx.de> To: <xxx@gmail.com> Subject: [subject] Server: [mail.gmx.net:587]
@Christian, hast du die Änderungen aus dem Wiki wieder zurück gedreht?
Hallo,
Steps die ich gemacht habe:
01. Raspian RasPi Imager auf SD Karte installiert
02. SSH datei angelegt
03. Einstecken in the PI und booten
04. per SSH einloggen
sudo apt-get update
sudo apt-get dist-upgrade
05. Welche Version mit cat /etc/os-release prüfen
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
06. Beschreinung nach [link]https://wiki.fhem.de/wiki/E-Mail_senden[/link] folgen und folgendes machen:
sudo apt-get update
sudo apt-get install sendemail libio-socket-ssl-perl libnet-ssleay-perl perl
07. reboot des PIs
08. sendemail versions check sendemail -h
Ergebnis:
sendemail-1.56 by Brandon Zehm
09. Test mit sendEmail -vvv -f 'User@gmx.net' -t 'empfänger@gmail.com' -u 'subject' -m 'body' -s 'mail.gmx.net:465' -xu 'user@gmx.net' -xp 'Password' -o tls=auto
Ergebnis (kein unterschied ob mit oder ohne -o tls=yes):
Nov 09 13:26:44 raspberrypi sendEmail[1209]: DEBUG => Connecting to mail.gmx.net:465
Nov 09 13:26:44 raspberrypi sendEmail[1209]: DEBUG => My IP address is: 192.168.10.31
Nov 09 13:26:54 raspberrypi sendEmail[1209]: ERROR => mail.gmx.net:465 returned a zero byte response to our query.
10. Test mit sendEmail -vvv -f 'User@gmx.net' -t 'empfänger@gmail.com' -u 'subject' -m 'body' -s 'mail.gmx.net:587' -xu 'user@gmx.net' -xp 'Password' -o tls=auto
Ergebnis:
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => Assigned $opt{} key/value: tls => auto
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => Connecting to mail.gmx.net:587
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => My IP address is: 192.168.10.31
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => evalSMTPresponse() - Checking for SMTP success or error status in the message: 220 gmx.net (mrgmx104) Nemesis ESMTP Service ready
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => evalSMTPresponse() - Found SMTP success code: 220
Nov 09 13:28:05 raspberrypi sendEmail[1283]: SUCCESS => Received: 220 gmx.net (mrgmx104) Nemesis ESMTP Service ready
Nov 09 13:28:05 raspberrypi sendEmail[1283]: INFO => Sending: EHLO raspberrypi
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => evalSMTPresponse() - Checking for SMTP success or error status in the message: 250-gmx.net Hello raspberrypi [109.250.4.191], 250-8BITMIME, 250-SIZE 69920427, 250 STARTTLS
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => evalSMTPresponse() - Found SMTP success code: 250
Nov 09 13:28:05 raspberrypi sendEmail[1283]: SUCCESS => Received: 250-gmx.net Hello raspberrypi [109.250.4.191], 250-8BITMIME, 250-SIZE 69920427, 250 STARTTLS
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => The remote SMTP server supports TLS :)
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => Starting TLS
Nov 09 13:28:05 raspberrypi sendEmail[1283]: INFO => Sending: STARTTLS
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => evalSMTPresponse() - Checking for SMTP success or error status in the message: 220 OK
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => evalSMTPresponse() - Found SMTP success code: 220
Nov 09 13:28:05 raspberrypi sendEmail[1283]: SUCCESS => Received: 220 OK
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => TLS: Using cipher: TLS_AES_256_GCM_SHA384
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => TLS session initialized :)
Nov 09 13:28:05 raspberrypi sendEmail[1283]: INFO => Sending: EHLO raspberrypi
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => evalSMTPresponse() - Checking for SMTP success or error status in the message: 250-gmx.net Hello raspberrypi [109.250.4.191], 250-8BITMIME, 250-AUTH LOGIN PLAIN, 250 SIZE 69920427
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => evalSMTPresponse() - Found SMTP success code: 250
Nov 09 13:28:05 raspberrypi sendEmail[1283]: SUCCESS => Received: 250-gmx.net Hello raspberrypi [109.250.4.191], 250-8BITMIME, 250-AUTH LOGIN PLAIN, 250 SIZE 69920427
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => SMTP-AUTH: Using LOGIN authentication method
Nov 09 13:28:05 raspberrypi sendEmail[1283]: INFO => Sending: AUTH LOGIN
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => evalSMTPresponse() - Checking for SMTP success or error status in the message: 334 VXNlcm5hbWU6
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => evalSMTPresponse() - Found SMTP success code: 334
Nov 09 13:28:05 raspberrypi sendEmail[1283]: SUCCESS => Received: 334 VXNlcm5hbWU6
Nov 09 13:28:05 raspberrypi sendEmail[1283]: INFO => Sending: a29obGVAZ214Lm5ldA==
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => evalSMTPresponse() - Checking for SMTP success or error status in the message: 334 UGFzc3dvcmQ6
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => evalSMTPresponse() - Found SMTP success code: 334
Nov 09 13:28:05 raspberrypi sendEmail[1283]: SUCCESS => Received: 334 UGFzc3dvcmQ6
Nov 09 13:28:05 raspberrypi sendEmail[1283]: INFO => Sending: SGl0YWNoaUNFMjAxMw==
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => evalSMTPresponse() - Checking for SMTP success or error status in the message: 535 Authentication credentials invalid
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => evalSMTPresponse() - Found SMTP error code: 535
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => SMTP-AUTH: LOGIN authenticaion failed.
Nov 09 13:28:05 raspberrypi sendEmail[1283]: ERROR => ERROR => SMTP-AUTH: Authentication to mail.gmx.net:587 failed.
Das wundert mich jetzt aber sehr den ich kann mich in der GUI wunderbar bei GMX einloggen.
Habs auch in thunderbird mal angelegt und dort klappt das auch ohne probleme mit dem selben Daten.
Und noch etwas. Habe wireshark mal benutzt um zu sehen was Thunderbird für eine TLS version benutzt in Verbindung mit gmx. Antwort TLSv1.3
Gruß
Christian
Folgendes laut WIKI kontrolliert?
Zitat(Hinweis: manche Provider (z.B. gmail) lassen diesen Zugang erst nach Freischaltung zu!).
Nov 09 13:28:05 raspberrypi sendEmail[1283]: DEBUG => SMTP-AUTH: LOGIN authenticaion failed.
da hätte ich doch eher auf ein falsches Passwort getippt -> Tippfehler??
Zitat von: Kohle77 am 09 November 2021, 14:50:22
Und noch etwas. Habe wireshark mal benutzt um zu sehen was Thunderbird für eine TLS version benutzt in Verbindung mit gmx. Antwort TLSv1.3
👍
Geht auch hiermit https://ciphersuite.info/cs/TLS_AES_256_GCM_SHA384/ :)
Zumindest gibt es jetzt keinen TLS Fehler mehr, d.h. in Deinen ursprünglichen System steckt noch ein Problem.
Ich würde auch auf Tippfehler tippen - GMX braucht meines Wissen die von Werner angesprochene Freischaltung nicht.
Gruß Otto
Dort stand ja auch gmail und nicht gmx .. ::)
War mir aber nicht sicher, wo er seine EMail hat ...
Guten morgen,
ja es war ein Tippfehler... Asche auf mein Haupt.
Jetzt muss ich nur noch mein anderes System hinbiegen das es von dort auch funktioniert.
Es sind somit keine settings bei gmx zu machen.
Danke and alle.
Gruß
Christian
Dann viel Erfolg.
Kannst mal mit reinstall probieren.
sudo apt install --reinstall sendemail
Guten Morgen,
gute Nachricht. Es wäre wirklich interessant zu wissen an welcher Stelle es klemmt.
Fakt ist offenbar:
Am sendemail muss nichts korregiert werden.
An der SSL.pm muss nix korregiert werden.
In letzter Zeit fiel immer mal Stammzertifikate auf die aktualisiert werden mussten.
Aber irgendwie habe ich keine Idee zum suchen.
::) ???
Gruß Otto
Zitat von: Kohle77 am 05 November 2021, 15:03:58
Den Tip aus dem Wiki mit der Zeil 1907 in /usr/bin/sendEmail have ich überprüft aber das ist schon jetzt so wie im wiki beschrieben.
Was meinst du damit?Es sollte folgendes dort stehenZitatif (! IO::Socket::SSL->start_SSL($SERVER, SSL_version => 'SSLv3 TLSv1')) {
Oh nein! Aktuell steht in der Zeile 1933:
grep -n SSLv /usr/bin/sendEmail
1933: if (! IO::Socket::SSL->start_SSL($SERVER, SSL_version => 'SSLv23:!SSLv2')) {Und man muss nichts ändern!
ZitatDas SSL v3 Protokoll wird von den meistens Servern im Web nicht mehr akzeptiert.
Zitat von: Otto123 am 10 November 2021, 10:49:15
Oh nein! Aktuell steht in der Zeile 1933:
grep -n SSLv /usr/bin/sendEmail
1933: if (! IO::Socket::SSL->start_SSL($SERVER, SSL_version => 'SSLv23:!SSLv2')) {
Und man muss nichts ändern!
Sorry, ich komme aktuell nicht an mein System und hatte mich am Wiki und TLS orientiert ::)
Ich streiche es im vorigen Beitrag.
Hallo,
um noch die Finale Antwort zu lieferen.
Ich habe mir einen neuen Master PI FHEM server aufgesetzt.
Auf diesen habe ich das Backup des originalen FHEM Servers eingespielt und siehe da auf dem neuen FHEM Server kann ich mails aus der command line verschicken.
Muss also irgendwas verstrubbelt haben auf dem alten Server.
Gruß
Christian