The STARTTLS is only exposed by the business domains: Aruba is one of the biggest registrars for the .IT TLD, so it also handle inboxes for a lot of small business domains here in Italy.
The receiving MX for the "non free" inboxes are: 62.149.128.(151|154|158|160|163|166) Every domain uses a single mx.domain.com and the MX points to the 6 IN A record above: some of the domains also have 2 more IPs in the pool. An example domain hosted there is @archme.it The "free" @aruba.it domain is not big but I see at least 500K domains with almost 3 millions inboxes targeted by our infrastructure in the last month hosted there. Trying 62.149.128.151... > Connected to 62.149.128.151. > Escape character is '^]'. > 220 mxcmd08.ad.aruba.it bizsmtp ESMTP server ready > ehlo foo > 250-mxcmd08.ad.aruba.it hello [149.202.192.114], pleased to meet you > 250-HELP > 250-AUTH LOGIN PLAIN > 250-SIZE 524288000 > 250-ENHANCEDSTATUSCODES > 250-8BITMIME > 250-STARTTLS > 250 OK > quit > 221 2.0.0 mxcmd08.ad.aruba.it bizsmtp closing connection Thank you for confirming the Google behaviour! Stefano On 27 January 2017 at 21:27, Brandon Long <bl...@google.com> wrote: > > > 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
