Notification Service(s) Impacted

Email / SMTP

What happened

Apprise's email notification plugin accepts a self-signed and hostname-mismatched SMTP TLS certificate even though certificate verification is enabled by default.

For HTTPS-based notification services, Apprise passes verify=self.verify_certificate to the underlying HTTP client. The email SMTP path also exposes the same verify_certificate=True URL-level setting, but it is not converted into a validating TLS context for SMTP.

In the current source, the SSL SMTP path calls smtplib.SMTP_SSL(...) without a context argument, and the STARTTLS path calls socket.starttls() without a context argument. In Python's smtplib, both cases fall back to ssl._create_stdlib_context(), which does not enforce normal CA validation and hostname verification.

Expected behavior: when verify_certificate=True (the default), SMTPS and STARTTLS SMTP connections should reject self-signed, untrusted, expired, or hostname-mismatched certificates before credentials or message data are sent.

Actual behavior: a local SMTPS server presenting a self-signed certificate for wrong.example.test is accepted when connecting to 127.0.0.1, and Apprise proceeds to send SMTP commands including MAIL FROM, RCPT TO, DATA, and QUIT.

Impact

An attacker who can intercept or redirect SMTP traffic can present an untrusted certificate and receive the SMTP session. This can expose SMTP credentials and notification contents, and can allow notification modification or suppression.

Steps to reproduce

1. Install or run Apprise from the latest source.
2. Start a local SMTPS server that presents a self-signed certificate whose CN/SAN does not match the target hostname, for example a certificate for wrong.example.test while the client connects to 127.0.0.1.
3. Add an Apprise email notification URL using SMTPS:

   mailtos://127.0.0.1:24652?from=sender@example.com&to=recipient@example.com&mode=ssl
   

4. Send a notification through Apprise.
5. Observe that the SMTP session continues past TLS setup and reaches MAIL FROM, RCPT TO, and DATA.

A secure SMTP client with certificate verification enabled should fail the TLS handshake before sending SMTP credentials or message data.

Logs

notify_result=True
smtp_transcript_marker=ehlo [127.0.1.1]|mail FROM:<sender@example.com>|rcpt TO:<recipient@example.com>|data|quit
APPRISE_SELF_SIGNED_SMTP_ACCEPTED

Above the reproduction output means that Apprise successfully connected to the test SMTPS server and treated the TLS connection as valid, even though the server presented a self-signed certificate with a hostname mismatch.

This is important because, if certificate verification were working correctly, the connection should fail during the TLS handshake due to the self-signed and hostname-mismatched certificate, before any MAIL FROM command is sent.