Der verschlüsselte Versand selbst ist in Ordnung: über PREFERENCES_MAIL_USESSL wird zwischen STARTTLS (Transport "smtp", mail.smtp.starttls.enable) und implizitem TLS (Transport "smtps", mail.smtp.ssl.enable) umgeschaltet. Beim Durchsehen sind aber drei Punkte in derselben Methode aufgefallen.

1) Zertifikatsprüfung

props.put("mail.smtp.ssl.trust", '*');

Gemeint ist offenbar "allen Zertifikaten vertrauen". Falls das greift, ist die Zertifikatsprüfung ausgehebelt und die TLS-Verbindung gegen Man-in-the-Middle nicht mehr geschützt - der Verschlüsselung bliebe dann nur noch die Wirkung gegen passives Mitlesen.

Vermutlich greift es allerdings gar nicht: '*' ist ein char, kein String. Angus Mail liest diese Eigenschaft über Properties.getProperty(), das bei einem Nicht-String-Wert null liefert. Nachgemessen ist das nicht.

Vorschlag: Zeile entfernen. Wird ein Vertrauensanker für selbstsignierte Zertifikate gebraucht, gehört dort eine echte Host-Liste als String hin, idealerweise aus den Einstellungen und nicht fest verdrahtet.

2) System-Properties werden verändert

final Properties props = System.getProperties();
props.put(...Host, Auth, StartTLS, SSL, Port, ssl.trust...);

Die SMTP-Einstellungen werden in die JVM-weiten System-Properties geschrieben und bleiben dort auch nach dem Versand stehen. Sie wirken damit auf die gesamte Anwendung und überdauern jeden weiteren Sendevorgang. Sauberer wäre ein frisches new Properties(), das nur an die Session übergeben wird.

3) Irreführende Port-Eigenschaft

props.put(MailServiceConstants.MAIL_SMTP_PORT, MailServiceConstants.MAIL_SMTP_DEFAULT_PORT);  // 587

Hier wird immer der Vorgabeport gesetzt, während connectTransport() den tatsächlich eingestellten Port aus MailSettings.getPort() an transport.connect() übergibt. Folgenlos, weil der Aufrufparameter gewinnt, aber beim Lesen und bei der Fehlersuche irreführend.

Der ursprüngliche Forumsbeitrag zum Thema ("EMAIL nur unverschlüsselt/ungesichert", Januar 2025) ist damit erledigt und wurde nicht als eigenes Ticket erfasst.