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
> DBmail@dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail
>
--
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
