Re: Bypass RBL checks for specific address
On Wed, 23 Dec 2020, Grant Taylor wrote: On 12/23/20 9:55 PM, John Hardin wrote: Did you see my mention of this earlier? Yes, I did see it. That's a bit more invasive of a change than I was hoping to do for this task. I had been waiting to reply to your earlier message to test some things that you recommended. As you will see in my recent reply, I do believe that I've managed to achieve most of what I wanted to do. Good. I did notice from your earlier description that you (weakly) wanted to completely bypass SA scanning for those automated messages, which makes sense from a resource management perspective. The milter proxy would be the way to do that, as it would give you a way to bypass spamass-milter based on recipient (or more reliably sender + recipient). -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.org pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- "Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never does quite what I want. I wish Christopher Robin was here." -- Peter da Silva in a.s.r --- Tomorrow: Christmas
Re: Bypass RBL checks for specific address
On Wed, 23 Dec 2020, Grant Taylor wrote: On 12/23/20 2:15 PM, John Hardin wrote: spamass-milter has a -u flag for a username to pass to SA. If these are single-recipient messages that may be enough to reliably tie into per-user config to disable the RBL check. It seems as if spamass-milter is using the -u to specify a default user. It also seems as if spamass-milter will attempt to discover the (first) recipient if -x is also used. Spamass-milter will then use -u to pass the username default for first detected to spamc so that spamc can use personalized settings. Right. Sorry, I misworded my description a bit. I am fairly sure that setting a rule score to zero bypasses the rule (vs. running it and ignoring the result) but you will probably want to test that to confirm whether the RBL is checked anyways. However, if the RBL check is written as a subrule then it can't be disabled this way as subrules don't have scores to set to zero. ACK This matches my tests. Oh, good. Thanks for the confirmation. That last option sounds to me like the first one you should explore. Thankfully, and to my surprise, SpamAssassin / spamass-milter /is/ attempting personalization. "-u spamass-milter" was already in place. I added "-x" to cause spamass-milter to try to detect the first user, tweaked permissions (group membership) to allow spamass-milter to run sendmail -bv to detect some other users correctly, and now things seem to be working much closer to how I want. Initial testing seems very promising use of heavily modified ~/.spamassassin/user_prefs. Good news! -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.org pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- "Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never does quite what I want. I wish Christopher Robin was here." -- Peter da Silva in a.s.r --- Tomorrow: Christmas
Re: Bypass RBL checks for specific address
On 12/22/20 4:56 PM, Grant Taylor wrote: Is there a way to bypass RBL checks for a specific address? Thank you all. I believe I have been able to get the result I desired and learn a few things in the process. TL;DR: Setting scores to 0 in the specific recipient's ~/.spamassassin/user_prefs file worked. I learned that spamass-milter /does/ /apparently/ support personalization, something I wasn't aware of. I learned that adding the "-x" option to spamass-milter will cause it to use sendmail -bv to try to identify the Unix account that needs to be passed to spamc via (spamc's) "-u" option. I needed to tweak group membership so that the user spamass-milter ran as could read /etc/mail/virtusertable.db. Now, things seem to be working. spamd is setuid(ing) to the correct Unix user and reading the user_prefs file like I need. Thank you again for all your help. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: Bypass RBL checks for specific address
On 12/23/20 9:55 PM, John Hardin wrote: Did you see my mention of this earlier? Yes, I did see it. That's a bit more invasive of a change than I was hoping to do for this task. I had been waiting to reply to your earlier message to test some things that you recommended. As you will see in my recent reply, I do believe that I've managed to achieve most of what I wanted to do. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: Bypass RBL checks for specific address
On 12/23/20 2:15 PM, John Hardin wrote: spamass-milter has a -u flag for a username to pass to SA. If these are single-recipient messages that may be enough to reliably tie into per-user config to disable the RBL check. It seems as if spamass-milter is using the -u to specify a default user. It also seems as if spamass-milter will attempt to discover the (first) recipient if -x is also used. Spamass-milter will then use -u to pass the username default for first detected to spamc so that spamc can use personalized settings. I am fairly sure that setting a rule score to zero bypasses the rule (vs. running it and ignoring the result) but you will probably want to test that to confirm whether the RBL is checked anyways. However, if the RBL check is written as a subrule then it can't be disabled this way as subrules don't have scores to set to zero. ACK This matches my tests. That last option sounds to me like the first one you should explore. Thankfully, and to my surprise, SpamAssassin / spamass-milter /is/ attempting personalization. "-u spamass-milter" was already in place. I added "-x" to cause spamass-milter to try to detect the first user, tweaked permissions (group membership) to allow spamass-milter to run sendmail -bv to detect some other users correctly, and now things seem to be working much closer to how I want. Initial testing seems very promising use of heavily modified ~/.spamassassin/user_prefs. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: Bypass RBL checks for specific address
On Wed, 23 Dec 2020, Grant Taylor wrote: That's all considerably more complicated than I'm comfortable with at the moment. Did you see my mention of this earlier? https://milter-manager.osdn.jp/reference/introduction.html -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.org pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- "Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never does quite what I want. I wish Christopher Robin was here." -- Peter da Silva in a.s.r --- 2 days until Christmas
Re: Bypass RBL checks for specific address
On 12/23/20 2:21 PM, Bill Cole wrote: You definitely would know if it were. One would think. My head is in a different project at the moment, and I can't tell you exactly how things are configured without going back and looking. /If/ things are configured to load per user settings from files in the recipient's home directory, then things are looking up. I have not tested it, but I'm pretty sure that it actually disables the tests, as it does with any other type of rule. ACK -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: Bypass RBL checks for specific address
On 12/23/20 3:32 PM, Martin Gregorie wrote: - In my case I run every message through SA, diverting spam into a quarantine directory and passing the rest to Postfix for delivery. I don't quarantine anything on this system. Spam is tagged if the score is between 5 and 15. Spam is rejected /during/ the SMTP transaction if the score is 15 or higher. - In your case you want to pass mail, which is being sent to a small set of recipients on your server directly to your local MTA for delivery. The rest gets run through SA before being handed to your local MTA, again for local delivery. Email only passes through the local MTA one time. Sendmail is configured to interface with SpamAssassin via spamass-milter /during/ the SMTP transaction. No looping. This is also part of why I'm not 100% sure what user SpamAssassin is filtering the messages as. I don't know if it's currently configured as a single user that the daemons are running as -or- if it's somehow changing users to the recipient Unix account. I know that this particular system was never configured with SQL database for per-user settings. Which I think I needed to do the last time I did per-user settings. But that's been more than a decade ago. I quite certain that I did not explicitly did anything to enable per-user settings on this system. But I can't rule out some sort of option being default to look for per-user settings in home directories. The logic needed to do both tasks would seem to be essentially the same: read the names of all recipients that are NOT scanned by SA into a searchable no-scan recipients list. for every message received read the message into a buffer look up its recipient in the no-scan recipients list if the recipient is in the list pass the message on for delivery by writing it to stdout else pass the message to SA for markup as ham or spam via spamc i.e, pipe the buffer content into spamc's stdin channel receive the marked-up message back from spamc i.e. read spamc's stdout channel into a buffer fi pass the marked-up message to your MTA for delivery i.e write the buffer content to stdout clear the buffer end-for That's not how things work with the milter configuration. Assuming that you're using Postfix as your MTA, you just replace spamc in the Postfix process chain with a program that does the above. Nope. As indicated multiple places, Sendmail, not Postfix. In a little more detail: - This implies writing a program in C, Java or (possibly) Python or Perl. - if your list of no-filter recipients has more than about ten entries, consider using a B-tree to efficiently search the list. In C use bsearch() and in Java use a TreeMap - both are very fast. - the message buffer needs to be self-extending to match any received message. This is a no-brainer in Java (all Strings automatically resize to hold what is put in them, but needs a little more care if written in C because you don't know how big an incomming message is until you've read it. - this approach doesn't need any modifications to your existing SA configuration That's all considerably more complicated than I'm comfortable with at the moment. It also seems to target an MTA that I'm not running. I hope this gives you some useful ideas. Eh It's something to think about. But I think it's elephants when I'm talking about trees. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: Bypass RBL checks for specific address
On Wed, 23 Dec 2020 14:01:25 -0600 (CST) Dave Funk wrote: > 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. A couple of years ago some changes were made to support RBLS being short-circuited out. See bug 5930. I'm not sure whether those perl changes in trunk are essential for it to work or whether they just handle some special cases.
Re: Bypass RBL checks for specific address
On Wed, 2020-12-23 at 20:44 +0100, Benny Pedersen wrote: Fhis requirement is almost exactly rgew opposite of something I've been running for years: - In my case I run every message through SA, diverting spam into a quarantine directory and passing the rest to Postfix for delivery. - In your case you want to pass mail, which is being sent to a small set of recipients on your server directly to your local MTA for delivery. The rest gets run through SA before being handed to your local MTA, again for local delivery. The logic needed to do both tasks would seem to be essentially the same: read the names of all recipients that are NOT scanned by SA into a searchable no-scan recipients list. for every message received read the message into a buffer look up its recipient in the no-scan recipients list if the recipient is in the list pass the message on for delivery by writing it to stdout else pass the message to SA for markup as ham or spam via spamc i.e, pipe the buffer content into spamc's stdin channel receive the marked-up message back from spamc i.e. read spamc's stdout channel into a buffer fi pass the marked-up message to your MTA for delivery i.e write the buffer content to stdout clear the buffer end-for Assuming that you're using Postfix as your MTA, you just replace spamc in the Postfix process chain with a program that does the above. In a little more detail: - This implies writing a program in C, Java or (possibly) Python or Perl. - if your list of no-filter recipients has more than about ten entries, consider using a B-tree to efficiently search the list. In C use bsearch() and in Java use a TreeMap - both are very fast. - the message buffer needs to be self-extending to match any received message. This is a no-brainer in Java (all Strings automatically resize to hold what is put in them, but needs a little more care if written in C because you don't know how big an incomming message is until you've read it. - this approach doesn't need any modifications to your existing SA configuration I hope this gives you some useful ideas. Martin
Re: Bypass RBL checks for specific address
Bill Cole wrote: On 23 Dec 2020, at 13:57, Grant Taylor wrote: On 12/22/20 11:03 PM, Bill Cole wrote: Do you have a setup that supports per-user preferences? e.g.: real system accounts. Sort of. The recipient is a real Unix account. However I don't think my milter is configured to use per recipient filtering. You definitely would know if it were. If so, you can disable off individual rules for a user by giving them a score of 0 in ~/.spamassassin/user_prefs if they have a real account or in whatever you use for per-user prefs if they are virtual users. Would that truly disable the tests? Or does SpamAssassin still run the tests but ignore the result? I have not tested it, but I'm pretty sure that it actually disables the tests, as it does with any other type of rule. Only if you set the score to 0 on the rule that actually triggers the DNSBL call. Until recently(ish) this was the only way to selectively disable DNSBLs enabled by default in the stock rules. skip_rbl_checks or dns_available should work per-user by way of userprefs. dns_query_restriction has now been around for a few releases and makes it easier to be sure you've disabled all DNS lookups for a particular domain. -kgd
Re: Bypass RBL checks for specific address
On 23 Dec 2020, at 13:57, Grant Taylor wrote: On 12/22/20 11:03 PM, Bill Cole wrote: Do you have a setup that supports per-user preferences? e.g.: real system accounts. Sort of. The recipient is a real Unix account. However I don't think my milter is configured to use per recipient filtering. You definitely would know if it were. If so, you can disable off individual rules for a user by giving them a score of 0 in ~/.spamassassin/user_prefs if they have a real account or in whatever you use for per-user prefs if they are virtual users. Would that truly disable the tests? Or does SpamAssassin still run the tests but ignore the result? I have not tested it, but I'm pretty sure that it actually disables the tests, as it does with any other type of rule. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Bypass RBL checks for specific address
On Wed, 23 Dec 2020, Grant Taylor wrote: 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). spamass-milter has a -u flag for a username to pass to SA. If these are single-recipient messages that may be enough to reliably tie into per-user config to disable the RBL check. I am fairly sure that setting a rule score to zero bypasses the rule (vs. running it and ignoring the result) but you will probably want to test that to confirm whether the RBL is checked anyways. However, if the RBL check is written as a subrule then it can't be disabled this way as subrules don't have scores to set to zero. You may need to patch spamass-milter to add the ability to bypass specific recipient addresses to achieve this. This discussion and patch may help as a starting point: https://mail-index.netbsd.org/pkgsrc-users/2010/09/10/msg012736.html It looks like that patch might be already implemented in some distros. There appears to be a sendmail patch that adds the ability to control milter execution via sendmail rulesets: https://groups.google.com/g/comp.mail.sendmail/c/kPZtOXIclQ0 milter-rres at http://www.jmaimon.com/sendmail/#milter-rrres.v16 I don't know whether that patch is in current sendmail, but I don't have high hopes. The latest version (v16) on the author's site is from 2007 for sendmail 8.13 It looks like that this milter proxy would allow you to dynamically bypass spamass-milter based on recipient address without patching either sendmail or spamass-milter: https://milter-manager.osdn.jp/reference/introduction.html I don't have any familiarity with it, though. It is fairly current, last released in September 2019. That last option sounds to me like the first one you should explore. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.org pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- "Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never does quite what I want. I wish Christopher Robin was here." -- Peter da Silva in a.s.r --- 2 days until Christmas
Re: Bypass RBL checks for specific address
On 12/23/20 1:37 PM, Dave Funk wrote: If all you want is for a particular class of recipients (at the envelope RCPT level) not be passed to spamass-milter inside sendmail that can be done with a bit of hacking of your sendmail config and the milter. Please elaborate. I'm not opposed to reconfiguring Sendmail. Though I'd prefer to do it through macros and not need to create custom ruleset(s). I would prefer an option that does not require altering Sendmail's behavior /if/ it's possible to make SpanAssassin alter it's behavior. I run my own customized miltrassassin milter which has support for custom macros handed to it from sendmail and it takes special action based on what it gets handed. Yes, it's possible to pass different macros to different milter stages / action / check points / term???. But that's just data, and not in and of itself conditional. For example if the 'skip_check' is defined, the miter just returns a 'OK' and doesn't call SA at all. How are you conditionally passing that to a milter? Does that involve a custom rule set to put 'skip_check' in a macro based on the envelope recipient and not for other recipients? If the 'no_reject' macro is set then the milter will not generate a "550" SMTP status regardless of how high the SA score is. (needed for "postmaster" messages). Same question as above, save for 'no_reject' vs 'skip_check'. What version of sendmail are you using? 8.15.2 (It's an older Ubuntu install that is in need of an upgrade.) -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: Bypass RBL checks for specific address
On Wed, 23 Dec 2020, Grant Taylor wrote: Context is Sendmail, spamass-milter, and SpamAssassin (spamd). I didn't see any way to have spamass-milter bypass, much less conditionally bypass. Nor did I see a way to have Sendmail conditionally bypass a milter. If all you want is for a particular class of recipients (at the envelope RCPT level) not be passed to spamass-milter inside sendmail that can be done with a bit of hacking of your sendmail config and the milter. I run my own customized miltrassassin milter which has support for custom macros handed to it from sendmail and it takes special action based on what it gets handed. For example if the 'skip_check' is defined, the miter just returns a 'OK' and doesn't call SA at all. If the 'no_reject' macro is set then the milter will not generate a "550" SMTP status regardless of how high the SA score is. (needed for "postmaster" messages). What version of sendmail are you using? -- Dave Funk University of Iowa College of Engineering 319/335-5751 FAX: 319/384-05491256 Seamans Center, 103 S Capitol St. Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527 #include Better is not better, 'standard' is better. B{
Re: Bypass RBL checks for specific address
Dear Dave,The purpose of setting a priority higher than the RBL check is the run that meta before the DNS queries and if there is a match to stop additional tasks.Best Regards,Iulian Stan Original message From: Dave Funk Date: 12/23/20 22:01 (GMT+02:00) To: users@spamassassin.apache.org Subject: Re: Bypass RBL checks for specific address That may not work for what the OP wanted.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.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.This begs the question, what is the need to completely avoid running RBL checks for that special recipient?What is supposed to happen when a message comes in that is addressed to multiple recipients, including the special recipient?This could get messy.On Wed, 23 Dec 2020, Iulian Stan wrote:> Hello all,> > You can create a meta rule with very high prio(actually check to be higher than your RBL), match what you need> from email headers and than use shortcircuit to skip additional tests.> > > Best regards,> Iulian Stan> > > > Sent from my Galaxy> > > Original message > From: Grant Taylor > Date: 12/23/20 20:59 (GMT+02:00)> To: users@spamassassin.apache.org> Subject: Re: Bypass RBL checks for specific address> > On 12/22/20 11:56 PM, Axb wrote:> > whitelist_to ?> > My understanding is that whitelist_to, more_spam_to, and all_spam_to> behave the same way and effectively just alter the scoring offset.> > It seems as if the tests are still run, and it's just the score is> artificially offset based on which setting is used.> > I'm wanting to not run RBL tests for the specific recipient email address.> > > > --> Grant. . . .> unix || die> > >-- Dave Funk University of Iowa College of Engineering319/335-5751 FAX: 319/384-0549 1256 Seamans Center, 103 S Capitol St.Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527#include Better is not better, 'standard' is better. B{
Re: Bypass RBL checks for specific address
On 12/23/20 12:40 PM, Benny Pedersen wrote: if you want to disable RBL for one single ip, then add it to trusted_networks in local.cf As indicated in the message you replied to, "I'm wanting to disable filtering for a recipient email address, which may receive messages from IP addresses all over the world." if you want to disable one single recipient want all spam, then use all_spam_to in local.cf As indicated elsewhere, using all_spam_to seems to still apply all normal filtering, including RBL checks, which I'm wanting to avoid. (See my reply to Dave F.'s message for more details as to what and why.) dont make amavisd a spam content filter Who said anything about Amavis? It's not in context. Context is Sendmail, spamass-milter, and SpamAssassin (spamd). I didn't see any way to have spamass-milter bypass, much less conditionally bypass. Nor did I see a way to have Sendmail conditionally bypass a milter. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: Bypass RBL checks for specific address
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
Re: Bypass RBL checks for specific address
That may not work for what the OP wanted. 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. 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. This begs the question, what is the need to completely avoid running RBL checks for that special recipient? What is supposed to happen when a message comes in that is addressed to multiple recipients, including the special recipient? This could get messy. On Wed, 23 Dec 2020, Iulian Stan wrote: Hello all, You can create a meta rule with very high prio(actually check to be higher than your RBL), match what you need from email headers and than use shortcircuit to skip additional tests. Best regards, Iulian Stan Sent from my Galaxy Original message From: Grant Taylor Date: 12/23/20 20:59 (GMT+02:00) To: users@spamassassin.apache.org Subject: Re: Bypass RBL checks for specific address On 12/22/20 11:56 PM, Axb wrote: > whitelist_to ? My understanding is that whitelist_to, more_spam_to, and all_spam_to behave the same way and effectively just alter the scoring offset. It seems as if the tests are still run, and it's just the score is artificially offset based on which setting is used. I'm wanting to not run RBL tests for the specific recipient email address. -- Grant. . . . unix || die -- Dave Funk University of Iowa College of Engineering 319/335-5751 FAX: 319/384-05491256 Seamans Center, 103 S Capitol St. Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527 #include Better is not better, 'standard' is better. B{
Re: Bypass RBL checks for specific address
On 2020-12-23 19:59, Grant Taylor wrote: On 12/22/20 11:56 PM, Axb wrote: I'm wanting to not run RBL tests for the specific recipient email address. you will for this specifik task need a custom plugin in spamassassin if you just want to disable rbl test then add the ip to trusted_networks if you still need to disable pr recipient add it to what AXB sayed you can do both or one of them more help show a spample to let others suggest more on how to solve
Re: Bypass RBL checks for specific address
Hello all,You can create a meta rule with very high prio(actually check to be higher than your RBL), match what you need from email headers and than use shortcircuit to skip additional tests.Best regards,Iulian StanSent from my Galaxy Original message From: Grant Taylor Date: 12/23/20 20:59 (GMT+02:00) To: users@spamassassin.apache.org Subject: Re: Bypass RBL checks for specific address On 12/22/20 11:56 PM, Axb wrote:> whitelist_to ?My understanding is that whitelist_to, more_spam_to, and all_spam_to behave the same way and effectively just alter the scoring offset.It seems as if the tests are still run, and it's just the score is artificially offset based on which setting is used.I'm wanting to not run RBL tests for the specific recipient email address.-- Grant. . . .unix || die
Re: Bypass RBL checks for specific address
On 2020-12-23 19:56, Grant Taylor wrote: Response Policy Zone(s) are neat and can do a LOT of things. But I don't think it's proper for my task at hand. if you want to disable RBL for one single ip, then add it to trusted_networks in local.cf if you want to disable one single recipient want all spam, then use all_spam_to in local.cf dont make amavisd a spam content filter
Re: Bypass RBL checks for specific address
On 12/22/20 11:56 PM, Axb wrote: whitelist_to ? My understanding is that whitelist_to, more_spam_to, and all_spam_to behave the same way and effectively just alter the scoring offset. It seems as if the tests are still run, and it's just the score is artificially offset based on which setting is used. I'm wanting to not run RBL tests for the specific recipient email address. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: Bypass RBL checks for specific address
On 12/22/20 11:03 PM, Bill Cole wrote: Do you have a setup that supports per-user preferences? e.g.: real system accounts. Sort of. The recipient is a real Unix account. However I don't think my milter is configured to use per recipient filtering. If so, you can disable off individual rules for a user by giving them a score of 0 in ~/.spamassassin/user_prefs if they have a real account or in whatever you use for per-user prefs if they are virtual users. Would that truly disable the tests? Or does SpamAssassin still run the tests but ignore the result? -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: Bypass RBL checks for specific address
Hi Rob, On 12/22/20 6:40 PM, Rob McEwen wrote: First, I'm NOT an expert on all of this - so somebody might be able to follow up with BETTER information, but this will hopefully point you in the right direction. Fair enough. Really big snip. First, I agree with and like your idea. For an IP address. However Second, I'm wanting to disable filtering for a recipient email address, which may receive messages from IP addresses all over the world. So ANOTHER option might be to use the newer "response-policy" feature - my first idea was a sort of hack - but this "response-policy" might be more intended for exactly this purpose. So do a search on the following: Response Policy Zone(s) are neat and can do a LOT of things. But I don't think it's proper for my task at hand. Thank you for your email Rob. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: Bypass RBL checks for specific address
whitelist_to ? On 12/23/20 12:56 AM, Grant Taylor wrote: Is there a way to bypass RBL checks for a specific address? I've tried the all_spam_to option, but it looks like it artificially lowers the score and still runs normal tests. I'd like to disable RBL checks for one address.
Re: Bypass RBL checks for specific address
On 22 Dec 2020, at 18:56, Grant Taylor wrote: Is there a way to bypass RBL checks for a specific address? I've tried the all_spam_to option, but it looks like it artificially lowers the score and still runs normal tests. I'd like to disable RBL checks for one address. Do you have a setup that supports per-user preferences? e.g.: real system accounts. If so, you can disable off individual rules for a user by giving them a score of 0 in ~/.spamassassin/user_prefs if they have a real account or in whatever you use for per-user prefs if they are virtual users. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Bypass RBL checks for specific address
On 12/22/2020 6:56 PM, Grant Taylor wrote: Is there a way to bypass RBL checks for a specific address? I've tried the all_spam_to option, but it looks like it artificially lowers the score and still runs normal tests. I'd like to disable RBL checks for one address. Grant, First, I'm NOT an expert on all of this - so somebody might be able to follow up with BETTER information, but this will hopefully point you in the right direction. So at some point, I think 10+ years ago, I needed to do this, and instead of doing this at the spam filter level - I found that it worked well to do this via BIND - so this works if you're using your own locally-hosted BIND server for resolving DNSBL queries. So, for example, if you qualified for use of the free version of SpamCop (as an example), and you wanted to whitelist the IP 1.2.3.4, you could add the following to your named.conf file: zone "4.3.2.1.bl.spamcop.net" in { type master; notify no; file "master/null.zone"; }; Then add another such record for each DNSBL that you use. Then the "master/null.zone" file can be the following EMPTY zone (or something like this - change as desired! This might not even be the best or "right" way to do this - this is just what I had in that null.zone file when I was doing this 10+ years ago): $TTL 52w @ IN SOA root.localhost. root.localhost ( 2005012001 ; serial 52w ; refresh 52w ; retry 52w ; expire 52w ; ttl ) @ IN NS localhost localhost IN A 127.0.0.1 So by referencing an empty zone file, that way, each "zone" entry just points to this one file, for maximum efficiency and caching, and you don't have to reenter this for each zone. In the named.conf file, I think each zone statement (my 1st example abovw) would go AFTER the "options" section, but before the "includes" section. Obviously, if you suddenly needed to do this for 10s of thousands of IPs or hostnames, then maybe it would then start to have resource/maintenance issues - but on a smaller scale, this works great! HOWEVER - This was so long ago, that I don't know if this STILL works in more recent version of BIND without causing issues? It is possible that in more recent version of BIND, DNSSEC might interfere with being able to do this? So ANOTHER option might be to use the newer "response-policy" feature - my first idea was a sort of hack - but this "response-policy" might be more intended for exactly this purpose. So do a search on the following: "response-policy" "BIND" "NXDOMAIN" ...with each in quotes, as shown, for instructions on how this is done. So I think the example above, if implemented using "response-policy", would be the following: response-policy { 4.3.2.1.bl.spamcop.net IN CNAME . }; Or something like that. Double-check my syntax. It might be wrong! So, again, I've never done the "response-policy", so this is just to get you started and point you in the right direction. If someone comes along and corrects my possible mistakes, or provides BETTER info - that is excellent - in the meantime, hopefully this will point you in the right direction, or give you some ideas. -- Rob McEwen, invaluement