Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Qmail>
  3. users
Spamcontrol 2.7.32 qmail-remote TLS problems
brunni at netestate
Apr 14, 2016, 3:53 AM
Post #1 of 8 (4035 views)
Permalink
hi all,

I have transient TLS problem with certain destinations that cause some mails
to be delayed with the error

delivery ... deferral: TLS_connection/protocol_error_for_for_host:..._(#4.4.1)/

Sometimes mail goes through right away, sometimes after several trials and
sometimes it takes days. So far I have identified these destinations:

hotmail.com (mx1.hotmail.com)
neumann-neumann.com (mail.neumann-neumann.com)
ton-objekt.de (ton-objekt.de.pri-mx.eu0103.smtproutes.com)

Most interesting here is hotmail.com. I am not able to communicate properly with
mx*.hotmail.com via the openssl client. An encrypted connection via STARTTLS
is established but then the server does not respond to most commands.
"QUIT" works, "quit", "HELO", "EHLO", "MAIL FROM:" does not:

openssl s_client -connect mx1.hotmail.com:25 -starttls smtp
CONNECTED(00000003)
...
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-SHA384
Session-ID: 493A0000F823516DED700287A61AAA62F886AD12B02635F4A7B2845431B4CF3F
Session-ID-ctx:
Master-Key: 3FEC7E06D8229053DF4FA60DD7BBFA850C86BB198AA8C4E325729619EE9486D548B4541B34D277780D93A6503DC45B03
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1460629034
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
250 OK
EHLO fiano.netestate.de
read:errno=104

The response to QUIT is also quite non-SMTP-like:

250 OK
QUIT
DONE

I can reproduce this running the openssl client from several data centers and
distributions (OpenSSL 1.0.1s and 1.0.1f). http://checktls.com does not report
any problems with hotmail.com.

Can somebody here reproduce this or shed light on it?

I had two mails to hotmail.com in the queue today that were delayed for days.
After putting "!hotmail.com:" in tlsdestinations, hotmail reported
"552 Message size exceeds fixed maximum message size".

I am quite sure that in my first trials with the openssl client and
ton-objekt.de.pri-mx.eu0103.smtproutes.com, the connection was closed after
the TLS connection was established but before I could enter a command but I
was not able to reproduce this since then.

I will conduct further experiments but maybe someone has clues for me.

Regards,

Michael Brunnbauer

--
++ Michael Brunnbauer
++ netEstate GmbH
++ Geisenhausener Straße 11a
++ 81379 München
++ Tel +49 89 32 19 77 80
++ Fax +49 89 32 19 77 89
++ E-Mail brunni@netestate.de
++ http://www.netestate.de/
++
++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
++ USt-IdNr. DE221033342
++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel

Attached Files:

Re: Spamcontrol 2.7.32 qmail-remote TLS problems [ In reply to ]
brunni at netestate
Apr 14, 2016, 9:45 AM
Post #2 of 8 (3986 views)
Permalink
hi all,

the admins of one of the affected MX tell me that they have problems with
DH parameters > 768 bits causing timeouts. We recently upgraded from OpenSSL
1.0.1q to 1.0.1s and the changelog for 1.0.1r says:

"Reject DH handshakes with parameters shorter than 1024 bits."

https://www.openssl.org/news/cl101.txt

Maybe that explains it?

Regards,

Michael Brunnbauer

On Thu, Apr 14, 2016 at 12:53:54PM +0200, Michael Brunnbauer wrote:
>
> hi all,
>
> I have transient TLS problem with certain destinations that cause some mails
> to be delayed with the error
>
> delivery ... deferral: TLS_connection/protocol_error_for_for_host:..._(#4.4.1)/
>
> Sometimes mail goes through right away, sometimes after several trials and
> sometimes it takes days. So far I have identified these destinations:
>
> hotmail.com (mx1.hotmail.com)
> neumann-neumann.com (mail.neumann-neumann.com)
> ton-objekt.de (ton-objekt.de.pri-mx.eu0103.smtproutes.com)
>
> Most interesting here is hotmail.com. I am not able to communicate properly with
> mx*.hotmail.com via the openssl client. An encrypted connection via STARTTLS
> is established but then the server does not respond to most commands.
> "QUIT" works, "quit", "HELO", "EHLO", "MAIL FROM:" does not:
>
> openssl s_client -connect mx1.hotmail.com:25 -starttls smtp
> CONNECTED(00000003)
> ...
> SSL-Session:
> Protocol : TLSv1.2
> Cipher : ECDHE-RSA-AES256-SHA384
> Session-ID: 493A0000F823516DED700287A61AAA62F886AD12B02635F4A7B2845431B4CF3F
> Session-ID-ctx:
> Master-Key: 3FEC7E06D8229053DF4FA60DD7BBFA850C86BB198AA8C4E325729619EE9486D548B4541B34D277780D93A6503DC45B03
> Key-Arg : None
> PSK identity: None
> PSK identity hint: None
> SRP username: None
> Start Time: 1460629034
> Timeout : 300 (sec)
> Verify return code: 0 (ok)
> ---
> 250 OK
> EHLO fiano.netestate.de
> read:errno=104
>
> The response to QUIT is also quite non-SMTP-like:
>
> 250 OK
> QUIT
> DONE
>
> I can reproduce this running the openssl client from several data centers and
> distributions (OpenSSL 1.0.1s and 1.0.1f). http://checktls.com does not report
> any problems with hotmail.com.
>
> Can somebody here reproduce this or shed light on it?
>
> I had two mails to hotmail.com in the queue today that were delayed for days.
> After putting "!hotmail.com:" in tlsdestinations, hotmail reported
> "552 Message size exceeds fixed maximum message size".
>
> I am quite sure that in my first trials with the openssl client and
> ton-objekt.de.pri-mx.eu0103.smtproutes.com, the connection was closed after
> the TLS connection was established but before I could enter a command but I
> was not able to reproduce this since then.
>
> I will conduct further experiments but maybe someone has clues for me.
>
> Regards,
>
> Michael Brunnbauer
>
> --
> ++ Michael Brunnbauer
> ++ netEstate GmbH
> ++ Geisenhausener Straße 11a
> ++ 81379 München
> ++ Tel +49 89 32 19 77 80
> ++ Fax +49 89 32 19 77 89
> ++ E-Mail brunni@netestate.de
> ++ http://www.netestate.de/
> ++
> ++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
> ++ USt-IdNr. DE221033342
> ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
> ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel



--
++ Michael Brunnbauer
++ netEstate GmbH
++ Geisenhausener Straße 11a
++ 81379 München
++ Tel +49 89 32 19 77 80
++ Fax +49 89 32 19 77 89
++ E-Mail brunni@netestate.de
++ http://www.netestate.de/
++
++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
++ USt-IdNr. DE221033342
++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel

Attached Files:

Re: Spamcontrol 2.7.32 qmail-remote TLS problems [ In reply to ]
feh at fehcom
Apr 14, 2016, 1:18 PM
Post #3 of 8 (3985 views)
Permalink
Hi Michael,

regarding Spamcontrol + s/qmail and certainly most other TLS enhancements for qmail, these kind of problems belong to the TLS layer.

sslserver/qmail-remote/qmail-smtpd are users of TLS (either by an API or by included libs).

There are very few 'knobs' you can tune:

a) ucspi-ssl (my version) does not allow SSLv2 connections (as hard coded; but subject of change in the sources).

b) The cipher suite to be announced or accepted (by qmail-remote). In the TLS scheme, the server provides a set of acceptable suites, while the client choses one.
Both depend on the OpenSSL or LibreSSL libs are whatever is in place. In particular, if ECC can be used or not.

Unfortunately, the OpenSSL error codes don't tell very much. In you case the simply say: 'I do have a TLS handshake problem with this host' -- please fix it.

regards.
--eh.


> Am 14.04.2016 um 18:45 schrieb Michael Brunnbauer <brunni@netestate.de>:
>
>
> hi all,
>
> the admins of one of the affected MX tell me that they have problems with
> DH parameters > 768 bits causing timeouts. We recently upgraded from OpenSSL
> 1.0.1q to 1.0.1s and the changelog for 1.0.1r says:
>
> "Reject DH handshakes with parameters shorter than 1024 bits."
>
> https://www.openssl.org/news/cl101.txt
>
> Maybe that explains it?
>
> Regards,
>
> Michael Brunnbauer
>
> On Thu, Apr 14, 2016 at 12:53:54PM +0200, Michael Brunnbauer wrote:
>>
>> hi all,
>>
>> I have transient TLS problem with certain destinations that cause some mails
>> to be delayed with the error
>>
>> delivery ... deferral: TLS_connection/protocol_error_for_for_host:..._(#4.4.1)/
>>
>> Sometimes mail goes through right away, sometimes after several trials and
>> sometimes it takes days. So far I have identified these destinations:
>>
>> hotmail.com (mx1.hotmail.com)
>> neumann-neumann.com (mail.neumann-neumann.com)
>> ton-objekt.de (ton-objekt.de.pri-mx.eu0103.smtproutes.com)
>>
>> Most interesting here is hotmail.com. I am not able to communicate properly with
>> mx*.hotmail.com via the openssl client. An encrypted connection via STARTTLS
>> is established but then the server does not respond to most commands.
>> "QUIT" works, "quit", "HELO", "EHLO", "MAIL FROM:" does not:
>>
>> openssl s_client -connect mx1.hotmail.com:25 -starttls smtp
>> CONNECTED(00000003)
>> ...
>> SSL-Session:
>> Protocol : TLSv1.2
>> Cipher : ECDHE-RSA-AES256-SHA384
>> Session-ID: 493A0000F823516DED700287A61AAA62F886AD12B02635F4A7B2845431B4CF3F
>> Session-ID-ctx:
>> Master-Key: 3FEC7E06D8229053DF4FA60DD7BBFA850C86BB198AA8C4E325729619EE9486D548B4541B34D277780D93A6503DC45B03
>> Key-Arg : None
>> PSK identity: None
>> PSK identity hint: None
>> SRP username: None
>> Start Time: 1460629034
>> Timeout : 300 (sec)
>> Verify return code: 0 (ok)
>> ---
>> 250 OK
>> EHLO fiano.netestate.de
>> read:errno=104
>>
>> The response to QUIT is also quite non-SMTP-like:
>>
>> 250 OK
>> QUIT
>> DONE
>>
>> I can reproduce this running the openssl client from several data centers and
>> distributions (OpenSSL 1.0.1s and 1.0.1f). http://checktls.com does not report
>> any problems with hotmail.com.
>>
>> Can somebody here reproduce this or shed light on it?
>>
>> I had two mails to hotmail.com in the queue today that were delayed for days.
>> After putting "!hotmail.com:" in tlsdestinations, hotmail reported
>> "552 Message size exceeds fixed maximum message size".
>>
>> I am quite sure that in my first trials with the openssl client and
>> ton-objekt.de.pri-mx.eu0103.smtproutes.com, the connection was closed after
>> the TLS connection was established but before I could enter a command but I
>> was not able to reproduce this since then.
>>
>> I will conduct further experiments but maybe someone has clues for me.
>>
>> Regards,
>>
>> Michael Brunnbauer
>>
>> --
>> ++ Michael Brunnbauer
>> ++ netEstate GmbH
>> ++ Geisenhausener Straße 11a
>> ++ 81379 München
>> ++ Tel +49 89 32 19 77 80
>> ++ Fax +49 89 32 19 77 89
>> ++ E-Mail brunni@netestate.de
>> ++ http://www.netestate.de/
>> ++
>> ++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
>> ++ USt-IdNr. DE221033342
>> ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
>> ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
>
>
>
> --
> ++ Michael Brunnbauer
> ++ netEstate GmbH
> ++ Geisenhausener Straße 11a
> ++ 81379 München
> ++ Tel +49 89 32 19 77 80
> ++ Fax +49 89 32 19 77 89
> ++ E-Mail brunni@netestate.de
> ++ http://www.netestate.de/
> ++
> ++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
> ++ USt-IdNr. DE221033342
> ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
> ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel

Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id: EE00CF65

Attached Files:

Re: Spamcontrol 2.7.32 qmail-remote TLS problems [ In reply to ]
support at nelsonandwright
Apr 14, 2016, 7:28 PM
Post #4 of 8 (3970 views)
Permalink
Hello,

I'm going to interject here but I have been running FreeBSD for quite a
number of years and smtp TLS runs fine on i386 but with amd64 it does
not. It just gives me a status 11 in the qmail smtp logs and in the
freebsd messages log it just says segfault. I have been troubleshooting
this myself and according to the tls log it does answer ready for tls
but the session fails when sending a message.

Bill

On 2016-04-14 16:18, Erwin Hoffmann wrote:
> Hi Michael,
>
> regarding Spamcontrol + s/qmail and certainly most other TLS
> enhancements for qmail, these kind of problems belong to the TLS
> layer.
>
> sslserver/qmail-remote/qmail-smtpd are users of TLS (either by an API
> or by included libs).
>
> There are very few 'knobs' you can tune:
>
> a) ucspi-ssl (my version) does not allow SSLv2 connections (as hard
> coded; but subject of change in the sources).
>
> b) The cipher suite to be announced or accepted (by qmail-remote). In
> the TLS scheme, the server provides a set of acceptable suites, while
> the client choses one.
> Both depend on the OpenSSL or LibreSSL libs are whatever is in place.
> In particular, if ECC can be used or not.
>
> Unfortunately, the OpenSSL error codes don't tell very much. In you
> case the simply say: 'I do have a TLS handshake problem with this
> host' -- please fix it.
>
> regards.
> --eh.
>
>
>> Am 14.04.2016 um 18:45 schrieb Michael Brunnbauer
>> <brunni@netestate.de>:
>>
>>
>> hi all,
>>
>> the admins of one of the affected MX tell me that they have problems
>> with
>> DH parameters > 768 bits causing timeouts. We recently upgraded from
>> OpenSSL
>> 1.0.1q to 1.0.1s and the changelog for 1.0.1r says:
>>
>> "Reject DH handshakes with parameters shorter than 1024 bits."
>>
>> https://www.openssl.org/news/cl101.txt
>>
>> Maybe that explains it?
>>
>> Regards,
>>
>> Michael Brunnbauer
>>
>> On Thu, Apr 14, 2016 at 12:53:54PM +0200, Michael Brunnbauer wrote:
>>>
>>> hi all,
>>>
>>> I have transient TLS problem with certain destinations that cause
>>> some mails
>>> to be delayed with the error
>>>
>>> delivery ... deferral:
>>> TLS_connection/protocol_error_for_for_host:..._(#4.4.1)/
>>>
>>> Sometimes mail goes through right away, sometimes after several
>>> trials and
>>> sometimes it takes days. So far I have identified these destinations:
>>>
>>> hotmail.com (mx1.hotmail.com)
>>> neumann-neumann.com (mail.neumann-neumann.com)
>>> ton-objekt.de (ton-objekt.de.pri-mx.eu0103.smtproutes.com)
>>>
>>> Most interesting here is hotmail.com. I am not able to communicate
>>> properly with
>>> mx*.hotmail.com via the openssl client. An encrypted connection via
>>> STARTTLS
>>> is established but then the server does not respond to most commands.
>>> "QUIT" works, "quit", "HELO", "EHLO", "MAIL FROM:" does not:
>>>
>>> openssl s_client -connect mx1.hotmail.com:25 -starttls smtp
>>> CONNECTED(00000003)
>>> ...
>>> SSL-Session:
>>> Protocol : TLSv1.2
>>> Cipher : ECDHE-RSA-AES256-SHA384
>>> Session-ID:
>>> 493A0000F823516DED700287A61AAA62F886AD12B02635F4A7B2845431B4CF3F
>>> Session-ID-ctx:
>>> Master-Key:
>>> 3FEC7E06D8229053DF4FA60DD7BBFA850C86BB198AA8C4E325729619EE9486D548B4541B34D277780D93A6503DC45B03
>>> Key-Arg : None
>>> PSK identity: None
>>> PSK identity hint: None
>>> SRP username: None
>>> Start Time: 1460629034
>>> Timeout : 300 (sec)
>>> Verify return code: 0 (ok)
>>> ---
>>> 250 OK
>>> EHLO fiano.netestate.de
>>> read:errno=104
>>>
>>> The response to QUIT is also quite non-SMTP-like:
>>>
>>> 250 OK
>>> QUIT
>>> DONE
>>>
>>> I can reproduce this running the openssl client from several data
>>> centers and
>>> distributions (OpenSSL 1.0.1s and 1.0.1f). http://checktls.com does
>>> not report
>>> any problems with hotmail.com.
>>>
>>> Can somebody here reproduce this or shed light on it?
>>>
>>> I had two mails to hotmail.com in the queue today that were delayed
>>> for days.
>>> After putting "!hotmail.com:" in tlsdestinations, hotmail reported
>>> "552 Message size exceeds fixed maximum message size".
>>>
>>> I am quite sure that in my first trials with the openssl client and
>>> ton-objekt.de.pri-mx.eu0103.smtproutes.com, the connection was closed
>>> after
>>> the TLS connection was established but before I could enter a command
>>> but I
>>> was not able to reproduce this since then.
>>>
>>> I will conduct further experiments but maybe someone has clues for
>>> me.
>>>
>>> Regards,
>>>
>>> Michael Brunnbauer
>>>
>>> --
>>> ++ Michael Brunnbauer
>>> ++ netEstate GmbH
>>> ++ Geisenhausener Straße 11a
>>> ++ 81379 München
>>> ++ Tel +49 89 32 19 77 80
>>> ++ Fax +49 89 32 19 77 89
>>> ++ E-Mail brunni@netestate.de
>>> ++ http://www.netestate.de/
>>> ++
>>> ++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
>>> ++ USt-IdNr. DE221033342
>>> ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
>>> ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
>>
>>
>>
>> --
>> ++ Michael Brunnbauer
>> ++ netEstate GmbH
>> ++ Geisenhausener Straße 11a
>> ++ 81379 München
>> ++ Tel +49 89 32 19 77 80
>> ++ Fax +49 89 32 19 77 89
>> ++ E-Mail brunni@netestate.de
>> ++ http://www.netestate.de/
>> ++
>> ++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
>> ++ USt-IdNr. DE221033342
>> ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
>> ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
>
> Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id:
> EE00CF65
Re: Spamcontrol 2.7.32 qmail-remote TLS problems [ In reply to ]
qbitza at gmail
Apr 15, 2016, 5:42 AM
Post #5 of 8 (3970 views)
Permalink
I've also been looking for a solution for this.

On 15 April 2016 at 04:28, <support@nelsonandwright.com> wrote:

> Hello,
>
> I'm going to interject here but I have been running FreeBSD for quite a
> number of years and smtp TLS runs fine on i386 but with amd64 it does not.
> It just gives me a status 11 in the qmail smtp logs and in the freebsd
> messages log it just says segfault. I have been troubleshooting this myself
> and according to the tls log it does answer ready for tls but the session
> fails when sending a message.
>
> Bill
>
>
> On 2016-04-14 16:18, Erwin Hoffmann wrote:
>
>> Hi Michael,
>>
>> regarding Spamcontrol + s/qmail and certainly most other TLS
>> enhancements for qmail, these kind of problems belong to the TLS
>> layer.
>>
>> sslserver/qmail-remote/qmail-smtpd are users of TLS (either by an API
>> or by included libs).
>>
>> There are very few 'knobs' you can tune:
>>
>> a) ucspi-ssl (my version) does not allow SSLv2 connections (as hard
>> coded; but subject of change in the sources).
>>
>> b) The cipher suite to be announced or accepted (by qmail-remote). In
>> the TLS scheme, the server provides a set of acceptable suites, while
>> the client choses one.
>> Both depend on the OpenSSL or LibreSSL libs are whatever is in place.
>> In particular, if ECC can be used or not.
>>
>> Unfortunately, the OpenSSL error codes don't tell very much. In you
>> case the simply say: 'I do have a TLS handshake problem with this
>> host' -- please fix it.
>>
>> regards.
>> --eh.
>>
>>
>> Am 14.04.2016 um 18:45 schrieb Michael Brunnbauer <brunni@netestate.de>:
>>>
>>>
>>> hi all,
>>>
>>> the admins of one of the affected MX tell me that they have problems with
>>> DH parameters > 768 bits causing timeouts. We recently upgraded from
>>> OpenSSL
>>> 1.0.1q to 1.0.1s and the changelog for 1.0.1r says:
>>>
>>> "Reject DH handshakes with parameters shorter than 1024 bits."
>>>
>>> https://www.openssl.org/news/cl101.txt
>>>
>>> Maybe that explains it?
>>>
>>> Regards,
>>>
>>> Michael Brunnbauer
>>>
>>> On Thu, Apr 14, 2016 at 12:53:54PM +0200, Michael Brunnbauer wrote:
>>>
>>>>
>>>> hi all,
>>>>
>>>> I have transient TLS problem with certain destinations that cause some
>>>> mails
>>>> to be delayed with the error
>>>>
>>>> delivery ... deferral:
>>>> TLS_connection/protocol_error_for_for_host:..._(#4.4.1)/
>>>>
>>>> Sometimes mail goes through right away, sometimes after several trials
>>>> and
>>>> sometimes it takes days. So far I have identified these destinations:
>>>>
>>>> hotmail.com (mx1.hotmail.com)
>>>> neumann-neumann.com (mail.neumann-neumann.com)
>>>> ton-objekt.de (ton-objekt.de.pri-mx.eu0103.smtproutes.com)
>>>>
>>>> Most interesting here is hotmail.com. I am not able to communicate
>>>> properly with
>>>> mx*.hotmail.com via the openssl client. An encrypted connection via
>>>> STARTTLS
>>>> is established but then the server does not respond to most commands.
>>>> "QUIT" works, "quit", "HELO", "EHLO", "MAIL FROM:" does not:
>>>>
>>>> openssl s_client -connect mx1.hotmail.com:25 -starttls smtp
>>>> CONNECTED(00000003)
>>>> ...
>>>> SSL-Session:
>>>> Protocol : TLSv1.2
>>>> Cipher : ECDHE-RSA-AES256-SHA384
>>>> Session-ID:
>>>> 493A0000F823516DED700287A61AAA62F886AD12B02635F4A7B2845431B4CF3F
>>>> Session-ID-ctx:
>>>> Master-Key:
>>>> 3FEC7E06D8229053DF4FA60DD7BBFA850C86BB198AA8C4E325729619EE9486D548B4541B34D277780D93A6503DC45B03
>>>> Key-Arg : None
>>>> PSK identity: None
>>>> PSK identity hint: None
>>>> SRP username: None
>>>> Start Time: 1460629034
>>>> Timeout : 300 (sec)
>>>> Verify return code: 0 (ok)
>>>> ---
>>>> 250 OK
>>>> EHLO fiano.netestate.de
>>>> read:errno=104
>>>>
>>>> The response to QUIT is also quite non-SMTP-like:
>>>>
>>>> 250 OK
>>>> QUIT
>>>> DONE
>>>>
>>>> I can reproduce this running the openssl client from several data
>>>> centers and
>>>> distributions (OpenSSL 1.0.1s and 1.0.1f). http://checktls.com does
>>>> not report
>>>> any problems with hotmail.com.
>>>>
>>>> Can somebody here reproduce this or shed light on it?
>>>>
>>>> I had two mails to hotmail.com in the queue today that were delayed
>>>> for days.
>>>> After putting "!hotmail.com:" in tlsdestinations, hotmail reported
>>>> "552 Message size exceeds fixed maximum message size".
>>>>
>>>> I am quite sure that in my first trials with the openssl client and
>>>> ton-objekt.de.pri-mx.eu0103.smtproutes.com, the connection was closed
>>>> after
>>>> the TLS connection was established but before I could enter a command
>>>> but I
>>>> was not able to reproduce this since then.
>>>>
>>>> I will conduct further experiments but maybe someone has clues for me.
>>>>
>>>> Regards,
>>>>
>>>> Michael Brunnbauer
>>>>
>>>> --
>>>> ++ Michael Brunnbauer
>>>> ++ netEstate GmbH
>>>> ++ Geisenhausener Straße 11a
>>>> ++ 81379 München
>>>> ++ Tel +49 89 32 19 77 80
>>>> ++ Fax +49 89 32 19 77 89
>>>> ++ E-Mail brunni@netestate.de
>>>> ++ http://www.netestate.de/
>>>> ++
>>>> ++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
>>>> ++ USt-IdNr. DE221033342
>>>> ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
>>>> ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
>>>>
>>>
>>>
>>>
>>> --
>>> ++ Michael Brunnbauer
>>> ++ netEstate GmbH
>>> ++ Geisenhausener Straße 11a
>>> ++ 81379 München
>>> ++ Tel +49 89 32 19 77 80
>>> ++ Fax +49 89 32 19 77 89
>>> ++ E-Mail brunni@netestate.de
>>> ++ http://www.netestate.de/
>>> ++
>>> ++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
>>> ++ USt-IdNr. DE221033342
>>> ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
>>> ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
>>>
>>
>> Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id: EE00CF65
>>
>
>
Re: Spamcontrol 2.7.32 qmail-remote TLS problems [ In reply to ]
feh at fehcom
Apr 15, 2016, 2:04 PM
Post #6 of 8 (3966 views)
Permalink
Hi,

thanks for pointing me to this kind of problem.

Since I'm a user of Spamcontrol + FreeBSD (currently 10.3) as well (and this mail header being produced on FreeBSD as first hop and Linux as a 2nd) shows the email went thru without problems (using qmail-remote + QMTPS on s/qmail, I really am interested you should Spamcontrol make fail on AMD64 which I use as test and development environment.

Here is my con-ld file:

[sqmail@bigchief /usr/local/src/qmail-1.03.2732]$ vi conf-ld
cc -s -m64

This is for AMD64 architecture; use else:

cc -s

This will be used to link .o files into an executable.

Note: UCSPI-SSL's conf-ld needs to use the same architecture!
~

:q!
[sqmail@bigchief /usr/local/src/qmail-1.03.2732]$ ls -la conf-ld
-rw-r--r-- 1 root wheel 181 Oct 26 2014 conf-ld

Did you adjust for those?

Regards.
--eh.


> Am 15.04.2016 um 14:42 schrieb Willo van der Merwe <qbitza@gmail.com>:
>
> I've also been looking for a solution for this.
>
> On 15 April 2016 at 04:28, <support@nelsonandwright.com> wrote:
> Hello,
>
> I'm going to interject here but I have been running FreeBSD for quite a number of years and smtp TLS runs fine on i386 but with amd64 it does not. It just gives me a status 11 in the qmail smtp logs and in the freebsd messages log it just says segfault. I have been troubleshooting this myself and according to the tls log it does answer ready for tls but the session fails when sending a message.
>
> Bill
>
>
> On 2016-04-14 16:18, Erwin Hoffmann wrote:
> Hi Michael,
>
> regarding Spamcontrol + s/qmail and certainly most other TLS
> enhancements for qmail, these kind of problems belong to the TLS
> layer.
>
> sslserver/qmail-remote/qmail-smtpd are users of TLS (either by an API
> or by included libs).
>
> There are very few 'knobs' you can tune:
>
> a) ucspi-ssl (my version) does not allow SSLv2 connections (as hard
> coded; but subject of change in the sources).
>
> b) The cipher suite to be announced or accepted (by qmail-remote). In
> the TLS scheme, the server provides a set of acceptable suites, while
> the client choses one.
> Both depend on the OpenSSL or LibreSSL libs are whatever is in place.
> In particular, if ECC can be used or not.
>
> Unfortunately, the OpenSSL error codes don't tell very much. In you
> case the simply say: 'I do have a TLS handshake problem with this
> host' -- please fix it.
>
> regards.
> --eh.
>
>
> Am 14.04.2016 um 18:45 schrieb Michael Brunnbauer <brunni@netestate.de>:
>
>
> hi all,
>
> the admins of one of the affected MX tell me that they have problems with
> DH parameters > 768 bits causing timeouts. We recently upgraded from OpenSSL
> 1.0.1q to 1.0.1s and the changelog for 1.0.1r says:
>
> "Reject DH handshakes with parameters shorter than 1024 bits."
>
> https://www.openssl.org/news/cl101.txt
>
> Maybe that explains it?
>
> Regards,
>
> Michael Brunnbauer
>
> On Thu, Apr 14, 2016 at 12:53:54PM +0200, Michael Brunnbauer wrote:
>
> hi all,
>
> I have transient TLS problem with certain destinations that cause some mails
> to be delayed with the error
>
> delivery ... deferral: TLS_connection/protocol_error_for_for_host:..._(#4.4.1)/
>
> Sometimes mail goes through right away, sometimes after several trials and
> sometimes it takes days. So far I have identified these destinations:
>
> hotmail.com (mx1.hotmail.com)
> neumann-neumann.com (mail.neumann-neumann.com)
> ton-objekt.de (ton-objekt.de.pri-mx.eu0103.smtproutes.com)
>
> Most interesting here is hotmail.com. I am not able to communicate properly with
> mx*.hotmail.com via the openssl client. An encrypted connection via STARTTLS
> is established but then the server does not respond to most commands.
> "QUIT" works, "quit", "HELO", "EHLO", "MAIL FROM:" does not:
>
> openssl s_client -connect mx1.hotmail.com:25 -starttls smtp
> CONNECTED(00000003)
> ...
> SSL-Session:
> Protocol : TLSv1.2
> Cipher : ECDHE-RSA-AES256-SHA384
> Session-ID: 493A0000F823516DED700287A61AAA62F886AD12B02635F4A7B2845431B4CF3F
> Session-ID-ctx:
> Master-Key: 3FEC7E06D8229053DF4FA60DD7BBFA850C86BB198AA8C4E325729619EE9486D548B4541B34D277780D93A6503DC45B03
> Key-Arg : None
> PSK identity: None
> PSK identity hint: None
> SRP username: None
> Start Time: 1460629034
> Timeout : 300 (sec)
> Verify return code: 0 (ok)
> ---
> 250 OK
> EHLO fiano.netestate.de
> read:errno=104
>
> The response to QUIT is also quite non-SMTP-like:
>
> 250 OK
> QUIT
> DONE
>
> I can reproduce this running the openssl client from several data centers and
> distributions (OpenSSL 1.0.1s and 1.0.1f). http://checktls.com does not report
> any problems with hotmail.com.
>
> Can somebody here reproduce this or shed light on it?
>
> I had two mails to hotmail.com in the queue today that were delayed for days.
> After putting "!hotmail.com:" in tlsdestinations, hotmail reported
> "552 Message size exceeds fixed maximum message size".
>
> I am quite sure that in my first trials with the openssl client and
> ton-objekt.de.pri-mx.eu0103.smtproutes.com, the connection was closed after
> the TLS connection was established but before I could enter a command but I
> was not able to reproduce this since then.
>
> I will conduct further experiments but maybe someone has clues for me.
>
> Regards,
>
> Michael Brunnbauer
>
> --
> ++ Michael Brunnbauer
> ++ netEstate GmbH
> ++ Geisenhausener Straße 11a
> ++ 81379 München
> ++ Tel +49 89 32 19 77 80
> ++ Fax +49 89 32 19 77 89
> ++ E-Mail brunni@netestate.de
> ++ http://www.netestate.de/
> ++
> ++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
> ++ USt-IdNr. DE221033342
> ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
> ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
>
>
>
> --
> ++ Michael Brunnbauer
> ++ netEstate GmbH
> ++ Geisenhausener Straße 11a
> ++ 81379 München
> ++ Tel +49 89 32 19 77 80
> ++ Fax +49 89 32 19 77 89
> ++ E-Mail brunni@netestate.de
> ++ http://www.netestate.de/
> ++
> ++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
> ++ USt-IdNr. DE221033342
> ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
> ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
>
> Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id: EE00CF65
>
>

Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id: EE00CF65

Attached Files:

Re: Spamcontrol 2.7.32 qmail-remote TLS problems [ In reply to ]
qbitza at gmail
Apr 16, 2016, 2:22 AM
Post #7 of 8 (3960 views)
Permalink
UCSPI-SSL is working fine. I can connect using an SSL encrypted protocol
without problems.

The issue is when issuing the STARTTLS command.

I've tried modifying conf-ld and rebuilding, but the segfault still happens.

On 15 April 2016 at 23:04, Erwin Hoffmann <feh@fehcom.de> wrote:

> Hi,
>
> thanks for pointing me to this kind of problem.
>
> Since I'm a user of Spamcontrol + FreeBSD (currently 10.3) as well (and
> this mail header being produced on FreeBSD as first hop and Linux as a 2nd)
> shows the email went thru without problems (using qmail-remote + QMTPS on
> s/qmail, I really am interested you should Spamcontrol make fail on AMD64
> which I use as test and development environment.
>
> Here is my con-ld file:
>
> [sqmail@bigchief /usr/local/src/qmail-1.03.2732]$ vi conf-ld
> cc -s -m64
>
> This is for AMD64 architecture; use else:
>
> cc -s
>
> This will be used to link .o files into an executable.
>
> Note: UCSPI-SSL's conf-ld needs to use the same architecture!
> ~
>
> :q!
> [sqmail@bigchief /usr/local/src/qmail-1.03.2732]$ ls -la conf-ld
> -rw-r--r-- 1 root wheel 181 Oct 26 2014 conf-ld
>
> Did you adjust for those?
>
> Regards.
> --eh.
>
>
> > Am 15.04.2016 um 14:42 schrieb Willo van der Merwe <qbitza@gmail.com>:
> >
> > I've also been looking for a solution for this.
> >
> > On 15 April 2016 at 04:28, <support@nelsonandwright.com> wrote:
> > Hello,
> >
> > I'm going to interject here but I have been running FreeBSD for quite a
> number of years and smtp TLS runs fine on i386 but with amd64 it does not.
> It just gives me a status 11 in the qmail smtp logs and in the freebsd
> messages log it just says segfault. I have been troubleshooting this myself
> and according to the tls log it does answer ready for tls but the session
> fails when sending a message.
> >
> > Bill
> >
> >
> > On 2016-04-14 16:18, Erwin Hoffmann wrote:
> > Hi Michael,
> >
> > regarding Spamcontrol + s/qmail and certainly most other TLS
> > enhancements for qmail, these kind of problems belong to the TLS
> > layer.
> >
> > sslserver/qmail-remote/qmail-smtpd are users of TLS (either by an API
> > or by included libs).
> >
> > There are very few 'knobs' you can tune:
> >
> > a) ucspi-ssl (my version) does not allow SSLv2 connections (as hard
> > coded; but subject of change in the sources).
> >
> > b) The cipher suite to be announced or accepted (by qmail-remote). In
> > the TLS scheme, the server provides a set of acceptable suites, while
> > the client choses one.
> > Both depend on the OpenSSL or LibreSSL libs are whatever is in place.
> > In particular, if ECC can be used or not.
> >
> > Unfortunately, the OpenSSL error codes don't tell very much. In you
> > case the simply say: 'I do have a TLS handshake problem with this
> > host' -- please fix it.
> >
> > regards.
> > --eh.
> >
> >
> > Am 14.04.2016 um 18:45 schrieb Michael Brunnbauer <brunni@netestate.de>:
> >
> >
> > hi all,
> >
> > the admins of one of the affected MX tell me that they have problems with
> > DH parameters > 768 bits causing timeouts. We recently upgraded from
> OpenSSL
> > 1.0.1q to 1.0.1s and the changelog for 1.0.1r says:
> >
> > "Reject DH handshakes with parameters shorter than 1024 bits."
> >
> > https://www.openssl.org/news/cl101.txt
> >
> > Maybe that explains it?
> >
> > Regards,
> >
> > Michael Brunnbauer
> >
> > On Thu, Apr 14, 2016 at 12:53:54PM +0200, Michael Brunnbauer wrote:
> >
> > hi all,
> >
> > I have transient TLS problem with certain destinations that cause some
> mails
> > to be delayed with the error
> >
> > delivery ... deferral:
> TLS_connection/protocol_error_for_for_host:..._(#4.4.1)/
> >
> > Sometimes mail goes through right away, sometimes after several trials
> and
> > sometimes it takes days. So far I have identified these destinations:
> >
> > hotmail.com (mx1.hotmail.com)
> > neumann-neumann.com (mail.neumann-neumann.com)
> > ton-objekt.de (ton-objekt.de.pri-mx.eu0103.smtproutes.com)
> >
> > Most interesting here is hotmail.com. I am not able to communicate
> properly with
> > mx*.hotmail.com via the openssl client. An encrypted connection via
> STARTTLS
> > is established but then the server does not respond to most commands.
> > "QUIT" works, "quit", "HELO", "EHLO", "MAIL FROM:" does not:
> >
> > openssl s_client -connect mx1.hotmail.com:25 -starttls smtp
> > CONNECTED(00000003)
> > ...
> > SSL-Session:
> > Protocol : TLSv1.2
> > Cipher : ECDHE-RSA-AES256-SHA384
> > Session-ID:
> 493A0000F823516DED700287A61AAA62F886AD12B02635F4A7B2845431B4CF3F
> > Session-ID-ctx:
> > Master-Key:
> 3FEC7E06D8229053DF4FA60DD7BBFA850C86BB198AA8C4E325729619EE9486D548B4541B34D277780D93A6503DC45B03
> > Key-Arg : None
> > PSK identity: None
> > PSK identity hint: None
> > SRP username: None
> > Start Time: 1460629034
> > Timeout : 300 (sec)
> > Verify return code: 0 (ok)
> > ---
> > 250 OK
> > EHLO fiano.netestate.de
> > read:errno=104
> >
> > The response to QUIT is also quite non-SMTP-like:
> >
> > 250 OK
> > QUIT
> > DONE
> >
> > I can reproduce this running the openssl client from several data
> centers and
> > distributions (OpenSSL 1.0.1s and 1.0.1f). http://checktls.com does not
> report
> > any problems with hotmail.com.
> >
> > Can somebody here reproduce this or shed light on it?
> >
> > I had two mails to hotmail.com in the queue today that were delayed for
> days.
> > After putting "!hotmail.com:" in tlsdestinations, hotmail reported
> > "552 Message size exceeds fixed maximum message size".
> >
> > I am quite sure that in my first trials with the openssl client and
> > ton-objekt.de.pri-mx.eu0103.smtproutes.com, the connection was closed
> after
> > the TLS connection was established but before I could enter a command
> but I
> > was not able to reproduce this since then.
> >
> > I will conduct further experiments but maybe someone has clues for me.
> >
> > Regards,
> >
> > Michael Brunnbauer
> >
> > --
> > ++ Michael Brunnbauer
> > ++ netEstate GmbH
> > ++ Geisenhausener Straße 11a
> > ++ 81379 München
> > ++ Tel +49 89 32 19 77 80
> > ++ Fax +49 89 32 19 77 89
> > ++ E-Mail brunni@netestate.de
> > ++ http://www.netestate.de/
> > ++
> > ++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
> > ++ USt-IdNr. DE221033342
> > ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
> > ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
> >
> >
> >
> > --
> > ++ Michael Brunnbauer
> > ++ netEstate GmbH
> > ++ Geisenhausener Straße 11a
> > ++ 81379 München
> > ++ Tel +49 89 32 19 77 80
> > ++ Fax +49 89 32 19 77 89
> > ++ E-Mail brunni@netestate.de
> > ++ http://www.netestate.de/
> > ++
> > ++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
> > ++ USt-IdNr. DE221033342
> > ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
> > ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
> >
> > Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id:
> EE00CF65
> >
> >
>
> Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id: EE00CF65
>
>
>
>
>
>
Re: Spamcontrol 2.7.32 qmail-remote TLS problems [ In reply to ]
support at nelsonandwright
Apr 16, 2016, 4:59 AM
Post #8 of 8 (3962 views)
Permalink
Hello,

I owe you Eric a HUGE thank you. I just tried this on my setup. I wanted
to point out that I am not using s/qmail. I am using my own qmail
install that I have been maintaining for years on
http://freebsdrocks.net . I will look into spamcontrol. Here is a copy
of my log:

2016-04-16 07:51:36.973705500 tcpserver: status: 1/30
2016-04-16 07:51:36.973905500 tcpserver: pid 57415 from 192.168.9.7
2016-04-16 07:51:37.019839500 tcpserver: ok 57415
nelsonandwright.local:::ffff:192.168.9.19:587 :::ffff:192.168.9.7::51031
2016-04-16 07:51:37.034161500 qmail-smtpd[57415]: AUTH successful
[192.168.9.7] postmaster@nelsonandwright.local
2016-04-16 07:51:37.034907500 qmail-smtpd[57415]: MAIL
FROM:<postmaster@nelsonandwright.local>
2016-04-16 07:51:37.035446500 qmail-smtpd[57415]: RCPT
TO:<postmaster@nelsonandwright.local>
2016-04-16 07:51:37.190482500 tcpserver: end 57415 status 256
2016-04-16 07:51:37.190485500 tcpserver: status: 0/30

I do get error 256 on both the SSL and TLS services but the message does
send.

THANK YOU ERIC!

Bill


On 2016-04-16 05:22, Willo van der Merwe wrote:
> UCSPI-SSL is working fine. I can connect using an SSL encrypted
> protocol without problems.
>
> The issue is when issuing the STARTTLS command.
>
> I've tried modifying conf-ld and rebuilding, but the segfault still
> happens.
>
> On 15 April 2016 at 23:04, Erwin Hoffmann <feh@fehcom.de> wrote:
>
>> Hi,
>>
>> thanks for pointing me to this kind of problem.
>>
>> Since I'm a user of Spamcontrol + FreeBSD (currently 10.3) as well
>> (and this mail header being produced on FreeBSD as first hop and
>> Linux as a 2nd) shows the email went thru without problems (using
>> qmail-remote + QMTPS on s/qmail, I really am interested you should
>> Spamcontrol make fail on AMD64 which I use as test and development
>> environment.
>>
>> Here is my con-ld file:
>>
>> [sqmail@bigchief /usr/local/src/qmail-1.03.2732]$ vi conf-ld
>> cc -s -m64
>>
>> This is for AMD64 architecture; use else:
>>
>> cc -s
>>
>> This will be used to link .o files into an executable.
>>
>> Note: UCSPI-SSL's conf-ld needs to use the same architecture!
>> ~
>>
>> :q!
>> [sqmail@bigchief /usr/local/src/qmail-1.03.2732]$ ls -la conf-ld
>> -rw-r--r-- 1 root wheel 181 Oct 26 2014 conf-ld
>>
>> Did you adjust for those?
>>
>> Regards.
>> --eh.
>>
>>> Am 15.04.2016 um 14:42 schrieb Willo van der Merwe
>> <qbitza@gmail.com>:
>>>
>>> I've also been looking for a solution for this.
>>>
>>> On 15 April 2016 at 04:28, <support@nelsonandwright.com> wrote:
>>> Hello,
>>>
>>> I'm going to interject here but I have been running FreeBSD for
>> quite a number of years and smtp TLS runs fine on i386 but with
>> amd64 it does not. It just gives me a status 11 in the qmail smtp
>> logs and in the freebsd messages log it just says segfault. I have
>> been troubleshooting this myself and according to the tls log it
>> does answer ready for tls but the session fails when sending a
>> message.
>>>
>>> Bill
>>>
>>>
>>> On 2016-04-14 16:18, Erwin Hoffmann wrote:
>>> Hi Michael,
>>>
>>> regarding Spamcontrol + s/qmail and certainly most other TLS
>>> enhancements for qmail, these kind of problems belong to the TLS
>>> layer.
>>>
>>> sslserver/qmail-remote/qmail-smtpd are users of TLS (either by an
>> API
>>> or by included libs).
>>>
>>> There are very few 'knobs' you can tune:
>>>
>>> a) ucspi-ssl (my version) does not allow SSLv2 connections (as
>> hard
>>> coded; but subject of change in the sources).
>>>
>>> b) The cipher suite to be announced or accepted (by
>> qmail-remote). In
>>> the TLS scheme, the server provides a set of acceptable suites,
>> while
>>> the client choses one.
>>> Both depend on the OpenSSL or LibreSSL libs are whatever is in
>> place.
>>> In particular, if ECC can be used or not.
>>>
>>> Unfortunately, the OpenSSL error codes don't tell very much. In
>> you
>>> case the simply say: 'I do have a TLS handshake problem with this
>>> host' -- please fix it.
>>>
>>> regards.
>>> --eh.
>>>
>>>
>>> Am 14.04.2016 um 18:45 schrieb Michael Brunnbauer
>> <brunni@netestate.de>:
>>>
>>>
>>> hi all,
>>>
>>> the admins of one of the affected MX tell me that they have
>> problems with
>>> DH parameters > 768 bits causing timeouts. We recently upgraded
>> from OpenSSL
>>> 1.0.1q to 1.0.1s and the changelog for 1.0.1r says:
>>>
>>> "Reject DH handshakes with parameters shorter than 1024 bits."
>>>
>>> https://www.openssl.org/news/cl101.txt [1]
>>>
>>> Maybe that explains it?
>>>
>>> Regards,
>>>
>>> Michael Brunnbauer
>>>
>>> On Thu, Apr 14, 2016 at 12:53:54PM +0200, Michael Brunnbauer
>> wrote:
>>>
>>> hi all,
>>>
>>> I have transient TLS problem with certain destinations that cause
>> some mails
>>> to be delayed with the error
>>>
>>> delivery ... deferral:
>> TLS_connection/protocol_error_for_for_host:..._(#4.4.1)/
>>>
>>> Sometimes mail goes through right away, sometimes after several
>> trials and
>>> sometimes it takes days. So far I have identified these
>> destinations:
>>>
>>> hotmail.com [2] (mx1.hotmail.com [3])
>>> neumann-neumann.com [4] (mail.neumann-neumann.com [5])
>>> ton-objekt.de [6] (ton-objekt.de.pri-mx.eu0103.smtproutes.com
>> [7])
>>>
>>> Most interesting here is hotmail.com [2]. I am not able to
>> communicate properly with
>>> mx*.hotmail.com [2] via the openssl client. An encrypted
>> connection via STARTTLS
>>> is established but then the server does not respond to most
>> commands.
>>> "QUIT" works, "quit", "HELO", "EHLO", "MAIL FROM:" does not:
>>>
>>> openssl s_client -connect mx1.hotmail.com:25 [8] -starttls smtp
>>> CONNECTED(00000003)
>>> ...
>>> SSL-Session:
>>> Protocol : TLSv1.2
>>> Cipher : ECDHE-RSA-AES256-SHA384
>>> Session-ID:
>> 493A0000F823516DED700287A61AAA62F886AD12B02635F4A7B2845431B4CF3F
>>> Session-ID-ctx:
>>> Master-Key:
>>
> 3FEC7E06D8229053DF4FA60DD7BBFA850C86BB198AA8C4E325729619EE9486D548B4541B34D277780D93A6503DC45B03
>>> Key-Arg : None
>>> PSK identity: None
>>> PSK identity hint: None
>>> SRP username: None
>>> Start Time: 1460629034
>>> Timeout : 300 (sec)
>>> Verify return code: 0 (ok)
>>> ---
>>> 250 OK
>>> EHLO fiano.netestate.de [9]
>>> read:errno=104
>>>
>>> The response to QUIT is also quite non-SMTP-like:
>>>
>>> 250 OK
>>> QUIT
>>> DONE
>>>
>>> I can reproduce this running the openssl client from several data
>> centers and
>>> distributions (OpenSSL 1.0.1s and 1.0.1f). http://checktls.com
>> [10] does not report
>>> any problems with hotmail.com [2].
>>>
>>> Can somebody here reproduce this or shed light on it?
>>>
>>> I had two mails to hotmail.com [2] in the queue today that were
>> delayed for days.
>>> After putting "!hotmail.com [2]:" in tlsdestinations, hotmail
>> reported
>>> "552 Message size exceeds fixed maximum message size".
>>>
>>> I am quite sure that in my first trials with the openssl client
>> and
>>> ton-objekt.de.pri-mx.eu0103.smtproutes.com [7], the connection
>> was closed after
>>> the TLS connection was established but before I could enter a
>> command but I
>>> was not able to reproduce this since then.
>>>
>>> I will conduct further experiments but maybe someone has clues
>> for me.
>>>
>>> Regards,
>>>
>>> Michael Brunnbauer
>>>
>>> --
>>> ++ Michael Brunnbauer
>>> ++ netEstate GmbH
>>> ++ Geisenhausener Straße 11a
>>> ++ 81379 München
>>> ++ Tel +49 89 32 19 77 80
>>> ++ Fax +49 89 32 19 77 89
>>> ++ E-Mail brunni@netestate.de
>>> ++ http://www.netestate.de/ [11]
>>> ++
>>> ++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
>>> ++ USt-IdNr. DE221033342
>>> ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
>>> ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
>>>
>>>
>>>
>>> --
>>> ++ Michael Brunnbauer
>>> ++ netEstate GmbH
>>> ++ Geisenhausener Straße 11a
>>> ++ 81379 München
>>> ++ Tel +49 89 32 19 77 80
>>> ++ Fax +49 89 32 19 77 89
>>> ++ E-Mail brunni@netestate.de
>>> ++ http://www.netestate.de/ [11]
>>> ++
>>> ++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
>>> ++ USt-IdNr. DE221033342
>>> ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
>>> ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
>>>
>>> Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de [12] | PGP
>> Key-Id: EE00CF65
>>>
>>>
>>
>> Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de [12] | PGP
>> Key-Id: EE00CF65
>
>
>
> Links:
> ------
> [1] https://www.openssl.org/news/cl101.txt
> [2] http://hotmail.com
> [3] http://mx1.hotmail.com
> [4] http://neumann-neumann.com
> [5] http://mail.neumann-neumann.com
> [6] http://ton-objekt.de
> [7] http://ton-objekt.de.pri-mx.eu0103.smtproutes.com
> [8] http://mx1.hotmail.com:25
> [9] http://fiano.netestate.de
> [10] http://checktls.com
> [11] http://www.netestate.de/
> [12] http://www.fehcom.de

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal