Relayed mails with PMG get +2.0 score due "Delivered to internal network by a host with no rDNS"

[jmjosebest]

Hi, I use PMG as a relay to filter SPAM in outgoing emails.
The problem is that the emails are sent with the header:

Received: from relay.xxx.com (localhost.localdomain [127.0.0.1])
   by relay.xxx.com (Proxmox) with ESMTP id CDDC12130A
   for <info@yyy.yyy>; Tue,  3 Jul 2018 11:24:48 +0200 (CEST)

And this causes the recipient that has the rule: RDNS_NONE to generate a score of +2.0 and is very likely to consider it as SPAM.

 Content analysis details:   (3.5 points, 3.0 required)

  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
  1.3 HTML_IMAGE_ONLY_24     BODY: HTML: images with 2000-2400 bytes of words
  0.0 HTML_MESSAGE           BODY: HTML included in message
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from author's
                            domain
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily valid
  0.3 HTML_SHORT_LINK_IMG_3  HTML is very short with a linked image
  2.0 RDNS_NONE              Delivered to internal network by a host with no rDNS
  0.0 T_REMOTE_IMAGE         Message contains an external image
X-Spam-Flag: YES

How can we define for the relay to use the server's main IP instead of 127.0.0.1 ?

Thanks!

 

[heutger]

Please check the full log, I'm afraid, it's not because of localhost (127.0.0.1) as this received header may come from the content_filter setup of spamassassin in PMG. I don't use outgoing spam checking, but if your mails are filtered through PMG, they are usually going like this:

sending server (you deliver your outgoing mails to via smtp-auth, submission, ...)
PMG postfix server on port 26 getting mails from the sending server, which uses PMG as smarthost/relayhost
PMG then delivers the mail then to the pmg-smtp-filter which includes spamassassin via localhost (127.0.0.1), so called after-queue
PMG then sends the mail out to the destination server

That's why you have this received header in the mail, but if everything works fine, the spamassassin will check the recent host, the mail came from, so your sending server, and this one seems not to provide a rDNS record. So please check your header data for the entries just before the one, you copied above.

So e.g. incoming is like this:

Received: from pmg.xxx.xxx (pmg.xxx.xxx [1.2.3.4])
 by server.xxx.xxx (Postfix) with ESMTPS id 2AE887C1DE
 for <xxx@xxx.xxx>; Tue,  3 Jul 2018 05:33:00 +0200 (CEST)
Received: from pmg.xxx.xxx (localhost.localdomain [127.0.0.1])
 by pmg.xxx.xxx (Proxmox) with ESMTP id 04AF7411EF
 for <xxx@xxx.xxx>; Tue,  3 Jul 2018 05:33:00 +0200 (CEST) => this header is written by pmg-smtp-filter
Received: from outside.domain.tld (outside.domain.tld [4.3.2.1])
 by pmg.xxx.xxx (Proxmox) with ESMTP id 10810402DD
 for <xxx@xxx.xxx>; Tue,  3 Jul 2018 05:32:47 +0200 (CEST)

Outgoing it should look similar, just flipped order. server.xxx.xxx is your smtp server, pmg.xxx.xxx is PMG, outside.domain.tld is the outside server, you try to reach.

 

[jmjosebest]

Thanks for your reply!

The 127.0.0.1 Is the only IP without rDNS record.
Both IPs used in the original sender and the relay have a rDNS records correctly configured.
Also is the only private IP, both other are public.

You can check here full headers: removed link

Thanks!

 

[heutger]

Hi,

hmm, your paste shows me some problems:

1. you seem to run PMG with a provider provided nameserver, so your URIBL check has been blocked (URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information)
2. there are two missing rDNS or more concrete: two rDNS records are not been able to be fetched:
a) Received: from [2a03:c7c0:1:1a::] (port=42380 helo=cli.ginernet.com) (and this IPv6 has no rDNS)
b) Received: from [188.213.5.77] (port=43802 helo=relay.ginernet.com) is not resolvable by vps.skatie.es. I see the reverse record, but the VPS resolver seems to have problems to get the record, as it does not state any hostname, just the IP. Maybe you should check vps.skatie.es mail server log, it may contain "unknown client hostname" here. Then you need to check the resolver used there. As that's the system, which delivers to vps.skatie.es, which is performing the additional spamassassin check and showing the rDNS score, it's only important, who is delivering to this one, the chain before rDNS does not take care of. It's different on blacklist checking, if you don't use -lastexternal in SpamAssassin, but rDNS just looks for the last hop before.

For the first problem see my thread advancing PMG, I recommend to install unbound, it's faster and more reliable than bind, in my commercial test setup, I had many problems with bind. Maybe your PMG is behind a firewall/UTM/... or sth. similar which may provide it's own resolver (still should not forward to public DNS servers but use the root servers itself to get the TLDs and then the domain zone files), then it's for sure better to use this one.

 

[jmjosebest]

Again, thank you very much for your answer

It is true that IPv6 ending in ::0 have some problems depending the RDNS service that you use to query. I tried to change it by :: 1 and the result was the same. Now I have completely disabled IPv6 and the result is the same.

I have also tested the PTR resolution on the server that receives the e-mail and it is ok.

The URIBL problem I think has no relation to my question, but we can analyze it to solve it personally at another time.

Please, check the logs: https://pastebin.com/3RPHV4hg

Thanks!!

 

[heutger]

I'm sorry, but I don't know too much of how exim logs look like, I'm just confused, that the first entry has no hostname in front of the IP, but with connection close, there is a hostname. Maybe you should compare with other entries, where rDNS score is not given. Alternative, you may send an e-mail to me, so I could send you, what my system is telling about the mail. My address is my first name at my last name (which is my profile name here) dot net.

Regards,
Christian

 

[jmjosebest]

Maybe you should compare with other entries, where rDNS score is not given. Alternative, you may send an e-mail to me, so I could send you, what my system is telling about the mail.

Mail sent, but the recipient's server is cPanel, so we are talking about millions of e-mail accounts in the world that have this filter.

By this I mean that even if your system does not include this rule it does not have to be a reference.

Is it really impossible to change the private IP and put the public IP of the PMG?

 

[heutger]

I don't believe the mistake is in the in cPanel integrated SpamAssassin setup but in problems with rDNS record.

So your problem is about the 127.0.0.1 in the headers or about the IP, PMG is delivering to you? As the IP looks public, I believe you're claiming about 127.0.0.1. You could for sure change, but I don't believe, it's the problem. You could copy the templates (look manual for pmg templates copying and syncing) and adjust main.cf as well as master.cf then instead of using 127.0.0.1 to your public IP and need to adjust pmg-smtp-filter not to listen any more on 127.0.0.1:10023/10024 but on your public IP.

However, I won't believe, this would solve your problem. If you like to, you could add one of my domains I currently don't really use for mails to your cPanel and I could change my transport to forward such mails to your cPanel system, maybe we could check, if there is something wrong with your PMG system. However, this could not solve problems, the cPanel server may have. As mentioned, I'm unsure, if the problem really occures on PMG.

https://wiki.apache.org/spamassassin/Rules/RDNS_NONE states "This test checks to see if there is a PTR record (reverse DNS) for the last untrusted relay, which points to a domain with a matching A record.", so the 127.0.0.1 record is not(!) the last untrusted relay before reaching your VPS.

Ups, by reading the link above, just follow the next sentence! "The name is a little confusing, because it's Forward Confirmed reverse DNS that we're looking for, not just any PTR record." It's no solely rDNS check, it's a FCrDNS check, and now I found your problem. 188.213.5.77 resolves to relay.ginernet.com but relay.ginernet.com does not resolve to 188.213.5.77 but 5.134.116.177. That's why I changed in my advancing PMG thread for the commercial test setup from reject_unknown_client_hostname (which is the same FCrDNS check) to reject_unknown_reverse_client_hostname (which is just the PTR check), as that may happen much more often as expected and although it's an administrators mistake, I still prefer some spam instead of walking the hard way.