No, this defeats the purpose of the plugin.  If new protocol support is needed,
it should be written in.

So I must do a fork if I want a real working mailwatch plugin with Thunderbird. :(

Ok, this is ridiculous.  All you've done so far is demand things.  There hasn't
even been a release yet, and Pasi has already said he'd implement Mozilla's
status flags.  And yet all you do is complain.  Give it a rest.

I can describe, why the basic mailwatch plugin will NEVER work with Thunderbird
if Thunderbird doesn't change:

While receiving new mails, Thunderbird adds the messages to the Inbox. If mail
receiving is finished, it runs the spamfilter. So the mailwatch plugin says that
I have new mails if I have just spam. Another problem is that Mozilla doesn't
execute the spamfilter if the plugin is running. I don't know why but it's
simply a fact.

My script does following:

It checks the number of new mail and only if the new mail doesn't increase for a
specified number of time (i.e. if receiving is finished) it reports new mail.
Such a special hack could never make it into the plugin, but the ability to run
it as external program provides me with a working mailwatch solution.

So, I have three possibilities: 

 1. Fork and maintain it my own.
 2. Don't use the mailwatch plugin.
 3. Use Gkrellm, that has the ability.

You even are a bit against the "X-Mozilla-Status" code not in the plugin code.
So what's the purpose of the plugin if it simply don't work with Mozilla which
is a widely spread MUA on the Linux desktop? 

Can you explain why you are against the external script? I'm simply disappointed
-- I hoped for a real working mailwatch plugin. Gktrellm would work but it's not
in the panel.

It's not because of X-Mozilla-Status, even if that would be implemented it
doesn't work because of the way the spamfilter of Mozilla works. 

And I don't simply demand things, I would implement and maintain it. That's a
difference. 

Ok, my formulation was bad, so can we come back to a objectively discussion? I
simply want a working solution with Thunderbird, that's all.

Ok, I hacked a patch for the X-Mozilla-Status thing to see if it works (see
other bugreport).

It works very well now, the spam filter in Thunderbird has no problems with it.
If I increase the check interval, this also solves the problem I described with
reporting new mails while receiving mails.

It cannot be solved really, but that's a problem with Thunderbird and not with
you mailchecker. After thinking a while, I aggree that a external mailchecker is
not a very good idea.

I hope we can forget this discussion, I apologize for being a bit rude. I hope
you accept this!

Perhaps you just aren't using Thunderbird in a common way.  I use it as well,
and I experience none of your problems.  My differences:

I use Thunderbird to watch three IMAP mailboxes.  All of them are filtered by
spamassassin on the server side, and (also on the server) spam messages are
automatically moved into two separate folders (almost-certainly-spam and
probably-spam).  Now, spamassassin isn't perfect; I usually end up with 15-20
spam messages that make it through, some of which Thunderbird correctly flags as
spam, some which it misses.  I have Thunderbird automatically move messages it
flags as spam into my Junk folder.  I periodically go through Junk to make sure
it doesn't pick up any false positives, and every Sunday night a cron job runs
on the mail server which puts my Junk folder through spamassassin's bayes
autolearn facility, and then dumps the mailbox.  The almost-certainly-spam and
probably-spam folders I usually end up going through manually every few weeks.

Now, from what I'm gathering here, you use fetchmail to fill your local mail
spool, and then Thunderbird to catch and filter your spam.  Are you using
movemail (or something similar) to move messages from your mail spool into
Thunderbird's inbox?  If not, this isn't the proper configuration.  I've seen
problems with locking when trying to do similar things.  I suspect this is why
Thunderbird won't run its spam filter it the plugin is checking mail - and this
is correct behaviour: your setup is unsafe with regard to file locking and
avoiding corrupted files due to multiple access.  The only apps that should be
accessing a mail spool file are the MTA and MUAs that understand how to do so
properly (like mutt and pine) - *not* Thunderbird.

The bottom line is that what you want/need is basically a hack, and I'm not a
fan of hacks unless they serve a large majority of users - and even then I'd
rather look very hard for a better way.  If you want to maintain a special
version of the mbox protocol file, that's fine, but I don't want weird stuff
like this in the plugin itself.

I don't use movemail or fetchmail, I just have multiple POP3 accounts and one
IMAP account. With the patch supplied by me it basically works. 

The only problem is that spamfiltering takes place after receiving all mail, so
the mailchecker may report spam which is moved away after that. But: This is ok
and my script wasn't perfect in the past.

So, from my view things are perfect now and I really hope that we can forget
this issue and you accept my apology!

Small question: Does the mail check plugin lock the file? Because my mail files
are on NFS, this may be an issue.

We're talking about the mbox file here? No, the file is not locked by the
plugin. I'm not sure how nfs copes with it, but I didn't think it's necessary as
we're only reading the file.

Ok. NFS is a bit problematic when locking, but I also think that read-only
access needs no file locking.