On 18 Mar 2021, at 18:34, Antonio Leding wrote:
Hello all,
#### 1. Where to place IPBL\DNSBL rules
* Because the result of a hit against an IPBL\DNSBL is to REJECT, does
it make sense to place these kind of rules earlier in the
SMTPD_RESTRICTIONS eval chain (i.e. CLIENT) rather than later (i.e.
RECIPIENT) as shown in the _Getting selective with SMTP access
restriction lists_ section of the SMTPD_ACCESS_README document.
That depends on what you want to achieve, how strongly you trust the
lists you use, and how much flexibility in exemption from lists you want
to have.
#### 2. Making hits against an IPBL\DNSBL advisory
* Will using **warn_if_reject** essentially just log, rather than
REJECT, when an entry hits an IPBL\DNSBL?
That's what the documentation says, and I have no reason to doubt it.
* If so, does this apply to **(a)** the entire set of restrictions;
**(b)** just the restriction list where cfg’d; **(c)** only the
restriction that immediately follows **warn_if_reject**?
As I read the postconf(5) man page and SMTPD_ACCESS_README, it is a
prefix for a single restriction directive: "c"
HOWEVER, "b" would not be a totally unreasonable implementation or
reading of the docs, so I could be wrong.
It would be silly and almost useless to implement "a" and I believe the
documentation clearly limits the context to AT MOST the current
restriction list.
* If “C”, then can **warn_if_reject** be safely used in production
(manpage indicates this is a “safety net for testing”)?
Yes. That phrase probably should be “safety net for testing in
production” because that's really the only way most people can test
any mail config: on a real mail stream. The discussion and example in
ADDRESS_VERIFICATION_README implies use for testing against a real mail
stream.
* The reason I ask is, due to a large number of false positives, I
would like to have any hits against Spamcop be advisory rather than
dropping the conversation.
You should have opened with that :)
Put "warn_if_reject reject_rbl_client bl.spamcop.net=127.0.0.2" in the
smtpd_client_restrictions. If you have other directives in that list,
take care with the ordering of the list to make sure you check clients
you want to check and skip those you want to skip.
An alternative approach for DNSBLs that intermittently list mixed
ham/spam sources (which IME is the only significant problem with
SpamCop) is to use them in a scoring model, e.g. postscreen or a complex
filter like SpamAssassin.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
