Neither. A while ago, some yotz spammed the Forge with two private messages to everyone, with a photoshopped porn image. Clinton erased them all. So the message is merely a leftover from that event and has nothing to do with you actually.

As I understand it, once you click on your message page, the little cookie or whatever will make the notification go away. But if that doesn't happen, contact Vincent and see what he knows or does about that.

I haven't had the leisure to figure out how to fix it. Honestly it's not a high priority for me; if it's a high priority for someone, I encourage that person to take the first step, go through Simple Machine Forum's online documentation yourself, and let me know what you find.

I'm pretty sure that this phenomenon only affects people whoa) were registered before the event andb) did not read the spam before Clinton manually removed it.So it's not a problem for new users, only those who have been away from the Forge for a while and haven't noticed one of these regular question threads about the phenomenon.

The basic technical reason probably has to do with the forum infrastructure keeping tabs on unread messages in a different part of the database from where the messages themselves are stored. (Couldn't imagine a different way of doing it, anyway.) Clinton, again, would have destroyed the spam by manually checking the private message data table and removing all messages that the given registered user sent within the target timeframe. This would not affect the count of unread messages kept in a different table, which would then cause the phenomenon.

That is all pertinent mainly because I'm pretty sure that the only way to fix the problem would be to manually fix the user data tables that include the miscounted number of unread messages. I'm not personally familiar with particular SMF architecture, but it's quite likely that the number of unread messages is stored as a simple integer in a particular data field in the user data table, rather than a full hash table structure that'd track the unread status of individual messages. Considering this, the easiest way to remove the problem is to find the correct field in the user data table, verify that it doesn't indeed carry any other information, and then zero it for all users. A side-effect would be that everybody would then show zero unread messages whether they actually have new messages or not, but that wouldn't be a problem going forward, as the new message count would then match the actual messages in the person's mail box later on.

The one question mark in this purely theoretical plan is that I don't quite see why checking your new messages does not actually zero the counter for new messages, as it should if the number of new messages stored was actually just an independent number incremented when new messages arrive and zeroed when they are read; apparently some piece of code is actually checking the read-status of each message in the mailbox independently, and as it's not seeing the deleted messages, it's not decreasing the new message counter either. Perhaps this functionality is in place to handle several pages of new messages, in which case a user might not "see" all messages at once when they go to their mailbox. Other than that the SMF system loads and shows all new messages at once, so I don't see any other reason. Anyway, that kind of system would still be likely to be implemented with a specific counter field, so the only thing that really matters is finding that counter and zeroing it.

Of course not a matter of practical importance for me, either. Probably falls in the category of things that go away with the next forum update, whenever that will be.