What is the best way to undo DKIM and DMARK?

IT_Architect

Verified User
Joined
Feb 27, 2006
Messages
1,114
What is the best way to undo DKIM and DMARK?

Basically, I set up everything in CB 2.0 with SpamBlocker, SpamAssassin, got it to use rbls, and all of the other recommended stuff on a new server. The only thing that I've accomplished with all of that careful work is to get blacklisted and stuff like "DMARC Record Published" "No DMARC Record found", they want to know a selector to test DKIM and nothing works. They want PTR records, and I have them. I'm also going to shut of RBL checking. I'd rather have the spam and be able to send E-Mail. POPFile works way better and way easier to get rid of spam.

Thanks!
 
I think the key issue here is that if you setup for example DKIM and DMARC, you have to set it up correctly, or otherwise it will cause more harm than it will do good. For example, if Exim is signing your e-mail with a DKIM key, but your DNS doesn't have the corresponding data, it will raise a red flag.

So either set them all up properly, or remove them completely.

With DKIM it's about disabling it in Exim & removing the DNS record: https://help.directadmin.com/item.php?id=569 (sort of reverse these things)
For DMARC, it's only a DNS record: https://help.directadmin.com/item.php?id=596

About RBL: this is more for incoming mail rather than outgoing mail.

Personally I would advice to keep DKIM (and SPF), it seems to be the current standard every email provider is checking for.

The thing also is:
- even if you have everything setup properly, if the contents and or headers of the e-mail are suspect (according to receiving spam checks), they may also choose to flag your mail.
- some providers/spamcheckers will give entire IP-blocks a (negative) reputation

When blacklisted, you'd really need to try to figure out the exact cause.
 
>When blacklisted, you'd really need to try to figure out the exact cause. <
I'm done figuring.

The new server had been up for at least 6 weeks when I decided one day that I'd like to check RBLs, so I switched it to using the DNS of the server, which then let me use RBLs with no errors. That lasted about a week before I ended up on Barracuda's blacklist. I couldn't imagine what that would be about, and when you click on the details, there is "No reason given". I requested to be removed, and I was for about 48 hours. During the process they have links to set up an account, which I did. It seemed they wanted me to register to use their stuff. That is not mentioned anywhere in the DA docs, nor do I know if it is true, but they sent me a link to test from the server to see if they were communicating, and it returned they were communicating fine. Then I requested to be removed. I was for a short time again, and then back on again. Next I decided to follow the directions here to set it up here, and since the new server uses CB 2.0, it isn't editing files as in CB 1.0, but rather following the directions and running scripts so that CB 2.0 can keep things in sync. So I followed the directions for DKIM and DMARC trying to make Barracuda happy. If there were other things not in the directions that we are supposed to do that are not documented, then they are invalid. I pulled them using their instructions of deleting the key sets, delete the txt records, and setting DKIM to zero.

I've been blacklisted twice in 10 years, once by a few RBLs, and once by the data center. Both times it was a hacked email account. There is no such situation here. The old server with the same IPs used only spf and a the data centers private dns, until I decided to change to using the local DNS server so it could simply work with RBLs. After all of this, I went back to the the way the way the old servers are that works, complete with bounced rbls, and I have requested to be taken off again.

The only one I have a problem with is Barracuda. They also try to up-sell me their whitelisting services, but their links are broken to EmailReg.org, and from the dates on other's posts, they have been that way for quite some time. They feign EmailReg.org as independent, but it is in fact owned by Barracuda, and operates in the address range that belongs to them. It is widely seen now as a scam since they have the power to arbitrarily block your emails with no reason given, they are the only ones doing it, and they sell you the solution, or so they say. Presently, I don't know if there actually is any way off their list without paying someone, and with the broken links, I'm not sure that's possible. One thing is for sure, they won't give you a reason for why they have black listed you. There have been many FTC filings against them, but if it isn't real, then why does it take years to get rid if the links?
 
Last edited:
Perhaps the most useful thing to be done here could be arguing to DA to remove barracudacentral from the default RBL lists https://help.directadmin.com/item.php?id=610

I haven't followed the latest development on this area, but if what you say is true, all DA users shouldn't be encouraged using this list by default as it would contribute to it's wide usage and power it gives to the list.

I see spamhaus is on there as well, I remember the same kind of complaints about them from like 10 years ago; to an extend to which an ISP opened a DDOS attack to spamhaus which went into the history records as one of the biggest at the time.

In that light, maybe it could be reasonable for the DA community to check once again if RBLs are still a good way to mitigate spam in the year 2018.
 
I don't know. I use barracudacentral for many years already and I'm happy with it. I did subscribe with them and entered my server ip's, maybe that's the difference.
There are more systems that try to sell you whitelisting services if you're on a blacklist. And it won't help removing it from DA, because you still can get blacklisted by them.

You could also just create a custom file to define to remove barracuda from the RBL list, that's fairly easy to do.

But it's always good to check if RBL's are still things to be used at this time. However, I think they are. When I look at my rejectlog, I'm very glad that I've got them, and... loads of spam are blocked by barracudacentral so I will keep using it.
 
I did subscribe with them and entered my server ip's, maybe that's the difference.
The documentation to install SpamBlocker and its components are worse than invalid if it leaves out steps that result in getting it blacklisted. There is no place in the setup instructions that even mentions that it uses the Barracuda RBL, even if you happened to know that Barracuda requires registration first. All of the sudden you're just on a Barracuda's blacklist.

I'm going to drop the Barracuda RBL I/A/W SpamBlocker 4.x: Custom RBL lists and SpamBlocker 4.x: Custom RBL lists. Those instructions are conflicting and both wrong. The RBL variable that contains the RBLs it uses is indeed at the top of the exim.conf as indicated in the first link. The first link addresses exactly what I want to do. It says to make a exim.strings.conf.custom file and shows the format to use. When I look in the exim.strings.conf file, there are no variables in it. It contains phrases used in display messages. Then, that article tells you to check out the second article towards the bottom for more details. When you read it, it says:
Once you've set your exim.variables.conf.custom, they need to be merged into /etc/exim.variables.conf, which CB2.0 can do for you, but using:
./build exim_conf
We used he merge method because exim does not allow a variable to be set twice (== does not work), and also because we may want to add more default variables in the future, but still allow you to override the values you want.
After reading this, I simply made the exim.variables.conf.custom file and copied in as-is:
RBL_DNS_LIST=\
cbl.abuseat.org : \
bl.spamcop.net : \
b.barracudacentral.org : \
zen.spamhaus.org
from the exim.conf file, and dropped the b.barracudacentral.org line. When I ran ./build exim_conf it bombed telling me I needed to use ==, not =. After I changed it to ==, and ran ./build exim_conf again, it worked fine, and exim would now start again now. When I checked, it wrote what I had placed in exim.variables.conf.custom to the top of exim.variables.conf file, using the same == format. What I still don't have is a method to know for sure what Exim is using at run time, nor do I know if SpamAssassin also uses them, nor how to determine either. /etc/mail/spamassassin/local.cf doesn't show any. What I DO know is Barracuda has no problem blacklisting people, but have a big problem telling them why they blacklisted them, even though they know, and if the DKIM and DMARK instructions work about like these, it could be a while before I get them to work correctly.

...and entered my server ip's
By server IPs, you mean your mail servers' IPs which happen to be the same as ns1, plus the ns2, which is one number away, and points to the same server? That ends up being about 2 per machine, and since the order of DNS requests starts at the top of the resolve.conf, the first two addresses in that file would be your server/ns1, and ns2?
 
Last edited:
@IT_Architect, I have not subscribed or registered for barracudacentral, however I do have b.barracudacentral.org in my exim.conf - if it is needed to subscribe/register with them first, then they should be removed from default exim.conf, however I don't think it is needed to subscribe/register as I have not been blacklisted by them on any of my servers.
 
if it is needed to subscribe/register with them first, then they should be removed from default exim.conf, however I don't think it is needed to subscribe/register as I have not been blacklisted by them on any of my servers.
Thank you for your reply. That's what it says on their site, Richard G. says that what he did, and then I wondered too why it would be part of exim.conf if all it did is get you blacklisted.

They give you a verification number when you fill out a removal request, and that's the last you hear from them. The Barracuda site is full of broken links to things that have been gone for nearly a decade, so I don't know if there is really anybody home over there. It is a new server, and I have not added more domains because if this problem. There is basically 4 email users; a secretary, and 3 engineers, who were on an older server, where they had no problems for a decade. The IP group I am using on the new server came from another server that never had any kind of blacklist problem, and addresses that hadn't been used for over 2 years.
 
Thank you for your reply. That's what it says on their site, Richard G. says that what he did, and then I wondered too why it would be part of exim.conf if all it did is get you blacklisted.[cut]

But they have NOT blacklisted any of my servers, and I have not registered with them.
 
The Barracuda Reputation Block List (BRBL) is be available free of charge to anyone who wants to use it. We simply request that you provide the list of IP addresses of your domain name servers (DNS servers) that will be making queries. IP addresses not listed may be blocked, rate controlled or otherwise denied access without warning. You can list up to 10 IP addresses to make queries.

Access will be typically granted in 10 minutes of submitting this form. Please note that requests with false information may be rejected and access denied.

I think the deal here is that if you don't register you may get blacklisted:
1. Maybe when you have high rate of incoming mail which results in high checking at their RBL list.
2. When they do blacklist your IP, e-mail you send may also be blocked by the receiving party if they also use barracudacentral.
 
I think the deal here is that if you don't register you may get blacklisted:
1. Maybe when you have high rate of incoming mail which results in high checking at their RBL list.
2. When they do blacklist your IP, e-mail you send may also be blocked by the receiving party if they also use barracudacentral.
1. There are free limits of so many queries per day. One reason people get blocked is a they use a public, free, DNS servers, which eat that up very fast. In fact, I don't think it gets that far. The moment you include a public in your resolve.conf, you will see RBL block messages in your email headers. As I recall, the limit per day for Barracuda is 250,000/day.
2. SpamHaus is even more restictive in a licensing way:
Use of the Spamhaus DNSBLs via DNS queries to our public DNSBL servers is free of charge if you meet all three of the following criteria:
1) Your use of the Spamhaus DNSBLs is non-commercial*,
and
2) Your email traffic is less than 100,000 SMTP connections
per day, and
3) Your DNSBL query volume is less than 300,000 queries
per day.
If you do not fit all three of these criteria then please do not use our public DNSBL servers, instead see 'Professional Use'.
3.
URIBL provides public lookups over DNS for low volume usage. If you spam check a large amount of email, or you use a shared DNS platform for resolution, you may receive a response saying the query was refused. That said, Public DNS providers such as OpenDNS or Google Public DNS are effected due to the high volume of queries they generate, as are many other internet service providers (ISP) that use caching nameservers for their customer base.
So then I would guess your resolv.conf, at least the top two of the 3 total entries, had better have the IPs of your own server's name servers listed, and maybe no more, or at least if there is a 3rd, another low-volume PUBLICLY-ATTACHED, and privately used server like your web server. They won't respond to queries anymore that originate from any private address DNS server, as is commonly used in data centers.

So if DA doesn't mention this stuff, or the default isn't RBLs off, then they are setting people up. My guess is it hasn't always been this way, and I have grandfathered servers, etc. But if you think about it, you could sell a commercial service off the backs of other people's work by simply passing through queries.
 
Last edited:
But I don't think it's actually a good idea to resolve incoming messages against an RBL with the same IP as to which you send e-mail from. If you are being blacklisted by asking too many incoming checkups, you may not be able to send e-mail anymore as well (to receivers also using barracuda). Assuming that if they will block you for incoming, they will also block you on their RBL list.

If that's not the case, than the worst that can happen is that you can't lookup incoming e-mail against their RBL anymore, which shouldn't be the end of the world.
 
I see there are more answers, but I just want to comment on this part below mentioned in your reply #6.

I don't know if it has to do with registering the server ip's with barracuda or not, it was just an idea of me which might have something to do with it. But since others don't have issues, without registering, that won't be the cause.
And indeed Spamhaus is even using stricter rules.

By server IPs, you mean your mail servers' IPs which happen to be the same as ns1, plus the ns2, which is one number away, and points to the same server? That ends up being about 2 per machine, and since the order of DNS requests starts at the top of the resolve.conf, the first two addresses in that file would be your server/ns1, and ns2?
A mail server's ip does not have to be the same as ns1 and ns2 pointing to the same server.

a.) It's not necessary to put ns1 and ns2 as first in the resolv.conf. Even better, some do point to an ip from the datacenter and some even use Googles DNS servers in resolv.conf. It can be wise however to use NS1 in there to prevent running into certain issues. Which you also mentioned yourself.
b.) NS2 should be an ip on an totally different server in a different geographical location for good DNS practices. So in a good case, this is not the same server.
c.) Your mailserver is by default running on your main servers hostname ip. Which does not need to be the same ip for ns1 or ns2. You can also use other ip's on the server (if present) to be used as ns1 and ns2. It doesn't have anything to do with your mailserver ip.

So I only use 1 ip for mail, which is my primary hostname ip adres of the server. And yes, in my case the mailserver's IP is the same as ns1.
My ns2 is resided on a totally different server and the second entry in my resolv.conf is a server from the datacenter.
So when registering it only needs to be 1 ip, or 2 if you're using ipv6 too for mail.
If you have a lot of servers, then this will be a lot of work.

But since most don't even bother, it looks like it's not really needed.
 
I finally got a response from Barracuda that they were going to un-blacklist me, and check me out again in 30 days. The new server is no longer blacklisted. The problem is, I'm not sure what to do different over the next 30 days. MXToolbox likes my E-Mail server. I did register my IPs for their free RBL service, which for now I had Exim drop them. I did prove with an nslookup that the server was indeed using the BIND installed on my server, and resolv.conf only has our IPs that point to the local DNS server, and there is no 127.0.0.1 so it cannot route through localhost and thereby be a violation of the rules with Barracuda.

During this period I've had to spend WAY too much time thinking about E-Mails and protocols. We forward E-Mails consciously from time to time, but many set up forwarders, and about half of them are to external E-Mail accounts like Google, Yahoo!, Hotmail.com/Outlook.com. Whenever you forward an message, you have to preserve the original sender as well as the receiver so they can respond to it. So how would that work out?

I. SPF:
A. Someones E-Mail account gets compromised and they are broadcasting spam. It hits your E-Mail server. Your server does a DNS lookup on the senders domain for the SPF record, and reads it. Your server sees that envelope-from address and the IP address match, so you drop the score of the E-Mail and accept it. It does not consider that the From the user sees and the one in the envelope from do not match.
B. Your E-Mail server sees that it needs to forward the message to GMail. The forwarding email server, your server, must impersonate the original email server in order to preserve the original sender information. The GMail server reads the envelope-from, does a DNS lookup on the senders domain for the SPF record, and reads it. The destination server realizes that your E-Mail server is trying to deliver E-Mail it is not authorized to send E-Mails for the sending domain, and it naturally knows your server's IP address. Now who is the scammer/spammer? Not the server with the hacked account that can pass the SPF test, it is yours because you cannot. In fact you've been passing lots of E-Mails that your server hasn't been authorized to pass (legitimately). The only time SPF forwards will NOT fail is if they are forwarded to another user on the same physical E-Mail server.
C. GMail tells RBLs that you are acting like a spammer. Now let's add to that some reports from Yahoo! and Hotmail/Outlook.com, Office365, etc. where you forward E-Mails.

II. DKIM:
A. Someones E-Mail account gets compromised. The hacker sends messages from that account only this time the server adds a DKIM signature. One thing that is different is the From: field that the user sees is the header From: filed, the one that the user sees when he makes the E-Mail, that is always included in the hash it creates, while SPF uses the (envelope-from field, something the user never sees. It actually cannot happen any other way because at the point where the hashing and encryption have to take place, you couldn't include the information from the envelopes because they don't exist yet. The destination E-Mail server sees sees that it has a DKIM signature, which reveals which “domain/selector” combination used in the encryption process. To validate the signature, the destination E-Mail server will run a DNS query to find the DKIM public key contained in a TXT record for that domain on your server. With that key it can decrypt it back to the original hash. The destination E-Mail server then takes the elements of the email signed by DKIM and generates its own hash of these elements, and compares it to the decrypted hash from the DKIM signature. If they match, we know that:
1. The DKIM domain really does “own” the email, otherwise the decryption process wouldn’t have worked in the first place.
2. The elements of the email signed by DKIM were not changed in transit (if they were changed, the hashes would not match)
If it all validates and your server drops the spam score.
B. Your E-Mail server sees that it needs to forward the message to GMail. As before, the forwarding email server, your server, must impersonate the original email server in order to preserve the original sender information so the recipient can respond to the original sender. However, things play out a little differently this time. GMail's E-Mail server notices the message has a DKIM signature, so it skips the SPF test because it knows it fails half the time because of how often people forward E-Mail messages. DKIM doesn't care how the message got there, it does the same thing your server did, and looks for the DKIM TXT record in the DNS that originated with the E-Mail, and reads the public key. If after it unencrypts the signature and validates the hash, it validates so GMail's server drops the spam score.
C. GMail finds out the message is spam, but with DKIM, they know the message originated from the domain listed in the message header From:, not your E-Mail server. It doesn't mean you are completely off the hook because you could have tampered with the content, but they do know it didn't originate from your server. It's more likely to report to RBLs that the spam is coming from domain in the header From: than from you, the forwarding domain.
*Reality. Anyone can write or changing anything in the message that is not in the hash, and it will will not mess up the DKIM signature. Because DKIM only signs the specified parts of the message, the message can be forwarded on by an intermediary that inserts the extra fields, and the signature will still match. This is called a replay attack. You might believe that if you have DKIM encrypt more of the message, the safer the messages would be. The problem with that scenario is that Anti-Malware and Anti-Spam software often write changes to the E-Mail, and if one of the fields is in the hash, then DKIM sees it as a message that has been tampered with. Another is the myth that DKIM cannot be spoofed. What hackers do is add a second From:, To:, or Subject:.

III. DMARC
DMARC can be used with SPF, or DKIM, or both. DMARC's function is simple
A. For SPF it is matching the header "From:" domain name portion that the user sees, with the envelope's "(envelope from” domain name that the SPF check uses. (alignment)
B. For DKIM, it is about matching the header "From:” domain name that the user sees, with the “d= domain name” in the DKIM signature. (alignment) A mismatch there or any of the other fields in the hash indicates the message has been tampered with.
C. To pass DMARC authentication, a message must pass SPF authentication and SPF alignment and/or DKIM authentication and DKIM alignment. For DMARC to use SPF and DKIM together to lower spam scores significantly and increase trust against spoofing, they must be aligned together. E.G. both using the same domain. A message will fail DMARC and often acceptance if the sending and destination domains support both SPF and DMARC and fails both.
Reality: Dave Rand and Doug Otis of Trend Micro argue that a weakness in the specification means that end-users can be effectively spoofed if they don't check for duplicate header records and since they are in there anyway, that should be checked and by messages that pass both DMARC testseven with the criteria of SPF, DKIM, and DMARC being satisfied and that it would be trivial to add code to check for duplicate headers. The committee argued that would be a malformed E-Mail, and that it should not be handled by DMARC.

Summary Thoughts
- SPF is almost universal, and drop-dead simple to deploy. While the destination E-Mail server can determine from it if the E-Mail server is authorized to deliver E-Mail for the sending domain, it cannot use it to raise the spam score if it doesn't match because every E-Mail that is forwarded meets that criteria. Shucks, I could set up an E-Mail server with an spf record and domain spam-inc.com, send spam to people, and have the E-Mail message they receive look like it come from you to them, because spf simply verifies the (envelope-from, which would be spam-inc.com and I have a matching spf record to match.
- DKIM was made to "solve" the spoofing problem by hashing and encrypting the header From: field ans several others the sending user sees and created and should not change during its travel to its destination. When the destination E-Mail server sees the DKIM code in the message, it can use the header From: to find the domain's public key to unencrypt the hash with, and compare that hash to the hash that it generates from the same fields in the current version of the message to determine if any of them have been tampered with. It isn't interested in how the message got there. The problem is we know that it can be spoofed by simply adding additional headers.
- If you add DMARC to SPF, DMARC looks at both the (envelope-from that the user does not see, and the header From:, which the user does see, and checks for a match. As stated before, SPF fails if a message is simply forwarded, so you can't really raise the spam score, but you could drop it it some.
- If you add DMARC to DKIM, DMARC looks at both the (envelope-from that the user does not see, and the DKIM's secure hash that includes -d domain, and the From:, which the user does see, and checks for a match.
- If both SPF and DKIM succeed, it means you have a message where the important fields have not changed since it was accepted by its E-Mail server, and the destination server can be sure it is talking to one that the domain authorized to send E-Mail for it. DMARC does not by itself deliver on its design goal to prevent spoofing due to the multiple header field vulnerability.
- It is my opinion that the whole DMARC strategy is so flawed that I struggle to find any real value. 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. These protocols are so short-sighted it's as though the Bank of Nigeria and ransomware authors staffed the committees that came up with them.
- It seems like the old school technologies of Bayesian filtering, and clever, highly responsive, Anti-Virus and Anti-Spam to minimize the damage, are the most effective. RBLs, due to their nature, need to be slow to react to prevent false positives and thereby turn into a nuisance.
 
Last edited:
What we need from DirectAdmin are:
- Software that minimizes DMARC's vulnerabilities.
- 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 they are using for RBLs, which ones they can just use, which ones are free with registration, which ones cost money for commercial purposes, and fix the mistakes in their 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
Code:
# 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 ]
Then check things out with:
Code:
# ps -ax | grep exim
# ps -ax | grep spamd

Next I looked in /etc/exim.variables.conf and can see where ./build exim_conf inserted our customized RBL_DNS_LIST variable at the top of the file. Then I ran some test E-Mails back and forth and it worked great!

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.
 
Last edited:
Back
Top