FS#10038 - [courier-mta] and GNU TLS
Attached to Project:
Community Packages
Opened by Andrej Podzimek (andrej) - Monday, 31 March 2008, 16:23 GMT
Last edited by Sven-Hendrik Haase (Svenstaro) - Sunday, 24 October 2010, 16:11 GMT
Opened by Andrej Podzimek (andrej) - Monday, 31 March 2008, 16:23 GMT
Last edited by Sven-Hendrik Haase (Svenstaro) - Sunday, 24 October 2010, 16:11 GMT
|
Details
Description:
I badly need Courier-MTA with GNU TLS support. More than 50% of ESMTP servers talking to my machine do SSL3 on the TLS port. This is illegal, but servers do that... (Switching all the encryption off would be a _bad_ solution.) I used to build a gnutls-enabled Courier-MTA by adding --with-gnutls to the PKGBUILD. It worked just fine for more than half a year. With GNU TLS, you can specify TLS_PROTOCOL="TLS1_1:TLS1:SSL3" in your config files for automatic fallback. Since this week and the courier-mta update, Courier does *not* work with GNU TLS any more. A TLS connection cannot be established. Nothing is logged after STARTTLS, but dmesg says: couriertls[21106]: segfault at b89f60b5 eip 0804c980 esp bfe12c1c error 6 Each attempt to STARTTLS over ESMTP adds one such error message to dmesg... No connection is established. As for IMAP with TLS, connections are terminated immediately, with no log messages between 'connected' and 'disconnected'. Additional info: * package version(s) * config and/or log files etc. 0.57.1 worked, 0.59.0 fails. Steps to reproduce: Install gnutls. Add --with-gnutls to PKGBUILD for courier-mta. Build and install the courier-mta package this way. Start the server and try to send a message via ESMTP with STARTTLS. |
This task depends upon
Closed by Sven-Hendrik Haase (Svenstaro)
Sunday, 24 October 2010, 16:11 GMT
Reason for closing: No response
Additional comments about closing: I'm closing this due to lack of new input. Please reopen if the problem persists.
Sunday, 24 October 2010, 16:11 GMT
Reason for closing: No response
Additional comments about closing: I'm closing this due to lack of new input. Please reopen if the problem persists.
http://www.nabble.com/courier-TLS_PROTOCOL-compatibility-td15970197.html
My courier setups are very simple AND i control all the clients that connect so that was not an issue for me.
Just a wild guess: GNU TLS hasn't changed much lately. So there must be a bug in the new version of Courier-MTA. However, this is hard to prove, for:
1) Courier 0.57.1 and 0.58 won't even compile. (string.h had been included indirectly in many files...)
2) Courier 0.59 does compile (--with-gnutls), but couriertls segfaults.
It would be great to upgrade the whole Courier-MTA mess using something like 'pacman -S courier-mta-gnutls'. That would be much better than editing the PKGBUILD and recompiling on each update. Without a unified package, one can't even guess whether the segfault is caused by a problem on my machine or by a serious bug...
Anyway, nobody voted for this task except for me, which might mean nobody wants/needs TLS 1.1 and TLS 1.2 support right now. If so, just feel free to delete this task.
I don't feel like maintaining a openssl Courier AND gnutls Courier is overkill. We need to find a way that works with just one package providing sufficient ssl support.
I'm not sure though what could be done at the moment about it ...
Today, my mail server met a peer who required TLS >= 1.1 and refused the OpenSSL-based connection. (It was, presumably, a customer support mail server run by a bank.) That's why GNU TLS could be useful, if not vital. What could I do to find out where exactly the segfault occurs? (It might be caused by one of the dependencies, not by GNU TLS itself...)
* drop the --with-gnutls option, or
* release a version which doesn't segfault when compiled with it
Once we've done that, it sounds to me like we should close this bug, as it doesn't sound like there's much else for us to do.