Re: [courier-users] submission problems

[<co...@ec...>]

Hi,

first of all, I want to thank all of you for your replies. It sure gave 
hope and helped me resolve the issue!

Ángel writes:
> The working IMAP over tls will have a process similar to:
> /usr/sbin/couriertcpd -address=0 -maxprocs=... -maxperip=... - 
> access=/etc/courier/imapaccess.dat -nodnslookup -noidentlookup 993 
> /usr/bin/couriertls -server -tcpd -user=courier /usr/lib/courier/courier/imaplogin ...
>
> whereas SMTP over tls should look basically the same but running 
> courieresmtpd instead of imaplogin, e.g.
>
> /usr/sbin/couriertcpd -stderrlogger=/usr/sbin/courierlogger - 
> stderrloggername=esmtpd-ssl -maxprocs=... -maxperip=... -maxperc=... - 
> pid=/var/run/courier/esmtpd-ssl.pid -stderrlogger=/usr/sbin/courierlogger 
> -noidentlookup -user=courier -group=courier - 
> access=/etc/courier/smtpaccess.dat -address=0 465 /usr/bin/couriertls - 
> server -tcpd /usr/sbin/courieresmtpd

Yes, these processes are running.

btw: there's an easier way to find the PIDs: they are stored in 
/run/courier/...

> Assuming the later is running (as it probably does, since *something*
> is replying on that port), you should check why is couriertls not .
> Have a look at the TLS_CERTFILE= configured for the esmtpd-ssl, you can
> verify it is indeed set for that binary looking at /proc/<pid>/environ
> and also that the user under which it is running is able to open the
> file (including all intermediate folders)

TLS_CERTFILE is the same for both - according to config and environment.

In fact, I haven't changed either config since march 2019.

Sam Varshavchik writes:
> Another possibility is that imap reads the certificate as root, but esmtp as 
> a non-privileged user so file access permissions could be the factor, but I 
> would expect this to manifest differently. Here, it looks like it read the 
> certicicate, but crashed inside gnutls.

Indeed, esmtpd-ssl runs as courier user, while imapd-ssl runs as root 
user. However, when I 'su courier', the courier user can perfectly read 
the cipher files:

$ sha512sum /var/lib/courier/keys/*
8-snip-1  /var/lib/courier/keys/fullchain.pem
9-snip-a  /var/lib/courier/keys/privkey.pem
d-snip-3  /var/lib/courier/keys/ssl-dhparams.pem

btw: I attached strace to the esmtpd-ssl part of courier (I don't want to 
post the complete output right now, I'm not sure, that it doesn't contain 
the private keys) and there is only an "openat" for 
/var/lib/courier/keys/ssl-dhparams.pem which are the dh parameters lying 
next to the keys, but no openat for the keys/certs themself (yet). Then it 
appears to read all certs in /etc/ssl/certs/, after which it crashes with:

[pid 381845] mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
[pid 381845] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x8c} ---
[pid 381845] +++ killed by SIGSEGV (core dumped) +++

Maybe the crux is this line, which I have in esmtpd-ssl but not imapd-ssl (for years):
AUTH_REQUIRED=1

the full diff:
--- /etc/courier/esmtpd-ssl	2023-01-06 21:59:56.767564673 +0100
+++ /etc/courier/imapd-ssl	2023-01-06 21:59:56.767564673 +0100
@@ -1,25 +1,17 @@
-AUTH_REQUIRED=1
-BOFHCHECKDNS=1
-BOFHNOEXPN=0
-BOFHNOVRFY=0
  COURIERTLS=/usr/bin/couriertls
-ESMTPDSSLSTART=NO
-ESMTP_LOG_DIALOG=0
-MAXDAEMONS=40
-MAXPERC=20
-MAXPERIP=10
-NOADDDATE=1
-NOADDMSGID=1
-NOADDRREWRITE=0
+IMAPDSSLSTART=NO
+IMAPDSTARTTLS=YES
+IMAP_TLS_REQUIRED=0
+MAILDIRPATH=Maildir
  SSLADDRESS=0
-SSLPIDFILE=/run/courier/esmtpd-ssl.pid
-SSLPORT=465
-TARPIT=1
-TCPDOPTS+=' -noidentlookup'
+SSLLOGGEROPTS="-name=imapd-ssl"
+SSLPIDFILE=/run/courier/imapd-ssl.pid
+SSLPORT=993
+TLS_CACHEFILE=/var/spool/courier/couriersslpop3cache
+TLS_CACHESIZE=524288
  TLS_CERTFILE=/var/lib/courier/keys/fullchain.pem
  TLS_DHPARAMS=/var/lib/courier/keys/ssl-dhparams.pem
  TLS_PRIVATE_KEYFILE=/var/lib/courier/keys/privkey.pem
+TLS_STARTTLS_PROTOCOL="$TLS_PROTOCOL"
  TLS_TRUSTCERTS=/etc/ssl/certs/
  TLS_VERIFYPEER=NONE
-exec_prefix=/usr
-prefix=/usr

My guess: The server reads all those certs to be able to verify peers. One 
of them triggers a (new) bug in gnutls.

Indeed, when I change
TLS_TRUSTCERTS=/etc/ssl/certs/
to
TLS_TRUSTCERTS=/dev/null
and restart courier-esmtpd-ssl, then submission works!

Are these certificates really only needed to verify peers as the comment 
in the config suggests? If so, then I can safely keep this workaround.

OTOH, it might be nice to dive into this issue and file a bug against 
gnutls.

regards,
Erich