Benachrichtigung eMail ohne Funktion

[konmil]

Hallo,

ich versuche gerade eine Benachrichtigung per eMail zu konfigurieren, scheitere jedoch.
Das Ganze wird áuf einem F6706T mit ADM 5.1.1.RCI1 versucht.
Der Mailserver (mailcow-Instanz) benötigt sowohl Authentifizierung als auch TLS. Versucht wurden port 465 und 587 (auch testweise 25)

Angeblich geht die Mail durch doch in den Server Logs ist zu sehen dass KEINE Authentifizierung stattfindet nach dem initialen Verbindungsaufbau - irgenwie scheint da etwas nicht korrekt implementiert zu sein.
Hmm, Bilder kann man scheinbar nicht posten.

Serviveanbieter: andere
eMail: no-reply@DOMAIN.de
Betreff: ASUSTOR Gerätename
SMTP-Server: IP von mailcow-Instanz
SMTP-Port: 465 (auch 587 und 25 versucht)
SMTP-Authentifizierung: Haken rein
Konto: no-reply@DOMAIN.de
Kennwort: <das passende Kennwort>
SSL7TLS-Verschlüsselung: Haken rein

Jemand eine Idee?
Gruß Stefan

[lensin1]

Ich weiß nicht viel über Ihr Problem, aber vielleicht können Sie diesen Artikel lesen:

https://www.asustor.com/de/online/Colle ... ?topic=269

[konmil]

Danke für die Antowrt,

leider passt die Beschreibung gar nicht zum Problem ...
Es soll kein Mailserver installiert werden. Es sollen nur Benachrichtigungen per Mail versendet werden können, als Client.

Gruß,
Stefan

[lensin1]

Ich habe Ihre Frage missverstanden. Ich dachte, Sie möchten einen Mailserver installieren...
Ich habe mein Gmail-Konto in den Benachrichtigungen hinterlegt und es funktioniert einwandfrei. Vielleicht können Sie sich bei Ihrem E-Mail-Anbieter erkundigen.

[konmil]

Laut wireshark wohl ein Problem mit dem TLS Handshake, nach einem "Change Cipher Spec" beented das Asustor einfach
die Verbindung.

Aber warum hier zum einen TLS1.0 und TLS1.1 angeboten wird, das schon seit mehreren Jahren nicht mehr
verwendet werden soll, und zum anderen PQC ist einfach nur Quatsch. Der alte Mist muss raus.

Gruß,
Stefan

[lensin1]

Wenn das der Fall ist, dann scheint es, als wären verschiedene Versionen von TLS im NAS verfügbar. Die alten Versionen werden möglicherweise beibehalten, um ältere Programme zu unterstützen. Laut der Website bietet PQC einen recht fortschrittlichen Schutz vor Ransomware unter Verwendung von TLS 1.3.

[konmil]

Ja das scheint eine Kompatibilitätsgeschichte zu sein, vielleicht sollte man das aber konfigurierbar machen
und standard mässig deaktivieren.
Mit openssl kann man die prinzipielle TLS Konnektivität des Servers testen, auf der commandline vom NAS,
das scheint auch zu passen, siehe unten, jetzt stellt sich nur die Frage mit welchem Tool wird gesendet
und was macht es anders.

openssl s_client -connect 192.168.x.y:465
Connecting to 192.168.x.y
CONNECTED(00000003)
Can't use SSL_get_servername
depth=2 C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication Root R46
verify return:1
depth=1 C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV R36
verify return:1
depth=0 CN=*.xxxxxxxx.de
verify return:1
---
Certificate chain
0 s:CN=*.xxxxxxxx.de
i:C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV R36
a:PKEY: RSA, 4096 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Aug 18 00:00:00 2025 GMT; NotAfter: Sep 18 23:59:59 2026 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=CN=*.xxxxxxxx.de
issuer=C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV R36
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: rsa_pss_rsae_sha256
Peer Temp Key: X25519, 253 bits
---
SSL handshake has read 2746 bytes and written 1618 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Protocol: TLSv1.3
Server public key is 4096 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: F2C371BB6B9194ADE922BAE1B454687340B3D67D2B6C7769325CEC0F0BADB24A
Session-ID-ctx:
Resumption PSK: 910339AD8CB7D49DBE7B6D2F0201AA703C94F9013869B095E0F1DB3E594744425C875C1C9BAAB1DCD94F043816ACA837
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - 30 42 7f 97 d3 38 2e 70-97 af 7e 91 50 6b ce 2c 0B...8.p..~.Pk.,
...
00c0 - da 4e e5 7d 67 ae 85 af-2e ac 63 9a 5f bf aa 59 .N.}g.....c._..Y

Start Time: 1769686285
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
220 intmail.xxxxxxxx.de ESMTP Postcow

[konmil]

Also die Nachricht versucht ein "notification.cgi" zu verschicken.
Das liegt unter /usr/builtin/webman/portal/apis/settings. Damit ist an dieser Stelle Schluß da es ein binary ist.

Mal sehen ob man den Datenverkehr genauer analysieren kann.

[lensin1]

Sie sind wirklich ein großartiger Forscher, der nach der Wahrheit sucht!!! Bravo!

[konmil]

Danke, hilft nur leider nicht weiter.

Meine derzeitige Erkenntnis ist, das direkt nach dem TLS Schlüsseltausch *VOM* Asustor ein TCP-RST (Wireshark/tcpdump) gesendet wird und damit die Verbindung
abbricht *BEVOR* ein Nutzer sich am Mailserver per PLAIN oder LOGIN authentifizieren kann. Der Grund könnte ein Problem beim Schlüsseltausch sein.