Quantcast

domain bl

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

domain bl

richard lucassen
I just added dbl.spamhaus.org:

smtpd_sender_restrictions =
  reject_non_fqdn_sender
  reject_unknown_sender_domain
  reject_rhsbl_sender dbl.spamhaus.org
  [...further checks...]

This works fine. But if mail is sent from an ip which was already in the
postscreen cache database before activating the DBL check, the DBL check
is skipped, although this DBL check is made at the next hop AFAIUI.
Removing the ip from the cache makes the DBL check work again for that
particular ip.

Is this behaviour correct or did I make a config error somewhere?

R.

--
richard lucassen
http://contact.xaq.nl/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: domain bl

Noel Jones-2
On 5/19/2017 8:55 AM, richard lucassen wrote:

> I just added dbl.spamhaus.org:
>
> smtpd_sender_restrictions =
>   reject_non_fqdn_sender
>   reject_unknown_sender_domain
>   reject_rhsbl_sender dbl.spamhaus.org
>   [...further checks...]
>
> This works fine. But if mail is sent from an ip which was already in the
> postscreen cache database before activating the DBL check, the DBL check
> is skipped, although this DBL check is made at the next hop AFAIUI.
> Removing the ip from the cache makes the DBL check work again for that
> particular ip.
>
> Is this behaviour correct or did I make a config error somewhere?
>
> R.
>

There may be a problem, but it seems to me your analysis is flawed.

reject_rhsbl_sender operates on the MAIL FROM domain name, not an IP
address.

Postscreen tests and its cache are independent of
smtpd_*_restrictions, and postscreen operates only on the client IP
address.

There is some interaction between IP-based dnsbl lookups,
postscreen, and the DNS cache.  Freshly-listed IPs may get a brief
pass until the DNS cache refreshes, and subject to
postscreen_dnsbl_{min,max}_ttl settings.  Note this only affects IP
based "dnsbl" lookups, never domain name "rhsbl" lookups.

For further help, please show "postconf -nf" output, and logging
demonstrating the problem.




  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: domain bl

Wietse Venema
In reply to this post by richard lucassen
richard lucassen:
> I just added dbl.spamhaus.org:
>
> smtpd_sender_restrictions =
>   reject_non_fqdn_sender
>   reject_unknown_sender_domain
>   reject_rhsbl_sender dbl.spamhaus.org
>   [...further checks...]

that is a setting for smtpd(8)

> This works fine. But if mail is sent from an ip which was already in the
> postscreen cache database before activating the DBL check, the DBL check

Thew postscreen cache does not disable checks in smtpd.

        Wietser
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: domain bl [closed]

richard lucassen
On Fri, 19 May 2017 12:27:23 -0400 (EDT)
[hidden email] (Wietse Venema) wrote:

> > I just added dbl.spamhaus.org:
> >
> > smtpd_sender_restrictions =
> >   reject_non_fqdn_sender
> >   reject_unknown_sender_domain
> >   reject_rhsbl_sender dbl.spamhaus.org
> >   [...further checks...]
>
> that is a setting for smtpd(8)

That is just the reason I was wondering why these blacklisted domains
still pass.

> > This works fine. But if mail is sent from an ip which was already
> > in the postscreen cache database before activating the DBL check,
> > the DBL check
>
> Thew postscreen cache does not disable checks in smtpd.

The only thing I can think about is that a domain is not yet
on the DBL, spamassassin rejects the mail with a 5xx, the mail is in the
queue because the sender is unreachable, and meanwhile the domain was
added to the DBL. Hmmm, and now that I'm writing this I will have to
check why smtpd does not apply a 5xx reject if the next hop (amavis) is
generating a 5xx code.

Anyway, there is no blame on Postfix: doing some checks using "swaks"
things work as expected.

R.

--
richard lucassen
http://contact.xaq.nl/
Loading...