On Feb 5, 2019, at 7:15 AM, Burak Arslan wrote:

Hello,

I'm trying to deliver mail using twisted.mail.sendmail (version 18.9.0)

Thanks for using Twisted, and thanks for already being on the latest version!

Delivery attempts to some servers fail either with disconnections or timeouts following the STARTTLS command. When I disable STARTTLS (by patching tryTLS()) message delivery succeeds.

So is there a way to log the TLS handshake process to be able to understand why the TLS connection cannot resume? Any suggestions for troubleshooting this? A dry ConnectionDone doesn't tell much.

If you really want to log the handshake itself, you could try starting with Wireshark, which would at least tell you something about the contents of said handshake. However, this may not be all that useful initially. There are lots of potential problems here. One is that ESMTPSender uses TLSv1_METHOD[1], which may be provoking your peers into dropping the connection because it's too old a version. You haven't said anything about how you're building your client context, and there are several other potential problems with the default. Another potential problem is that I don't know how you've set up Twisted's logging. If Twisted were logging a traceback, would you see it? In general this is a very difficult problem to debug, email is non-deterministic and scary, but it upgrades from "difficult" to "impossible" without seeing the sample code doing the sending :-).

Is it possible to make t.m.sendmail() attempt another delivery without STARTTLS?

If you do this, you're quite likely to end up in a situation where your messages are far more likely to be flagged as spam by your ESP. STARTTLS is generally considered a positive signal for deliverability. (See https://starttls-everywhere.org https://starttls-everywhere.org/).

Best regards, Burak ARSLAN

Hopefully some of my guesses were helpful, but I'm looking forward to seeing your code, and hopeful that someone on the list can help you work through to the point where you can deliver some mail :). -g [1]: At the time ESMTPSender was written, TLSv1_METHOD was a bold, forward-looking SSL_METHOD to select! It was the most recent version of the protocol, and explicitly opted out of vulnerable SSLv2 and SSLv3 protocol versions. However, the OpenSSL API is nothing if not deeply unfortunate, so this has metastasized over time into an incredibly ancient and bad SSL_METHOD; the correct one that you want is SSLv23_METHOD which means "negotiate TLS version" (and practically no current version of OpenSSL will negotiate either SSLv2 *or* SSLv3 with this method, since they're broken and deprecated).