SpamBlocker 4.3.0, BlockCracking, Easy Spam Figther, and new exim.pl

DirectAdmin Support

Administrator
Staff member
Joined
Feb 27, 2003
Messages
8,509
Note, this our DirectAdmin branch off of Jeff's SpamBlocker, coded with a few different defaults.

I've added a KB entry for simple install/updates:
http://help.directadmin.com/item.php?id=576

status: Beta Testing

We've been working hard and we've got some exciting new features for the exim.conf.
Exim.conf: 4.3.3
Exim.pl: 20-beta2
BlockCracking: 1.2
EasySpamFighter: 1.7

We're going to announce them as Alpha, for early production testing.. so you're likely only going to want to try this if you're an advanced User.
Report any issues back to this thread, and avoid support@ emails for now, to avoid duplicate reporting, and because this alpha testing is a lower priority for support.


  • SMTP-time ACL blocking, better error messages for Users who've reached their limits, rather than wrong passwords.
  • Many major exim.conf ACL improvements across the board.
  • No more need to edit the exim.conf to enable things via use of .include_if_exists, throughout.
  • /etc/virtual/blacklist_usernames for 100% email blocking, even at the shell/script level. Zero sends through exim.
  • BlockCracking for vastly better outbound spam detection and blocking. It counts the number of failed recipients to block a User or script, without affecting other Users or other scripts.
  • DA will give much more detailed reports on the offending script, and even parses the /home/user/.php/php-mail.log to tell you which script is the likely offender (ability to automatically chmod to 0, disabled by default)
  • EasySpamFigther for SMTP-time spam scanning/scoring and blocking, including reverse IP lookups, DKIM/SPF checks, and smtp-time SpamAssassin runs based on the actual ~/.spamassasin/user_prefs.

Note that the exim.conf and exim.pl versions are paired. You cannot update one without the other.
The new exim.pl will not work for older exim.conf files.
The new exim.conf will not work with old exim.pl files.

A quick install guide using CustomBuild 2.0 can be found here:
http://help.directadmin.com/item.php?id=576

-----------------------

And after all of that, restart exim.. and hopefully it restarts :)
Code:
/etc/init.d/exim restart

Note, you do not need to install BlockCracking and/or EasySpamFighter, set them to "no" in the above install guide,if you don't want them (SB on it's own still has some useful features)
However, if you want BC or ESF, they do require exim.conf 4.3.x and exim.pl 19.
Use CustomBuild 2.0 to install things for you.

Post any issues to this thread.

Good luck!

John
 
Hi John,

i've installed SB 4.3.0 and im doing some diffs to check if i need to import anything.

Apparently the DKIM checks are now part of it (very nice) when Easy Spam Filter get intalled, but it differ a lit from the one i was using, i paste it here, let me know if are actually the same
Code:
>         warn    add_header      = X-DKIM-Status: $dkim_verify_status [($dkim_cur_signer) - $sender_host_address]
>                 sender_domains  = $sender_address_domain:$dkim_signers
>                 dkim_signers    = $sender_address_domain:$dkim_signers
>                 dkim_status     = invalid
>                 condition       = ${if eq {${lc:$dkim_verify_status}}{invalid}{true}{false}}
>
>         warn    add_header      = X-DKIM-Status: $dkim_verify_status [($dkim_cur_signer) - $sender_host_address]
>                 sender_domains  = $sender_address_domain:$dkim_signers
>                 dkim_signers    = $sender_address_domain:$dkim_signers
>                 dkim_status     = fail
>                 condition       = ${if eq {${lc:$dkim_verify_status}}{fail}{true}{false}}
>
>         warn    add_header      = X-DKIM-Status: $dkim_verify_status [($dkim_cur_signer) - $sender_host_address]
>                 sender_domains  = $sender_address_domain:$dkim_signers
>                 dkim_signers    = $sender_address_domain:$dkim_signers
>                 dkim_status     = none
>                 condition       = ${if eq {${lc:$dkim_verify_status}}{none}{true}{false}}
>
>         warn    add_header      = X-DKIM-Status: $dkim_verify_status [($dkim_cur_signer) - $sender_host_address]
>                 sender_domains  = $sender_address_domain:$dkim_signers
>                 dkim_signers    = $sender_address_domain:$dkim_signers
>                 dkim_status     = pass
>                 condition       = ${if eq {${lc:$dkim_verify_status}}{pass}{true}{false}}
>         accept

I've notice that all EDIT#9 is missing:
Code:
> #EDIT#9:
> message_size_limit = 25M
> smtp_receive_timeout = 5m
> smtp_accept_max = 100
> message_body_visible = 3000
> print_topbitchars = true
> smtp_accept_max_nonmail = 10
> smtp_accept_max_per_host = 10
> recipients_max = 150
> smtp_accept_queue_per_connection = 10

Is that ok and normal? Since the new exim.conf have not EDIT#9 there is a logical hole (not big issue at all) on numbering sections.

Another thing i do use on my server and would maybe be useful to see is the Greylist possibility:
Code:
#COMMENT#43:
# ACCEPT EMAIL BEGINNING HERE
  # Perform greylisting.
  # EDIT: Uncomment the section below if you've installed greylistd on your
  # server. Note that this section should NOT be uncommented unless
  # greylistd is installed on your server.

  defer message         = $sender_host_address is greylisted. Please try again later.
         log_message    = greylisted.
         domains        = +relay_domains : +local_domains
         !senders       = : postmaster@*
         !hosts         = : +relay_hosts : \
                           ${if exists {/etc/virtual/whitelist-hosts}\
                           {/etc/virtual/whitelist-hosts}{}}

         verify         = recipient/callout=5s,use_sender,defer_ok
         condition      = ${readsocket{/var/run/greylistd/socket}\
                           {--grey $sender_host_address $sender_address $local_part@$domain}{5s}{}{false}}

#         set acl_m4     = ${mask:$sender_host_address/24}
#         set acl_m5     = ${sg{$acl_m4}{/24}{}}
#         set acl_m6     = $acl_m5 $sender_address $local_part@$domain
#         set acl_m6     = ${readsocket{/var/run/greylistd/socket}{$acl_m6}{5s}{}{false}}
#         condition      = ${if eq {$acl_m6}{grey}{true}{false}}

  # accept if address is in a local domain as long as recipient can be verified
  accept  domains = +local_domains
          endpass
          message = "Unknown User"
          verify = recipient

Would be nice to have it integrated also for who doesnt use greylist at all.

If greylist is running on the server, than this additional check get complted, otherwise, if greylist is not started or present in the system it get skipped and mail come normally.

Would be possible to add? Or may be considered the add of greylist in a standard installation?

I'll post here any other information i can reach with this new setup, those was just first impressions on differences

Best regards
 
1) The previous DKIM you've pasted merely adds headers, letting you check them if you want. It doesn't act on them, so the failed DKIM message would continue to pile in.
DKIM headers only verify an email is from the correct place. Lack of DKIM headers don't tell us anything, as they could still be from the correct place, so we don't penalize for that.

The ESF DKIM implementation actually blocks emails if they fail, defers them if it's not sure (usually if there is an error with the DKIM setup for the domain).
(although, I doubt any spammer would add any signatures, ever, unless they're sending from the correct box)
But if the DKIM works and passes, the spam score is lowered accordingly.
It will still add the headers so you can check after it's arrived.


2) Moved to /etc/exim.variables.conf so we can eventually add them into DA to manage through the GUI.
This also allows you to update to a new exim.conf, and not actually change your selected settings. Fun, eh?
Will also keep all of the bonus bits you've added, like BC/ESF/SA/DKIM, without any changes to the exim.conf when it's updated.
Clean, easy, and can (eventually) be updated via CB2.

3) Can consider grey-listing for future versions.
After implementing these features, our ACL understanding has gone through the roof, so those types of features should be easier to add :)

Thanks!

John
 
Hi John,

thanks for those infos :)

I've just noticed something that may be a missconfiguration but i'm not totally sure

I'd just received an e-mail from CentOS Mirror Mailing List that is DKIM signed but i dont have the DKIM Status header line.

Does the new DKIM implementation actually also add an header line? I suppose yes since of this " add_header = DKIMCheck: Server passes DKIM test, EASY_DKIM_PASS Spam score"

But:
Code:
Return-path: <[email protected]>
Envelope-to: [email protected]
Delivery-date: Thu, 09 Oct 2014 11:41:25 +0200
Received: from mail by Orange01.CrazyNetwork.it with spam-scanned (Exim 4.84)
	(envelope-from <[email protected]>)
	id 1XcADo-0006i9-1D
	for [email protected]; Thu, 09 Oct 2014 11:41:25 +0200
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	Orange01.CrazyNetwork.it
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	HTML_MESSAGE,T_RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no
	version=3.4.0
Received: from mail.centos.org ([72.26.200.203])
	by Orange01.CrazyNetwork.it with esmtp (Exim 4.84)
	(envelope-from <[email protected]>)
	id 1XcADh-0006hT-PW
	for [email protected]; Thu, 09 Oct 2014 11:41:19 +0200
Received: from mail.centos.org (localhost [127.0.0.1])
	by mail.centos.org (Postfix) with ESMTP id 6185DA00A73;
	Thu,  9 Oct 2014 09:40:47 +0000 (UTC)
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com
	[209.85.192.48])
	by mail.centos.org (Postfix) with ESMTP id 43B3BA00049
	for <[email protected]>; Thu,  9 Oct 2014 09:40:44 +0000 (UTC)
Received: by mail-qg0-f48.google.com with SMTP id i50so1163869qgf.35
	for <[email protected]>; Thu, 09 Oct 2014 02:40:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type;
	bh=+AI+xaTa4wFqlv3K5fM5ROnFrE/Sc8Wg3NSB8gY2Whg=;
	b=F6gc7EKqe60ujqUcbEK3ApATbDsb4828L7iZ54xm9MDoxUGYZ8f57Rcr4RNdOtwSV9
	AW8u0ZuNIkdLBdEKj/c8MlNGAoqC5jcgHmbFESGun88FS1/eXxhgFYVlMJMF0Xu3290J
	zQmXa5G816EolnMEzr8WtDrkf0gpndPEtBbFZDS4SRinU9UeRQhmDR3r81yve+bG28HW
	6qCeVQTLAnJUcUCQyNlD+ntDveeWml2bqD9M0jWkd+X1rxIUi8RNdEW4O1mgdhNa7JtC
	Qf12/emhZsE8uoRNW1IpE6vrs11sQslgzxV9yoUTmNVZIKDXzqSkHUX7OtKWRtq9blsC
	NnaQ==
X-Gm-Message-State: ALoCoQnFYT5NABWFBGRfZlWBs45SQqGrBFTkhL2FLbDCY/7e3qAHiWzKxX9W24oiFu5q2ocZpu/6
MIME-Version: 1.0
X-Received: by 10.140.88.208 with SMTP id t74mr43615850qgd.29.1412847645203;
	Thu, 09 Oct 2014 02:40:45 -0700 (PDT)
Received: by 10.140.96.130 with HTTP; Thu, 9 Oct 2014 02:40:44 -0700 (PDT)
Received: by 10.140.96.130 with HTTP; Thu, 9 Oct 2014 02:40:44 -0700 (PDT)
In-Reply-To: <[email protected]>
References: <CAFp=DbMeyZ6X4BxmxpMndPTVMh50Dm2K4qOMygE1xP6+NXQTMw@mail.gmail.com>
	<[email protected]> <[email protected]>
Date: Thu, 9 Oct 2014 17:40:44 +0800
Message-ID: <CAFp=DbPeJw+V1QcgFGyzMpod_0qMLv6jTPcexjgqQXPX2rRwfQ@mail.gmail.com>
From: Mohd Zaimiruddin Mohamed <[email protected]>
To: "Mailing list for CentOS mirrors." <[email protected]>
Subject: Re: [CentOS-mirror] Mirror Status
X-BeenThere: [email protected]
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: "Mailing list for CentOS mirrors." <[email protected]>
List-Id: "Mailing list for CentOS mirrors." <centos-mirror.centos.org>
List-Unsubscribe: <http://lists.centos.org/mailman/options/centos-mirror>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lists.centos.org/pipermail/centos-mirror/>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.centos.org/mailman/listinfo/centos-mirror>,
	<mailto:[email protected]?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2348937745646633376=="
Sender: [email protected]
Errors-To: [email protected]
SpamTally: Final spam score: 0

As far as i can see here, there is a DKIM signature, but there is no the header line which confirm the DKIM pass, am i right? Am i missing something or somehow exim didnt "notice" that was signed?

Regards
 
Maybe i've found another bug, here an e-mail with domain impersonating which is arriving to my address

Code:
Return-path: <[email protected]>
Envelope-to: [email protected]
Delivery-date: Thu, 09 Oct 2014 12:03:25 +0200
Received: from mail by Orange01.CrazyNetwork.it with spam-scanned (Exim 4.84)
	(envelope-from <[email protected]>)
	id 1XcAZ6-0003Zo-35
	for [email protected]; Thu, 09 Oct 2014 12:03:25 +0200
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	Orange01.CrazyNetwork.it
X-Spam-Level: **
X-Spam-Status: No, score=2.5 required=5.0 tests=DATE_IN_FUTURE_06_12,
	DKIM_ADSP_ALL,DOS_OUTLOOK_TO_MX autolearn=no autolearn_force=no version=3.4.0
Received: from [58.225.173.5]
	by Orange01.CrazyNetwork.it with esmtp (Exim 4.84)
	(envelope-from <[email protected]>)
	id 1XcAZ0-0003Pl-2e
	for [email protected]; Thu, 09 Oct 2014 12:03:20 +0200
From: <[email protected]>
To: <[email protected]>
Subject: Gregario
Date: 10 Oct 2014 02:56:37 +0800
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acsvlc7ttru0g33lsvlc7ttru0v2wa==
X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17514
ReverseDNS: No reverse DNS for mailserver, +30 Spam score
BlacklistCheck: Blacklisted address, +50 Spam score
SpamTally: Final spam score: 80

It didnt become SPAM, no subject chane and no drop, and it is in an enabled RBL.
Apparently SpamAssassin run before DKIM check or RBL check since

Code:
X-Spam-Status: No, score=2.5 required=5.0 tests=DATE_IN_FUTURE_06_12,
	DKIM_ADSP_ALL,DOS_OUTLOOK_TO_MX autolearn=no autolearn_force=no version=3.4.0

Appear before this:
Code:
ReverseDNS: No reverse DNS for mailserver, +30 Spam score
BlacklistCheck: Blacklisted address, +50 Spam score
SpamTally: Final spam score: 80

And so the e-mail sint dropped at all.

Any hint?

Regards
 
Thank you so much John for moving forward on the move to a SpamBlocker 4.3 configuration which will be manageable through CustomBuild and through DirectAdmin.. Would you be so kind as to post the difference between my defaults and yours? I've probably already switched to them in my own versions, but if not I'd like to know which ones, so if you have the list it will be easier for me.

Some comments on your comments:

1) DKIM: Internet Pioneer Jon Postel, who died at age 55 in 1998 probably said it best in what's often called Postel's Law:
an implementation should be conservative in its sending behavior, and liberal in its receiving behavior

Reworded in RFC 1122 as oart if the Robustness Principal, section 1.2.2:
At every layer of the protocols, there is a general rule whose application can lead to enormous benefits in robustness and interoperability [IP:1]:

"Be liberal in what you accept, and
conservative in what you send"

Software should be written to deal with every conceivable error, no matter how unlikely; sooner or later a packet will come in with that particular combination of errors and attributes, and unless the software is prepared, chaos can ensue. In general, it is best to assume that the network is filled with malevolent entities that will send in packets designed to have the worst possible effect. This assumption will lead to suitable protective design, although the most serious problems in the Internet have been caused by unenvisaged mechanisms triggered by low-probability events
In general I've never blocked specifically based on absence of either missing or incorrect DKIM or SPF, but rather have allowed SpamAssassin to score based on both as rules have been implemented. Now that we'll have EasySpamFighter I'll study it to see if it does the job as granularly as SpamAssassin does. In my opinion (shared by many) DKIM and SPF should be used as part of a scoring mechanism rather than to institute arbitrary blocking action. Especially as long as we still use forwarding of email. Many of oucr clients forward email to their accounts at Yahoo, Gmail, and Hotmail, and after all, we do want them to get their email. Perhaps we can eventually switch from forwarding to resending.

(Note I'm not referring to the manual forwarding you do in a mail client, but rather what occurs when you set up Forwarders in DirectAdmin.

And as part of this particular issue we should try to understand the difference between aliases and forwarders, both lumped together as forwarders in the DirectAmin control panel:

Forwarder: A forwarder is used to send email to a different domain, often, but not necessarily, on a different mail server.

Alias: An alias should be used when email is simply delivered to a different mailbox user in the same domain, by the same local mailserver. Perhaps this should be done without adding any headers at all, though I'm not sure if this is covered in any RFC, and I haven't studied any implementations since about ten years ago.

2) Variables: Very good idea to make these variables so they can be managed by DirectAdmin through the control panel. Very good to be able to keep them separate so they won't change when exim is updated, but perhaps even more important to be able to update them separately. The actual exim.conf file hasn't been changed much over the years, and with this modularization hopefully it won't be needed much in the future.

3) GreyListing: I've always lilked Greylisting, but I've never been a fan of the complexity involved in the various implementations.

I particularly like Andrea's implementation and I've been considering it for some time now. But please, Andrea, tell me why the exim variables acl_m4, acl_m5, and acl_my are commented out? As a side note I've consider that each section using variables should use it's only prefix letter (not necessarily m to make it easier to modify sections without worrying about infringing on variable usage.

Note that I've gotten measurable results without ever losing legitimate email by what I and others call nolisting. Simply set up, and if you've got an IP# which you control which you know doesn't accept email (for example a backup server or slave nameserver which doesn't have a running MTA daemon. Just use that IP# as an mx0 entry in the DNS zone for any domain on which you want it implemented with a value of 0, so it always gets tried first. This works well with no load on the server simply because all properly configured mailservers following RFCs always check the server with the second lowest cost MX record if the lowest-cost one doesn't respond. But spam severs do not.

All in all, I'm very happy to see this and look forward to full implementation.

Jeff
 
Any hint?
Maybe I shouldn't be up this late (03:10 here) and I'm missing something else, but from what I'm reading of your post (and I admit I've not yet downloaded or studied the new file), but it appears that the scoring is finalized by SpamAssassin before the scores for No rDNS or blacklisted addresses is counted. Perhaps these are two different systems, and the latter is somehow being missed by the delivery mechanism.

In my opinion scores such as +50 and +30 are too high, if this is part of the SpamAssassin system wherein a score of +5 is enough to count an email as spam. Penalizing for blacklist entries should be based on appearances in multiple blacklists, but adding them up to well over the threshold with only one entry is no different from blocking completely at the first listing. Without seeing the actual scores for each one I can't judge the logic, but I will want to look into that further. And penalizing rDNS with a score high enough to keep negative scores from overriding out doesn't allow delivery at all if (for example) DNS is down, even if only temporarily and the email otherwise has high negative values.

Perhaps this will force all of us to get slave DNS service somewhere if we want to send email to each other, but in my opinion not liberal enough (see my prior reply).

However, notice John's comments in his first post; it may simply be that the blocks aren't implemented by default.

Jeff
 
Hi Jeff,

thanks for your words :)

The commented lines were a test to automatic whitelist a subnet once one if IP of the subnet was whitelisted.

To make it more clear, was made for hotmail.it/gmail.com/big-provider.tld just cause they have multiple outgoint server and each mail-send-attempt is provided from a different server, this cause to have e-mail stucked in greylist for many many hours untill a second attempt come from an already greylisted/pending address.

It didnt work so i commented it out and im using senderbase.org (CISCO antispam system) to get all outgoing server (at least 1000 of them from their export tool) and manually inserting them in /etc/virtual/whitelist_hosts_ip so the greylist is skipped for this address

Best regards :)
 
Another issue: Outgoing e-mail are not DKIM signed anymore.

#COMMENT#61:
driver = smtp
.include_if_exists /etc/exim.dkim.conf

But /etc/exim.dkim.conf doesnt exist at all and and it wasnt created from those install steps.

I'd created them using data from my old exim.conf this way:

Code:
  dkim_domain = $sender_address_domain
  dkim_selector = x
  dkim_private_key = ${if exists{/etc/virtual/$sender_address_domain/dkim.private.key}{/etc/virtual/$sender_address_domain/dkim.private.key}{0}}
  dkim_canon = relaxed
  dkim_strict = 0

And now is signing outgoing e-mail again.

I would suggest to add a check for this if DKIM=1 in directadmin.conf and/or add this file in the first post as for /etc/exim.variables.conf

Regards
 
Another issue: Outgoing e-mail are not DKIM signed anymore.

#COMMENT#61:
driver = smtp
.include_if_exists /etc/exim.dkim.conf

But /etc/exim.dkim.conf doesnt exist at all and and it wasnt created from those install steps.

I'd created them using data from my old exim.conf this way:

Code:
  dkim_domain = $sender_address_domain
  dkim_selector = x
  dkim_private_key = ${if exists{/etc/virtual/$sender_address_domain/dkim.private.key}{/etc/virtual/$sender_address_domain/dkim.private.key}{0}}
  dkim_canon = relaxed
  dkim_strict = 0

And now is signing outgoing e-mail again.

I would suggest to add a check for this if DKIM=1 in directadmin.conf and/or add this file in the first post as for /etc/exim.variables.conf

Regards

I think it's documented in http://help.directadmin.com/item.php?id=569. It might be that you missed the following part:
Code:
cd /etc
wget -O exim.dkim.conf http://files.directadmin.com/services/exim.dkim.conf
 
Thanks Martynas,

since the first post was going to set all needed part a thot DKIM would be part of them since also spamassassin part get re-downloaded in first post :)

Best regards
 
Regarding forwarders in DirectAdmin. When customer forwards emails to for example their gmail accounts, then spam is also forwarded. Gmail see the spam as if it is sent from our mail server.

I ask that DirectAdmin can change the forwarders so that the envelope sender is not changed when forwarding emails, so that Gmail don't see it as spam sent from our mail server. Here is a quote from "Best practices for forwarding mail to Gmail" at https://support.google.com/mail/answer/175365?hl=en

We recommend that you do not change the envelope sender when forwarding email to Gmail. Sometimes, when forwarding email, the envelope sender gets changed to your domain. When this happens, Gmail may learn that your domain is sending spam, and will treat other emails from this domain as spam as well.
 
2) Variables: Very good idea to make these variables so they can be managed by DirectAdmin through the control panel. Very good to be able to keep them separate so they won't change when exim is updated, but perhaps even more important to be able to update them separately. The actual exim.conf file hasn't been changed much over the years, and with this modularization hopefully it won't be needed much in the future.

They'd need to be updated every time you update exim.conf, so that you'd have all of the used variables set. To customize any of the settings, you'd need to use the following files:
Code:
/etc/exim.variables.conf.custom
/etc/exim.strings.conf.custom

No custom files for BlockCracking of Easy Spam Fighter are available yet.
 
Hi again,

another side note, would be nice to check DKIM also for local emails that are from domainA to domainB and maybe also domainA to domainA since end-user wanna always be sure for email, dont need to know if sender is hosted on same server at all actually :)

Hope John gonna reply as soon he have few free time to all my posts :)

Regards
 
Hi Jeff,

regarding the high values in mail headers

ReverseDNS: No reverse DNS for mailserver, +30 Spam score
BlacklistCheck: Blacklisted address, +50 Spam score
SpamTally: Final spam score: 80

I'd talk with John and those are value for EASY_SPAM_FIGHTER and are actually pretty useful once you tweak them

Code:
exim.conf code related
  warn
    add_header = SpamTally: Final spam score: $acl_m_easy69

  drop
    condition = ${if >{$acl_m_easy69}{EASY_HIGH_SCORE_DROP}{1}{0}}
    message = Your message was classified as SPAM.  Please add more content, cut down on HTML links, use fewer naughty words etc.  Also, ask your IT dept to make sure your mailserver has REVERSEDNS, SPF and is not on any black lists. Your score: $acl_m_easy69

Related variables files: /etc/exim.easy_spam_fighter/variables.conf

Related variables:
EASY_HIGH_SCORE_DROP = 100
EASY_NO_REVERSE_IP = 30
EASY_DNS_BLACKLIST = 50

I've tweaked this way:
EASY_HIGH_SCORE_DROP = 100
EASY_NO_REVERSE_IP = 100
EASY_DNS_BLACKLIST = 100

Since the DROP is set to 100, and since for me being in a RBL and/or have no rDNS set is 99.99% synthom of being spam, those two values themself get the email reject at beginning as it is for most worldwide providers.

Does you agree with me?

Regards
 
I've tweaked this way:
EASY_HIGH_SCORE_DROP = 100
EASY_NO_REVERSE_IP = 100
EASY_DNS_BLACKLIST = 100

Since the DROP is set to 100, and since for me being in a RBL and/or have no rDNS set is 99.99% synthom of being spam, those two values themself get the email reject at beginning as it is for most worldwide providers.


Does you agree with me?
I'm going to respectfully disagree. No rDNS can be caused by a failure in DNS resolution. It should certainly have a lot of weight, but I don't think it should be enough. Don't forget that many of don't have control of our own rDNS; we're at the mercy of our own upstream providers. I understand that the big guys count this as spam, but I'm not sure they completely block. I believe most of them rotue to spambox or delay, or rate limit, but don't completely block/drop.

And the spam blocklists? Again, this would depend on how each individual blacklist is weighted. Most blacklists specifically publish that you shouldn't depend on them alone to block.

Jeff
 
But usually when you rent a server or buy a hosting you always have a rDNS set on the IP, it may not be the same as hostname, ok, but usually a rDNS exist, its pretty strange if there is absolutlely none, am i wrong?

Regarding the RBL i may agree with you, but for example the single email i'd sent to DA Staff was about domain impersonating, they was pretending to send from [email protected] to [email protected], and that must (to me, unless different set) happend, specially if the sender is in a RBL and have no rDNS, so, maybe set 50/50 as point on those two option would be a better solution, so, if both match the "missconfiguration" the server set them as spam.

Regards
 
But usually when you rent a server or buy a hosting you always have a rDNS set on the IP, it may not be the same as hostname, ok, but usually a rDNS exist, its pretty strange if there is absolutlely none, am i wrong?
Usually, but not always. Over the years I've seen lots of errors. We expect that the big providers (especially the free ones) will block such emails, and in fact we usually tell our new clients not to use email addresses at free providers when ordering from us, because we want to be sure they get our emails.

I've actually polled our clients. Universally they'd rather get spam than risk losing even one important email, so we're very careful about what we block. And we still block lots of spam.

Regarding the RBL i may agree with you, but for example the single email i'd sent to DA Staff was about domain impersonating, they was pretending to send from [email protected] to [email protected], and that must (to me, unless different set) happend, specially if the sender is in a RBL and have no rDNS, so, maybe set 50/50 as point on those two option would be a better solution, [/quote]
That would depend on which blocklists you're using. Many blocklists are what I call quick on the trigger and some of them I no longer use at all. But that's why we have whitelists. If all the blocklists we choose all the time always worked we wouldn't need them. But manual intervention is very time-consuming and annoying to recipients who don't get email. And honest senders. (For example, hotmail and yahoo often get on blockliss, gmail occasionally but not as often).
so, if both match the "missconfiguration" the server set them as spam.
There are lots of misconfigured servers out there. I've quoted Jon Postel previously in these forums and I wont go back to find his exact words now, but simply, he believed, and I believe, that we need to be conservative in what we send, and liberal in what we accept.

I won't argue the point, but there's lots of disagreement. I want my clients to have what they want, and universally that's to get all their legitimate email, even if it means they get a lot of spam.

I'm getting very interested in setting up sa-learn on a per (system-user) basis, but first need verification so I know that's what it does. If no one can help us know that I can try to test for it myself.

Jeff
 
I'm testing sa-learn those days and i'd made a script to teach all domain/users, but i've noticed that it is creating a /root/.spamassassin path where all the bayes are saved, so i'm fixing/improoving it a bit for save each bayes on a user-level path (cause my bayes on /root/.spamassassin was becoming pretty big).

If you're interested on the script (which is baesd on http://help.directadmin.com/item.php?id=358) just let me know.

Regards
 
Very much interested, Andrea. I noticed a post you made ten minutes before this one, about a problem you were having. Are you still having the problem? Not that I have answers, unfortunately; I've always worked on the blocking stuff and I've let others work on the SA effort.

But I'm very interested in yor project.

Jeff
 
Back
Top