Based on some support requests recently, mainly from users of the privacy-concerned provider mailbox.org, we decided to include support for STARTTLS into the first phase of normal email pings. When registering a new email address for your account a ping email is sent in two steps, the first of which is performed synchronously when the request is placed (checking the server’s existence), while the actual sending uses a mail server at CAcert to handle delivery and retransmission.
The change was realized in two parts as based on support requests we received two distinct issues were present when deciding to send mails: The first issue (fixed in bug 1318) was about the order the receiving servers for a domain were tried. This lead sometimes to situations where mails from CAcert were marked as spam as the first server tried by our website software accidentially was the spam-trap of that domain. To avoid this the software now respects the priority given in the MX records and shuffles equal priority records in random order as allowed by the RFC.
Once the order of the servers, that should be tried to deliver the mail, has been decided on, the second change comes into play, which is explained further in bug 1288 of our issue tracker. The changes in the second part are focused on the connection content when talking to a foreign MTA. For this the code implementing the dialog phase has been reworked to query for STARTTLS in the feature list of the EHLO command (previously only a simple HELO was sent) and establishing an opportunistic layer of encryption with the other side. For simplicity whenever STARTTLS is advertised we will be using STARTTLS in this phase and thus fail the connection when no TLS session can be established.
We hope that this change lifts the delays some of our users experience when registering a new domain of certain providers. Although please note that most MTAs use anti-spam measures regardless of encryption and thus a manuel retry after some (usually 5) minutes might still be necessary.