After a bit more digging around, I found an old libdbmail sitting around in /usr/local/lib ... so I'm wondering if some of the problems I've seen were from that (I'll hope/presume they maybe were).
As to the sieve error, it says "unexpected '.'"; I have one rule that potentially might be related: header :value "ge" :comparator "i;ascii-numeric" "X-Spam-Score" "9" I tested and both ".5" and "20.5" perform as expected there .. perhaps a spam with a bogus header came through? I'll watch for more such messages and try to correlate them. If that's the case (ie. a bogus header came through), is generating an error with INBOX delivery the appropriate behavior? It arguably could be. It also gives spammers a nice way to bypass my above check to discard high-scoring spam. Perhaps a runtime error should be treated as a false (no match) instead, and processing proceed as normal? Or maybe a knob to turn on/off runtime sieve errors? Of course this is just guessing, too, till I can correlate one of those generated sieve errors with the actual message which produced it. Thanks, Jesse On Mon, 2007-06-25 at 09:14 -0600, Jesse Norell wrote: > On Fri, 2007-06-22 at 16:44 +0000, Aaron Stone wrote: > > On Fri, Jun 22, 2007, Jesse Norell <[EMAIL PROTECTED]> said: > > > > > Hello, > > > > > > I apparently just deleted the error email I wanted to ask about, but > > > I'll provide another if I get one soon. Anyways, after making a few > > > changes to my sieve filters yesterday, I've now gotten 3 instances of an > > > error report email showing up in my INBOX from the sieve system. It has > > > a diagnostic message (eg. something like "next atom expecting ':'" or > > > along those lines), but there are no line numbers or context from the > > > email, so I have no idea where I should be looking for the problem. > > > > > > Also, usually when I've made a mistake in a sieve script, > > > dbmail-sievecmd doesn't let me insert it. Even yesterday when I made > > > changes I had to fix a couple things before I could insert it ... and > > > when it let me, I assumed it was syntactically valid. Maybe it is... > > > can there be effectively a "run time" error in a sieve script? Anyways, > > > if better checking could be done at insert time, that'd definitely be a > > > good thing. > > > > Run time errors are possible, and the error notifications are > > unfortunately not particularly helpful except to let you know that > > _something_ happened. > > > > > As to this email itself, I think the header cache stuff isn't done > > > right. I can view message source and see a few headers, but in my email > > > client (evolution, using imap), it showed no sender, subject or date ... > > > which I think probably all comes from the header cache? > > > > Yes. If these are newly received messages, then something is probably > > wrong with your database. If they're old messages, you might just need to > > flush the cache tables and reload them with dbmail-util. I've been > > thinking about adding a flag that does this, rather than a manual flush + > > automated reload. > > I'm sure they're newly received (they have to be, don't they? dbmail > doesn't have any ability to retroactively apply sieve filters to > existing messages, does it?). > > > > This is dbmail 2.2.5, with libsieve 2.2.5. I don't have a copy of my > > > sieve script as it was before I changed it to diff against, but I can > > > provide a copy of the current one and point out the places that changed > > > if desired. It all looks correct, and indeed passes the parser at > > > insert time. I'll also try to turn up debugging for sieve to get some > > > useful logs. > > I got another 4 of these this weekend, so I'll see about digging out > the degbug messages and other info. Again the "From", "Subject" and > "Date" shown in my mail program were empty, though they do exist in the > actual message when I view message source: > > > From: [EMAIL PROTECTED] > Subject: Sieve script run error > To: jesse > Message-Id: <1182608217l.13986l.0l@(none)> > MIME-Version: 1.0 > Content-Type: text/plain; charset=utf-8 > Content-Transfer-Encoding: 7bit > X-DBMail-PhysMessage-ID: 1383963 > X-Evolution-Source: imap://[EMAIL PROTECTED]/ > Date: Mon, 25 Jun 2007 08:25:21 -0600 > > Your Sieve script [standard] failed to run correctly. > Messages will be delivered to your INBOX for now. > The error message is: > syntax error, unexpected '.', expecting ATOM or QUOTE or ':' or '<' > > > The timestamp here is misleading .. every time I view message source > it changes to the current time .. so I don't know exactly when they > actually took place. If I look at some of the headers in the database, > they appear to be there: > > mysql> select * from dbmail_fromfield where physmessage_id = 1383963; > +----------------+--------+----------+-----------------------------+ > | physmessage_id | id | fromname | fromaddr | > +----------------+--------+----------+-----------------------------+ > | 1383963 | 570447 | | [EMAIL PROTECTED] | > +----------------+--------+----------+-----------------------------+ > > > mysql> select * from dbmail_tofield where physmessage_id = 1383963; > +----------------+--------+--------+--------+ > | physmessage_id | id | toname | toaddr | > +----------------+--------+--------+--------+ > | 1383963 | 660173 | | jesse | > +----------------+--------+--------+--------+ > > > mysql> select * from dbmail_datefield where physmessage_id = 1383963; > +----------------+--------+---------------------+ > | physmessage_id | id | datefield | > +----------------+--------+---------------------+ > | 1383963 | 570355 | 1970-01-01 00:00:00 | > +----------------+--------+---------------------+ > > > Note the Date is bogus .. maybe should default to NOW() instead of the > epoch? > > select count(*) from dbmail_datefield where datefield = '1970-01-01 > 00:00:00'; > +----------+ > | count(*) | > +----------+ > | 49 | > +----------+ > > And/Or maybe it's the fault of the part injecting the message, as it > looks to be missing the Date: > > > mysql> select messageblk from dbmail_messageblks where physmessage_id = > 1383963 limit 1; > > From: [EMAIL PROTECTED] > Subject: Sieve script run error > To: jesse > Message-Id: <1182608217l.13986l.0l@(none)> > MIME-Version: 1.0 > Content-Type: text/plain; charset=utf-8 > Content-Transfer-Encoding: 7bit > > > > Isn't dbmail.err supposed to be timestamped now? I remember an update > by Paul that said it was syntactically identical to syslog... some > messages seem to be, but others aren't (eg. "(process:12837): > gmime-CRITICAL **: parse_rfc822_date: assertion `tokens != NULL' > failed"). > > Still working on tracking more debugging info down... I'll go back > and work on my script some more, and see if I can find the error. But > A) can the sieve error message be made more useful (ie. a line number or > a little context info or something)? and B) do the sieve runtime errors > work correctly (wrt header data) for anyone else? This database was > migrated manually, it's possible something isn't exactly right (but did > seem to be working till my last script edits, so I suspect it's ok). > > Thanks, > Jesse > > -- Jesse Norell Kentec Communications, Inc. [EMAIL PROTECTED] _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
