Your message dated Sat, 11 Jan 2020 13:28:35 +0100 with message-id <20200111122834.GA9963@azadi> and subject line opendkim: Signing via TCP socket works, unix socket fails with SSL error has caused the Debian Bug report #944513, regarding opendkim: Signing via TCP socket works, unix socket fails with SSL error to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 944513: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944513 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: opendkim Version: 2.11.0~alpha-12 Severity: normal Dear Maintainer, I'm using opendkim to sign outbound messages in Postfix. My previous installation used a TCP socket, that configuration still works. According to Debian Wiki and upstream, we should use a unix socket now, not TCP. Postfix is in a chroot at /var/spool/postfix. I switched the socket, as advised, to local:/var/spool/postfix/var/run/opendkim/opendkim.sock in /etc/opendkim.conf and gave smtpd_milters = unix:/var/run/opendkim/opendkim.sock non_smtpd_milters = unix:/var/run/opendkim/opendkim.sock in /etc/postfix/main.cf. After restarting postfix and opendkim, signing outbound messages fails. The postfix submission process returns an error to the client. The error message in /var/log/mail.info is Nov 10 20:47:03 seed10 opendkim[24709]: 120F6205B0: SSL error:0D06B08E:asn1 encoding routines:asn1_d2i_read_bio:not enough data Nov 10 20:47:03 seed10 opendkim[24709]: 120F6205B0: dkim_eom(): resource unavailable: d2i_PrivateKey_bio() failed I expected a localhost:TCP socket and a unix socket would behave the same. It looks as if SSL is not receiving all the information it needs from opendkim. I worked around the failure by reverting the socket change. -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-cloud-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages opendkim depends on: ii adduser 3.118 ii dns-root-data 2019031302 ii libbsd0 0.9.1-2 ii libc6 2.28-10 ii libdb5.3 5.3.28+dfsg1-0.5 ii libldap-2.4-2 2.4.47+dfsg-3+deb10u1 ii liblua5.1-0 5.1.5-8.1+b2 ii libmemcached11 1.0.18-4.2 ii libmemcachedutil2 1.0.18-4.2 ii libmilter1.0.1 8.15.2-14~deb10u1 ii libopendbx1 1.4.6-13+b1 ii libopendkim11 2.11.0~alpha-12 ii librbl1 2.11.0~alpha-12 ii libssl1.1 1.1.1d-0+deb10u2 ii libunbound8 1.9.0-2+deb10u1 ii libvbr2 2.11.0~alpha-12 ii lsb-base 10.2019051400 opendkim recommends no packages. Versions of packages opendkim suggests: ii opendkim-tools 2.11.0~alpha-12 pn unbound <none> -- Configuration Files: /etc/default/opendkim changed: RUNDIR=/var/spool/postfix/var/run/opendkim SOCKET=local:$RUNDIR/opendkim.sock USER=opendkim GROUP=opendkim PIDFILE=$RUNDIR/$NAME.pid EXTRAAFTER= /etc/dkimkeys/README.PrivateKeys [Errno 13] Permission denied: '/etc/dkimkeys/README.PrivateKeys' /etc/opendkim.conf changed: Syslog yes UMask 007 KeyFile /etc/dkimkeys/truffula.private Domain truffula.us Selector mail Socket inet:12301@localhost PidFile /run/opendkim/opendkim.pid OversignHeaders From TrustAnchorFile /usr/share/dns/root.key UserID opendkim -- no debconf information
--- End Message ---
--- Begin Message ---Searching for the OpenSSL error message online yields a number of hits all pointing to corruption or format error of public or private key. I suggest double-checking the key, and perhaps regenerate. In the meantime, the Debian wiki page has been thoroughly overhauled and now contains the most up-to-date information regarding socket config. It is unlikely that this problem is related to the UNIX domain socket. This functionality is stable and generally working well, and so I’m closing this bug. We can of course reopen if necessary.
--- End Message ---
