Spam after ESF update

Richard G

Richard G

Verified User
Joined
Jul 6, 2008
Messages
14,535
Location
Maastricht
With the latest Exim 4.90.1 there was also an ESF update.
Since then we're getting a higher amount of spam, so I investigated and then found this in one of the spam mails:
Code: 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
                             [score: 0.0000]
[b]  0.8 RDNS_NONE              Delivered to internal network by a host with no rDNS[/b]
033  SpamTally: Final spam score: -10

While in the variables.conf this is stated:
EASY_NO_REVERSE_IP = 100
and
EASY_FORWARD_CONFIRMED_RDNS = -10

So why is this spammer getting only a 0.8 score for rDNS instead of a +100?

Having this issue on 2 of 3 servers which are running ESF.
 
Hi guys,

If the lookup failed, you'd see this in the headers:
Code: 
ReverseDNS: No reverse DNS for mailserver at $sender_host_address, +100 Spam score

What you will see if the rDNS worked and the forward lookup of that result worked would be:
Code: 
Forward-Confirmed-ReverseDNS: Reverse and forward lookup success on 1.2.3.4, -10 Spam score
So if either of those 2 headers show up, then we'll know more about what exim is seeing.

The RDNS_NONE section is from SpamAssassin, not exim.. but in theory if there is no rDNS for SpamAssassin, there shouldn't be rDNS for ESF either.
But the -10 might be the Forward-Confirmed-ReverseDNS working.

Easiest way from that point is to login to ssh, and literally check to see if there is an rDNS to see which of the 2 is wrong, eg:
Code: 
dig -x 1.2.3.4
then do a normal dig on the resulting value that showed up to see if the A record shows up pointing to the same host.

Also worth checking /etc/resolv.conf and testing each IP:
https://help.directadmin.com/item.php?id=602

For what it's worth, we have a live production test box with all of the latest versions, but ESF 1.16 rDNS appears to be working on that box (CentOS 6 64-bit) based on the Forward-Confirmed-ReverseDNS header showing up.

John
 
Thank you for answering.

I have to wait to test the spam ip's because I can't find the "Delivered to internal network by a host with no rDNS" line in the logs. I'll then check the reverse DNS if I encounter this again.

However, I noticed something strange when doing the /etc/resolv.conf to check the ip's.
When checking 127.0.0.1 which is the first nameserver, I get 6 google ip's.
Code: 
google.com.             300     IN      A       64.233.164.139
and 5 others in the 64.233.164.xx segment.

When I check the second ip, being the nameserver we got from the datacenter, I get a completely different result.
Code: 
;; ANSWER SECTION:
google.com.             168     IN      A       172.217.16.206
and the second time I try this:
Code: 
;; ANSWER SECTION:
google.com.             142     IN      A       216.58.206.14
These ip's belong to Google, but it's odd that on my local dns server I get the answer with 6 ip's and on the datacenter nameserver I only get 1 ip, which also differs from network segment.
I don't know if this could cause any issues.

On the second server there is no difference, I get only 1 ip on localhost and datacenter nameserver, they differ but all are from google.

I don't have any DNS issues as far as I know, it's just strange to see that on my first server the localhost continuously finds 6 google ip's.
 
I use 127.0.0.1 as nameserver in resolv.conf. It seems to work fine:

root@srv2:/usr/local/directadmin/custombuild # dig A google.com @8.8.8.8

; <<>> DiG 9.12.0 <<>> A google.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56005
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com. IN A

;; ANSWER SECTION:
google.com. 299 IN A 216.58.206.174

;; Query time: 39 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Feb 21 23:30:57 EET 2018
;; MSG SIZE rcvd: 55

root@srv2:/usr/local/directadmin/custombuild # dig A google.com @127.0.0.1

; <<>> DiG 9.12.0 <<>> A google.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14081
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 4ce920356402ab8fe2ba4e425a8de516d5c15effd66a67f1 (good)
;; QUESTION SECTION:
;google.com. IN A

;; ANSWER SECTION:
google.com. 256 IN A 216.58.206.174

root@srv2:/usr/local/directadmin/custombuild # dig -x 216.58.206.174 @127.0.0.1

; <<>> DiG 9.12.0 <<>> -x 216.58.206.174 @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45470
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: d4a1d5edc89ad0aabffe58925a8de5439675fbddaa7fc4f7 (good)
;; QUESTION SECTION:
;174.206.58.216.in-addr.arpa. IN PTR

;; ANSWER SECTION:
174.206.58.216.in-addr.arpa. 86315 IN PTR sof02s27-in-f14.1e100.net.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Feb 21 23:31:47 EET 2018
;; MSG SIZE rcvd: 123
Click to expand...
 
I don't have that cookie stuff what you got. Did the same with this answer, but it looks fine though, or not?:
Code: 
 dig -x 216.58.206.174 @127.0.0.1

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.5 <<>> -x 216.58.206.174 @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33946
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;174.206.58.216.in-addr.arpa.   IN      PTR

;; ANSWER SECTION:
174.206.58.216.in-addr.arpa. 86400 IN   PTR     sof02s27-in-f14.1e100.net.

;; Query time: 51 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Feb 21 22:52:36 2018
;; MSG SIZE  rcvd: 84
 
Oke I got another one, now I tested this one:
Code: 
Return-path: <kao****[email protected]>
Received: from [149.56.205.76] (helo=broprints.com)
	by serverxx.mycompany.nl with esmtp (Exim 4.90_1)
	(envelope-from <kao****[email protected]>)
This is one of the spammers. The ip address 149.56.205.76 does not belong to the domani broprints.com where the helo is coming from.
So the helo domain has an rDNS, but it's spoofed as the ip does not belong to that domain, neither has this ip an MX address or rDNS.

Is this of any help?
 
Last edited:
broprints.com does not have an SPF record. So basically anyone can send from any IP without having any penalty for it.
 
Yes I know, but the issue here was that a score of +100 wasn't given for a missing rDNS. And broprints does have an rDNS, but the abusing sending ip does not.
So basically the mail should be refused with a +100 score, but it only get's a 0.8 or ESF is not doing it's job or something.
 
root@srv2:~ # dig -x 149.56.205.76

;; ANSWER SECTION:
76.205.56.149.in-addr.arpa. 53670 IN PTR 0004554.com.
 
Yes right, but that's not the rDNS for the helo name.
I thought the rDNS would be checked against the helo name and then the ip wouldn't match the rDNS record.
 
rDNS is only checked for the connecting IP. It has nothing to do with HELO name.

The connecting IP is looked up, eg: dig -x 1.2.3.4
That will return a PTR value, eg: server.domain.com.
Then a forward lookup is done on the server.domain.com that was returned from the rDNS PTR lookup.
If the server.domain.com A's record resolves to 1.2.3.4, then it a "forward confirmed reverse dns" pass.
rDNS and FCRDNS have nothing to do with the HELO value given to exim. It does often match the rdns, but it's not part of the rdns check.

John
 
Ah it's confusing but I think it's working as designed, just a matter of how you read this, the line by Spamassassin probably just reads the other way around like:
Code: 
  0.8 RDNS_NONE              Delivered to internal network by a host with no rDNS
since it's not delivered by a host with no rDNS, the score is only 0.8.

So if the ip did not have an rDNS, this would read (I presume) something like:
Code: 
 100.0 RDNS_NONE              Delivered to internal network by a host with no rDNS
and also ESF would put a line like:
Code: 
ReverseDNS: No reverse DNS for mailserver at $sender_host_address, +100 Spam score
Correct?
 
You must log in or register to reply here.
Back
Top