All incoming mail blocked by bl.spamcop.net

R

rvandam

Verified User
Joined
Aug 28, 2009
Messages
41
Since a few hours all incoming mail was blocked by bl.spamcop.net We tried sending mails to ourself from gmx, gmail and microsoft.

The solution was to comment out spamcop in /etc/exim.conf

The spamcop site is unreachable (domain expired). Do others have the same problem (is something strange going on)?

This is the log entry from exim/mainlog:

H=mout.gmx.net [212.227.17.21] X=TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no F=<[email protected]> rejected RCPT <[email protected]>: Email blocked by bl.spamcop.net
Click to expand...
 
Last edited:
This was the error I got trying to send from GMX to my own email:
This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of
its recipients. This is a permanent error. The following address(es)
failed:

[email protected]:
SMTP error from remote server for RCPT TO command, host: myserver.nl (myip) reason: 550 Email blocked by bl.spamcop.net
Click to expand...
 
It seems that domain spamcop.net was not payed :)
Remove line witch contains bl.spamcop.net from exim.conf and restart exim.

Or update exim.conf to the latest version using custombuild.
 
Please check forums before posting. ;)

Spamcop will be back, is already resolving with some, so no need to remove it, or only for a short while.
 
For them to not renew their domain is just stupid and bad for reputation, especially as they can break lots of MTAs.
 
Sorry for not checking the forum before posting. The was stress involved :rolleyes: I managed to resolve before posting, but I was sure others would have the same problem too.

Strange that a problem like this can shut down so many mail servers. This is more Exim related then Directadmin I think. Now working through 600+ log lines of rejected mail to see if we missed something important.
 
Removing the spamcop area from exim.conf and restarting exim does not fix the problem.
 
rvandam said:
Sorry for not checking the forum before posting. The was stress involved :rolleyes: I managed to resolve before posting, but I was sure others would have the same problem too.

Strange that a problem like this can shut down so many mail servers. This is more Exim related then Directadmin I think. Now working through 600+ log lines of rejected mail to see if we missed something important.
Click to expand...
If done in time , they send again automaticly.
 
ikkeben said:
Her the exim.conf custombuild latest version is working, do you have used that for update, some custom or version somewhere because of exim version problems some had before?
Click to expand...
- It's not standard, and I doubt anyones' are these days, and it has worked perfectly until the spamcop issue.
- I turned off the firewall, which checks for crap, but that didn't work.
- The file checks other sources that are downloaded daily so I'm guessing it blacklisted the whole world in one of those files. It looks like I auger through things to get things working today. It will tell me which sources use Spamcop and I'll eliminate them.
 
I tracked it down. The new /etc/exim.conf didn't work right at all, so I put the original one back that I had edited out spamcop on. I did a grep -rli "bl.spamcop.net" /etc and found the definitive RBL_DNS_LIST is not located in /etc/exim.conf. It is overridden in /etc/exim.variables.conf. If you go to that file it says not to edit it directly, and to make an /etc/exim.variables.conf.custom. However, that does not work because there is no place where that gets included, not in /etc/exim.conf nor /etc/exim.variables.conf. It's passing email now after I edited /etc/exim.variables.conf. Tonight I'll sort out the mess, but for now email is working. I'll probably make a /etc/exim.variables.conf.custom tonight and find or add a way to get it included after /etc/exim.variables.conf or add a line to /etc/exim.variables.conf. Perhaps the newer files have that fixed too.
 
Richard G said:
You could have used the /etc/exim.strings.conf.custom which are used to include or exclude RBL's.
Click to expand...
Re-read what I wrote about that. It didn't work and then I discovered why. Another thing that turned it into as big of a hairball as it did, and why I had some servers with no issues and some with issues is Spamcop had/has a 24hr TTL. So half of the queries elicited a response from a parking page indicating it is spam server and others hit the real spamcop servers where there would be a no response thereby indicating it was not a spam server.
 
Last edited:
Maybe you re-read what I wrote? I wasn't talking about exim.variables.conf like you but about exim.STRINGS.conf.custom.

I don't need to re-read what you wrote and I stay with my answer.
You have an odd configuration. Spamcop -is- listed in exim.conf and is not present in exim.variables.conf als you declare.
I am working with exim.strings.conf.custom for years with this and it's working.

So you have probably an older exim.conf or some other reason why it was not working with you.

FYI:
Code: 
[root@server23: /etc]# grep -rli "bl.spamcop.net" /etc
/etc/exim.conf
/etc/exim.strings.conf.custom
/etc/csf/csf.rblconf
and I've not update exim.conf and put it myself in exim.strings.conf.custom.
 
It didn't affect me at all since I don't block spam and now I am very glad I don't.
 
Well... I have the same with spamhaus, which was blocking all my mail because it was looking at ISP ip it was send from instead of server ip the mail was send through via smtp. And lots of other false flagged positives. Which was the reason I started using the exim.strings.conf.custom in the first place. To exclude the spamhaus list. ;)

Do you have better ones? I use barracuda, spamcop and abuseat, but improvement is always nice.
 
Richard G said:
Maybe you re-read what I wrote? I wasn't talking about exim.variables.conf like you but about exim.STRINGS.conf.custom.

I don't need to re-read what you wrote and I stay with my answer.
You have an odd configuration. Spamcop -is- listed in exim.conf and is not present in exim.variables.conf als you declare.
I am working with exim.strings.conf.custom for years with this and it's working.

So you have probably an older exim.conf or some other reason why it was not working with you.

FYI:
Code: 
[root@server23: /etc]# grep -rli "bl.spamcop.net" /etc
/etc/exim.conf
/etc/exim.strings.conf.custom
/etc/csf/csf.rblconf
and I've not update exim.conf and put it myself in exim.strings.conf.custom.
Click to expand...
root@server:~ # grep -rli "bl.spamcop.net" /etc
/etc/exim.conf
/etc/exim.variables.conf
/etc/exim.variables.conf.custom

My files were from 11/25/2018.
- I have the /etc/exim.strings.conf but of course it has only strings in it. I know you can do more with *.custom by reference by I wasn't using it.
- I have no /etc/csf

I'm on the FreeBSD version. I'll probably update and sort things out with some newer files because the configs from back then didn't exactly work right. I've settled on and have been using:
RBL_DNS_LIST==\
cbl.abuseat.org : \
bl.spamcop.net : \
b.barracudacentral.org
Which has worked perfectly until this happened. My initial reaction is to dump spamcop.net, but it has been good until today, so I need to cool down so I don't cut off my nose to spite my face. The former crew at CISCO are probably working on their resumes as we speak. I went through RBLs about 18 months ago, and found these to be common denominators for spam appliances. Yes, Barracuda makes appliances too, but I mean appliances that are not barracuda have them as one of their defaults.

The problem with spam is one man's junk is another man's treasure, so I've been using sa-learn/teach-isspam/teach-isnotspam method. It's about phychic after a little training but every user dictates for all virtual users so I normally tell one person how to use it. I've set up both POP3 and IMAP on the same desktop client when desired so when ham comes in they can copy to teach-isnotspam and for spam drag to teach-isspam, and the every 5 minute cron will clean feed sa-learn and clean out the folder.
 
Last edited:
You must log in or register to reply here.
Back
Top