Beauregard T. Shagnasty wrote:
> Heidi wrote:
>
>> Should I change it to just :fail: ?
>
> How about: :blackhole:
>
> This way you don't send an email back to the victim's forged address
> the spammer used, like you do with ":fail: No Such User Here"
huh?
There are sound technical reasons that you should only use :fail: and not
:blackhole: on a cPanel server running exim. We have conducted quite
extensive testing to establish this configuration is best and outline the
reasons here.
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
>> Stay informed about: Dictionary Attack Help?