You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Grant Taylor <gt...@tnetconsulting.net> on 2020/12/22 23:56:18 UTC
Bypass RBL checks for specific address
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. . . .
unix || die
Re: Bypass RBL checks for specific address
Posted by Grant Taylor <gt...@tnetconsulting.net>.
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
Re: Bypass RBL checks for specific address
Posted by Kris Deugau <kd...@vianet.ca>.
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
Posted by Bill Cole <sa...@billmail.scconsult.com>.
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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: Bypass RBL checks for specific address
Posted by Grant Taylor <gt...@tnetconsulting.net>.
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
Re: Bypass RBL checks for specific address
Posted by Bill Cole <sa...@billmail.scconsult.com>.
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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: Bypass RBL checks for specific address
Posted by Grant Taylor <gt...@tnetconsulting.net>.
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
Re: Bypass RBL checks for specific address
Posted by Dave Funk <db...@engineering.uiowa.edu>.
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
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center, 103 S Capitol St.
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Bypass RBL checks for specific address
Posted by Grant Taylor <gt...@tnetconsulting.net>.
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
Re: Bypass RBL checks for specific address
Posted by Benny Pedersen <me...@junc.eu>.
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
Posted by Grant Taylor <gt...@tnetconsulting.net>.
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
Re: Bypass RBL checks for specific address
Posted by Rob McEwen <ro...@invaluement.com>.
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
Re: Bypass RBL checks for specific address
Posted by Grant Taylor <gt...@tnetconsulting.net>.
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
Re: Bypass RBL checks for specific address
Posted by John Hardin <jh...@impsec.org>.
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 KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org pgpk -a jhardin@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
Posted by Grant Taylor <gt...@tnetconsulting.net>.
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
Re: Bypass RBL checks for specific address
Posted by John Hardin <jh...@impsec.org>.
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 KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org pgpk -a jhardin@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
Posted by Grant Taylor <gt...@tnetconsulting.net>.
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
Re: Bypass RBL checks for specific address
Posted by Martin Gregorie <ma...@gregorie.org>.
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
Posted by Benny Pedersen <me...@junc.eu>.
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
Posted by Iulian Stan <iu...@sphere.ro>.
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 <gt...@tnetconsulting.net> 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
Posted by Grant Taylor <gt...@tnetconsulting.net>.
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
Posted by Axb <ax...@gmail.com>.
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.