E-Mail security additions and cleanups

[IT_Architect]

What would like to see are:
- Find or write software that minimizes DMARC's vulnerabilities. To get a true picture of how easy it is for a spammer or scammer to get around DMARC and even use it to his advantage, see Breaking DKIM - on Purpose and by Chance.
- A procedure or script for CB 2.0 to easily turn off unencrypted E-Mail access so users don't compromise their credentials at hot spots with their mobile devices.
- Add to the documentation for SpamBlocker
A. How to configure your resolv.conf and system to ensure you use the public address of your own BIND servers or to select one without much traffic so that it doesn't go beyond the limits of the RBL and cut you off.
B. Who you are using for RBLs or at least where to find it, which ones are free, which require registration, which ones cost money for commercial purposes, and fix the mistakes in the documentation on how to add or remove entries from the RBL_DNS_LIST for CB 2.0. What I currently see in the exim.conf are these:
RBL_DNS_LIST=\
cbl.abuseat.org : \ <-- "The CBL is still firmly committed to free access to small and medium sized organizations. See Terms of Service" Then it goes on to say, CBL is now a division of the Spamhaus Project. In the meantime, you may wish to familiarize yourself with the Spamhaus DNSBL Usage Terms and contrast "Free usage" versus "Professional usage". Do NOT use this with SpamHaus.org products because they use the same database. This is the free-for-commercial-use version of zen.spamhaus.
bl.spamcop.net : \ <-- "If you use the blocklist and like it, please feel free to make a donation... This one started out independent, then IronPort Systems bought them for their anti-spam hardware appliance, after which Cisco bought them. It works by keeping track of at-a-boys and aw-craps. When the aw-crap score exceeds the at-a-boy score, you end up on their RBL. There is no manual way off. You have to fix where the aw-craps are coming from, and it will clear itself in approximately 48 hours.
b.barracudacentral.org : \ <-- Free with registration: and Barracuda Reputation Block List (BRBL) – How to Use They are probably the most highly respected company for their Anti-Spam hardware appliances, which is also one source of their information that they put a lot of trust in. You can request removal here with valid reasons as to why they should remove you, such as compromised account re-secured.
zen.spamhaus.org <-- Free for non-commercial use only. "You should not use ZEN together with other Spamhaus IP blocklists, or with blocklists already included in our zones (such as the CBL) or you will simply be wasting DNS queries and slowing your mail queue." So from this, it seems like CBL is giving away Spamhaus for free, at least for the time being. However, this didn't make a lot of sense so it kept bothering me. I was right. Spamhaus needed CBL. CBL specializes in "IP addresses exhibiting characteristics specific to open proxies, spamware, malware downloaders, botnets and the like." Spamhaus markets this as XBL (Exploits Block List) as part of Spamhaus, but not separate as CBL is. Therefore, Spamhaus includes CBL, but CBL does not include all of Spamhaus.

With this information we know the stock RBLs in exim.conf don't make sense. CBL is free, and Spamhaus is not. If you use Spamhaus, don't use CBL, so the list of RBL defaults as-is, is a problem. People need to know they need to register with, and set up the IPs to with Barracuda. Thus, I opened /etc/exim.conf, copied the RBL_DNS_LIST, made a new etc/exim.variables.conf.custom, file, and copied the RBL_DNS_LIST into it so it looked like this:

RBL_DNS_LIST=\
cbl.abuseat.org : \
bl.spamcop.net : \
b.barracudacentral.org : \
zen.spamhaus.org

then made it a double ==, and dropped zen.spamhaus.org so it looks like this:

RBL_DNS_LIST==\
cbl.abuseat.org : \
bl.spamcop.net : \
b.barracudacentral.org

Then

# cd /usr/local/directadmin/custombuild
# ./build exim_conf
.
.
.
Enabling Easy Spam Fighter...
Easy Spam Fighter is now enabled.
Restarting exim.
Shutting down exim:     [ OK ]
Starting exim:          [ OK ]

A common theme in the Terms of Service is:

As a matter of best practise, you MUST NOT bounce (accept then queue up separate email to the sender), but instead reject (issue SMTP rejection inline). This largely prevents your filters mail bombing the victims of forgery.

 

[Richard G]

You could also just have them on 1 line like this:

RBL_DNS_LIST==cbl.abuseat.org : bl.spamcop.net : b.barracudacentral.org

as shown in:
https://help.directadmin.com/item.php?id=610
which might prevent trailing : and/or \ typo's and is a bit easier imho.

This is using the exim.strings.conf.custom by the way.

 

[IT_Architect]

This is using the exim.strings.conf.custom by the way.

And then you read the link reference inside of that link which says to put it in the variable one and keep the string ones for strings, which makes sense because what is in the string one has to do with messages, and it says to use == on the strings, and single = on the variables, except single = doesn't work on variables, you need to use ==.

 

[Richard G]

Maybe you were replying to my message which I changed before.

I was just pointing out an easier way to do this with less chance of typo's.

It works exactly as I wrote in my example in reply #2 (same as the help section I linked to). I've used that to remove a blacklist from being used by Exim and is working perfectly like that.

 

[IT_Architect]

Maybe you were replying to my message which I changed before.

There are several things going on here.
1. I wrote incorrectly in my previous message single and double quotes. That is just plain wrong. I meant to say single = and double == and I just now updated what I wrote.

2. What you aren't getting is if you read the link that you posted, there is a link about halfway down that references the more in-depth about the custom files and talks about toward the bottom. I read that reference, and I looked at the strings file and the variables file. The strings file contains strings used in messages. The variables one reads like things things we have here. I believe you that it works either way. I simply copied and pasted the variable from Exim.conf to the variable custom as-is, and edited. It shows up just like in exim.conf except with modification, in the variable file when the process completes.

3. In the instructions for variables in the referenced link, it is explicit to use a single = with variables, but it doesn't work. When the script runs, it tells you that you need to use double ==. When you use double like the script message states, it works perfectly.

Summary, what I'm saying here is the link you referenced, and the link within that link do not agree, nor does it seem that the statement in the second link is accurate because a single = does not work, and a double == does. From what I gather now, both files work the same. If you are overriding a DA string or variable, you need to use the ==. If you are adding a new one, then you use =.

 

[Richard G]

Summary, what I'm saying here is the link you referenced, and the link within that link do not agree, nor does it seem that the statement in the second file is accurate because a single = does not work, and a double == does.

Correct, but that is only applicable when using the custom variables.conf, they should update/fix that.

For the custom strings.conf it contains the correct notice about the need for double == in both links.