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
Task Type Feature Request
Category Packages
Status Closed
Assigned To Tobias Kieslich (tobias)
Sven-Hendrik Haase (Svenstaro)
Architecture All
Severity High
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

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.
Comment by Andrej Podzimek (andrej) - Monday, 31 March 2008, 16:27 GMT Comment by Tobias Kieslich (tobias) - Sunday, 06 April 2008, 21:29 GMT
I am not sure what exactly I can do about that issue. You say you wanna have it built against gnu_tls which I think i could do (recompile the whole family) but you also say that courier does not work with gnu_tls anymore. So I'm not sure what I should do ?
My courier setups are very simple AND i control all the clients that connect so that was not an issue for me.
Comment by Andrej Podzimek (andrej) - Sunday, 06 April 2008, 23:23 GMT
Well, introducing a new (separate) package of Courier-MTA with GNU TLS support would be an ideal solution. (Not right now, but once the current bugs are fixed.) I don't think GNU TLS won't work with Courier any more. It just doesn't work right now, presumably due to a bug.

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.
Comment by Tobias Kieslich (tobias) - Monday, 07 April 2008, 18:41 GMT
Okay, it sounds like you wanna have Courier compiled against gnutls because openssl provides SSL3 only which is valid but most clients don't really support it. For more practicability it would be better to be compiled against gnutls because that provides TLS AND SSL in different versions. However, with courier-mta0.59 that is broken upstream.
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 ...
Comment by Andrej Podzimek (andrej) - Tuesday, 15 April 2008, 23:06 GMT
I still can't find a single note about this problem. Google doesn't know about it. What if bot GNU TLS and Courier work just fine and there's something wrong with my system? That's the only explanation I can think of right now... Don't have access to multiple machines, can't prove or disprove this. As already mentioned, there was nothing useful in the logs even with debugging messages turned on.

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...)
Comment by Glenn Matthys (RedShift) - Tuesday, 17 June 2008, 19:27 GMT
What's the status of this issue?
Comment by Andrej Podzimek (andrej) - Sunday, 28 December 2008, 05:20 GMT
The current version of Courier-MTA still segfaults when compiled --with-gnutls.
Comment by Andrej Podzimek (andrej) - Saturday, 07 March 2009, 03:36 GMT
The current version of Courier-MTA still segfaults when compiled --with-gnutls. People from Courier-MTA reported some GNU TLS bugs some time ago, but there's still no improvement at all.
Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 05 June 2009, 18:56 GMT
status with the latest gnutls?
Comment by Andrej Podzimek (andrej) - Wednesday, 01 July 2009, 17:16 GMT
Still the same old story.
Comment by Paul Mattal (paul) - Friday, 05 March 2010, 13:42 GMT
Have we filed anything upstream here? It seems that courier-mta would agree to either:

* 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.
Comment by Sven-Hendrik Haase (Svenstaro) - Friday, 24 September 2010, 04:26 GMT
Is this still an issue with the most recent package?

Loading...