Sieve logging - Vacations failing
ken at oceana.com
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.
> 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
> Which of course is actually the Postfix to Sendmail compatibility
> Here's what I see in my /var/log/maillog with my notes
> Dec 17 17:06:05 courier postfix/smtp: 2778E5649F:
> to=<accessho2 at mx1.clickcom.com>, relay=127.0.0.1[127.0.0.1], 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: connect from
> localhost[127.0.0.1] Dec 17 17:06:05 courier postfix/qmgr:
> 9B34E55DB1: from=<jsmailing at clickcom.com>, size=1539, nrcpt=1 (queue
> 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: E13495649F:
> client=localhost[127.0.0.1] Dec 17 17:06:06 courier
> postfix/cleanup: E13495649F:
> message-id=<cmu-sieve-40582-1040162755-0 at courier.clickcom.com>
> 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: gBHM66vs042062:
> Authentication-Warning: courier.clickcom.com: cyrus set sender to <>
> using -f Dec 17 17:06:06 courier sendmail: gBHM66vs042062:
> from=<>, size=2746, class=0, nrcpts=1,
> msgid=<cmu-sieve-40582-1040162766-1 at courier.clickcom.com>,
> relay=cyrus at localhost Dec 17 17:06:06 courier sendmail:
> gBHM66vs042062: to=cyrus, delay=00:00:00, xdelay=00:00:00, mailer=relay,
> pri=30382, relay=localhost.my.domain. [127.0.0.1], dsn=2.0.0, stat=Sent
> (Ok: queued as 62C4556E14) Dec 17 17:06:06 courier postfix/smtpd:
> disconnect from localhost[127.0.0.1]
> 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: E13495649F: from=<>,
> size=6349, nrcpt=1 (queue active) Dec 17 17:06:06 courier
> postfix/smtp: E13495649F: to=<cyrus at courier.clickcom.com>,
> relay=courier.clickcom.com[18.104.22.168], 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 courier.clickcom.com instead of postmaster at clickcom.com?
> A very confused,
> John Straiton
> jks at clickcom.com
> Clickcom, Inc
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26 Orchard Park, NY 14127
--PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp
More information about the Info-cyrus