You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Yang Xiao <yx...@gmail.com> on 2004/11/11 22:11:34 UTC

DNSBL Question

Hi all,
I'm confused about the answer given in the FAQ on the website regards
to DNS settings

 Q: The dns-blocklists just don't appear to be used. What is going wrong?
...
A: Third, if your email gateway is behind a firewall make sure that
SpamAssassin is resolving the gateway to it's external address. If
SpamAssassin resolves the gateway to an private IP or can't resolve
the name at all, it may mark the sending system as a trusted relay. As
a result, some or all of the spammer's systems will not be checked
against the DNSBL. (I'm not aware of anyway to specify 'last trusted
relay' in SA).

What is this saying? if the SMTP gateway host SpamAssassin is running
on is behind the firewall and is NATed, whatever DNS server the SMTP
is using should resolve itself using it's NATed (Internet) IP address?

Can I just add a /etc/host entry using the Internet Address instead of
the DMZ address of the machine?

Thanks,

Yang

Re: DNSBL Question

Posted by Matt Kettler <mk...@evi-inc.com>.
At 04:11 PM 11/11/2004, Yang Xiao wrote:
>  Q: The dns-blocklists just don't appear to be used. What is going wrong?
>...
>A: Third, if your email gateway is behind a firewall make sure that
>SpamAssassin is resolving the gateway to it's external address. If
>SpamAssassin resolves the gateway to an private IP or can't resolve
>the name at all, it may mark the sending system as a trusted relay. As
>a result, some or all of the spammer's systems will not be checked
>against the DNSBL. (I'm not aware of anyway to specify 'last trusted
>relay' in SA).
>
>What is this saying? if the SMTP gateway host SpamAssassin is running
>on is behind the firewall and is NATed, whatever DNS server the SMTP
>is using should resolve itself using it's NATed (Internet) IP address?

Yes, OR you should manually set trusted_networks (generaly a better solution).

The problem lies in SA assumes that unless you set trusted_networks the 
first "by" server that resolves as a public IP in a received: chain is part 
of your network. If your email gateway resolves as a private IP, this means 
SA will "trust" an external mailserver that it should not.

For example, I have this problem. Xanadu is a nated mail gateway running 
SA, and sees itself as a 192.168.x.x IP address. I have had to hand set 
trusted networks:

#trust xanadu itself:
trusted_networks        192.168.x.x/32
#trust internal mailserver 10.y.y.y
trusted_networks        10.y.y.y/32

Other side effects of a mis-configured trust path are spam mails matching 
ALL_TRUSTED on 3.x