Emails via SMTP aus Schild 2 / 3

[JKleine]

Hallo zusammen!

Derzeit scheitere ich daran, Emails per SMTP aus Schild (2) zu versenden, und suche meinen Fehler.

Unter Extras -> Programm-Einstellungen -> Globale Einstellungen -> Email-Versand ist "Direkt über SMTP" sowie die jeweils vom Betreiber angegebene Adresse des SMTP-Servers und die Nummer des SMTP-Ports eingetragen (habe es sowohl mit unserem MS-Office-Zugang als auch testhalber mit meinem web.de-Account probiert), Haken bei "StartTSL verwenden".

Bei den individuellen Einstellungen habe ich unter "E-Mail-Kontodaten bearbeiten (SMTP)" die jeweilige Mailadresse und die Zugangsdaten eingetragen. "Einstellungen testen" sagt jetzt in beiden Fällen "Verbindung erfolgreich hergestellt".

Verlasse ich nun die individuellen Einstellungen und kehre wieder zurück, ist das Passwort für den Mailaccount nicht mehr das, was ich vorher eingetragen hatte (sehe ich an der Anzahl der Platzhalter-Punkte - das Passwort steht ja nicht im Klartext drin). Der Verbindungstest schlägt jetzt fehl, wie logischerweise auch jeder Versuch, eine Mail aus Schild zu versenden.

Das Problem habe ich analog in Schild 2 wie 3. Wenn man nachschaut, werden die Passwörter in beiden Datenbanktypen verschlüsselt gespeichert (was ja auch so sein sollte) - hat es damit zu tun? Oder habe ich einen Denkfehler?

[GE Schwerte]

Ein seit langem bestehende Problem, häufig auch hier gemeldet.
Nicht nur in Schild, wir können auch seit langem keine Mails aus Schild-Media versenden.
Für Lupo hatte ich das Problem vor 9 Monaten hier beschrieben.

Für Schild:

- Wenn "Einstellung testen" funktioniert, können Sie keine E-Mails versenden
- Bekommen Sie bei "Einstellung testen" eine Fehlermeldung, klappt danach der E-Mail Versand aus Schild.

Für Mails über Office365:
Globale Schild-Einstellungen: SMTP-Port 587 verwenden, Haken bei SSL-Verschlüsselung *aus*, Haken bei StartTSL *an*.
(siehe Bild)

Individuelle Schild-Einstellungen -> E-Mail Konto bearbeiten:
Bei Mail-Adresse und Mail-Benutzername die E-Mail Adresse eintragen, Kennwort natürlich auch.
Ignorieren Sie die Fehlermeldung bei "Einstellung testen", versuchen Sie einfach, einen Report zu vermailen.

Hier hat Hr. Raffenberg nochmal eine neue Programmkomponente verlinkt:
viewtopic.php?p=48101#p48101

Viel Erfolg!

[Raffenberg]

sehe ich an der Anzahl der Platzhalter-Punkte - das Passwort steht ja nicht im Klartext drin

Ich meine, dass die Anzahl der Punkte nicht die Anzahl der Zeichen im Passwort wiederspiegelt...

[Hauke Hayen]

Sind die letzen drei Beiträge in diesem github-issue hilfreich?
https://github.com/SVWS-NRW/Schild-NRW- ... 3503122530

[JKleine]

sehe ich an der Anzahl der Platzhalter-Punkte - das Passwort steht ja nicht im Klartext drin

Ich meine, dass die Anzahl der Punkte nicht die Anzahl der Zeichen im Passwort wiederspiegelt...

Beim direkten Eingeben schon...
Dann wird es ja in die Tabelle "user" (Schild 2) bzw. "benutzeremail" (Schild 3) eingetragen und dabei ein Hash erstellt, der i.d.R. eine andere Zeichenkettenlänge aufweist. Mein amateurhafter Gedanke war, dass dieses gehashte Passwort nicht richtig zurücktransformiert wird, um sich damit bei meinem Mailprovider anzumelden.

[JKleine]

Vielen Dank an GSSchwerte und Hauke fürs Mitdenken. Den Post mit der neuen Fleximailer.dll hatte ich nicht gesehen. Allerdings hat der Austausch der DLL bei mir weder in Schild 2 noch in Schild 3 etwas geändert. Meine Einträge in den globalen Einstellungen waren von Anfang an dieselben wie von GSSchwerte. Ich habe jetzt alle Varianten mal durchprobiert, auch in Schild 3 die von Hauke bei GitHub vorgegebene mit Port 465 und dem "AutoAnpassen" - leider ohne Erfolg. Muss ich wohl erstmal mit leben.

[JKleine]

Hallo zusammen,
ich muss mich doch nochmal kurz zum Thema melden.
Mittlerweile habe ich den Email-Versand per SMTP aus SchILD 2 mit derselben (Access-)Datenbank auf drei verschiedenen Systemen getestet (alle Windows 11) und - siehe da - in zwei der drei Systemen funktioniert er problemlos, sogar ohne Austausch der Fleximailer.dll.

Einstellungen global:
- Direkt über SMTP
- SMTP-Server: smtp.office365.com (weil es eine Office-365-Mailadresse ist)
- SMTP-Port: 587
- StartTSL verwenden aktiviert, SSL-Verschlüsselung nicht

Einstellungen individuell:
- Mailadresse als Adresse und Benutzername, Kennwort eingetragen

Es funktioniert sowohl der Verbindungstest als auch das Versenden von z.B. Reports an Emailadressen problemlos.

Meiner Ansicht nach liegt es an der verschlüsselten Speicherung das Email-Kennworts in der Access-Datenbank. Bei den funktionierenden Systemen habe ich Anlass zur Vermutung, dass das Kennwort Zeichen für Zeichen verschlüsselt wird - die Länge bleibt erhalten ( ) und es gibt andere Anzeichen dafür. Im dritten - nicht funktionierenden - System wird eine Zeichenkette anderer Länge und mit anderen Charakteren angelegt.

Es klappt übrigens auch nicht, die Datenbank aus einem der "funktionierenden" Systeme mit nicht verändertem Kennwort in das nicht funktionierende System zu übernehmen.

An der Stelle enden meine Fähigkeiten, ich wollte diese Beobachtung aber gern hier dokumentieren.

[Raffenberg]

Kannst Du noch ein paar Infos benennen?

Du schreibst von 3 PCs mit Windows 11. Befinden sich alle drei PCs im gleichen Netzwerk und greifen auf Schild auf einem Server zu? Oder handelt es sich um lokale Rechner in getrennten Netzwerken, auf denen Schild lokal installiert ist? Im ersten Fall kommunizieren die Clients mit der Datenbank auf dem Server. Im zweiten Fall mit der lokalen Datenbank.

Hast Du auf PC2 und 3 Schild neu installiert, oder den Schild-Ordner von PC1 kopiert?

Du kannst folgendes testen. Vergib mal an allen PCs in Schild ein kurzes Kennwort, um das Speichern in die Datenbank zu testen. Das Kennwort soll nur aus Buchstaben und Zahlen bestehen (z.B. Test1234). Vergleiche die Hashes in der Datenbank. Mach das Gleiche mit einem langen Kennwort (TestTestTestq23456789012345678). Vergleiche erneut. Dann ein Kennwort mit Sonderzeichen. So kannst Du rausbekommen, ob Sonderzeichen ein Problem sind und damit ggf. die CodePage des PCs.
Zweite Ursache könnten unterschiedliche AccessEngines sein, also Unterschiede im verwendeten ODBC Treiber, der für die Kommunikation zwischen Schild und der AccesDB verantwortlich ist.
Wenn Du auf PC2 und 3 Schild neu installiert hast, so kann es sich lohnen, dies auf PC1 ebenfalls zu tun. SichereDeine Daten, deinstalliere Schild und entferne Reste. Installiere Schild neu und spiele DB und Reports zurück.
Wenn PC1 auf einen Server zugreift und PC2 und 3 nicht, so kann ein veraltetes SMB Protokoll oder eine gestörte Kommunikation mit dem Server die Ursache sein.

Kurz: Kennwort ohne Sonderzeichen checken, ODBC Treiber checken, SMB Protokoll checken (1,2 oder 3).