Sieve logging - Vacations failing

Ken Murchison ken at
Thu Dec 19 11:20:43 EST 2002

John Straiton wrote:
> I wrote last week about a problem I've been having with the "reply" and
> "vacation" type sieve filters, but found that I was incorrect in my
> assesment of what might be wrong.
> I think my problem is that my sendmail isn't liking what cyrus is
> sending to it for the replies. What I'm looking for is to find out how I
> can peer into what sieve is doing (logging?) and also where it gets the
> command line from that it chooses to use to reply to people via sieve so
> I can start debugging from there.

The response is done with lmtpd.c:send_response().  The command line is:

sendmail -i -f <> -- rcpt

I'm not a Postfix expert, but IIRC Postfix doesn't like the empty
Return-Path being specified by '-f <>'

You could try it without this option.  If this doesn't fix it, then I'd
start by testing a redirect action, since it is much less complex than

> The only thing I found in regards to this so far was a message from over
> a year ago saying that you have to patch the cyrus code in order for
> this to happen...I could do this on a spare machine but I thought I'd
> ask before I goto the trouble of building a machine, getting FreeBSD
> installed and then installing all these packages.
> John
> Should it help, here's what I *think* I know at this point.
> I am using Cyrus 2.1.11 with Postfix on FreeBSD, both compiled from
> ports basically. All sieve scripts work just fine for moving messages to
> imap folders and for discarding, but I'm trying to get vacation messages
> to work. This problem is identical on another machine I built using the
> same manifest.
> If I set up a rule for instance, to reply to all messages with a
> vacation notification, then the next rule down is to move the mail to a
> subfolder, then the message will get moved to a subfolder but the sender
> of original message won't ever see a thing.
> Here are what I think are the relavent lines from my imapd.conf # Note
> that duplicate delivery suppression is required for Sieve.
> duplicatesuppression: yes
> sieveusehomedir: false
> sievedir: /var/imap/sieve
> sendmail: /usr/sbin/sendmail
> And of course:
> > which sendmail
> /usr/sbin/sendmail
> Which of course is actually the Postfix to Sendmail compatibility
> interface
> Here's what I see in my /var/log/maillog with my notes
> Dec 17 17:06:05 courier postfix/smtp[42054]: 2778E5649F:
> to=<accessho2 at>, relay=[], delay=0,
> status=sent (250 Ok, id=39631-07, from MTA: Ok: queued as 9B34E55DB1)
> Ok, we got it..
> Dec 17 17:06:05 courier postfix/smtpd[42008]: connect from
> localhost[] Dec 17 17:06:05 courier postfix/qmgr[40332]:
> 9B34E55DB1: from=<jsmailing at>, size=1539, nrcpt=1 (queue
> active)
> Ok, we virus scanned it via amavisd and reinjected it..Now here's where
> I'm getting lost...
> Dec 17 17:06:05 courier postfix/smtpd[42008]: E13495649F:
> client=localhost[] Dec 17 17:06:06 courier
> postfix/cleanup[41269]: E13495649F:
> message-id=<cmu-sieve-40582-1040162755-0 at>
> Looks promising..I'd imagine the message-id means sieve did try to
> reply... (courier and mx1 = same machine)
> Dec 17 17:06:06 courier sendmail[42062]: gBHM66vs042062:
> Authentication-Warning: cyrus set sender to <>
> using -f Dec 17 17:06:06 courier sendmail[42062]: gBHM66vs042062:
> from=<>, size=2746, class=0, nrcpts=1,
> msgid=<cmu-sieve-40582-1040162766-1 at>,
> relay=cyrus at localhost Dec 17 17:06:06 courier sendmail[42062]:
> gBHM66vs042062: to=cyrus, delay=00:00:00, xdelay=00:00:00, mailer=relay,
> pri=30382, [], dsn=2.0.0, stat=Sent
> (Ok: queued as 62C4556E14) Dec 17 17:06:06 courier postfix/smtpd[42008]:
> disconnect from localhost[]
> I guess my sendmail didn't like the command line issued to it, but this
> message ID doesn't match anyway. However the timestamps are AWFUL close
> together....perhaps the reply has a new ID?
> Dec 17 17:06:06 courier postfix/qmgr[40332]: E13495649F: from=<>,
> size=6349, nrcpt=1 (queue active) Dec 17 17:06:06 courier
> postfix/smtp[41916]: E13495649F: to=<cyrus at>,
>[], delay=1, status=sent (250 Ok:
> queued as 43E3755C10)
> So I guess this might have been a bounce message that is misdirected to
> cyrus at instead of postmaster at
> A very confused,
> John Straiton
> jks at
> Clickcom, Inc
> 704-365-9970x101

Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--

More information about the Info-cyrus mailing list