Differences between :fail: and :blackhole:
The terms :fail: and :blackhole: have special meaning in your control panel. This means that they must be typed or copied exactly for them to work correctly. :fail: will reject any message as soon as it reaches the mail server. Because the mail server is configured to read :fail: as a fail attempt, the e-mail is rejected and sent back to the user, without ever reading the message. This saves cpu consumption on the server, because the message is never read or parsed. Further, because the message is properly rejected, we are better able to detect the rejected recipient message and block potential spammer IPs. Using :blackhole:, the message is accepted for delivery. However, instead of being delivered to a mailbox, the message is sent to a blackhole. However, the mail server reads this as accepting the message and the message is fully read and parsed, using cpu cycles, and then thrown away. If you want to disable your default box, please use :fail:

If you have several e-mail addresses you receive legitimate e-mail for and have been using the default box to catch these messages, it may be better if you instead setup forwarders to do this work for you. By using a forwarder you can single out specific e-mail addresses you want to receive e-mail at, and only those messages will be sent to you. If you currently have your default box set to forward to an e-mail address, you would simply setup forwarders for specific e-mail addresses and forward e-mail from those addresses to your real e-mail address, the one you have set for your default box. If you don't have your default address set to forward to an e-mail addresses, you will need to create a POP account and forward those e-mail addresses to that POP account. I will detail both ways below.

Why is forwarding your default address to an off-site e-mail address a bad idea
Forwarding your unroutable mail to an off-site e-mail address is generally a bad idea because of the sheer volume of e-mail this address will produce. This means that everytime an unroutable address receives a message at your domain, an SMTP connection must be opened with the remote mail server. Any time you have to open a TCP/IP connection causes several cpu cycles to negotiate the connection and send the data. This becomes increasingly cumbersome when the messages you are sending are likely spam and are not very relevant. Further, some remote mail servers will view these spam messages as spam originating from our server and may be forced to blacklist our server. It is difficult, if not impossible, for a 3rd party mail server to realize that the message did not originate from our server. Because the message was sent from our server, it does look like the spam message was sent from our server, when really it did not originate at our server. You should also be extremely careful when marking messages as spam messages if you are using a 3rd party e-mail service and forwarding your mail from your domain name to this service. Reporting those spam messages may lead to our server being blacklisted and your forwarders will no longer forward.