some weirdness and broken error handling with sieve (in 2.2.12)

[Greg A. Woods]

So I finally decided to try actually using SIEVE to allow me some
mobility and separation between my INBOX sorting and my client(s).

However my first experiment (the one taken directly from the
install-sieve.html guide) ended in a minor disaster (because I did it
live on my home mail server, not on my test system, sigh) when I didn't
have the correct path configured for sendmail.  (I thought I had
corrected the hard-coded path for my installation, but I obviously
hadn't.)

Here's the log of what happened on the Cyrus side when the message to be
rejected arrived:

Nov 28 20:52:52 most lmtpunix[27427]: executed
Nov 28 20:52:52 most lmtpunix[27427]: accepted connection
Nov 28 20:52:52 most lmtpunix[27427]: lmtp connection preauth'd as postman
Nov 28 20:52:52 most lmtpunix[27428]: FATAL: couldn't exec() sendmail
Nov 28 20:52:52 most lmtpunix[27427]: sieve runtime error for woods id <m1GpEcz-0051gHC at always.weird.com>: Reject: Sendmail process terminated normally, exit status 75 
Nov 28 20:52:52 most lmtpunix[27427]: DBERROR : db4
Nov 28 20:52:52 most lmtpunix[27427]: DBERROR: error fetching <m1GpEcz-0051gHC at always.weird.com>: Invalid argument
Nov 28 20:52:52 most lmtpunix[27427]: duplicate_check: error looking up <m1GpEcz-0051gHC at always.weird.com>/user.woods: cyrusdb error
Nov 28 20:52:52 most lmtpunix[27427]: IOERROR: opening /var/spool/imap/stage./27427-1164765172-0: No such file or directory
Nov 28 20:52:52 most lmtpunix[27427]: IOERROR: error unlinking file /var/spool/imap/stage./27427-1164765172-0: No such file or directory
Nov 28 20:53:52 most master[21410]: process 27427 exited, signaled to death by 11
Nov 28 20:53:52 most master[21410]: service lmtpunix pid 27427 in READY state: terminated abnormally


BTW, I don't have any problem with the duplicate DB normally -- it
usually works just fine:

Nov 29 15:58:53 most lmtpunix[22809]: dupelim: eliminated duplicate message to user.woods id <20061129205722.GA8748 at antioche.eu.org> (delivery)

The DBERROR lines above are the only ones in my log.


From there on the LMTP service was dead.  I had to stop and restart the
master daemon.  Worse yet all the "deliver" processes (I still use a
pipe to "deliver" to store incoming mail) would just hang indefinitely
(or at least for about an hour until I had the good sense to restart
Cyrus from scratch).

I tried to do a wee bit of debugging, of the latter issue and all I
could see was that the deliver processes were sitting in a read(2) call
on a unix socket that wasn't connected to anything.  Maybe this latter
issue is more a problem with the AF_LOCAL implementation on my server
than anthing else, though I thought there was a timeout alarm to catch
stuck LMTP connections....

I didn't think to try to get any clue of the state of the master daemon
as I didn't realize that it had effectively stopped the LMTP service
without warning.  I tried a SIGHUP first, but that didn't help.

Error handling of such an event is obviously not very robust yet.


I also had some confusion as well as to whether de-activating the script
allowed things to work again or not, though at this time I'm unsure as
to whether I had restared the master daemon first or not.  Maybe I'll
try that again once I've got some other issues sorted out.


BTW, this whole idea of generating new mail from SIEVE is bogus.  The
local mail service should NEVER EVER IN A MILLION YEARS ever generate
new messages in response to incoming mail (think backscatter, unless if
it had the kind of once-per-week protection built into the much older
unix vacation(1)).  The reject should happen within the LMTP transaction
(and in the case of "deliver" it should result in a unique exit code).
I'll be fixing that before I ever let my end users touch SIEVE, or at
least use the "reject" or "redirect" actions, etc.  I'm not even sure I
want to give my users a real "discard" action -- I think I'll rewrite it
to "fileinto Junk" or some such more undo-able action.

-- 
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com>       Secrets of the Weird <woods at weird.com>