From owner-ctm-users@freebsd.org Mon Sep 7 13:54:13 2015 Return-Path: Delivered-To: ctm-users@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8127A9CB390 for ; Mon, 7 Sep 2015 13:54:13 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B8CE31EC8 for ; Mon, 7 Sep 2015 13:54:11 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p5B227F18.dip0.t-ipconnect.de [91.34.127.24]) (authenticated bits=128) by slim.berklix.org (8.14.5/8.14.5) with ESMTP id t87DuYcM047416; Mon, 7 Sep 2015 15:56:34 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id t87Ds1S0009510; Mon, 7 Sep 2015 15:54:01 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id t87DrVGV023261; Mon, 7 Sep 2015 15:54:01 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <201509071354.t87DrVGV023261@fire.js.berklix.net> To: jvarner@gmail.com cc: ctm-users@freebsd.org, Peter Wemm Subject: Re: Future of CTM From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Sat, 05 Sep 2015 14:39:48 -0400." <201509051839.t85IdmIJ047044@eden.local> Date: Mon, 07 Sep 2015 15:53:31 +0200 X-BeenThere: ctm-users@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: CTM User discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 13:54:13 -0000 jvarner@gmail.com wrote: > (apologies for not replying to previous emails; just subscribed to > the list...) > Peter Wemm wrote: > > > I have been trying to find an example of somebody who is actually > > verifying signatures before piping the messages to ctm_rmail. > > I am such an example. The following recipe is the one I use (I > use nmh, so for most people the pipe to rcvstore should be > replaced with a simple mailbox or maildir delivery): > > :0 > * ^X-BeenThere: ctm-ports-cur@freebsd.org > { > > :0 c: ${MAILDIR}/ctm-ports.${LOCKEXT} > | rcvstore +ctm-ports -nounseen > > :0 c > | gpg --no-default-keyring --keyring ${PMDIR}/ctm.key --verify > > :0 a > | ctm_rmail -p ${HOME}/ctms/ports/pieces -d ${HOME}/ctms/ports/deltas -l ${PMDIR}/ctm.log > } Thanks for the example! I linked to it from http://ctm.berklix.org I'm studying it, before upgrading my http://berklix.com/~jhs/dots/.procmailrc.lists http://berklix.com/~jhs/src/bsd/jhs/bin/local/mail/ctm-freebsd-ports-incoming Suggestions: Line 1 s/:0/:0 Hw/ Line 11 s/:0 a/:0 Haw/ H is by default, but appending 'w', So if connecting to internet after days of absence, the 'w' should wait & thus reduce cpu load if mail includes an incoming flood of ctms for different paths, eg ports-cur src-9 src-10 etc that might otherwise run in parallel. Nit picking: ;-) Instead of * ^X-BeenThere: ctm-ports-cur@freebsd.org I use * ^Sender: (|owner\-)ctm-ports-cur(|\-bounces)@freebsd\.org Sender might be formaly correct, long term stable ? The 2nd ':' in ":0 c:" puzzled me. man 5 procmailrc shows you invoke a lockfile. No subsequent line uses your lock name, so why specify it "${MAILDIR}/ctm-ports.${LOCKEXT}" ? Is it so you know what to manually clear if something fails ? Why do you need a lockfile ? Is it gpg that needs the lockfile ? or would you have asserted a lock even if not using gpg ? (My non gpg ctm works, but I see bursts of errors which I guess are out of order mails, deltas or pieces to deltas, that dont always immediately build to an applicable ctm; is lockfile to mitigate that rather than particulary for gpg ?) man 5 procmailrc quotes opaquely: "A locallockfile on the recipe that marks the start of a non-forking nested block does not work as expected." > Where ctm.key was produced by importing and exporting the ascii > armored key from the mailman info page. OK, There's a common key in both http://lists.freebsd.org/mailman/listinfo/ctm-ports-cur http://lists.freebsd.org/mailman/listinfo/ctm-src4 & it works for src-10 too, so presumably all. Extracted with vi. mv ~/.gnupg ~/.gnupg.orig gpg --import \ ~/public_html/src/bsd/jhs/bin/local/mail/ctm-freebsd-gnupg-pubkey.asc mv ~/.gnupg/pubring.gpg \ ~/public_html/src/bsd/jhs/bin/local/mail/ctm-freebsd-gnupg-pubring.pgp rm -rf ~/.gnupg mv .gnupg.orig .gnupg In a Makefile (to test return result is 0 on success): gpg --verify --no-default-keyring --keyring \ ~/public_html/src/bsd/jhs/bin/local/mail/ctm-freebsd-gnupg-pubring.pgp \ /home/jhs/mail/CTM/36 cat ~/mail/CTM/36 | gpg --verify --no-default-keyring --keyring \ ~/public_html/src/bsd/jhs/bin/local/mail/ctm-freebsd-gnupg-pubring.pgp \ /home/jhs/mail/CTM/36 Both exit OK with next command running, though I saw: gpg: Good signature from "CTM Generator " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs \ to the owner. I tried briefly but failed to get rid of the warning with gpg --edit-key trust 65FE4840 > I did check to confirm > that modifying a signed CTM message will prevent ctm_rmail from > running (gpg exits with an status of 2, which prevents the 'a' > recipe from running). Makefile errored both times when I tampered 1st char of delta or signature. > I did not check to confirm that a > mis-signed message would not verify, but my presumption is that > the combination of --no-default-keyring and --keyring should > prevent that verification from working since the only key in the > specified keyring is the CTM signing key. Sound reasonable. Thanks, & if you have time for questions above, great :-) Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Reply after previous text, like a play - Not before, which looses context. Indent previous text with "> " Insert new lines before 80 chars. Send plain text, Not quoted-printable, Not HTML, Not ms.doc, Not base64.