Re: Spamcontrol 2.7.32 qmail-remote TLS problems

Erwin Hoffmann <[email protected]> Fri, 15 Apr 2016 23:04:39 +0200
Newsgroups	gmane.mail.qmail.general
Message-ID	<[email protected]>
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
signature.asc (application/pgp-signature, 842 B)