On such a sieve error message, would it be reasonably doable to add the original message as an attachement? (And would that just trigger a loop? Ie. do sieve filters apply to headers of mime parts or just the outer message?)
On Mon, 2007-06-25 at 17:09 +0000, Aaron Stone wrote: > On the issue of what to do with an email that cannot be parsed by > libSieve, I'm not sure what the best behavior is. On the one hand, seeing > the email show up in your Inbox might lead you to think that the Sieve > script was broken - so the error message is intended to clarify what > happened. On the other hand, it's annoying and the messages are confusing. > > I like the idea of adding a dbmail.conf option to turn the messages off in > the case of a bum email, and only alert if the script itself is broken > (which can happen, if, say, you wrote a web sieve client that inserts > directly into the dbmail_sievescripts table, bypassing the checks in > ManageSieve and dbmail-sievecmd). > > I also like the idea of adding some vendor extensions, so that we can give > users some mechanisms to configure their DBMail Sieve environment. Top of > the script might have something like: > > require ["vnd.dbmail"]; > vnd_dbmail :foo "bar"; > ... > > This would hamper script portability a little bit, but so long as the > vendor specific stuff is well marked as such, it should be fine. > > Aaron > > On Mon, Jun 25, 2007, Jesse Norell <[EMAIL PROTECTED]> said: > > > 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 > > > -- Jesse Norell Kentec Communications, Inc. [EMAIL PROTECTED] _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
