50.4 Security Options
50.4.1 Overview ¶
For all server connections (IMAP, SMTP, POP3) the program requires TLS encryption - either as implicit SSL mode or as the StartTLS extension over the plain connection. The program validates server certificates against the Windows system certificate stores: valid certificates of public CAs are accepted automatically; invalid or unknown certificates lead to a connection refusal.
50.4.2 Security Modes ¶
Per account and per server direction (incoming, outgoing) you choose a security mode:
| Mode |
Behavior |
| Automatic |
Program tries SSL first, then StartTLS - chooses the variant the server supports |
| SSL |
Implicit SSL connection from the start (typical port 993 for IMAP, 465 for SMTP) |
| StartTLS |
Plain connection with upgrade to TLS via the STARTTLS command (typical port 143 for IMAP, 587 for SMTP) |
Recommendation: If the hoster documents a specific variant, choose it explicitly - the Automatic mode is a convenience fallback, not a security optimum.
50.4.3 Certificate Errors ¶
When establishing a connection, the program checks the server certificate. On problems, an error message appears with the cause:
| Error |
Cause |
Action |
| “Certificate not trusted” |
Self-signed certificate, or certificate signed by an unknown CA |
Import certificate into the Windows certificate store |
| “Certificate expired” |
Server certificate has expired |
Inform the IT administrator of the hoster |
| “Hostname does not match” |
Certificate was issued for a different hostname |
Check the correct server name (e.g. imap.firma.de instead of mail.firma.de) |
| “TLS handshake failed” |
TLS versions or cipher suites incompatible |
Ask the hoster which TLS version is required (TLS 1.2 or newer is standard) |
50.4.4 Self-Signed Certificates ¶
Self-signed certificates (e.g. an internal mail server without a public CA) are by default not accepted by the Windows system. To allow the connection, the certificate of the internal server must be imported into the Windows certificate store under “Trusted Root Certification Authorities”.
The import is typically done via a group policy (in corporate environments) or manually via certmgr.msc. After the import, the Windows system trusts the certificate - and so does the program.
Security note: Import only certificates whose origin you know. An imported root certificate is a global trust statement and affects all applications on the system.
50.4.5 TLS Versions ¶
The program uses the TLS versions supported by the system - typically TLS 1.2 and TLS 1.3. Deprecated versions (SSL 3.0, TLS 1.0, TLS 1.1) are not actively established because they are considered insecure and have not been recommended for years.
If a server supports only old TLS versions, the connection fails with a TLS handshake error - the only sensible path is to ask the server operator for an upgrade or to use a different server.
50.4.6 Credential Security ¶
Passwords are not stored in clear text. The program offers two storage modes:
| Mode |
Method |
Binding |
| Encrypted in configuration (default) |
Passwords are stored encrypted in EmailAccounts.json |
Program-internal, not bound to user or PC |
| Windows Credential Manager |
Stored as a generic credential in the Windows vault |
Bound to the Windows user |
The selection is made in Program options -> Security (see chapter 40.9).
Note on portability: In the default mode Encrypted in configuration, EmailAccounts.json can be transferred between users and computers - any installation of the program can read the file. This is intentional, so backups can be moved to a new computer. Anyone wanting an additional binding to the Windows user (e.g. to make a copied configuration unusable) switches to Windows Credential Manager mode. On the switch, the program reads the passwords from the configuration and stores them in the Credential Manager.
50.4.7 Tip ¶
- For recurring TLS problems, a test with Outlook or Thunderbird using the same data is worthwhile - if the other clients also fail, the problem is on the server, not in the program