Mailing List Archive

On 2/16/2023 9:13 PM, joe a wrote:
>
> Well, I am in unfamiliar waters.
>
> picking one error message as typical:
>
> plugin: failed to parse plugin (from @INC): Can't locate
> Mail/SpamAssassin/Plugin/iXhash2.pm:
> lib/Mail/SpamAssassin/Plugin/iXhash2.pm: Permission denied at (eval
> 1746) line 1.
>
> The file locations shown do not exist, as explicitly as shown. What I
> find using "locate iXhash2.pm" is:
>
> /usr/lib/perl5/vendor_perl/5.26.1/Mail/SpamAssassin/Plugin/iXhash2.pm
> which the SA user can access, at least see via ll. The others I've
> checked are also visible, and directories are x (exccutable).
>
> The sense I am getting is there is a perl file that contains these
> paths that is referred to as @INC.
>
> I don't have the knowledge at this point to see if, somehow, root sees
> the files as shown in the error or if the path is somehow altered for
> the SA user.
>
> Thanks for any guidance.

Sounds like you've got a case of discombobulated PERL.  @INC is a list
of directories to search for modules to INCLUDE at a PERL script's
compile time.  It is usually baked into the PERL executable by the
package builder.  Who really knows why they put things where they do?

perl -V gives verbose output.  @INC paths should be listed near, or at,
the bottom.
To simplify that with a one-liner: perl -e 'printf "%d %s\n", $i++, $_
for @INC'

How you got into that state is a mystery to me.

I see a few symbolic links in your future.  For example:
ln -s /usr/lib/perl5/vendor_perl/5.26.1/Mail /lib/Mail

Or, if you have to be more specific (say, /lib/Mail exists already),
something like:
ln -s /usr/lib/perl5/vendor_perl/5.26.1/Mail/SpamAssassin
/lib/Mail/SpamAssassin

etc...

--Jared Hall

On 16.02.23 15:57, joe a wrote:
>Re-energized having recently heroically wrestled an elusive issue (to
>me) into surrender . . . we now turn to another issue.
>
>Probably I need to retrain BAYES "From scratch". I have a mess
>(years?) of stored sample emails that and be relearned.
>
>I understand that sa-learn should be run as the same user as spamd,
>however I find it has always been run as root and when running as the
>spamassassin user results in errors, such as:
>
>~su -c "sa-learn --spam /var/mail/spamd/Cabinet.Missed-SPAM" spamfilter
>
>results in errors, starting with:
>
>plugin: failed to parse plugin (from @INC): Can't locate
>Mail/SpamAssassin/Plugin/SpamCop.pm:
>lib/Mail/SpamAssassin/Plugin/SpamCop.pm: Permission denied at (eval
>44) line 1.
>
>plugin: failed to parse plugin (from @INC): Can't locate
>Mail/SpamAssassin/Plugin/AutoLearnThreshold.pm:
>lib/Mail/SpamAssassin/Plugin/AutoLearnThreshold.pm: Permission denied
>at (eval 45) line 1.

try first changing current working directory into one readable by user
"spamfilter", perhaps root (/).

--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Despite the cost of living, have you noticed how popular it remains?

On Thu, 2023-02-16 at 23:32 +0100, hg user wrote:
> root can do anything. a restricted user can't: it's only allowed to do
> what
> others allowed it.
>
> it also runs with another environment, so it may miss PATHes or @INC
> directories.
>
You can check this by running 

env | less

from a command line under the appropriate user and making sure that all
the environment variables you expect to see defined are, and have the
values you expect.

Martin

On 2/17/2023 7:37 AM, Reindl Harald wrote:
>
>
> Am 16.02.23 um 23:34 schrieb joe a:
>>>> I have no idea what you refer to when you state "don't user proper
>>>> packages".  "Proper" in what sense? A rhetorical question.
>>>
>>> i have no idea how you installed SA but rpm packages or debs usually
>>> have correct permissions
>>
>> Oh, of course.  I installed as root initially, being foolish perhaps
>
> you *must* install software as root because the service *must not* have
> write permissions to it's own binary files
>
>> but did create a specific user "later" and adjusted permissions as
>> needed.  Or, so I thought
>
> the real question was HOW DID YOU INSTALL it
>
> from the first day i maintained production servers i learnt to build my
> own rpm packages - no matter if it's software written in C, PHP or Perl
>
> why?
>
> * because you get rid of leftover files over the years
> * permissions are part of te package
> * the package manager dectects many conflicts

One of the first things I learned when assembling things or attempting
to learn something new, is to follow the instructions and only attempt
to vary from them once you absolutely understood what your were doing.
Or, suffer the consequences along with the (rare) accolades for
improving a process.

That said, I would never "build my own rpm package" in this context.

This is almost entirely a "home/office" system that seems low traffic.

So, I installed postfix and spamassassin initially from the OS vendor
supplied packages. Over the years I applied updates from outside the OS
vendor channel, from packages from "authors" sites, as the versions
diverged enough to be a concern. There have been some OS updates as
well and at least one transfer from one VM to another.

All this appears to be digression, to me, the issue, to me, seems to be
why root sees the stuff in this @INC entity differently from how the SA
user sees it.

With the insights and pointers gained in this thread, I hope to solve
that sometime soon.

On 2/17/2023 4:42 AM, Matus UHLAR - fantomas wrote:
> On 16.02.23 15:57, joe a wrote:
>> Re-energized having recently heroically wrestled an elusive issue (to
>> me) into surrender . . . we now turn to another issue.
>>
>> Probably I need to retrain BAYES "From scratch".  I have a mess
>> (years?) of stored sample emails that and be relearned.
>>
>> I understand that sa-learn should be run as the same user as spamd,
>> however I find it has always been run as root and when running as the
>> spamassassin user results in errors, such as:
>>
>> ~su -c "sa-learn --spam /var/mail/spamd/Cabinet.Missed-SPAM" spamfilter
>>
>> results in errors, starting with:
>>
>> plugin: failed to parse plugin (from @INC): Can't locate
>> Mail/SpamAssassin/Plugin/SpamCop.pm:
>> lib/Mail/SpamAssassin/Plugin/SpamCop.pm: Permission denied at (eval
>> 44) line 1.
>>
>> plugin: failed to parse plugin (from @INC): Can't locate
>> Mail/SpamAssassin/Plugin/AutoLearnThreshold.pm:
>> lib/Mail/SpamAssassin/Plugin/AutoLearnThreshold.pm: Permission denied
>> at (eval 45) line 1.
>
> try first changing current working directory into one readable by user
> "spamfilter", perhaps root (/).
>

Could it have been that simple?

Yes, apparently it was.

Many thanks.

joe a.

On Fri, 2023-02-17 at 10:54 -0500, joe a wrote:

> Could it have been that simple?
>
If, like myself, you find reference books useful, you may want to get a
copy of "Linux in a Nutshell" - an O'Reilly book.

It tends to assume you know at least one other OS fairly well, is well
organised and concise. I've also found "Debian Reference"

 http://www.debian.org/doc/manuals/debian-reference/

useful for most flavours of Linux (I use Fedora and Raspbian)

Martin

>On Fri, 2023-02-17 at 10:54 -0500, joe a wrote:
>> Could it have been that simple?

On 17.02.23 16:44, Martin Gregorie wrote:
>If, like myself, you find reference books useful, you may want to get a
>copy of "Linux in a Nutshell" - an O'Reilly book.
>
>It tends to assume you know at least one other OS fairly well, is well
>organised and concise. I've also found?"Debian Reference"
>
>?http://www.debian.org/doc/manuals/debian-reference/
>
>useful for most flavours of Linux (I use Fedora and Raspbian)

reading such book is a good idea, but I think this is more a SA bug, @INC
containing something that references "." or "..", which it should not, and
which causes perl fail when it can't open directory in @INC.
(and perl has documented this feature iirc).

--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
WinError #98652: Operation completed successfully.

On 2/17/2023 11:44 AM, Martin Gregorie wrote:
> On Fri, 2023-02-17 at 10:54 -0500, joe a wrote:
>
>> Could it have been that simple?
>>
> If, like myself, you find reference books useful, you may want to get a
> copy of "Linux in a Nutshell" - an O'Reilly book.
>
> It tends to assume you know at least one other OS fairly well, is well
> organised and concise. I've also found "Debian Reference"
>
>  http://www.debian.org/doc/manuals/debian-reference/
>
> useful for most flavours of Linux (I use Fedora and Raspbian)
>
> Martin
>

There was also a "Unix in a Nutshell". I found it amusing, in my
NetWare days, to have a copy on my desk and offer it to the Unix-oids
that meanered in from time to time, that liked to scoff at "security by
obscurity" and those "Puny PC's you call Servers". (That from folks
that swore sendmail was forever king and operated the email server as an
open relay).

A bit of an issue when I offered that the book should be called "Nuts,
in a Unix Shell". . . Ah, the memories . . .

On 2/17/2023 3:25 PM, joe a wrote:

Did a simple test today sending an email from a gmail account to two
email accounts on my system. The only difference was the email
address, both were on the same "To:" line in the composed messages.

They receive wildly different BAYES scores.
------------------------------
X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on myserver
X-Spam-Level: *
X-Spam-Status: No, score=1.1 required=4.9 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,
IXHASH_X1,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_SOFTFAIL
autolearn=disabled version=3.4.5
X-Spam-Report:
* -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
* [score: 0.0002]
------------------------------

X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on myserver
X-Spam-Flag: YES
X-Spam-Level: *****
X-Spam-Status: Yes, score=5.2 required=4.9 tests=BAYES_20,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,
IXHASH_X1,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_SOFTFAIL
autolearn=disabled version=3.4.5
X-Spam-Report:
* 2.2 BAYES_20 BODY: Bayes spam probability is 5 to 20%
* [score: 0.0881]
------------------------------

Just another sign of BAYES wackiness? More evidence of need for rebuild?

> They receive wildly different BAYES scores.
> * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
> * [score: 0.0002]
> * 2.2 BAYES_20 BODY: Bayes spam probability is 5 to 20%
> * [score: 0.0881]

This looks like you have per-user Bayes databases, and the messaage type has
been trained differently in each.

Also, it looks like there are per-user rules, since BAYES_50 has a normal
score of 0.2, and there is no reason BAYES_20 (indicating much less spammy)
should have a score of 2.2.

On 2023-02-17 at 22:41:05 UTC-0500 (Fri, 17 Feb 2023 19:41:05 -0800)
Loren Wilton <lwilton@earthlink.net>
is rumored to have said:

>> They receive wildly different BAYES scores.
>> * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
>> * [score: 0.0002]
>> * 2.2 BAYES_20 BODY: Bayes spam probability is 5 to 20%
>> * [score: 0.0881]
>
> This looks like you have per-user Bayes databases, and the messaage
> type has been trained differently in each.
>
> Also, it looks like there are per-user rules, since BAYES_50 has a
> normal score of 0.2, and there is no reason BAYES_20 (indicating much
> less spammy) should have a score of 2.2.

Absolutely correct.

However, that does not prove definitively that there are per-user Bayes
DBs & rules, just that the BAYES_20 score is insane. The difference
between 8.81% and 00.02% isn't very meaningful. It isn't accidental that
SA doesn't have finer categories of Bayes scores.


--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

On 2/17/2023 8:24 PM, joe a wrote:
> On 2/17/2023 3:25 PM, joe a wrote:
>
> Did a simple test today sending an email from a gmail account to two
> email accounts on my system.   The only difference was the email
> address, both were on the same "To:" line in the composed messages.
>
> They receive wildly different BAYES scores.
>
Try rattling off another Gmail message, but this time switch the two
Email addresses on the "To:" line around. Maybe a case where only the
first Email address is looked at by SA?

Thanks,

Jared Hall

>On 2/17/2023 8:24 PM, joe a wrote:
>>Did a simple test today sending an email from a gmail account to two
>>email accounts on my system.?? The only difference was the email
>>address, both were on the same "To:" line in the composed messages.
>>
>>They receive wildly different BAYES scores.

as was mentioned, they were apparently tested under different user.

I want to add, that multiple similar messages can have invisible differences
which can result into different BAYES results.

Just this week I noticed (at least) two phishing waves, training one e-mail
resulted into pushing other e-mails' scores up to BAYES_999, while other
still had BAYES_50 or BAYES_80.

Simply, we need more training.

On 17.02.23 23:46, Jared Hall wrote:
>Try rattling off another Gmail message, but this time switch the two
>Email addresses on the "To:" line around. Maybe a case where only the
>first Email address is looked at by SA?

if needed, scan the same mail under different user, if possible.

--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Microsoft dick is soft to do no harm

On 2/17/2023 10:41 PM, Loren Wilton wrote:
>> They receive wildly different BAYES scores.
>> * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
>> *      [score: 0.0002]
>> *  2.2 BAYES_20 BODY: Bayes spam probability is 5 to 20%
>> *      [score: 0.0881]
>
> This looks like you have per-user Bayes databases, and the messaage type
> has been trained differently in each.
>
> Also, it looks like there are per-user rules, since BAYES_50 has a
> normal score of 0.2, and there is no reason BAYES_20 (indicating much
> less spammy) should have a score of 2.2.
>

Per-user is not setup.

This morning I sent the message again, with users reversed in the TO:
field and the scores are identical. This may prove nothing as I
thoughtlessly added the high score message to my "HAM" folder and it was
processed.

While the scores are identical the X-Spam-Report lists them in different
order, while X-Spam-Status shows them identically, "RCVD_IN_MSPIKE_H2
RBL" being listed near the top in one and near the bottom in the other.

Perhaps that is meaningless, but it pings my curiosity.

please
spamassassin -D bayes -t file.eml 2>/tmp/z
and in /tmp/z you will have the score assigned to the "tokens"... from
those points you will understand what created the different totals.

If you can you may relearn all the messages, both ham and spam, with the
tip suggested a couple of days ago, removing all the headers. It may lower
points to some spam but probably it's better..

On Sat, Feb 18, 2023 at 3:37 PM joe a <joea-lists@j4computers.com> wrote:

> On 2/17/2023 10:41 PM, Loren Wilton wrote:
> >> They receive wildly different BAYES scores.
> >> * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
> >> * [score: 0.0002]
> >> * 2.2 BAYES_20 BODY: Bayes spam probability is 5 to 20%
> >> * [score: 0.0881]
> >
> > This looks like you have per-user Bayes databases, and the messaage type
> > has been trained differently in each.
> >
> > Also, it looks like there are per-user rules, since BAYES_50 has a
> > normal score of 0.2, and there is no reason BAYES_20 (indicating much
> > less spammy) should have a score of 2.2.
> >
>
> Per-user is not setup.
>
> This morning I sent the message again, with users reversed in the TO:
> field and the scores are identical. This may prove nothing as I
> thoughtlessly added the high score message to my "HAM" folder and it was
> processed.
>
> While the scores are identical the X-Spam-Report lists them in different
> order, while X-Spam-Status shows them identically, "RCVD_IN_MSPIKE_H2
> RBL" being listed near the top in one and near the bottom in the other.
>
> Perhaps that is meaningless, but it pings my curiosity.
>
>
>
>
>