[Exim order issue] The bad_sender_hosts_ip does not work with cidr's?

[Richard G]

Oke I have a spammer with ip 103.198.26.117.

So I added the cidr to the /etc/virtualhost/bad_sender_hosts_ip as followed:
103.198.26.0/24
and reloaded Exim.

But it doesn't seem to get blocked, they use anoter domain on the same ip and this happens:

2022-10-22 23:54:47 1omMS5-0005rU-0N <= <> H=(e-storefront.co.uk) [103.198.26.117] P=esmtp S=17697 id=CUfDwc2zU3sEZA0FCxnuGkJ8c5dM7t84FwboX7pBGcahlNNs
2QMzbrG7LPQulzH3I00ERdPgJviUpqkV69Od1adzTb52KN7SOSMrE7h7QWMNBMmhb1Slb9yKJpvDg etc. IDSFWEFE.EUR
P193.PROD.OUTLOOK.COM T="Het is de perfecte tijd om te beginnen met Bitcoins" from <> for [email protected]

So it looks as if it send via outlook.com but the helo is clearly the ip mentioned.

Does the bad_sender_hosts_ip not block helo ip's?
Or what's wrong here?

 

[Swift-AU]

I would need to see your exim.conf to reason why the check has failed, but in the default config the CIDR you've added to bad_sender_hosts_ip should have blocked this host.

You can test the config by initiating a fake SMTP session with:

exim -bh 103.198.26.117
HELO e-storefront.co.uk
MAIL FROM:[email protected]
RCPT TO:[email protected]

After the RCPT TO command somewhere you should see the line:

check hosts = +bad_sender_hosts_ip

and a match (or not) on the IP address.

 

[Richard G]

Thank you for your answer @Swift-AU.

As for my exim.conf that is a default version 4.5.42. I never adjust my exim.conf file.

If I do the you provided (thank you), all goes fine until I use the RCPT TO command, then it will find the block and refuses the mail.

>>> host in "!+skip_rbl_hosts : !+skip_rbl_hosts_ip"? yes (end of list)
>>> check hosts = +bad_sender_hosts
>>> sender host name required, to match against nwildlsearch;/etc/virtual/bad_sender_hosts
>>> host in "nwildlsearch;/etc/virtual/bad_sender_hosts"? no (failed to find host name for 103.198.26.117)
>>> host in "+bad_sender_hosts"? no (end of list)
>>> deny: condition test failed in ACL "acl_check_recipient"
>>> processing "deny" (/etc/exim.conf 473)
>>>   message: 554 denied. 5.7.1 IP Blocked due to SPAM
>>> check hosts = +bad_sender_hosts_ip
>>> host in "/etc/virtual/bad_sender_hosts_ip"? yes (matched "103.198.26.0/24" in /etc/virtual/bad_sender_hosts_ip)
>>> host in "+bad_sender_hosts_ip"? yes (matched "+bad_sender_hosts_ip")
>>> deny: condition test succeeded in ACL "acl_check_recipient"
>>> end of ACL "acl_check_recipient": DENY
554 denied. 5.7.1 IP Blocked due to SPAM
LOG: H=(e-storefront.co.uk) [103.198.26.117] F=<[email protected]> rejected RCPT [email protected]: 554 denied. 5.7.1 IP Blocked due to SPAM

So that seems to work as designed.

Still makes me wonder why the mail could pass at 2022-10-22 23:54:47 as seen in the Exim log I posted, while the block was made already at 21.00 hours that day.

 

[Swift-AU]

So that seems to work as designed.

Still makes me wonder why the mail could pass at 2022-10-22 23:54:47 as seen in the Exim log I posted, while the block was made already at 21.00 hours that day.

Yup, that definitely looks like it's working now. I can't really imagine why it didn't work previously, being that you stated you reloaded exim after adding the IP address. You could possibly check your exim logs to make sure exim was actually restarted when you thought it was, e.g.

# grep -F "SIGHUP" /var/log/exim/mainlog

 

[Richard G]

It was a bit later, but indeed I did a restart before 23:54.

2022-10-22 22:22:11 pid 8131: SIGHUP received: re-exec daemon

So we tested and things should work according to the test.

Now be amazed again, that gbnetwork.my is spamming multiple customers on our server. Same ip again.

2022-10-25 13:10:46 1onHpT-0007ZK-0H <= <> H=(dcacinc.com) [103.198.26.117] P=esmtp S=37346 id=L2I1HNW04p3c4drZHvapvdslFB7rmyKFyvnEIDLbqSNF1YtR4qMyuMv
vhSggM7GzLGKmoG6rNbkhwPzH1n4gKjklVLBvankWpxCst33yDrwyW0Qjahy4Iv4uSL6gxxxxxxxxxxxxxxxxxxxxznFG79@VI1P193MB0590.EURP193.PROD.OUTLOOK.COM T="Spreek bijna
 elke taal in seconden, niet jaren!" from <> for [email protected]

Exactly the same ip as in the first post, tested that it should be blocked, and as you can see it's not blocked.
I'm getting very confused now.

Ofcourse I can block the ranges in the firewall, but that should not be necessery.

 

[Swift-AU]

Exactly the same ip as in the first post, tested that it should be blocked, and as you can see it's not blocked.
I'm getting very confused now.

Did you run the "exim -bh" test using the exact same HELO, sender e-mail address and recipient address that the spammer is using?

 

[Richard G]

using the exact same HELO, sender e-mail address and recipient address that the spammer is using?

No, because they constantly switch the sender e-mail address, but they use the same HELO ip.
Which is specifically why the bad_sender_hosts_ip is present, to block ip's sending mails, not sender e-mail addresses or recipient addresses, only ip's or ip ranges.

When looking at the test, that is exactly what happened and which should happen all the time.

As we can see from the test I did:

>>> host in "/etc/virtual/bad_sender_hosts_ip"? yes (matched "103.198.26.0/24" in /etc/virtual/bad_sender_hosts_ip)
>>> host in "+bad_sender_hosts_ip"? yes (matched "+bad_sender_hosts_ip")
>>> deny: condition test succeeded in ACL "acl_check_recipient"
>>> end of ACL "acl_check_recipient": DENY
554 denied. 5.7.1 IP Blocked due to SPAM

So it says IP blocked due the spam. IP is found in the bad_sender_hosts_ip, that is and should be the reason of blocking.

A bad_sender_hosts_ip file has totally no use if it won't block ip's.

Thank you for thinking with me on this anyway, I really appreciate that.

Maybe @mxroute has some clue what or if I'm doing something wrong? He's also a mail specialist.

 

[Richard G]

Just some guessing.

Could it be it's being bypassed because they send it via outlook.com or something, in spite of the fact that the helo is not from outlook?
I just rememberd that I got mail.protection.outlook.com in the whitelist_domains section because outlook was blocked a couple of times before.

Maybe that is causing the issue?

However, they are sending via PROD.OUTLOOK.COM, not via mail.protection.outlook.com. Hmmz..
40.92.0.0/15 is whitelisted too... that might be it maybe? Or not? Very confused at the moment.

 

[Swift-AU]

Just some guessing.

Could it be it's being bypassed because they send it via outlook.com or something, in spite of the fact that the helo is not from outlook?
I just rememberd that I got mail.protection.outlook.com in the whitelist_domains section because outlook was blocked a couple of times before.

Yes, essentially what I was getting at was that it's likely getting accepted based on some criteria, before it gets to the check for bad_sender_hosts_ip.

If it's being whitelisted by one of the user defined whitelists, it should mention that the message has been whitelisted in the exim log. If you do a grep or exigrep on the exim message id, do you see any other detail? e.g.

# exigrep 1onHpT-0007ZK-0H /var/log/exim/mainlog

 

[Richard G]

If you do a grep or exigrep on the exim message id, do you see any other detail? e.g.

I don't really see some whitelisting mentioned. The one today went to a customer of mine which is also a good friend.

This is the result of the command, I only masked the customers e-mail address:

root@server23:# exigrep 1onHpT-0007ZK-0H /var/log/exim/mainlog
2022-10-25 13:10:46 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1onHpT-0007ZK-0H

2022-10-25 13:10:46 1onHpT-0007ZK-0H <= <> H=(dcacinc.com) [103.198.26.117] P=esmtp S=37346 id=L2I1HNW04p3c4drZHvapvdslFB7rmyKFyvnEIDLbqSNF1YtR4qMyuMvvhSggM7GzLGKmoG6rNbkhwPzH1n4gKjklVLBvankWpxCst33yDrwyW0Qjahy4Iv4uSL6g6ia2Q7Xf1HVSRNngiJHqznFG79@VI1P193MB0590.EURP193.PROD.OUTLOOK.COM T="Spreek bijna elke taal in seconden, niet jaren!" from <> for [email protected]
2022-10-25 13:10:46 1onHpT-0007ZK-0H => friend <[email protected]> F=<> R=virtual_user T=dovecot_lmtp_udp S=38397 C="250 2.0.0 <[email protected]> YdgeJzbEV2NtbgAAursqdw Saved"
2022-10-25 13:10:46 1onHpT-0007ZK-0H Completed

 

[Swift-AU]

Ok, I've worked it out. The issue is that the spammer is not setting an envelope from address (shown as <> in the exim logs), which is what a mail server would do if it was sending a bounce message. Of course in this case we know it's really spam, and not a bounce. The reason that it's not getting blocked by bad_sender_hosts_ip is that exim is accepting bounce messages to domains that exist on your system, before it processes the bad_sender_hosts_ip. If you wish to change this behavior, you'll have to edit /etc/exim.conf as follows. Firstly find the following lines:

 # Remaining Mailer-Daemon messages must be for us
    accept senders = :
           domains = +relay_domains

and then cut and paste them to below the following:

#EDIT#34:
    deny message = 554 denied. 5.7.1 BLOCKED_DUE_TO_SPAM_IP
       hosts = +bad_sender_hosts_ip

Reload Exim and you'll be in business!

I might ping DA staff to see whether they want to consider moving this test further down the chain, because I can't see the reason to accept such messages from hosts that you want nothing to do with!

 

[Swift-AU]

Also incidentally, the IP address in question (103.198.26.117) is already on the spamhaus RBL, so if you move the code I mentioned above to BELOW the RBL checks, mail from 103.198.26.117 would be automatically blocked without you having to touch bad_sender_hosts_ip.

 

[Swift-AU]

I might ping DA staff to see whether they want to consider moving this test further down the chain, because I can't see the reason to accept such messages from hosts that you want nothing to do with!

Lol, I tried to send them the suggestion via the ticket interface, but they're not interested unless I purchase a support subscription

 

[Richard G]

@Swift-AU You're great! Fantastic you found that. I've seen indeed that they used that <> in the header. But didn't think of it that the system would see that as a bounce message.

However, in that case something else isn't working correctly. Because I've setup Exim to not include the full message in a bounce message.
I created a file /etc/exim.variables.conf.custom with this content:

bounce_return_message = false

or does this only work if the systeem can find out that the message originated from my own server?

As for the Spamhaus, they might be on there because I reported them to Spamcop every time or maybe they were on there before. However, we don't use Spamhaus anymore because they created false positives too many times, by checking the originating sender ip if I say it correctly, so the internet ip of the home user, instead of the ip of the server the home user used to send the mail.
Example.
My ip is (faked it) 84.30.22.21. In fact dynamic so like most dynamic ip's present in Spamhaus.
I send via my domain name on my server. So the mailserver on my server ip 123.45.67.89 will be sending the mail.
I had numerous times that Spamhaus blocked that mail (also incoming from other people) because it sees the 84.30.22.21 and seen that as sending ip, which is blocked due to dynamic, so mail was seen as spam and not delivered.
That happens once too much, so change zen.spamhaus.org to another part, happened again and then I threw Spamhaus out of the system.

As for the ticket... yes indeed. Must be possible some way to put in a bug report that way, but indeed, this is a know problem.
I'll try to tag somebody here on the forum, otherwise I might send them a mail.

I won't put this too solved yet, so I won't give the impression it's solved yet, because exim.conf needs changing.

@fln or @smtalk Can you please have al ook and see if you can change the order of the above in the Exim.conf so spammers can't abuse this method anymore?

 

[Swift-AU]

@Swift-AU You're great! Fantastic you found that

Interestingly I checked my own mail server logs and found 5 entries from the same IP address you originally listed, and noticed also that the spam had also been accepted by my system. So I wasn't going to stop until I figured out what was happening!

However, in that case something else isn't working correctly. Because I've setup Exim to not include the full message in a bounce message.

That's not related, in that it's simply used to determine whether your system will include the original message when it sends a bounce message back to a host.

I send via my domain name on my server. So the mailserver on my server ip 123.45.67.89 will be sending the mail.
I had numerous times that Spamhaus blocked that mail (also incoming from other people) because it sees the 84.30.22.21 and seen that as sending ip, which is blocked due to dynamic, so mail was seen as spam and not delivered.

That not actually the case, as the RBL's are used to block whatever IP address is connecting to your server to send the mail (it doesn't look at the mail content to get the originating IP address or suchlike). Normally end users (on their dynamically assigned ISP IP addresses) would not (and should not) be connecting directly to your server to send e-mail (unless they have domains hosted on your server), but would send the e-mail through the mail server of their ISP, which would then forward it to your server. Your server (and the RBL) would therefore use the IP address of the intermediate mail server when checking for spammers, and not the IP address of the person who sent the message. I've almost never had a false positive from zen.spamhaus.org, and if you're using DNS whitelists (which contain addresses of legitimate mail servers which should never be blocked) in combination with the RBLs, you can get as close to 0% false positives as practical.

 

[Richard G]

Normally end users (on their dynamically assigned ISP IP addresses) would not (and should not) be connecting directly to your server to send e-mail (unless they have domains hosted on your server),

Fully agree with this. But this was the case. I even experienced my own mail from my own domain resided on the server, blocked by Spamhaus because of the fact that my ip address was dynamic.
So no it should not be blocked indeed as you also say. But it was.
Which was the last drop for me to decide to kick out Spamhaus from my servers. However I also had some other false positives.

The situation you are describing in which blocking should take place, is relaying if I'm not mistaken. And I never had my servers being open relays.
So I was really wondered as to why Spamhaus used the dynamically assigned ISP ip address to block. Pity I don't have the logs anymore.

and if you're using DNS whitelists

I use one of them, which I also see occuring in the Exim mainlog. That is the list.dnswl.org list.

I'm really prepared to use zen.spamhaus.org again to test out and see what happens and if it happens again.

Interestingly I checked my own mail server logs and found 5 entries from the same IP address you originally listed, and noticed also that the spam had also been accepted by my system.

Aha... that's interesting indeed. Prooves to me that this provider is a spamming provider. I also had spam from another ip from the same provider.
And after reporting spam via Spamcop (which also sends the report to the concerned provider), spam suddenly raised.

 

[Swift-AU]

I'm really prepared to use zen.spamhaus.org again to test out and see what happens and if it happens again.

I definitely recommend doing so, and post back here in the forums if you believe it's blocking something it shouldn't be. spamhaus zen blocks about 95% of spam on my system -- it's really the single most effective spam control measure available.

On a related note I recently tried the default DirectAdmin config with blockcracking/easy spam fighter/spamassassin (rspamd) etc, and found it to be totally useless. So much faffing about, and at the end of the day it was marking things as spam that clearly weren't, and letting through more spam than my own setup which relies almost entirely on DNS whitelists/blacklists and my own greylisting system. Keep It Simple Simon!

I use one of them, which I also see occuring in the Exim mainlog. That is the list.dnswl.org list.

There's another one from hostkarma which is quite good (and definitely required if you're using hostkarma's blacklists)

Aha... that's interesting indeed. Prooves to me that this provider is a spamming provider. I also had spam from another ip from the same provider.
And after reporting spam via Spamcop (which also sends the report to the concerned provider), spam suddenly raised.

It may or may not have been a coincidence that the increase in spam happened after reporting it, but what I consistently find is that if your system is weak on rejecting spam, spam levels (from everywhere) will massively increase. In other words, once you are known to be an easy target, you WILL BE TARGETED.

 

[Richard G]

and found it to be totally useless.

Hmmz... odd, because I have my own RBL's which I use, inclusing Spamcop and made a small adjustment to ESF, but don't see any false negatives really. Those RBL's already stop most of the spam.
However that can also be because we don't have high volume mail systems on the servers, it's quite minimal.

There's another one from hostkarma which is quite good (and definitely required if you're using hostkarma's blacklists)

I don't use hostkarma's blacklist. Can't find a hostkarma whitelist either that quick. Also their site (junkemailfilter) does not use https, which normally gives me less trust in sites, because professionals can easily use LE. So maybe that's why I didn't try them yet.
However most spam is already filtered out, it's only once a while something is coming through.

In other words, once you are known to be an easy target, you WILL BE TARGETED.

Yep, I experienced that too in the beginning when my protection was less good. And instantly if some account is hacked and it's possible to send mail via some script, you see ip's of all kind of country's diving on it and spamming. Or at least trying, got good limits nowadays.

Anyway, I'm going to put in the zen spamhaus on 1 server now and then see what happens.

 

[johannes]

@Swift-AU please do yuo have maybe a link to hostkarma dns whitelist? thank you
@Richard G I had zen spamhaus dropped too because of false positives, am interested what yo`ll get now. Btw - may I ask, if its there an advantage to use bad_sender_hosts_ip over csf ip deny list? Is it faster? Whats about amount of possible ranges, where it will slow down, anything known? Thank you!

 

[Swift-AU]

please do yuo have maybe a link to hostkarma dns whitelist? thank you

Edit #36 in the default exim.conf shipped with DA already includes the hostkarma whitelist, so you only need to uncomment it.

#EDIT#36:
   accept domains = +local_domains
          dnslists = hostkarma.junkemailfilter.com=127.0.0.1
          logwrite = $sender_host_address whitelisted in hostkarma.junkemailfilter.com

Having said that, personally I add this whitelist to the conditions for the RBL, and also include the hostkarma yellowlist, which is hosts that have sent both spam and ham, and therefore should not be blocked unless you are OK with some false positives. An example based on the default DA exim.conf is below.

#  deny message = RBL_BLOCKED_BY_LIST
       hosts    = !+relay_hosts
       domains = +use_rbl_domains
       domains = !+skip_rbl_domains
       hosts = !+skip_rbl_hosts : !+skip_rbl_hosts_ip
       !authenticated = *
       !dnslists = hostkarma.junkemailfilter.com=127.0.0.1,127.0.0.3 
       dnslists = RBL_DNS_LIST

I hope that helps!