Re: qconfirm: manual confirmation-only mode?

Gerrit Pape <[email protected]>
Newsgroups gmane.comp.misc.pape.general
Message-ID <20050225082713.12205.qmail@5b4e5a50a4df8e.315fe32.mid.smarden.org>
On Fri, Feb 25, 2005 at 12:09:33AM +0100, C. Fischer wrote:
> * C. Fischer:
> 
> > with this patch on qconfirm-0.14.3 i experience the following, which i
> > cannot corelate to the change:  .qconfirm/pending/ doesn't contain
> > sender-IDs anymore, but qmail-queue IDs, ie. inodes like 461128 etc.
> 
> oh yes, i broke it.  maybe qconfirm-check's `mode' could be made a bit-field,
> but for the time beeing i settled for `mode2'.  gerrit, a manual mode would
> allow testing qconfirm-check more thoroughly than just checking its usage
> string, because it won't send any emails.  wouldn't that be a nice feature?

I don't think the 'manual' feature should be a different mode, but
simply an option.  You may want to use it for the message mode and
sender mode.  qconfirm-check already has an option for suppressing
delivery acknowledgements (see the ack variable), I suggest to do it
similar for delivery confirmation requests, e.g.

diff -u -r1.55 qconfirm-check.c
--- src/qconfirm-check.c        12 Dec 2004 16:52:22 -0000      1.55
+++ src/qconfirm-check.c        25 Feb 2005 08:22:46 -0000
@@ -79,6 +79,7 @@
 unsigned long timeout =TIMEOUT;
 unsigned long size =SIZE;
 int ack =1;
+int request =1;
 int wildhost =1;
 int badmailfrom =0;
 struct stat msg_st;
@@ -676,6 +677,7 @@
   }
   if (seek_begin(0) == -1) fatal("unable to seek: ", "stdin");
 
+  if (request) {
   /* inject confirmation request */
   if ((fdmsg =open_read(msg.s)) == -1) {
     if (unlink(fn_confirm.s) == -1) warn_unlink(fn_confirm.s);
@@ -686,6 +688,7 @@
     if (unlink(fn_confirm.s) == -1) warn_unlink(fn_confirm.s);
     if (unlink(fn_pending.s) == -1) warn_unlink(fn_pending.s);
     fatal("unable to inject: ", "confirmation request");
+  }
   }
 
   strerr_die3x(111, INFO, "Waiting for confirmation: ", fn_pending.s);

HTH, Gerrit.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.