Seit 09.03. werden von FHEM keine E-Mails gesendet.
Es muss etwas mit TLS zu tun haben soweit ich bei einem Testmail aus dem LOG feststellen kann.
2018.04.14 18:23:21.601 5: Cmd: >set BATALM ALARM<
2018.04.14 18:23:21.606 1: sendEmail RCP: name@domain.at
2018.04.14 18:23:21.607 1: sendEmail Subject: FHEM Batteriewarnung
2018.04.14 18:23:21.609 1: sendEmail Text: FHEM - Batterie Warnung von Gerät: Sonnen Intensität (Oregon)
2018.04.14 18:23:21.609 1: sendEmail Anhang:
2018.04.14 18:23:22.058 1: sendEmail returned: Apr 14 18:23:22 ccs-ht-rasp01 sendEmail[7402]: ERROR => TLS setup failed: SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
2018.04.14 18:23:22.060 5: Cmd: >setreading BATALD THGR810_2 ALARM<
Ich habe aber keine Änderungen was das TLS betrifft ausgeführt.
Hat sich etwas bei FHEM geändert?
Das sieht so aus, als ob sich an dem Mailserver, über den Du verschickst das Zertifikat geändert hat oder ungültig geworden ist. Schau mal mit openssl s_client nach, was der Server da für ein Zertifikat ausliefert und ob Dein TLS dem traut.
Gruß,
Reiner
Wie ist das mit openssl s_client gemeint?
https://www.thomas-krenn.com/de/wiki/TCP_Port_443_(https)_Zugriff_mit_openssl_überprüfen
Du darfst gerne das Teil zwischen Deinen Ohren verwenden.
Die Ausgabe dann hier posten.
Du bist wieder einmal sehr lustig mit deinen Texten. ::)
Wie soll ich auf diese Seite kommen wenn ich damit noch nie etwas damit zu tun hatte.
Bitte behalte dir künftig solche Bemerkung. Diese tragen nicht zu einer Lösung bei.
Im übrigem ist dies der passende Link.
https://www.thomas-krenn.com/de/wiki/TCP_Port_443_(https)_Zugriff_mit_openssl_%C3%BCberpr%C3%BCfen
Jedenfalls bekomme ich nichts vernüftiges angezeigt wenn ich die Abfrage auf einem anderem Raspberry starte.
Die DNS bzw. HOST Bezeichnung im Zertifikat lautet ccs-ht-rasp01.ccs-media.local.
Auf Konsole des ccs-ht-rasp02 ausgeführt
~$ openssl s_client -connect ccs-ht-rasp01.ccs-media.local:https
1995568544:error:20087002:BIO routines:BIO_lookup:system lib:../crypto/bio/b_addr.c:693:Name or service not known
connect:errno=0
Test nur mit der HOST Bezeichnung
~ $ openssl s_client -connect ccs-ht-rasp01:https
1995765152:error:0200206F:system library:connect:Connection refused:../crypto/bio/b_sock2.c:108:
1995765152:error:2008A067:BIO routines:BIO_connect:connect error:../crypto/bio/b_sock2.c:109:
connect:errno=111
Na dann sollte ja der Rest kein Problem mehr sein.
Kann mir jemand sagen was diese Meldung hervorruft?
~$ openssl s_client -connect ccs-ht-rasp01.ccs-media.local:https
1995568544:error:20087002:BIO routines:BIO_lookup:system lib:../crypto/bio/b_addr.c:693:Name or service not known
connect:errno=0
Ähm kurze Frage, wieso rufst du deinen Raspi auf und wieso 443. Ich dachte du hast Probleme mit deinem Mailprovider?
Zitat von: reibuehl am 14 April 2018, 19:37:23
Das sieht so aus, als ob sich an dem Mailserver, über den Du verschickst das Zertifikat geändert hat oder ungültig geworden ist. Schau mal mit openssl s_client nach, was der Server da für ein Zertifikat ausliefert und ob Dein TLS dem traut.
Gruß,
Reiner
ZitatÄhm kurze Frage, wieso rufst du deinen Raspi auf und wieso 443. Ich dachte du hast Probleme mit deinem Mailprovider?
Ich habe nichts von einem Provider erwähnt oder 443.
Das ist ein interner Mail Server über dem das Email versendet wurde und wird.
Ich habe jetzt kurzer Hand das TLS für den Mailversand ausgeschalte an diesem Raspberry und den Port gewechselt für ohne TLS.
sub
DebianMail
{
my $rcpt = shift;
my $subject = shift;
my $text = shift;
my $attach = shift;
my $ret = "";
my $sender = "fhem\@domain.local";
my $konto = "konto\@domain.local";
my $passwrd = "paswort";
my $provider = "IP:4587";
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' -a '$attach' -s '$provider' -xu '$konto' -xp '$passwrd' -o tls=no -o message-charset=utf-8);
$ret =~ s,[\r\n]*,,g; # remove CR from return-string
Log 1, "sendEmail returned: $ret";
}
Dann probiere es doch mal auf der Console, mach es Dir doch erstmal einfacher
sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text' -a '$attach' -s '$provider' -xu '$konto' -xp '$passwrd' -o tls=no -o message-charset=utf-8
Und Du sendest bestimmt an einen Provider Deine Mail (hier Anonymisiert),
my $provider = "IP:4587";
Sorry, aber so können wir Dir nicht helfen.
1. Was sagt der SSL Check bezüglich Deines EMail-Providers?
2. An WEN versendest Du Mails (Mailprovider)
Zitat von: Burny4600 am 15 April 2018, 17:09:36
Ich habe nichts von einem Provider erwähnt oder 443.
Das ist ein interner Mail Server über dem das Email versendet wurde und wird.
Ich habe jetzt kurzer Hand das TLS für den Mailversand ausgeschalte an diesem Raspberry und den Port gewechselt für ohne TLS.
sub
DebianMail
{
my $rcpt = shift;
my $subject = shift;
my $text = shift;
my $attach = shift;
my $ret = "";
my $sender = "fhem\@domain.local";
my $konto = "konto\@domain.local";
my $passwrd = "paswort";
my $provider = "IP:4587";
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' -a '$attach' -s '$provider' -xu '$konto' -xp '$passwrd' -o tls=no -o message-charset=utf-8);
$ret =~ s,[\r\n]*,,g; # remove CR from return-string
Log 1, "sendEmail returned: $ret";
}
Na um so besser wenn der Mailserver intern und Deiner ist. Da er unter Deiner Hoheit und Administration steht solltest Du ja wissen ob Dein Zertifikat abgelaufen ist oder nicht.
Es ist kein Zertifikat abgelaufen.
Die Zertifikate habe ich mit einer Laufzeit von 15 Jahren erstellt.
Die Installation von SSL/TLS hatte ich nach dieser Anleitung ausgeführt.
https://wiki.fhem.de/wiki/FHEM_mit_HTTPS_SSL-Zertifikat_und_eine_eigene_Zertifizierungsstelle
Ist euch auch geläufig als Errichter.
Als Hinweis würden mir besser Angaben helfen, denn ich bin kein SSL/TLS Experte.
Ich habe mich auch mit Testmails gespielt um es einzugrenzen.
Testmail
{ DebianMail ('name@domain.local','Test','Test-Text');; }
Ohne SSL Aktivierung über Port 4587 funktioniert es.
2018.04.15 17:43:39.210 1: sendEmail RCP: ccs-ht-rasp01@ccs-media.local
2018.04.15 17:43:39.211 1: sendEmail Subject: Test
2018.04.15 17:43:39.212 1: sendEmail Text: Test-Text
2018.04.15 17:43:39.212 1: sendEmail Anhang:
2018.04.15 17:43:39.213 1: PERL WARNING: Use of uninitialized value $attach in concatenation (.) or string at ./FHEM/99_myUtils.pm line 61.
2018.04.15 17:43:39.927 1: sendEmail returned: Apr 15 17:43:39 ccs-ht-rasp01 sendEmail[12752]: Email was sent successfully!
Outlook verschickt auch über SSL über den internen Mailserver über Port 4465 und hat keine Probleme.
Nur DebianMail will aus irgendeinem Grund mit aktivem SSL nicht mehr über diesen Port die Mails verschicken.
{ DebianMail ('name@domain.local','Test','Test-Text');; }
2018.04.15 17:58:41.988 1: sendEmail RCP: ccs-ht-rasp01@ccs-media.local
2018.04.15 17:58:41.990 1: sendEmail Subject: Test
2018.04.15 17:58:41.991 1: sendEmail Text: Test-Text
2018.04.15 17:58:41.992 1: sendEmail Anhang:
2018.04.15 17:58:47.422 1: sendEmail returned: Apr 15 17:58:47 ccs-ht-rasp01 sendEmail[13130]: ERROR => 192.168.17.1:4465 returned a zero byte response to our query.
Wie führe ich den SSL Check bezüglich aus?
Versendet wird intern an eine ZTL Emailadresse die dann weiter je nach Fehler anschließend an andere E-Mail Adressen weiter verteilt wird.
Dieser Part funktioniert auch. Geprüft ohne SSL Verwendung.
Ich hoffe das es jetzt soweit verständlich ist.
sendEmail ist das eigentliche Linuxprogramm welches die Mail verschickt. DebianMail ist ja nur eine Funktion.
Schaue dir bitte die manpage zu sendEmail an so kannst du kurze Testmails schicken und mit -vvv als Option eine erweiterte Ausgabe erzwingen.
Wir hatten hier erst kürzlich ein Thema zu dem Programm, ich schaue mal.
Wie ich in meinem Beitrag beschrieben habe, kannst Du bitte auf der Console (putty, ssh) testen?
Und ... Deine Beschreibung bezüglich Zertifikat ist FHEM, NICHT Mail.
Was für einen mailserver hast Du denn lokal laufen?
Bin wieder zurück.
Anscheinend gibt es größere Änderungen bei Microsoft und Linux betreffend SSL,TLS die noch nicht wirklich zusammenpassen was ich in der Zwischenzeit herausgefunden habe.
Der verwendete Mail Server unter Windows 2008 R2 64Bit nennt sich JanaServer.
@Wernieman
Zitatkannst Du bitte auf der Console (putty, ssh) testen?
Was genau hast du damit gemeint.
Via Putty SSH komme ich auf die Konsole vom Jessie Linux.
Wolltest du das wissen?
Ich muss mich mit den Änderung von SMB noch mehr auseinandersetzten das es bei Verwendung vom aktuellen Jessie Stretch als default Min Version SMB 2.0 jetzt verwendet und dies aber mit Windows immer einen Fehler im Log ergibt.
CIFS VFS: ioctl error in smb2_get_dfs_refer rc=-2SMB 2.1 ist als Default für Windows Server 2008 R2 und Windows 7 nach den aktuellen Updates.
Ich denke das dies auch bei dem Mail Versandt einen Einfluss darauf hat.
SMB brauchst Du aber nicht für Mail ... ?????
mit "kannst Du bitte auf der Console (putty, ssh) testen?" meinte ich, das Du Dein DebianMail OHNE FHEM testest.
Wenn Du Dir mal folgende Zeile Ansiehst:
$ret .= qx(sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text' -a '$attach' -s '$provider' -xu '$konto' -xp '$passwrd' -o tls=no -o message-charset=utf-8);
sendEmail ist "nur" ein externes Script, was FHEM aufrufen soll. Du kannst also sendEmail mal manuell auf der Konsole ausprobieren ....
Hi,
mir fällt da gerade ein: Es gab doch so ein Problem mit sendemail und SSL.pm in einer älteren Version, damals als alle Provider die Zertifikate geändert haben und SSLv3 abgeschaltet wurde.
Von wann ist dein sendemail? Versionsnummer bei Start ist eventuell nicht wirklich relevant, eher Datei Datum und Datei Größe.
Was ist es überhaupt für ein System? Aktuelles Stretch/Jessie oder was älteres?
Gruß Otto