Messages from this subsystems are directly inserted, bypassing all other checks. I'd have to do a little bit of reading on constructing a new message with GMime, but it should be pretty easy to do.
On Mon, Jun 25, 2007, Jesse Norell <[EMAIL PROTECTED]> said: > 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 > -- _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
