On Fri, Jan 27, 2017 at 1:02 AM, Stefano Bagnara <mai...@bago.org> wrote:
> 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 ;-) > Yes, if you advertise STARTTLS, we always try to use it, and if you return an error or the ssl negotiation fails, we treat that like any other temp failure. Eventually, we'll bounce. > 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. > They don't advertise STARTTLS to us, and my own telnet attempt from my workstation shows nothing: Trying 62.149.128.135... Connected to mailfree.aruba.it. Escape character is '^]'. 220 mxcm01.ad.aruba.it bizsmtp ESMTP server ready ehlo foo250-mxcm01.ad.aruba.it hello [104.132.11.86], pleased to meet you 250-HELP 250-AUTH LOGIN PLAIN 250-SIZE 524288000 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 OK quit 221 2.0.0 mxcm01.ad.aruba.it bizsmtp closing connection And none of our attempts in the past week have been encrypted to them. Not sure if they just don't advertise to us, or what. Brandon > (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
