Having STARTTLS on by default is a good idea but you do need to have a fallback in place as there's quite a lot of problematic servers:
* you need to trust self signed certificates, it doesn’t make much sense to go with plaintext if certificate is not valid * incompatible cipher suites (ie. servers using RC4 or worse) * servers advertising but not actually allowing to use STARTTLS * servers not advertising but actually supporting STARTTLS * servers where STARTTLS is availbale but disabled by state/operator/mitm, usually you see XXXXXXXX in the place where STARTTLS should be * etc. My personal favourite being a server that during TLS handshake, after it had received client side cipher list, ended the connection with no response whatsoever. Did not even finish the handshake, just closed the connection. If the cipher suite was ok for the server, then everything worked, if not then the connection was lost immediatelly after initiating the TLS handshake. Anyway we always try STARTTLS first and if it fails for whatever reason then immediatelly reconnect and send without using STARTTLS. There’s no grace period. We plan to start supporting DANE and probably STS which would change how TLS is handled but for now is purely opportunistic. Best regards, Andris Reinman Zone Meida https://github.com/zone-eu/zone-mta <https://github.com/zone-eu/zone-mta> > On 23. jaan 2017, at 20:15, Stefano Bagnara <mai...@bago.org> wrote: > > We recently enabled starttls to every destination (announcing the starttls > extension). > > We now see a lot of "454 4.3.3 TLS not available due to temporary reason" in > reply to the STARTTLS by a big B2B italian provider named Aruba. We usually > are able to send the email after 2-3-5 attempts, so this is not causing > "failures" but mainly delay, but randomness could even cause permanent > failures. > > Now, I read a forum where someone said Google try TLS delivery for 1 day, > then they switch to plain text delivery if the delivery didn't happen in the > first 24 hours. > > What do other senders do? Is this "try TLS for a while then switch to plain > text" a best practice or just something "invented" by Google? Or do you use > whitelist/blacklist in order to decide valid TLS destinations? > > I also have similar messages by other targets, but thet are very low volume, > so I didn't investigate them: > - 454 4.7.0 TLS not available due to local problem > - 454 4.3.0 TLS not available due to local problem > - 454 TLS currently unavailable > - 454 TLS missing certificate: error:02001002:system library:fopen:No such > file or directory (#4.3.0) ) > > Stefano > > PS: this is my first post and www mailop org is not working right now so I've > not been able to check the "posting guidelines" to see if this kind of > message is allowed or not in this list. > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
