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

Reply via email to