On 12/23/20 1:01 PM, Dave Funk wrote:
That may not work for what the OP wanted.
O.o?
Because it's assumed that DNS related stuff may take some time those rules (if configured to run) are launched early in the processing of a message.So if the OP wants to completely avoid running RBL checks (as opposed to just ignoring their scores/results) he may need to do some special tricks.
Yes, I want to completely avoid running the RBL checks for specific recipients.
One thing would be to have a separate SA instance with its own configuration which has the RBL stuff removed and then configure his MTA to select that particular SA filter when the special user address is detected.
Oy vey. That sounds more complicated than I was hoping for.
This begs the question, what is the need to completely avoid running RBL checks for that special recipient?
Fair question.I have about 2,000 messages a day that come in to my mail server for all recipients with the exception of one specific (set of) recipient(s). That (set of) recipient(s) receive 20,000 - 30,000 messages a day. They are very specific messages for an automated communications system and they don't need any spam filtering, specifically RBL filtering. (It's a matrix of about 20 different such parties sending between each other across the internet.)
I'm looking at implementing a new RBL from a service provider that offers a free tier of about 5,000 queries a day. My personal messages are way under that limit. The particular (set of) address(es) that I want to bypass RBL tests are way over that limit. So I would like to bypass the RBL tests for that specific (set of) address(es).
What is supposed to happen when a message comes in that is addressed to multiple recipients, including the special recipient?
That is a fair question. I think that it's exceptionally unlikely that the address(es) that I'm wanting to exclude co-mingling like you are asking about. If that does happen, I think it's rare enough that I don't care what happens. I would prefer that it not be filtered, but I expect the frequency would be low enough as to not push past the daily limit.
This could get messy.
Indeed. -- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature