I don't think the engine would be that easy. If TB marked as spam any mail that has urls to a different domain, then it would mark as spam emails from my friends that have links to other pages (since the email domain and the link are in different domains). I'm not sure about the fixed IP idea. In fact, TB gets just some of the messages as scam, and they all have links to other domains. So I guess it has something to do with some site they reference in those mails (I just compared some Insiders considered spam with some that aren't, but I couldn't figure out a particular site that's in all the ones marked and in none of the unmarked).

Ok, there's a confusion here. I meant SCAM (as in phishing), not SPAM (as in junk mail). Through it marked the first Insider I received as Spam, I unmarked it and it never marked it as junk again. But the anti-phishing engine seems to be a separate one. Thanks for the advice, through. :)

Since some weeks ago, Thunderbird has been marking the CodeProject Insider as scam! So, I know it's not, but I was wondering which part of the Insider could be the one triggering the rule. :confused:

I see three different outcomes here. 1. The item is found and deleted. Final result: the item is not in the collection. 2. The item is not found in the collection. Final result: the item is not in the collection. 3. There is an error while either looking for the item or trying to delete it. Final result: unknown (unpredictable) Since when the function works fine, the item is finally not in the collection (therefore that's something you already know), it would be useful to use the return value to know something you wouldn't know otherwise, like if the item was there in the first place or not (TRUE if the item was deleted, FALSE if it wasn't there). In case 3, where something went wrong, I think the best choice is to throw an exception, since it's an abnormal case. Besides, it can go wrong in many different ways, and a TRUE/FALSE result wouldn't help much in finding the cause.