Mailing List Message #106023
From: Massimo Bolzoni <>
Subject: Re: TLS response code
Date: Sun, 13 Mar 2016 14:41:58 +0100
To: CommuniGate Pro Discussions <>

Thanks for the explanation! Actually we run 6.1.9 and 5.4.0 was released 5 june 2011 so roughly 5 years ago.

That to say if you keep updated things are solved...

Email, contatti e rubrica in mobilità.

> Il giorno 12 mar 2016, alle ore 20:31, Bill Cole <> ha scritto:
>> On 4 Mar 2016, at 16:27, James Moe wrote:
>> opensuse 421.
>> cgate-pro 5.4.11
>>  We are getting this response during an attempt to send mail.
>>  What is TLS code 10? Is there some place where these codes are defined?
> RFC5246 describes when various codes should be used and it helps to understand the whole TLS connection setup process. Looking at the relevantcode of LibreSSL or OpenSSL or GNU-TLS might be illuminating as well. Also, it isn't entirely clear that in this case the "code 10" is a formal TLS error code instead of just some number Vlad chose for a particular sort of failure in CGP. Finally: you can BE SURE that over time CGP 5.4.11 will increasingly fail to negotiate ANY encryption with rationally-configured sites that support TLS, because the SSL/TLS library in 5.4 is a horrible antique mess, missing support for any protocol+ciphersuite combo that should be deemed secure in the modern world.
> Yes, I know that's less than entirely helpful.
> However...

>> ----[ log excerpt ]----
>> 09:06:41.190 4 SMTP-000114( cmd: EHLO
>> 09:06:41.202 4 SMTP-000114( rsp: 09:06:41.202 4 SMTP-000114( rsp: 250 STARTTLS
> Odd... I don't see as a MX for and when I connect to port 25 on and say EHLO with a correct name, it doesn't offer STARTTLS to me. Which means that something has changed on that end in the past week; They no longer support STARTTLS, or at least they don't for connections from any of a handful of unrelated addresses that don't nomally get shunned by anyone...
> Or you've mangled the logs into a useless fiction, which seems unlikely :)
>> 09:06:41.202 4 SMTP-000114( Connected. TLS
>> 09:06:41.202 4 SMTP-000114( starting TLS(optional)
>> 09:06:41.202 4 SMTP-000114( cmd: STARTTLS
>> 09:06:41.217 4 SMTP-000114( rsp: 220 2.0.0 Start TLS
>> 09:06:41.229 4 SMTP-000114( TLS aborting with code 10
>> 09:06:41.430 3 SMTP-000114( failed to establish a secure
>> connection with []:25. Error Code=connection reset by peer
> That *kinda* would make sense if the far end were configured to drop connections that attempt to negotiate a protocol version and/or ciphersuite that it deems unsafe. Or if it were using one of the hacked-up versions of OpenSSL that have been passed around during the past few years with "workarounds" for vulnerabilities that got publicized and exploited before any proper fixes existed, e.g. "solved" by just aborting a TCP connection when TLS negotiation would result in a vulnerable session.
> Hypothetically, if one had deployed such a botch 2 years ago and not freaked out about any intervening OpenSSL issues until this week's "DROWN" problem, one might do it wrong and end up just disabling STARTTLS altogether. Or if one were using some shoddy black-box SMTP loadbalancer (as implied by the hostname) with an old non-upgradeable SSL/TLS implementation that was occasionally a little broken last week, one might just turn off STARTTLS in the face of DROWN, which is enabled by using the same private key for obsolete and modern protocols. It sorta makes sense (finally) to actually disable STARTTLS entirely on SMTP systems that can't be updated or configured to never fall back to legacy SSL, since now it is a risk to systems with solid TLS to share a private key (like in a wildcard cert) with one anywhere else that is doing better-than-nothing encryption as a last resort.
> #############################################################
> This message is sent to you because you are subscribed to
> the mailing list <>.
> To unsubscribe, E-mail to: <>
> To switch to the DIGEST mode, E-mail to <>
> To switch to the INDEX mode, E-mail to <>
> Send administrative queries to  <>


Quest'anno festeggiamo 10 anni! Scopri di più su

Massimo Bolzoni - Solution Architect
Mob.: +39 335 5278936

Iscriviti ai nostri WEBINAR, solo 30 minuti per illustrarti i nostri servizi in the cloud (SAAS) e le nostre tecnologie CommuniGate, Mailspect e IP Technology LAB, maggiori info qui:

Answer srl: distributore italiano Communigate Pro, MailSpect, IP Technology labs

Answer srl
via Gandhi, 22 - 42123 Reggio Emilia
Tel +39 0522 286545
Le informazioni contenute nella presente comunicazione e i relativi allegati possono essere riservate e sono, comunque, rivolte esclusi-vamente al destinatario. La diffusione, distribuzione e/o copie deldocumento trasmesso o degli allegati da parte di qualsiasi soggettodiverso dal destinatario e'perseguibile ai sensi dell'articolo 616Codice Penale e del Decreto Legislativo n. 196/2003.Se avete ricevuto questo messaggio per errore, Vi preghiamo di re-inviarlo al mittente e distruggerlo.
Per informazioni potete contattare l'indirizzo
This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have receivedthe message in error, be informed that any use of the content hereofis prohibited and it is punished by law. Please return it immediatelyto the sender and delete the message.
Should you have any questions,please contact us at

Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster