E-Mail Benachrichtigung geht nicht

[Hagen2000]

Spitze! Vielen Dank.

[mathias.o]

Servus,

ich hänge mich mal mit ran und würde gern von meinen Problemen mit der Mail-Benachrichtigung berichten.

Ich benutze ein Konto von Microsoft (benutzername@outlook.de) und habe verschiedene smtp-Server Einstellungen/Adressen probiert - alles ohne Erfolg. Ich habe nun mehrfach Testmails versendet, die allerdings nur im Puffer landen. Trotz mehrfachem "clearen" bleibt eine Mail im Puffer. Ein Neustart behebt den Fehler leider nicht. Was mich nun wundert ist, dass der Trace weder für "Mail-Client" noch bei "SMTP-Client" eine Ausgabe erstellt.

Hier der Link zu den Einstellungen zu Outlook.com
https://support.microsoft.com/de-de/off ... 414e2aa040

[Hagen2000]

Hallo Mathias, lange nichts los gewesen in diesem Thread

Ich gehe mal davon aus, dass Du auf dem Screenshot den Benutzernamen verkürzt hast und nicht wirklich "@outlook.de" verwendest.
Hast Du mal versucht, die Authentifizierung auf "Bevorzugt Klartext" umzustellen? Sollte ja kein Problem sein, da Du ohnehin STARTTLS verwendest.
Ansonsten würde ich den E-Mail-Versand mal mit einem anderen E-Mail-Client (z. B. Thunderbird) probieren und dann die funktionierenden Einstellungen in den Router übernehmen.

[Dr.Einstein]

Was mich nun wundert ist, dass der Trace weder für "Mail-Client" noch bei "SMTP-Client" eine Ausgabe erstellt.

Wenn hier keine Ausgabe erfolgt, liegt in der Regel schon vorher ein Problem vor, z.B. dass der Router keine Namensauflösung hinbekommt oder selbst keine passende Route besitzt zum entsprechenden Loopback-Interface.

Gruß Dr.Einstein

[mathias.o]

@Hagen2000
Jupp - habe die Einträge mit Paint gekürzt. Konnte in einem Outlook auch Mails empfangen. Ich werde die Einstellung mal testen. Aufgrund anderer Arbeiten wird das sicher erst in KW14.

@Dr.Einstein
Der Ping nach 8.8.8.8 war erfolgreich. Kann ich per Konsole die Namensauflösung testen?

Vielen Dank trotzdem für die Hinweise

[Dr.Einstein]

Der Ping nach 8.8.8.8 war erfolgreich. Kann ich per Konsole die Namensauflösung testen?

Code: Alles auswählen

ping -a <Name des Quellnetzwerkes> google.de

Alternativ direkt

Code: Alles auswählen

ping google.de

wenn du keine ARF Tags etc benutzt. Kommen nirgends Antworten, mach vor dem Befehl noch ein

Code: Alles auswählen

trace # dns

und analysier den Fall.

[backslash]

Hi Dr.Einstein

seit der 10.50 git es auch ein "dig" ahnliches tool auf dem CLI... nennt sich dns_query:

Code: Alles auswählen

> dns_query ?
dnsquery command line options:
dnsquery [-t ...] [-d ...] name[@rtg-tag]

name              name to be resolved
@rtg-tag          routing tag to reach DNS servers (if no destination is pre set)
-t <type>         Typ: A, AAAA, PTR, SRV, NAPTR
-d <destination>  destination to reach DNS server

if no type is set, AAAA and A query is done
on type PTR the address has to be used as query name
<CR> stops running query

Als "destination" kann entweder die IP-Adresse des DNS-Servers (z.B. 8.8.8.8 für goggle) oder ein WAN-Interface (dem DNS-Server vom Provider zugewiesen wurden) angegeben werden.

wird keine "destination" angegeben, so nutzt die konfiguration des DNS-Forwarders

Gruß
Backslash

[reboot]

Hallo Allerseits,

ich hoffe es ist richtig, diesen Tread nach so langer Zeit fortzuführen.
Ich habe bei meinem Router (1784VA mit Fw 10.50.1050RU9) alle SMTP Einstellungen überprüft und diese sind genau wie bei anderen meiner Geräte, die damit erfolgreich Emails senden können.
Auf

Code: Alles auswählen

TestMail * meine@adresse.de test

bekomme ich folgende Trace Meldung:

Code: Alles auswählen

Building transport for <mail-server> failed. Terminate SMTP transfer.

Das ist sehr Aussagekräftig und ich habe zu dieser Fehlermeldung auch nichts in Googles Keller gefunden.
Hat jemand eine Idee, was mein Problem sein könnte?

Vieeelen Dank.
Gruß
Ralf

[tstimper]

Auf

Code: Alles auswählen

TestMail * meine@adresse.de test

bekomme ich folgende Trace Meldung:

Code: Alles auswählen

Building transport for <mail-server> failed. Terminate SMTP transfer.

Das ist sehr Aussagekräftig und ich habe zu dieser Fehlermeldung auch nichts in Googles Keller gefunden.
Hat jemand eine Idee, was mein Problem sein könnte?

Vieeelen Dank.
Gruß
Ralf

Wenn es auf anderen Geräten geht und nur auf dem einen nicht würde ich mal einen Packet Trace machen und schauen, was da sichtbar ist.

Bei uns hatte die Telekom am Business Anschluss (ohne Information an uns ..) mal Port 25 ausgehend gesperrt, nachdem ich dreimal hintereinander Updates zu einem Meeting an eine größere externe Teilnehmer Zahl geschickt hatte. Eingehende Emails funktionierten, uns war ewig nicht klar, was das Problem war. Eingehende Emails funktionierten die ganze Zeit.

Haben bestimmt drei Stunden im Mailserver und Spamfilter nach der Ursache gesucht.

Wir hatten da auch den armen Lancom Router verdächtigt, aber er war nicht schuld
Im Lancom Firewal Log haben wir gesehen, das das Paket dem Router richtung WAN verlassen wollte.

Ich habe dann die Anzahl gleichzeitiger SMTP Sessions veringert...


Viele Grüße

ts

[mathias.o]

Servus,

ich habe mich nach einiger Zeit nun mal wieder dem Thema gewidmet und erfolgreich gelöst.

Dazu habe ich einen anderen Account bei T-Online angelegt, der anfangs auch nicht funktionieren wollte. Im Trace wurde immer nur die Meldung "TCP Connection closed by peer" generiert. Meine Lösung dafür war das Umstellen des Port für die verwendete Verschlüsselung auf 587 in Verbindung mit STARTTLS.

T-Online funktioniert hier einfach besser, wenn man beachtet, dass man für den externen Zugriff ein separates Passwort anlegen muss. Das ist bei vielen Anbietern mittlerweile üblich und man wird im Portal doch recht deutlich darauf hingewiesen.

Vielen Dank an den Thread hier und im speziellen an GrandDixence.

[jal]

Hallo zusammen,

ich habe das selbe Problem wie mathias.o, es werden keine Mails verschickt. Eine Mails bleibt nach dem Löschen des Puffers immer noch drin und keine Mails gehen mehr raus. Ein Trace von Mail-Client und SNTP liefern keine Ausgabe!!!

Ich bin von eine Lancom Router 831a auf eine 1800VAW-G4 umgestiegen.
Ich trenne die VDSL-Verbindung selbst um 04:59 und lasse mir beim Ab- und Aufbau der Leitung eine Mail schicken (Aktions-Tabelle).
Beim 831a hat alles wunderbar funktioniert. Beim 1800VAW-G4 gibt es Probleme (Firmware 10.80.0233RU1).

Es beibt die 1. Mail im Puffer und nichts geht mehr.
Prinzipell funktioniert meine Konfiguration.
Das Problem kann ich nur lösen, wenn ich die Aktions-Tabelle deaktiviere, einen Neustart des Routers durchführe und den Mail-Puffer lösche. Dann funktioniert der Mail-Versand und auch Trace von Mail-Client und SNTP. Mit testmail und auch der wieder aktivierten Aktions-Tabelle. Ich bekomme dann die Mails (testmail und Aktions-Tabelle), allso der Mail-Account und meine Konfiguration stimmen.

Um 04:59 Uhr kommt dann der Leitungsabbau + Neuaufbau und die Mails klemmen wieder im Puffer und die 1. Mail lässt sich nicht löschen. Ich vermute mal einen Bug in der Firmware. Die 1. Mail klemmt wegen nich vorhandener VDSL-Verbindung.

Code: Alles auswählen

root@L1800VAW4G:/Status/Mail
> ls

Buffered-Mails     INFO:    1
Discarded-Mails    INFO:    0
Sent-Mails         INFO:    0
Clear-Buffer       ACTION:
Delete-Statistics  ACTION:

root@L1800VAW4G:/Status/Mail
>

root@L1800VAW4G:/Status/Mail
> do Clear-Buffer
OK: Action Clear-Buffer done

root@L1800VAW4G:/Status/Mail
> do Delete-Statistics
OK: Action Delete-Statistics done

root@L1800VAW4G:/Status/Mail
> ls

Buffered-Mails     INFO:    1
Discarded-Mails    INFO:    0
Sent-Mails         INFO:    0
Clear-Buffer       ACTION:
Delete-Statistics  ACTION:

root@L1800VAW4G:/Status/Mail
>
root@L1800VAW4G:/Status/Mail
> trace + mail
Mail-Client                ON

root@L1800VAW4G:/Status/Mail
> trace + sntp
SNTP                       ON

root@L1800VAW4G:/Status/Mail
> testmail xxx@xxx.ruhr.de xxx@xxx.ruhr.de sieben acht neun

root@L1800VAW4G:/Status/Mail

root@L1800VAW4G:/Status/Mail
> ls

Buffered-Mails     INFO:    2
Discarded-Mails    INFO:    0
Sent-Mails         INFO:    0
Clear-Buffer       ACTION:
Delete-Statistics  ACTION:

root@L1800VAW4G:/Status/Mail
> do Clear-Buffer
OK: Action Clear-Buffer done

root@L1800VAW4G:/Status/Mail
> ls

Buffered-Mails     INFO:    1
Discarded-Mails    INFO:    1
Sent-Mails         INFO:    0
Clear-Buffer       ACTION:
Delete-Statistics  ACTION:

root@L1800VAW4G:/Status/Mail

root@L1800VAW4G:/Setup/Mail
> ls

SSL                  MENU:
Buffers              VALUE:   100
E-Mail-Sender        VALUE:   xxx@xxx.ruhr.de
Hold-Time-(hrs.)     VALUE:   72
Loopback-Addr.       VALUE:   INTRANET
POP3-Port            VALUE:   110
POP3-Server          VALUE:   xxx.ruhr.de
Password             VALUE:   *
SMTP-Authentication  VALUE:   Preferred-Encrypted
SMTP-Port            VALUE:   25
SMTP-Server          VALUE:   xxx.ruhr.de
SMTP-use-TLS         VALUE:   Preferred
Send-Again-(min.)    VALUE:   30
User-Name            VALUE:   xxx@xxx.ruhr.de

[MoinMoin]

Moin, moin,

da scheint eine Mail beim Senden steckengeblieben zu sein. Ansonsten müsste sie sich löschen lassen. Nach einem Kaltstart des Routers sollte die weg sein. Wenn das Senden dann weiterhin nicht funktioniert, würde ich zuerst alle Benachrichtigungen deaktivieren, einen Kaltstart durchführen und dann bei aktiviertem Trace eine Testmail verschicken.

Ciao, Georg

[Hagen2000]

Bei uns funktioniert der E-Mail-Versand über securesmtp.t-online.de nicht mehr.
Die Konfiguration schaut fast identisch aus wie die von mathias.o ein paar Beiträge vorher.

Der LANtracer schreibt:

Code: Alles auswählen

[Mail-Client] 2024/02/07 15:00:11,045  Devicetime: 2024/02/07 15:00:11,378
C:STARTTLS<CRLF>

[Mail-Client] 2024/02/07 15:00:11,045  Devicetime: 2024/02/07 15:00:11,397
S:220 2.0.0 Ready to start TLS.<CRLF> 

[Mail-Client] 2024/02/07 15:00:11,045  Devicetime: 2024/02/07 15:00:11,397
<Opening TLS connection for SMTP to securesmtp.t-online.de>

[Mail-Client] 2024/02/07 15:00:41,028  Devicetime: 2024/02/07 15:00:41,430
<Could not open TLS connection to securesmtp.t-online.de>

Nach 30 Sekunden wird kommentarlos die Verbindung geschlossen. Zugangsdaten wurden verifiziert. Ein anderer Provider klappt problemlos.
Woran kann das liegen?

[rotwang]

Was in dieser halben Minute passiert ist, wird Dir am ehesten ein TLS-Trace verraten. Den bitte nicht über den LANtracer machen, sondern direkt auf der CLI, weil der LANtracer selber per Telnet über SSL/TLS auf die LCOS-CLI zugreift, und man einen Schneeballeffekt kriegt.

[Hagen2000]

Das schaut dann so aus:

Code: Alles auswählen

[TLS] 2024/02/07 15:51:27,799
Sending Client Hello on connection 2182:
-> start key share computation


[TLS] 2024/02/07 15:51:27,799
Performing Client Hello generation for connection 2182:


[TLS] 2024/02/07 15:51:27,800
Client Hello generation performed on connection 2182 (took 868 us)
--> client hello generation succeeded, ready to send client hello


[TLS] 2024/02/07 15:51:27,801
Sending Client Hello on connection 2182:
-> adding renegotiation_info extension to client hello
-> offering TLS 1.2 or below, offering extended master secret option as well
-> offering encrypt-then-mac option
-> all fine, receive Server Hello


[TLS] 2024/02/07 15:51:27,822
Receiving Server Hello on connection 2182:
-> cipher suite selected by server is TLS_AES_256_GCM_SHA384
-> parsing TLS extensions
-> protocol version is TLSv1.3
-> select cipher:
 -> check cipher TLS_AES_256_GCM_SHA384
 -> PFS suite or no PFS preference, selection done
-> selected elliptic curve point format is uncompressed
-> server turned down extended master secret option
-> server turned down Encrypt-then-MAC option
-> received hello retry request
--> new named group is secp384r1, preparing another client hello


[TLS] 2024/02/07 15:51:27,822
Sending Client Hello on connection 2182:
-> start key share computation


[TLS] 2024/02/07 15:51:27,823
Performing Client Hello generation for connection 2182:


[TLS] 2024/02/07 15:51:27,841
Client Hello generation performed on connection 2182 (took 18566 us)
--> client hello generation succeeded, ready to send client hello


[TLS] 2024/02/07 15:51:27,841
Sending Client Hello on connection 2182:
-> adding renegotiation_info extension to client hello
-> offering TLS 1.2 or below, offering extended master secret option as well
-> offering encrypt-then-mac option
--> sent dummy Change CipherSpec
-> all fine, receive Server Hello


[TLS] 2024/02/07 15:51:57,840
Closing connection 2182 because handshake did not complete within 30 seconds


[TLS] 2024/02/07 15:51:57,840
Preparing records to send on connection 2182:
-> not in application state, bailing out


[TLS] 2024/02/07 15:51:57,840
Closing connection 2182 (handshake completion timeout):
--> application state not reached (ClientRcvServerHello)
--> sending failure to requester