Nothing magic about it; it's just modeling.
In the following model, there are three primary entities: rooms (containers for either messages or other rooms), messages, and users. If you don't like the concept of "room," call it a "folder." Same thing.
The relationships are:
rooms-<messages (one to many). One room can contain many messages, but a message can exist in only one room.
users-<messages (one to many). Each message has one and only one author. An author may write many messages.
rooms-<rooms (one to many, recursive). This is how rooms can contain rooms (or folders can contain folders). This is why forums and topics are the same thing; they are just containers with a parent-child relationship. If you want to allow nesting to any arbitrary depth, the model allows for that.
The tricky one:
users>-<rooms (many to many). A user visits many rooms. A room is visited by many users. In every case we need to track a "high-water mark" -- in other words, a bookmark pointing to the last-read message. This lets us not only compute the number of unread messages, it lets us hide the old messages, a concept invented in the 1970s but sadly missing from many "modern" message boards.
To turn this into a physical model, start with one table for each entity. Rooms, users, messages. Three tables.
Then consider relationships.
One-to-many relationships are simple: a key in one table points to a record in another table. No additional tables are necessary.
Many-to-many relationships require another (relational) table.
So now we have four tables. See here:
http://stonemountain.yi.org/prattle/prattle.sql.txt
This is a model of a "linear" message board. If you like threading, it's fairly simple: add a one-to-many (parent-child) relation, message to messages. That requires an additional column in the message table, not an additional table.
If you need to "ban" IP's, that's a separate entity to track, so it deserves a separate table. I do agree with Kirk that it's not a good way of handling the problem.
I used to run a system with about 40,000 registered users. Once or twice we blocked a nuisance IP at the router or httpd level. Registration and email verification takes care of nearly all of the village idiots.