STARTTLS auto detection not working
When attempting to setup SMTP notifications to a mailserver which supports STARTTLS the following error occurrs:
Could not send the message to [firstname.lastname@example.org] -- Error: Failed to set sender: [email@example.com] [SMTP: Invalid response code received from server (code: 530, response: 5.7.0 Must issue a STARTTLS command first)].
In researching the issue it seems that on August 11th 2016 the web UI element for selecting STARTTLS was removed with the developer who made the change stating that pear-Mail will automatically use STARTTLS when the server supports it (see https://github.com/pfsense/pfsense/commit/c8c46e5a8e9551db0172b79aae1fee4553b3bf7d). Packet captures between the pfSense appliance and mail server reveal that the pfSense mail client fails to issue a STARTTLS command even when it has been advertised by the server (see https://pastebin.com/3CTW0wPC).
On a side note, while it is not necessarily a bug it is poor practice to rely on client-side autodetection of STARTTLS. In this situation an attacker positioned between the SMTP client and server can block STARTTLS advertisements thereby preventing the establishment of an encrypted connection, or they could establish an unencrypted connection to the client and an encrypted connection to the server in a replay attack. The user should have the ability to specify that STARTTLS is to always be used in the connection. It should also be noted that this change alone would not prevent a MITM from creating their own TLS connection to the client in a replay attack. Further measures would need to prevent the client from accepting a fraudulent certificate.