Re: Spamcontrol 2.7.32 qmail-remote TLS problems

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 <[email protected]> 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 <[email protected]>:
> >
> > I've also been looking for a solution for this.
> >
> > On 15 April 2016 at 04:28, <[email protected]> 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 <[email protected]>:
> >
> >
> > 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 [email protected]
> > ++  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 [email protected]
> > ++  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
>
>
>
>
>
>