On 5/5/2016 8:45 AM, Jorge wrote:
> Hi,
>
> can anyone of you give me some advise about which of the ACL verbs are the
> most convenient to prevents spamming to my server?
>
> I think this:
>
> DENY, if I use DENY, my server notifies to spammer that the recipients
> address is not exists and the spammer may be to send more and more mails to
> attack me.
>
> DISCARD, if I use DISCARD, my server do not response anything to the spammer
> and he/she thinks that the mail arrives OK and not disturbs more.
>
> DROP, similar of deny.
>
> Which you will use?
>
> Thanks in advance.
>
> Jorge Colaccini
>
>
Hello Jorge,
The purpose of spam rejection, I assume, is to avoid delivery of spam to
recipients. If you prevent delivery, it totally does not matter which
verb you use to prevent delivery.
Now, let us consider the sender, and let us consider how spammers work.
Spam is sent by robots. Please believe me when I tell you: Spammers DO
NOT read response codes, nor do they read any accompanying messages.
Also, spammers do not clean their lists. The robots will keep using the
dirty lists and attempting to send spam to the same nonexistent email
addresses. Forever.
Therefore, I recommend that you should NOT base your decision as to
which verb to use on how spammers will or will not react.
Instead, consider that a sending host that may have been identified as a
spammer, may actually be a badly configured host that is attempting to
deliver a valuable message that may be of great importance to you. Or,
perhaps the person who wrote the message may have used wording that
appears to be spam, for whatever reason. Therefore, base your acls on
the assumption that what your server thought was spam was actually not
spam, but that a legitimate source simply has made a mistake. My own
server has been misidentified (by only a few receiving hosts, but it
only takes a few to wreak havoce) as a spammer.
Legitimate sources DO read the responses and take action to insure their
message is delivered. Therefore, using that framework as your guide: I
strongly recommend that you use DENY with a message that clearly
indicates why delivery of that message was denied. The purpose of DENY
is not to say "gotcha" to spammers. The purpose is to explain to a
LEGITIMATE host with REAL email why the email was rejected. Therefore,
you should always make it as easy as possible for a legitimate (assumed)
sender to understand why their email was rejected.
Still assuming that you may actually be rejecting important email,
consider that DISCARD will misinform the legitimate sender that the
intended recipient (perhaps you, yourself) has been notified. But the
intended recipient HAS NOT been notified. Simply because of a
misconfigured server?
DROP is somewhat better than DISCARD because it at least tells the
sender that the message was not delivered. However, it offers no
information as to why the message was not delivered. Again, you should
always make it as easy as possible for a legitimate (assumed) sender to
understand why their email was rejected.
My configuration has (in part):
# -------------------------
# acl_smtp_mail
acl_check_mail:
# -------------------------
# Reject mail from hosts in spamhaus zen list
#
# This stops about 99% of all spam arriving at my server.
# The message generated by spamhaus explains precisely how
# the sender can be removed from the list
deny message = X-Warning: $sender_host_address is listed at
$dnslist_domain. $dnslist_text
log_message = $sender_host_address is listed at
$dnslist_domain ($dnslist_value: $dnslist_text)
dnslists = +defer_unknown : zen.spamhaus.org
# -------------------------
# acl_smtp_data
acl_check_data:
# -------------------------
# spamassassin scanner
# ==============================
# Because almost all spammers were rejected by apamhaus before DATA
# The result is this data scanner finds very little spam
# If huge message bypass scanning
#----------------------
accept condition = ${if >={$message_size}{100000} {yes}}
add_header = X-Spam-Note: SpamAssassin run bypassed due to message size
# Otherwise invoke spamassassin
# -----------------------
warn spam = nobody/defer_ok
add_header = \
:at_start:X-Spam-Flag: YES
add_header = X-Spam-Score: $spam_score ($spam_bar)
add_header = X-Spam-Report: $spam_report
# if the spam scan timed out, accept but
# add a spam header as a warning to recipient
# -----------------------
accept condition = ${if !def:spam_score_int {yes}}
add_header = X-Spam-Note: SpamAssassin invocation failed due
to timeout
# If SA score is 10 or more, DENY with a message
# -----------------------
deny condition = ${if >{$spam_score_int}{100} {yes}}
message = Our mail system has determined your message to
be SPAM.\n\
Contact webmaster if you feel this is not spam.\n\
===============
The acls shown above result in approximately one (1) spam per week (at
MOST) being accepted by this server, despite many hundreds of attempts.
At the same time, my server has failed to deliver exactly zero (0)
legitimate messages.
If your users believe "spam" is defined as any commercial email, even
from from companies that they do business with, then that is another
matter entirely. Everything in my setup as shown above is directed at
dealing with TRUE SPAM.
Addendum:
I have recently added the IpSet provided by spamhaus to my server's
firewall.
https://www.spamhaus.org/drop/
I use this only with Ipset-maintained sets that are denied using
iptables. The list is a set of IPs that are known to be hijacked.
Therefore it is safe to simply deny connection at hardware level to the
IPs in that set. It has (so far) resulted in only a few connections
(fewer than 10 per day) being denied connection. Therefore, it is likely
of marginal value, but because Ipset is so efficient, using these lists
with Ipset costs very little. (I use both DROP and EDROP lists)
Phil Carroll
