That is the wrong way to run a mail server. I know how common it is at big providers, but it's still wrong.
You should REJECT a message if you won't deliver it. If it was a legit message inappropriately REJECTed, then the server that's relaying it can generate a bounce back to the sender, and something can be figured out.
Dropping a message on the floor like that, after you have promised to deliver it is almost always the Wrong Way.
I imagine the reason that it's done is because rejecting it gives spammers more information that could possibly be used to get around the rejection. It's much harder if they aren't sure whether or not the message was received.
Whether or not that's appropriate is another thing, but that is probably the rationale behind it.
More likely the rationale is that it's easier to filter stuff asynchronously after it is sitting in queue, and there's no longer a TCP connection hanging off it, waiting for a response. In other words, it's cheaper.
You should REJECT a message if you won't deliver it. If it was a legit message inappropriately REJECTed, then the server that's relaying it can generate a bounce back to the sender, and something can be figured out.
Dropping a message on the floor like that, after you have promised to deliver it is almost always the Wrong Way.