Part of the issue here is that you are simply allowing any email to your domain to work vs letting them :fail:
in cPanel NEVER SET A DEFAULT ADDRESS TO FORWARD ALL MAIL - but rather set it as
:fail: no Such User Here Now Go Away and Spam someone else
Why you should use :fail:
There are sound technical reasons that you should only use :fail: and not :blackhole: on a cPanel server running exim.
In general the two different settings both discard email not destined for a POP3 account, an alias or a catchall alias. However, ever since cPanel included the verify = recipient code in the standard cPanel ACL section for exim, the way email is discarded differs with the two methods quite starkly:
Using :blackhole:
email is accepted and received into
the server in its entirety. It is then
processed through exim and only on
delivery is it written to the null
device (/dev/null) and silently
ignored. This wastes server bandwidth
as the email data, or body, of the
email is accepted into the server.
This wastes server resources (CPU,
memory and disk I/O) as the email is
fully processed by exim before being
finally written to /dev/null Because
the blackholed email is still
processed through the whole of exim
before it is finally deleted, if any
of the usual checks and routing that
any email goes through fails, such
email can be placed in the exim mail
queue for later reprocessing. This can
lead to tens of thousands of
blackholed emails accumulating in the
exim mail queue which in turn can
cause a range of serious server
performance and resource problems and
will affect the normal and timely
delivery of email
This actually breaks the SMTP RFC's
because you're not notifying the
sending SMTP server that the email is
undelivered, which is a requirement
Causes emails that will never be
delivered onto the exim mail queue
because checks such as sender
verification are still carried out
when processing such emails and if
they cannot complete they will stay on
the exim mail queue and repeatedly
reprocess the email until it is
finally discarded (usually 4+ days).
This can cause very large mail queues
full of spam which is repeatedly
processed causing severe performance
degradation
Using :fail: the email is never accepted into the server. During the initial SMTP negotiation when the senders SMTP server connects to your SMTP server, the sending SMTP server issues a RCPT command notifying your server which email address the email to follow is intended for. Your server then checks whether the recipient email actually exists on your server (a POP3 account, an alias or a catchall alias) and if it does not, it issues an SMTP DENY which terminates the attempt to deliver the email.
- This saves bandwidth as the email
data is never received into your
server
- This saves server resources as the
email never has to be processed
- This complies with the SMTP RFC's
because the sending SMTP server
receives the DENY command
- Your server does not send a bounce
message (just the DENY command)
- Your server does not send anything to
the sender of the email (i.e. the
address in the From: line)
- The sending SMTP server is
responsible for notifying the
original sender
Here is a simple explanation of what happens during the SMTP conversation
- Some other SMTP server connects to
your server on port 25 and initiates
an SMTP connection (EHLO command)
- Other server then sends a message
saying who they're delivering a
message for (MAIL FROM command)
- Other server then sends who the
message is for on your server (RCPT
command)
- At this point your server then
checks whether the email address in
the RCPT command can actually be
delivered on your server. If you do
not have a catchall alias configured
to point to an email address
(Default Address) and you have it
set to :fail: the following happens:
- Your server sends back along the
same connection to the sending
server "Go away, no-one here" (the
DENY command)
- The sender server would then
normally tell their user that the
attempt to email your server failed.
Your server does not send a "bounce"
message.
Using :fail: is wise - because As far as your server is concerned, all that has happened is a little SMTP chatter and no email has been received and no bounce sent
special thanks to Chirpy on the cpanel forums for an excellent write up and his work with configserver to help with this post.