[RPZ] RPZ and MX

[Vernon Schryver]

> To: Vernon Schryver <vjs at rhyolite.com>
> cc: dnsrpz-interest at lists.isc.org
> From: John Hascall <john at iastate.edu>

> Actually, in our case our central mail servers are using the
> main (RPZ-filtered) DNS servers.  I will converse with the mail
> team to see if the right approach is to point them at an
> unfiltered DNS server.  Thanks.

Differing flavors of RPZ zones are available.  Some are intended to
protect browsers from malware.  Others are intended to stop spam.
It's clear why one might sometimes want to be able to send mail to
some organizations that are hosting infectious web pages.  I guess one
might also want to be able to send mail to blacklisted sources of spam,
but those seem less common.

According to the spam rules of engagement that I follow, if you qualify
for a mail blacklist that I use, then I don't want any mail from you
whether arguing about my blacklists, your good intentions, stellar
reputation, or anything else.  Besides, basic politeness dictates that
if you can't send me mail, then I must not send you any mail.
(Of course, non-delivery reports don't count, because NDRs must be
handled during the original SMTP transaction.  Otherwise one is likely
to be hitting innocent forged senders with bounces and getting oneself
blacklisted.)

RPZ can be cheaper in network bandwidth and CPU cycles for all
concerned than checking DNSBLs for spam filtering.  RPZ spam filtering
can also be more effective than simple DNSBLs because you can easily
filter based DNS server IP address instead of waiting for the lastest
throw-away domain names to be listed.

In other words, I wonder if your central mail servers might want
their own BIND views with a subset of RPZ zones, perhaps NXDOMAIN
instead of walled garden RPZ results.

On the other hand, the simple ways to use RPZ for mail filtering don't
fit exempting some mailboxes from filtering.  There are other ways,
but they're probably not worth talking about.


Vernon Schryver    vjs at rhyolite.com