On 23 January 2017 at 20:42, Brandon Long <bl...@google.com> wrote: > Note that information about Google is about 3 years out of date, we no > longer fall back to unencrypted. >
Thank you very much Brandon for the updated info. So, in case of a destination server announcing STARTTLS and then failing at *every* STARTTLS request Gmail won't deliver the email: is this right? This is what I'm doing too, but if I tell my recipients that Gmail does the same there will be more chance they will understand they are wrong and try to fix their issues instead of blaming me for not being able to deliver emails ;-) About the Aruba issue, I had a single answer from the Aruba.it postmaster telling me that they fixed the issue the past Jan 17th: unfortunately my logs tell me nothing changed after that day and I keep receiving thousands of this errors daily. I replied to him my stats, but received no updates. On average 33% of connections to Aruba.it result in that STARTTLS error, so we need 3 attempts to send 2 messages to the 62.149.128.(151|154|158|160|163|166) servers. My main issue is that on average, 50% of messages destinated to that provider are delayed until the second retry (10 minutes for us). If I remove Aruba, the failure rate due to STARTTLS issues is about 1 on 100.000. (Of course we trust every certificate and we accept almost any cypher-suite, otherwise the failure rate would be much higher) Stefano > Your best bet for important domains you care about it to try and contact > their admins to fix it. > > Other than that, it's basically up to your policies what to do... well, > and what your software can do. > > For us, the numbers were small enough to not be worth potentially sending > the mail in the clear. > > Brandon > > On Jan 23, 2017 10:21 AM, "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
