Should NEW Untouched SeaMonkey Bugs Be UNCONFIRMED?

I posted an idea in a triage-related newsgroup post a month ago and lacking any reaction, I brought it up in the recent SeaMonkey Status Meeting, where it was decided to get feedback on it before deciding on it, so please tell me what you think about this:

SeaMonkey inherited a large legacy of of bugs from the Mozilla suite, most of which have an unconfirmed value nowadays, four years after founding the new project. The Bugzilla database reflects those as current bugs though, often bringing them up in queries as if they were current, even though we can't confirm nowadays that they still apply to our current development code or even releases.

We have almost 2800 bugs that haven't seen a comment since the project was started but are still in the NEW state, see the bug query if you don't believe it.

Ideally, we'd go and actively triage every single one of those bugs manually to try to find out if they are still valuable. If that takes only 5 minutes in average per bug, that's 29 8-hour workdays or almost 6 full work weeks for one person, and even if we would have someone with a capacity of so much time to work on SeaMonkey alone, I think we'd have higher priority stuff to spend the time on than finding out if bugs that weren't touch for more than 4 years still have any value.

When I thought about this and about how just mass-resolving bugs without warning is quite rude (we already had such incidents), I realized that we already have an identifier in Bugzilla that tells that "this bug is not confirmed to be valid" that also doesn't mean the bug is resolved for good in any way: UNCONFIRMED.
(That even includes enhancement requests for which we can't tell if they still apply to current code or project plans, by the way.)

So, what I'm proposing is that we mass-move those bugs in the SeaMonkey component that had no comment since 2005-03-10 and are still NEW to the UNCONFIRMED state.

This leaves them open but shows everyone that we are unsure that they are still valid within the SeaMonkey project nowadays without just kicking them off into nowhere land. Everyone who get bugmail about this and considers his pet bug in there to be still valid, can comment on that and/or move the bug back to NEW, which is easy - but instead of making one person go though a pile of rotten stuff to find the good stuff, we push the work to more people and to those who actually care about the specific bugs.

In a few months, when that has likely been sorted out and SeaMonkey 2.0 is out the door as a stable release, we can think about what to do with those bugs that still remain UNCONFIRMED - we might leave them as such or ultimately mass-resolve parts or all of them, but we have months before even thinking about this. For now, the proposal is just to make the state reflect reality and make them UNCONFIRMED.

What do you think about this idea to clean up our bug queries to find relevant stuff more easily?