Re: sa-update

[Matt Anton via users]

On 17 Mar 2023, at 16:03, Bill Cole wrote:

Correct. We've had a problem with RuleQA, in that we have not had 
enough spam in the masscheck submissions to run the rescoring 
properly. I'm not sure whose submissions have dried up...


The existing list of active rules and their scores is fine for now and 
won't likely be problematic in the near to mid term. Obviously we hope 
to resolve the underlying lack of data and to resume proper QA ASAP.


Thanks Bill for letting us know what’s going on!

cheers,

--
matt [at] lv223.org
GPG key ID: 7D91A8CA

Re: warnings with sa-compile?

[Matt Anton via users]

On 10 Feb 2023, at 13:28, Matt Anton via users wrote:

According to a thread on FreeBSD’s forums[1] and perl GitHub’s own 
tracker[2], perl is currently not friendly with clang-11 and above 
which was introduced on ≥12.2 and ≥13.1.


Err, I meant "not friendly with clang-13"...

--
matt [at] lv223.org
GPG key ID: 7D91A8CA

Re: warnings with sa-compile?

[Matt Anton via users]

On 10 Feb 2023, at 6:10, Dan Mahoney (Gushi) wrote:

> Hey there all.

Hello Dan,

> We're only using two real rulesets: core and kam.cf
>
> Our nightly sa-update/sa-compile run is throwing warnings like the following. 
>  So, these are only warnings, and the compile continues, but they're making 
> my cron jobs noisy.
>
> The questions:
>
> 1) Are these known issues.

We’re currently having here the same warnings too on 12.4 and 13.1 boxes.

According to a thread on FreeBSD’s forums[1] and perl GitHub’s own tracker[2], 
perl is currently not friendly with clang-11 and above which was introduced on 
≥12.2 and ≥13.1.

> 2) Is it worth filing a bug?

Not worth it imho as these are currently warnings and should be fixed upstream 
on the perl side.

> OS is FreeBSD 12.4, and I think these are using the on-box c compiler 
> (clang), not gcc.

Yep. No warnings are generated on clang ≤11.x (you also get those when 
building/upgrading perl5).


Cheers,

[1] 

[2] 


-- 
matt [at] lv223.org
GPG key ID: 7D91A8CA


signature.asc
Description: OpenPGP digital signature

Re: TxRep records unreliably on MySQL

[Matt Anton via users]

Le Mon, 09 Jan 2023 08:59:39 -0500,
Greg Troxel  a écrit :

> The perl source code for TxRep.  On my system:
> 
>   /usr/pkg/lib/perl5/vendor_perl/5.36.0/Mail/SpamAssassin/Plugin/TxRep.pm

Well, as my perl skills-fu are near 0, I'll stick to AWL as it is
working as it should since nearly a decade now.
TxRep on the paper brings neat ideas but if it requires me to a perl
guru to fix its code, its a no go.

> Maybe it should; someone has to read the code and figure this out.  I
> sort of intend to at some point, but haven't.

As you said, this plugin is not 100% baked as of now.

Cheers,

-- 
matt [at] lv223.org
GPG key ID: 7D91A8CA



pgpS_WVAlc1ys.pgp
Description: Signature digitale OpenPGP

Re: TxRep records unreliably on MySQL

[Matt Anton via users]

Hi Greg,

Le Mon, 09 Jan 2023 08:09:06 -0500,
Greg Troxel  a écrit :

> Your mail was miswrapped and thus hard to read.

Thanks for your reply.
Yeh the flowed mangled lines endings my bad and probably.

Here's what I'm having on the SQL spamassassin db:



> 1) txrep seems not 100% baked.   I suggest reading the code to see how
> this happened.

What code are you talking about?

> 2) txrep with bdb only has keys and values and it does overload the
> key for address and name.  So perhaps this is incompletey moving to
> the more complicated scheme.

And there you completely lost me ;)
I naively thought TxRep would record in a same way that AWL did (sql
schema for both plugins are the same).

-- 
matt [at] lv223.org
GPG key ID: 7D91A8CA



pgpE_1pFbhrDf.pgp
Description: Signature digitale OpenPGP

TxRep records unreliably on MySQL

[Matt Anton via users]

Hello list,

After an upgrade to SA-4.0.0 I decided to give TxRep a try after using 
AWL since it was introduced.
I set up TxRep accordingly to SA’s documentation with a mysql-5.7.40 
server, give it a first try by sending an email to the box where SA is 
running and saw TxRep just has recorded unreliably onto the sql table:


#v+
root@localhost [spamassassin]> describe txrep;
+--+--+--+-+---+-+
| Field| Type | Null | Key | Default   | Extra   
|

+--+--+--+-+---+-+
| username | varchar(100) | NO   | PRI |   | 
|
| email| varchar(255) | NO   | PRI |   | 
|
| ip   | varchar(40)  | NO   | PRI |   | 
|
| msgcount | int(11)  | NO   | | 0 | 
|
| totscore | float| NO   | | 0 | 
|
| signedby | varchar(255) | NO   | PRI |   | 
|
| last_hit | timestamp| NO   | MUL | CURRENT_TIMESTAMP | on update 
CURRENT_TIMESTAMP |

+--+--+--+-+---+-+
7 rows in set (0,00 sec)

root@localhost [spamassassin]> select * from txrep;
+--+---+--+--+--++-+
| username | email | ip  
 | msgcount | totscore | signedby   | last_hit|

+--+---+--+--+--++-+
| vscan| 209.85.218.51 | 
none |1 |   -0.217 || 2023-01-09 01:25:46 |
| vscan| aac3c57398484c78fd317abe6061e81c4b9296f2@sa_generated | 
none |1 |   -0.217 | 1673223945 | 2023-01-09 01:25:46 |
| vscan| gmail.com | 
none |1 |   -0.217 | gmail.com  | 2023-01-09 01:25:46 |
| vscan| mail-ej1-f51.google.com   | 
none |1 |   -0.217 | helo   | 2023-01-09 01:25:46 |
| vscan| u...@gmail.com| 
none |1 |   -0.217 | gmail.com  | 2023-01-09 01:25:46 |

+--+---+--+--+--++-+
5 rows in set (0,00 sec)
#v-

Anyone can tell me how the hell it is logging for example: an address in 
the email column or garbage on the signedby table?


SQL statements used to create txrep table is the one supplied by 
SA-4.0.0 (beside table’s name, this is the same as ones AWL need).


The following TxRep settings were been used in the global local.cf:

#v+
use_txrep 1
txrep_ipv4_mask_len 32
txrep_ipv6_mask_len 128
auto_welcomelist_distinguish_signed 1
txrep_spf 1
#v-

Cheers,

--
matt [at] lv223.org
GPG key ID: 7D91A8CA

Re: spamass-milter reject?

[Matt Anton]

On 27 Jun 2019, at 9:33, Matus UHLAR - fantomas wrote:

> for mail received from the net I use amavisd-new with amavisd-milter.
>
> Content filter accepts message, I don't want to drop it, send bounce or send
> it to anyone.  I use content filter for mail sent from internal network or
> through alternative ports.

Have you many false positives by rejecting outright mails marked as spam by 
amavisd-new?

-- 
matt [at] lv223.org
GPG key ID: 7D91A8CA


signature.asc
Description: OpenPGP digital signature

Re: spamass-milter reject?

[Matt Anton]

On 26 Jun 2019, at 10:26, Matus UHLAR - fantomas wrote:

>> Could it be what milter macros are sent by the MTA (postfix here) to the 
>> milter ?
>
> I don't think so, unless postfix doesn't allow milter to reject e-mail.
> rejections with amavis-milter work properly with postfix.

It does allow reinjection (on other milters too like open opendkim/opendmarc 
ones) so you’re right.
I don’t know why spamass-milter acts like that and submitting a bug report 
could be a dead end as it seems that milter looks like abandoned as lbutlr 
saids.

-- 
matt [at] lv223.org
GPG key ID: 7D91A8CA


signature.asc
Description: OpenPGP digital signature

Re: spamass-milter reject?

[Matt Anton]

On 26 Jun 2019, at 9:02, @lbutlr wrote:

> Well, I want spam MARKED at 5.0, but I want it REJECTED at 10.0. It is a 
> subtle difference, but the majority of spam being delivered to users is in 
> the 10-100 range.

I achieve that with amavisd-new being configured as an after queue content 
filter, thus the required_score in local.cf only applies to 
spamass-milter/spamd for rejecting outright before it is queued.


-- 
matt [at] lv223.org
GPG key ID: 7D91A8CA


signature.asc
Description: OpenPGP digital signature

Re: spamass-milter reject?

[Matt Anton]

On 25 Jun 2019, at 22:14, Matus UHLAR - fantomas wrote:

>> I simply overcame this by setting SA’s required_score parameter to a desired 
>> value in mail/spamassassin/local.cf

> I have different value in required_score than I use in -r flag.
> However that's sendmail installation. There's something strange here.

Could it be what milter macros are sent by the MTA (postfix here) to the milter 
?

-- 
matt [at] lv223.org
GPG key ID: 7D91A8CA


signature.asc
Description: OpenPGP digital signature

Re: spamass-milter reject?

[Matt Anton]

On 25 Jun 2019, at 2:57, @lbutlr wrote:

> These are inbound messages being delivered to local users with high spam 
> scores. I want Spamassassin-milter to honor the -r 10 flag setting to reject 
> messages scoring over 10.0

After digging on my configuration files I came to the same problem as you when 
I installed that milter  (spamass-milter doesn’t honours the -r flag no matter 
what I’ve tried).

I simply overcame this by setting SA’s required_score parameter to a desired 
value in mail/spamassassin/local.cf

FWIW this is with spamass-milter-0.4.0_3 on FreeBSD.

-- 
matt [at] lv223.org
GPG key ID: 7D91A8CA


signature.asc
Description: OpenPGP digital signature

Re: spamass-milter reject?

[Matt Anton]

On 23 Jun 2019, at 22:39, @lbutlr wrote:

> I did `postfix relaod`
>
> and the milter is running with the flags shown in the OP.

Talking about it and your recent thread there, why didn’t you use 
spamass-milter’s « -a » parameter which does skip messages received on an 
authenticated connection?

> I did not restart postfix entirely, but that shouldn’t be necessary?

Shouldn’t be needed as `postfix reload` just reloads main.cf
Did you restart spamass-milter/spamd after changing any of their parameters?

-- 
matt [at] lv223.org
GPG key ID: 7D91A8CA


signature.asc
Description: OpenPGP digital signature

Re: Mail to local users

[Matt Anton]

On 18 Jun 2019, at 22:45, @lbutlr wrote:

> Solution was ridiculously simple.
>
> I added
>
>   -o smtpd_milters=
>   -o milter_connect_macros=
>
> To submission and smpts in master.cf
>
> (I doubt the second line is needed, but eh… it’s not going to hurt)

You did post on postfix-users how you set in master.cf submission and smtps 
services (see verbatim of this below):

#v+
submission   inet  n   -   n   -   -   smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_security_options=noanonymous
  -o smtpd_sasl_path=private/auth
  -o syslog_name=postfix/submit
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o smtpd_data_restrictions=
  -o 
smtpd_relay_restrictions=permit_sasl_authenticated,reject_unauth_destination,reject
  -o smtpd_helo_restrictions=
  -o 
smtpd_recipient_restrictions=permit_sasl_authenticated,reject_unauth_destination,reject

smtps  inet  n   -   n   -   -   smtpd
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_security_options=noanonymous
  -o smtpd_sasl_path=private/auth
  -o smtpd_data_restrictions=
  -o 
smtpd_relay_restrictions=permit_sasl_authenticated,reject_unauth_destination,reject
  -o smtpd_helo_restrictions=
  -o 
smtpd_recipient_restrictions=permit_sasl_authenticated,reject_unauth_destination,reject
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
#v-

IMHO, you should have put ‘-o milter_macro_daemon_name=ORIGINATING’ to services 
to let milters know the mail stream from authenticated connections is 
considered local.

hth

-- 
matt [at] lv223.org
GPG key ID: 7D91A8CA


signature.asc
Description: OpenPGP digital signature