The short answer is that you cannot "block" an "id".
The reasons for this are that it's trivial to change your computer's id (just place a new computer and start spamming from that), and it's also trivial to spoof the id of someone else's computer (should you decide to make a "white list"). That, and your server will always receive all messages addressed to it anyway - best you can hope for is to manually check and discard unwanted messages.
That leaves the idea of implementing a form of flood control, and maybe even slap some encryption on top of that.
On the other hand: Your real problems here are the sleep statements (as while idling, the program discards any messages received due to the way sleeping makes use of the
event queue (which the rednet API relies on)). Even
with a decent flood control setup, if two different systems innocently message the server at once only one will be heeded.
You may consider using the
parallel API in a fashion similar to
this. The idea is that you can define two functions and run them more or less side by side - each gets its
own copy of the event queue, so one function can dump received messages in a table, the other function can process those as it sees them (while sleeping if it wants to), and no messages will be missed.
