Mailing List Archive

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 [ In reply to ]
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 [ In reply to ]
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 [ In reply to ]
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 [ In reply to ]
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 [ In reply to ]
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 [ In reply to ]
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 [ In reply to ]
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 [ In reply to ]
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 <gtaylor@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 [ In reply to ]
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 [ In reply to ]
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 <gtaylor@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
>
>
>

--
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 [ In reply to ]
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
Re: Bypass RBL checks for specific address [ In reply to ]
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 [ In reply to ]
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 <dbfunk@engineering.uiowa.edu> 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 <gtaylor@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> > >-- Dave Funk                               University of Iowa<dbfunk (at) engineering.uiowa.edu>     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 <std_disclaimer.h>Better is not better, 'standard' is better. B{
Re: Bypass RBL checks for specific address [ In reply to ]
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 [ In reply to ]
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 [ In reply to ]
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 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 [ In reply to ]
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 [ In reply to ]
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 [ In reply to ]
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 [ In reply to ]
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 [ In reply to ]
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 [ In reply to ]
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 [ In reply to ]
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 [ In reply to ]
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

1 2  View All