From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 96DBD6DE0240 for ; Tue, 30 Jan 2018 12:55:37 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[AWL=0.620, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8goE4ZetQhwU for ; Tue, 30 Jan 2018 12:55:34 -0800 (PST) X-Greylist: delayed 462 seconds by postgrey-1.36 at arlo; Tue, 30 Jan 2018 12:55:34 PST Received: from smtpx.feld.cvut.cz (smtpx.feld.cvut.cz [147.32.192.33]) by arlo.cworth.org (Postfix) with ESMTP id 5F7B46DE023A for ; Tue, 30 Jan 2018 12:55:34 -0800 (PST) Received: from localhost (unknown [192.168.200.7]) by smtpx.feld.cvut.cz (Postfix) with ESMTP id EC9FADC495; Tue, 30 Jan 2018 21:47:50 +0100 (CET) X-Virus-Scanned: IMAP STYX AMAVIS Received: from smtpx.feld.cvut.cz ([192.168.200.6]) by localhost (styx.feld.cvut.cz [192.168.200.7]) (amavisd-new, port 10054) with ESMTP id wuoESdLYSQTk; Tue, 30 Jan 2018 21:47:49 +0100 (CET) Received: from imap.feld.cvut.cz (imap.feld.cvut.cz [147.32.192.34]) by smtpx.feld.cvut.cz (Postfix) with ESMTP id 1DB1EDC3DF; Tue, 30 Jan 2018 21:47:49 +0100 (CET) Received: from wsh by steelpick.2x.cz with local (Exim 4.90) (envelope-from ) id 1egcol-0007ye-Om; Tue, 30 Jan 2018 21:47:47 +0100 From: Michal Sojka To: Daniel Kahn Gillmor , notmuch@notmuchmail.org Subject: Re: Long delay when opening signed emails In-Reply-To: <87lggfb8fk.fsf@fifthhorseman.net> References: <87607js4lp.fsf@steelpick.2x.cz> <87lggfb8fk.fsf@fifthhorseman.net> Date: Tue, 30 Jan 2018 21:47:47 +0100 Message-ID: <87efm7qdjg.fsf@steelpick.2x.cz> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.24 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 20:55:37 -0000 On Tue, Jan 30 2018, Daniel Kahn Gillmor wrote: > Hi Michal-- > > On Tue 2018-01-30 17:17:54 +0100, Michal Sojka wrote: >> Hi all, >> >> I experience annoyingly long delay, when opening some signed emails in >> Emacs. This is likely related to the following lines appearing in my >> log when opening the email: >> >> Jan 30 17:07:46 dirmngr[7526]: no CRL available for issuer id A401B7A860C859FEA90E1A7EEE2BAF37C7FB918F >> Jan 30 17:08:06 dirmngr[7526]: resolving 'crl3.digicert.com' failed: Server indicated a failure >> Jan 30 17:08:06 dirmngr[7526]: can't connect to 'crl3.digicert.com': host not found >> Jan 30 17:08:06 dirmngr[7526]: error retrieving 'http://crl3.digicert.com/TERENAeSciencePersonalCA3.crl': Server indicated a failure >> Jan 30 17:08:06 dirmngr[7526]: crl_fetch via DP failed: Server indicated a failure >> Jan 30 17:08:06 dirmngr[7526]: command 'ISVALID' failed: Server indicated a failure >> >> I don't understand why resolving crl3.digicert.com fails, because it >> works from command line. > > I think the e-mail in question is S/MIME-signed. is that right? Yes, that's correct. > It looks like dirmngr is having some problems with network connectivity > -- perhaps it has the wrong information about DNS resolvers? > > as a workaround, have you tried terminating dirmngr to let it restart > when needed? you can do that with: > > gpgconf --kill dirmngr > > (it should respawn automatically as needed) That didn't help. >> Any suggestions how to solve the failure or at least to get rid of the >> delay? > > Apart from the workaround described above, if you decide that you'd > rather avoid doing CRL checks in general (you might want that to avoid > metadata leakage at least), you could put "disable-crl-checks" on its > own line in ~/.gnupg/gpgsm.conf Perfect, that prevents the delays. > See also https://dev.gnupg.org/T3348 -- i'm asking upstream to default > to False there. Hmm, now I see that my problem is probably the same as in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842291 referenced from your GPG bug report. Thank you. -Michal