Package Details: courier-mta 1.0.14-1

Git Clone URL: (read-only, click to copy)
Package Base: courier-mta
Description: IMAP(s)/POP3(s) and SMTP Server with ML-manager, webmail and webconfig
Upstream URL:
Licenses: GPL2
Conflicts: courier-imap, courier-maildrop, imap-server, smtp-forwarder, smtp-server, ucspi-tcp
Provides: courier-imap, courier-maildrop, imap-server, pop3-server, smtp-forwarder, smtp-server
Submitter: Svenstaro
Maintainer: vario
Last Packager: vario
Votes: 11
Popularity: 0.000000
First Submitted: 2012-10-13 09:56
Last Updated: 2020-06-20 05:21

Required by (94)

Sources (14)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 Next › Last »

JesusMcCloud commented on 2015-09-13 19:52

Thanks for the input. I don't use STARTTLS, but TLS directly. This setup does not cause any problems.

andrej commented on 2015-09-13 17:53

I certainly don't want/need SSL3 to work. However, the default build with OpenSSL doesn't let Thunderbird connect and it doesn't even let openssl s_client in. The reason is unknown to me, simply because Thunderbird has no problem with TLS 1.2 otherwise. Switching to --with-gnutls on the Courier side resolved the issue and both Thunderbird and s_client connect just fine.

FTR, one can do some debugging over encrypted IMAP like this:
openssl s_client -starttls imap -connect your.server.address:143

Once you have this^^^ connection, you can do a few debugging steps like IMAP login, inbox queries etc. This is how I diagnosed the problem. I first tried to drop the STARTTLS requirement, just to find out that a clear text login from localhost worked. (So it was not an authdaemon or IMAP server problem.) Next I made STARTTLS mandatory again and tried to connect with s_client. Surprisingly, s_client connections failed with the error message noted below (no matter if I specified TLS 1, 1_1, 1_2 or whatnot on the command line explicitly) when attempted against the OpenSSL-based Courier. Once I switched to --with-gnutls, OpenSSL's s_client had no issues at all. And it says TLS 1.2 in its connection logs. Thunderbird works again, too. Well, this is somewhat weird, but now that GnuTLS doesn't make Courier segfault any more, it seems that everything works fine for me.

JesusMcCloud commented on 2015-09-13 11:50

Thanks @andrej, for pointing out errors in the unit files; this is fixed now.

Just to be clear, everything works fine on my machine when built against OpenSSL.
Deprecated protocols (such as SSL3) not working, is a *good* thing, not a bug.

markc commented on 2015-09-13 11:12

@andrej I think SSL3 has been removed from the latest courier config files. I can't check atm but it may be possible to add it back to one of the TLS variables. It's also possible OpenSSL have deprecated or removed it too. FWIW.

andrej commented on 2015-09-13 07:39

One more hint for those who run this:
A few months ago GnuTLS used to be broken (segfaulting) and OpenSSL used to work fine, supporting even TLS 1.1 and 1.2. Well, not any more...

With OpenSSL you'll now get the following error when trying to connect to IMAP with STARTTLS: routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:362

So I tried to compile Courier-MTA --with-gnutls and IMAP with STARTTLS works for me again.

andrej commented on 2015-09-13 07:23

Could you please fix the broken Systemd unit files? You can't put any shell commands into the unit file, so you need to set ExecStartPre=/bin/sh -c 'whatever stuff you have there now'.

markc commented on 2014-05-27 16:25

FWIW I just built 0.73.1 and it seems to work okay for local testing.

I also removed apache from the makedepends line and it did not interfere with the build so would you mind removing apache from the next update as I use nginx. Thanks.

@andrej: will take particular note of your problem and will report back if I notice anything similar. I have a Ubuntu 14.04 server with Btrfs that blocks for a few minutes until the client re-logs in. Slightly similar problem.

andrej commented on 2014-03-09 07:22

Courier-MTA 0.73.1 doesn't work for me for some reason. When I build it using the current PKGBUILD (just by editing the version number), I get a faulty Courier that cannot handle IMAP connections. There used to be 2 kinds of problems that could spoil IMAP connections: (1) something related to the (mis)use of Gamin / FAM and the IDLE IMAP extension, and (2) a glitch that caused the IMAP protocol handler (a binary that speaks IMAP and gets exec()'d (probably) by couriertcpd once the initial TCP and TLS matters are set) to be installed into a wrong directory, so the exec() failed and IMAP connections were closed immediately.

However, this time it's different. :-( The symptoms are similar to the well-known problems from the past, but it doesn't seem to be anything related to Gamin or installation paths. Additionally, although the IMAP connections are closed immediately according to Courier's logs, the underlying TCP connections remain open, blocking the IMAP client forever. Version 0.72 works OK for me. Sadly I just don't have time to look at the diffs and dig deeper into this issue.

meskarune commented on 2014-01-26 19:44

I'm going to work on getting this cleaned up and updated in the next 2 weeks. There is a new version that was released Jan. 13th. Any suggestions would be great appreciated, I'm fairly new to packaging.

andrej commented on 2013-11-26 18:03

I submitted a DKIM filter package for Courier-MTA. It seems to work fine on my server. Comments are welcome.