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 vacation. > 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=<[EMAIL PROTECTED]>, 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[42008]: connect from > localhost[127.0.0.1] Dec 17 17:06:05 courier postfix/qmgr[40332]: > 9B34E55DB1: from=<[EMAIL PROTECTED]>, 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[127.0.0.1] Dec 17 17:06:06 courier > postfix/cleanup[41269]: E13495649F: > message-id=<[EMAIL PROTECTED]> > > 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: courier.clickcom.com: cyrus set sender to <> > using -f Dec 17 17:06:06 courier sendmail[42062]: gBHM66vs042062: > from=<>, size=2746, class=0, nrcpts=1, > msgid=<[EMAIL PROTECTED]>, > relay=cyrus@localhost Dec 17 17:06:06 courier sendmail[42062]: > 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[42008]: > 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[40332]: E13495649F: from=<>, > size=6349, nrcpt=1 (queue active) Dec 17 17:06:06 courier > postfix/smtp[41916]: E13495649F: to=<[EMAIL PROTECTED]>, > relay=courier.clickcom.com[209.198.22.7], delay=1, status=sent (250 Ok: > queued as 43E3755C10) > > So I guess this might have been a bounce message that is misdirected to > [EMAIL PROTECTED] instead of [EMAIL PROTECTED]? > > A very confused, > John Straiton > [EMAIL PROTECTED] > 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-- http://www.oceana.com/~ken/ksm.pgp
