Re: IPv6 issue

[Jeremy Ardley]

On 6/5/22 6:31 pm, Ted Mittelstaedt wrote:



For unrelated reasons I had to turn off IPv6 on my incoming mailserver.

Spam plummeted.  Like by 80% at least.  Both uncaught and caught spam 
did.




Were there more hostname variations with  records than A records?

--
Jeremy


OpenPGP_signature
Description: OpenPGP digital signature

Re: IPv6 issue

[Greg Troxel]

I agree with what Grant said.

Also, I wonder how much greylisting would help, and if you were already
doing that.  The data I posted is for a machine that already does
greylisting in general, with varying times depending on inclusion in
various RBLs and local data.

I find that delaying connections from unknown places even 2 minutes
helps a lot.


signature.asc
Description: PGP signature

Re: IPv6 issue

[Grant Taylor]

On 5/6/22 10:49 AM, Ted Mittelstaedt wrote:
Arg.  Well I think you hit the nail on the head.  And I think I may 
have stumbled on to a spam defeating trick.


Ya ... not running email server on IPv6 is a way of not receiving (some) 
spam.  But I view it very similarly as not running an email server 
period is another way of not receiving (all) spam.


It's a short term gain that has long term negative repercussions.

The problem for them is that if there is no response from that A record 
then normal TCPIP stack is going to wait for a while then eventually 
time out.


What you are describing is the premise behind "No Listing".  The two 
primary ways it's done is to 1) leverage TCP timeouts or 2) leverage a 
TCP Reset.  Either way, you're tickling bugs that alter behavior of spam 
cannons.  Things that proper SMTP servers handle much more gracefully, 
most without any problem at all.


I did not remove the  records because the IPv6 RFCs require that 
if the initial connection tried with IPv6 fails you retry with IPv4.


I would encourage you to not have your host's FQDN include a  record 
if it's not going to be utilizing it.  I'd instead suggest adding an 
alternate name with the (bogus)  record and reference that in MX 
records.



It is in effect a sort of tarpit I believe.


That's not tar pitting to me.  Tar pitting would be answering and 
replying extremely slowly.  Such that you burn a LOT of time for an 
established and arguably functioning (as in exchanging data) SMTP 
connection.  Like one character per second or every few seconds.


You could extend this to defining multiple nonexistent numbers for 
an IPv4 host except that DNS does not seem to have a way to force 
ordering of multiple IPv4s


DNS zone files don't have a way to force ordering.  Some DNS servers, 
BIND in particular, does have the ability to sort records.


Of course, spammers could get around this by recompiling their bots 
to use only IPv4.


You can apply No Listing to different IPs within a protocol and / or 
across protocols.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: SPF skipped for whitelisted relay domain

[Kevin A. McGrail]

> we wait for spamassassin 4.0.0 :=)
>
> 4.0.0  is in pre-release now and in production for a few of us.  Start
stress testing it now so we can shake out the bugs and get it out the door!

Regards,
KAM

Re: Intuit servers sending paypal phishes

[Shawn Iverson]

Just got one as well, deciding how to handle it...

On Fri, May 6, 2022 at 1:52 PM Kevin A. McGrail  wrote:

> Oh joy.
> On 5/6/2022 11:19 AM, Dave Wreski wrote:
>
> Hi, Intuit's servers are being used to send Paypal phishing invoices
> combined with the "evil numbers" scam.
>
> --
> Kevin A. mcgrailkmcgr...@apache.org
>
> Member, Apache Software Foundation
> Chair Emeritus Apache SpamAssassin 
> Projecthttps://www.linkedin.com/in/kmcgrail - 703.798.0171
>
>

Re: Rule syntax in local.cf?

[Thomas Cameron]

On 5/6/22 11:31, Bill Cole wrote:

On 2022-05-06 at 10:58:15 UTC-0400 (Fri, 6 May 2022 09:58:15 -0500)
Thomas Cameron 
is rumored to have said:


Howdy, all -

As I mentioned in a previous email, I'm trying to bump up the score for 
BAYES_999. I have not messed with SA in years, but I'm trying to get back into 
it. Sorry if this is a silly question.

I tried to add the following line to /etc/mail/spamassassin/local.cf, but it's 
not firing:

[root@mail-east ~]# cat /etc/mail/spamassassin/local.cf
# These values can be overridden by editing ~/.spamassassin/user_prefs.cf
# (see spamassassin(1) for details)

# These should be safe assumptions and allow for simple visual sifting
# without risking lost emails.

score SPAM_999 3

Where are you getting that rule name???


If I'm reading it correctly, it is NOT bumping up the score for BAYES_999, it's 
only adding the default 0.2 to it.

SA is not clairvoyant or telepathic. It has no idea that you want to change the 
score on BAYES_999 by using the name of a non-existent rule SPAM_999.


I'm running this on Red Hat Enterprise Linux 8.5. The SA package is 
spamassassin-3.4.4-4.el8.x86_64.

What am I doing wrong?

Changing the score for a non-existent rule.


Ugh. I have no idea how I got it in my head that it was SPAM and not 
BAYES. Sorry for the noise.


Thomas

Re: Intuit servers sending paypal phishes

[Kevin A. McGrail]

Oh joy.

On 5/6/2022 11:19 AM, Dave Wreski wrote:
Hi, Intuit's servers are being used to send Paypal phishing invoices 
combined with the "evil numbers" scam.


--
Kevin A. McGrail
kmcgr...@apache.org

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail  - 703.798.0171

Re: Spamassassin with Galera as SQL-Backend?

[Darrell Budic]

I’ve had it running against a mariadb galera setup for a few years now. Have 
not experienced any issues here. Did not have to take any special actions on 
SpamAssassins side, just pointed it at a dns round robin entry for the backend 
servers and setup appropriate access perms for them. 

  -Darrell

> On May 6, 2022, at 4:08 AM, Niels Kobschätzki  wrote:
> 
> Hi,
> 
> I have a setup where the spamassassin-servers have actually no access to the 
> data of the mail-servers. Now I was looking into having per user 
> bayes-databases and saw that I can do that with a SQL-database. I have 
> already a small galera-cluster and I wonder if spamassassin will work with it 
> because of the limitations galera has.
> The limitations are:
> 
> only innodb
> unsupported explicit locking
> a primary key on all tables is necessary
> no XA transactions
> no reliance on auto-increment
> Does anyone have experience with such a setup?
> 
> Best,
> 
> Niels
> 

Re: IPv6 issue

[Ted Mittelstaedt]

Arg.  Well I think you hit the nail on the head.  And I think I may have
stumbled on to a spam defeating trick.  Here's what I think MAY be going on.

As we all know spammers are the textbook drive by shooters.  They are 
going to try the first A returned from the mailserver just like a 
regular mailer.


The problem for them is that if there is no response from that A record
then normal TCPIP stack is going to wait for a while then eventually 
time out.  When you are sending a bazillion spams you cannot afford to
tie up a process waiting around to see if a remote will eventually 
answer if it does not initially answer right away since at the high rate 
they are sending spams they would rapidly overflow memory on host 
machines, the mules, their bots are using to send out spam.  This would 
then cause those machine owners to investigate and remove those bots.

In addition their mules often operate on dynamic IP zones which are
blocked by many ISPs.  They can't tell if it's a network ACL blocking
them or if the IP simply isn't there.  So their bots try for a 
connection and if there is no response the bot quickly kills the process 
and moves to the next victim.


I did not remove the  records because the IPv6 RFCs require that if
the initial connection tried with IPv6 fails you retry with IPv4.

I SUSPECT the vast majority of mules are compromised systems that have
public IPs most likely end user workstations plugged directly into the
Internet or to cable modems and so on.  These machines have valid 
working IPv6 numbers.  (for example, plug a workstation into a Comcast

cable modem.  It will get a private IPv4 translated number and a public
IPv6 number.)  So their TCPIP stacks will automatically try IPv6 first.

The bot is not then attempting to try the IPv4 number, it's on to the
next victim host in the MX list.

So this makes an interesting possible way to block spammers.  Simply 
define an IPv6 number that does not exist as  for each of your MX hosts.


Legitimate mailservers will retry the IPv4 and complete the connection.

Drive bys cannot afford the time to verify that the IPv6 address is
timing out and then retrying the IPv4 for that host.

It is in effect a sort of tarpit I believe.

You could extend this to defining multiple nonexistent numbers for an
IPv4 host except that DNS does not seem to have a way to force ordering
of multiple IPv4s

Of course, spammers could get around this by recompiling their bots to
use only IPv4.  But then that means RBLs suddenly become extremely 
effective since there are so vastly fewer IPv4 numbers out there.  Also
a bot operating on a compromised mailserver that has a history of 
sending via IPv6 would stick out like a sore thumb and be easy for the

majors to block.

I think I will run the mailserver like this for a few weeks and see
what happens and if there are any user complaints.

Ted

On 5/6/2022 4:40 AM, Greg Troxel wrote:


Ted Mittelstaedt  writes:


For unrelated reasons I had to turn off IPv6 on my incoming mailserver.

Spam plummeted.  Like by 80% at least.  Both uncaught and caught spam did.

When IPv6 was on, the mailserver had all PTR and  and MX records to
allow it to receive incoming mail via IPv6.

Something about this seems really wrong.  Any suggestions of where to
start digging?


Something indeed seems fishy.  I look at uncaught spam to see what I
should tweak on a routine basis, and my impression has been that it's
overwhelmingly either places like gmail (which tend to be delivered over
v6 but would of course come v4 if you don't have v6), or v4.  So being
v4 only and getting 20% of the spam you used to get just doesn't make
sense.

When you "turned off" IPv6, did you change DNS so that doing MX/A/
no longer returned an  record?

Did you notice a reduction in legit mail and an associated increase in
complaints?

When you looked at incoming spam from the time when you had the normal
v4/v6 setup, did you find that most spam arrived over IPv6?

I looked over my own logs.  In the log interval I examined there are
spam counts:

   329 MTA rejects (which I count as 100% spam)
   139 filed as spam by the normal SA standards (>=5)
   26 filed as marginal (>=1 < 5)
   13 filed as ham (<1)

I'm not examining things misfiled as spam that I refiled into ham
folders.  I also skipped about 13 spams misfiled as ham, but on a quick
scan they fit the same pattern.

Looking at the 329 MTA rejects (because that was easiest):

   309  IPv4
20  IPv6

and of the IPv6:

4   gmail

   13a mailinglist/forwarding host (lists I'm on -- they don't filter
well enough)

2   my own v6 address - need to look into this, but pretty sure it
 is external spam logged oddly

1a v6 address with no rDNS that is probably some compromised
 server that happens to have v6 set up.  As far as I can tell
 it is some company in .au.

Looking over the 139 >=5 spams, it's mostly v4, and of the v6, once I
exclude 

Re: Rule syntax in local.cf?

[Bill Cole]

On 2022-05-06 at 10:58:15 UTC-0400 (Fri, 6 May 2022 09:58:15 -0500)
Thomas Cameron 
is rumored to have said:

> Howdy, all -
>
> As I mentioned in a previous email, I'm trying to bump up the score for 
> BAYES_999. I have not messed with SA in years, but I'm trying to get back 
> into it. Sorry if this is a silly question.
>
> I tried to add the following line to /etc/mail/spamassassin/local.cf, but 
> it's not firing:
>
> [root@mail-east ~]# cat /etc/mail/spamassassin/local.cf
> # These values can be overridden by editing ~/.spamassassin/user_prefs.cf
> # (see spamassassin(1) for details)
>
> # These should be safe assumptions and allow for simple visual sifting
> # without risking lost emails.
>
> score SPAM_999 3

Where are you getting that rule name???

> If I'm reading it correctly, it is NOT bumping up the score for BAYES_999, 
> it's only adding the default 0.2 to it.

SA is not clairvoyant or telepathic. It has no idea that you want to change the 
score on BAYES_999 by using the name of a non-existent rule SPAM_999.

> I'm running this on Red Hat Enterprise Linux 8.5. The SA package is 
> spamassassin-3.4.4-4.el8.x86_64.
>
> What am I doing wrong?

Changing the score for a non-existent rule.


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

Intuit servers sending paypal phishes

[Dave Wreski]

Hi, Intuit's servers are being used to send Paypal phishing invoices 
combined with the "evil numbers" scam.


https://pastebin.com/iad07S8N

Received: from o4.e.notification.intuit.com 
(o4.e.notification.intuit.com [167.89.82.160])

X-Spam-Status: No, score=-15.691 tagged_above=-200 required=5
tests=[DKIMWL_WL_HIGH=-0.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01,
T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001,
USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5]

Authentication-Results: orion.example.com;
dkim=pass (2048-bit key; unprotected) header.d=notification.intuit.com 
header.i=@notification.intuit.com header.a=rsa-sha256 header.s=s1 
header.b=p9xDPEcU


--


 DaveWreski

President & CEO

Guardian Digital, Inc.

We Make Email Safe






640-800-9446 

dwre...@guardiandigital.com 

https://guardiandigital.com 

103 Godwin Ave, Suite 314, Midland Park, NJ 07432



facebook    
twitter  
linkedin    

Rule syntax in local.cf?

[Thomas Cameron]

Howdy, all -

As I mentioned in a previous email, I'm trying to bump up the score for 
BAYES_999. I have not messed with SA in years, but I'm trying to get 
back into it. Sorry if this is a silly question.


I tried to add the following line to /etc/mail/spamassassin/local.cf, 
but it's not firing:


[root@mail-east ~]# cat /etc/mail/spamassassin/local.cf
# These values can be overridden by editing ~/.spamassassin/user_prefs.cf
# (see spamassassin(1) for details)

# These should be safe assumptions and allow for simple visual sifting
# without risking lost emails.

score SPAM_999 3

required_hits 5
report_safe 0
rewrite_header Subject [SPAM _SCORE_]

What I am seeing when I run spamassassin -D < mail/INBOX/spam looks like 
this:



From powerpl...@sqribblemoney.cam  Fri May  6 14:28:32 2022
Return-Path: 
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
    mail.redacted.foo
X-Spam-Flag: YES
X-Spam-Level: *
X-Spam-Status: Yes, score=9.3 required=5.0 tests=BAYES_99,BAYES_999,
HTML_IMAGE_ONLY_20,HTML_MESSAGE,HTML_SHORT_LINK_IMG_3,KHOP_HELO_FCRDNS,
    MAY_BE_FORGED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,
    URIBL_ABUSE_SURBL,URIBL_BLACK autolearn=disabled version=3.4.4
X-Spam-Report:
    *  1.2 URIBL_ABUSE_SURBL Contains an URL listed in the ABUSE SURBL
    *  blocklist
    *  [URIs: sqribblemoney.cam]
    *  3.5 BAYES_99 BODY: Bayes May  6 14:46:39.902 [8259] dbg: 
check: tagrun - tag DKIMDOMAIN is still blocking action 1
May  6 14:46:39.905 [8259] dbg: plugin: 
Mail::SpamAssassin::Plugin::MIMEHeader=HASH(0x5567f8e09e90) implements 
'finish_tests', priority 0
May  6 14:46:39.905 [8259] dbg: plugin: 
Mail::SpamAssassin::Plugin::Check=HASH(0x5567f8e0a430) implements 
'finish_tests', priority 0
May  6 14:46:39.922 [8259] dbg: netset: cache trusted_networks 
hits/attempts: 11/12, 91.7 %

spam probability is 99 to 100%
    *  [score: 1.]
    *  0.2 BAYES_999 BODY: Bayes spam probability is 99.9 to 100%
    *  [score: 1.]
    *  1.7 URIBL_BLACK Contains an URL listed in the URIBL blacklist
    *  [URIs: sqribblemoney.cam]
    *  0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
    *  0.0 SPF_NONE SPF: sender does not publish an SPF Record
    *  1.5 HTML_IMAGE_ONLY_20 BODY: HTML: images with 1600-2000 
bytes of

    *  words
    *  0.0 HTML_MESSAGE BODY: HTML included in message
    * -0.0 T_SCC_BODY_TEXT_LINE No description available.
    *  0.1 HTML_SHORT_LINK_IMG_3 HTML is very short with a linked image
    *  1.0 MAY_BE_FORGED Relay IP's reverse DNS does not resolve to IP
    *  0.0 KHOP_HELO_FCRDNS Relay HELO differs from its IP's 
reverse DNS



If I'm reading it correctly, it is NOT bumping up the score for 
BAYES_999, it's only adding the default 0.2 to it.


I'm running this on Red Hat Enterprise Linux 8.5. The SA package is 
spamassassin-3.4.4-4.el8.x86_64.


What am I doing wrong?

Thomas

Re: Spamassassin with Galera as SQL-Backend?

[Benny Pedersen]

On 2022-05-06 12:21, Niels Kobschätzki wrote:


But I read that redis doesn’t have per-user databases?


nope, pr user bayes needs one database in redis, not multiple pr user


And I probably
would need new machines with lots of RAM for it, because I have no
idea how much RAM is needed per user.


only redis works better if have Gb range of ram, while postgresql keep 
it at Mb og ram



And I already have a galera-cluster running and don’t want to set up
yet another database-cluster (psql).


redis can be clustered aswell :=)

even sqlite3 can be clustered

i only have fokus on ram usage, not what tool used



Niels

Re: IPv6 issue

[Greg Troxel]

Ted Mittelstaedt  writes:

> For unrelated reasons I had to turn off IPv6 on my incoming mailserver.
>
> Spam plummeted.  Like by 80% at least.  Both uncaught and caught spam did.
>
> When IPv6 was on, the mailserver had all PTR and  and MX records to
> allow it to receive incoming mail via IPv6.
>
> Something about this seems really wrong.  Any suggestions of where to
> start digging?

Something indeed seems fishy.  I look at uncaught spam to see what I
should tweak on a routine basis, and my impression has been that it's
overwhelmingly either places like gmail (which tend to be delivered over
v6 but would of course come v4 if you don't have v6), or v4.  So being
v4 only and getting 20% of the spam you used to get just doesn't make
sense.

When you "turned off" IPv6, did you change DNS so that doing MX/A/
no longer returned an  record?

Did you notice a reduction in legit mail and an associated increase in
complaints?

When you looked at incoming spam from the time when you had the normal
v4/v6 setup, did you find that most spam arrived over IPv6?

I looked over my own logs.  In the log interval I examined there are
spam counts:

  329 MTA rejects (which I count as 100% spam)
  139 filed as spam by the normal SA standards (>=5)
  26 filed as marginal (>=1 < 5)
  13 filed as ham (<1)

I'm not examining things misfiled as spam that I refiled into ham
folders.  I also skipped about 13 spams misfiled as ham, but on a quick
scan they fit the same pattern.

Looking at the 329 MTA rejects (because that was easiest):

  309   IPv4
   20   IPv6

and of the IPv6:

   4gmail

  13a mailinglist/forwarding host (lists I'm on -- they don't filter
well enough)

   2my own v6 address - need to look into this, but pretty sure it
is external spam logged oddly

   1a v6 address with no rDNS that is probably some compromised
server that happens to have v6 set up.  As far as I can tell
it is some company in .au.

Looking over the 139 >=5 spams, it's mostly v4, and of the v6, once I
exclude google and the same mailinglist, there is only1 v6 address, this
time a random company in .es.

So for me, spam over v6 is very rare, except for mailinglists without
adequately strict filtering and google (which we all know doesn't do a
good enough job of outgoing filtering, but that's not about v6).

Thus, I don't know what to make of your experience; something about it
must be very different and understanding that is likely interesting.


signature.asc
Description: PGP signature

Re: Spamassassin with Galera as SQL-Backend?

[Henrik K]

On Fri, May 06, 2022 at 12:31:47PM +0200, giova...@paclan.it wrote:
> On 5/6/22 11:08, Niels Kobschätzki wrote:
> > Hi,
> > 
> > I have a setup where the spamassassin-servers have actually no access to 
> > the data of the mail-servers. Now I was looking into having per user 
> > bayes-databases and saw that I can do that with a SQL-database. I have 
> > already a small galera-cluster and I wonder if spamassassin will work with 
> > it because of the limitations galera has.
> > The limitations are:
> > 
> >   * only innodb
> >   * unsupported explicit locking
> >   * a primary key on all tables is necessary
> >   * no XA transactions
> >   * no reliance on auto-increment
> > 
> > Does anyone have experience with such a setup?
> > 
> Few things to consider:
> bayes_expire has no primary key.

>From what I see, there's no reason why it shouldn't be.

CREATE TABLE bayes_expire (
  id int(11) NOT NULL default '0',
  runtime int(11) NOT NULL default '0',
  KEY bayes_expire_idx1 (id)
) ENGINE=InnoDB;

BayesStore/MySQL.pm has kind of a dumb insert which might insert things 
multiple times

  my $sql = "INSERT INTO bayes_expire (id,runtime) VALUES (?,?)";

It should just be converted to UPSERT.

Of course this won't help until 4.0.0 is released..

> bayes_vars MySQL table has the id defined as "id int(11) NOT NULL 
> AUTO_INCREMENT".

Google implies Galera supports auto_increment just fine, it just does
something funny like incrementing them in 3 multiples or something.

Re: Spamassassin with Galera as SQL-Backend?

[giovanni]

On 5/6/22 11:08, Niels Kobschätzki wrote:
> Hi,
> 
> I have a setup where the spamassassin-servers have actually no access to the 
> data of the mail-servers. Now I was looking into having per user 
> bayes-databases and saw that I can do that with a SQL-database. I have 
> already a small galera-cluster and I wonder if spamassassin will work with it 
> because of the limitations galera has.
> The limitations are:
> 
>   * only innodb
>   * unsupported explicit locking
>   * a primary key on all tables is necessary
>   * no XA transactions
>   * no reliance on auto-increment
> 
> Does anyone have experience with such a setup?
> 
Few things to consider:
bayes_expire has no primary key.
bayes_vars MySQL table has the id defined as "id int(11) NOT NULL 
AUTO_INCREMENT".

Actually I have no idea if this could be a blocker for you, there should be no 
problem if you do not use Bayes anyway.

 Giovanni


OpenPGP_signature
Description: OpenPGP digital signature

IPv6 issue

[Ted Mittelstaedt]

Hi All,

I hope this does not start a holy war.

For unrelated reasons I had to turn off IPv6 on my incoming mailserver.

Spam plummeted.  Like by 80% at least.  Both uncaught and caught spam did.

When IPv6 was on, the mailserver had all PTR and  and MX records to
allow it to receive incoming mail via IPv6.

Something about this seems really wrong.  Any suggestions of where to
start digging?

Ted

Re: Spamassassin with Galera as SQL-Backend?

[Niels Kobschätzki]

On 6 May 2022, at 11:31, Benny Pedersen wrote:

> On 2022-05-06 11:25, Henrik K wrote:
>> On Fri, May 06, 2022 at 11:08:21AM +0200, Niels Kobschätzki wrote:
>>> Hi,
>>>
>>> I have a setup where the spamassassin-servers have actually no access to the
>>> data of the mail-servers. Now I was looking into having per user
>>> bayes-databases and saw that I can do that with a SQL-database. I have 
>>> already
>>> a small galera-cluster and I wonder if spamassassin will work with it 
>>> because
>>> of the limitations galera has.
>>> The limitations are:
>>>
>>>   * only innodb
>>>   * unsupported explicit locking
>>>   * a primary key on all tables is necessary
>>>   * no XA transactions
>>>   * no reliance on auto-increment
>>>
>>> Does anyone have experience with such a setup?
>>
>> I see no reason why it wouldn't work, none of the limitations should apply
>> to SpamAssassin.

Great :)
I’d rather be safe than sorry and like to ask.

> fair, its just that redis is more prefered to bayes imho, and postgresql is 
> high performance without being memory hungry

But I read that redis doesn’t have per-user databases? And I probably would 
need new machines with lots of RAM for it, because I have no idea how much RAM 
is needed per user.
And I already have a galera-cluster running and don’t want to set up yet 
another database-cluster (psql).

Niels

signature.asc
Description: OpenPGP digital signature

Re: Spamassassin with Galera as SQL-Backend?

[Benny Pedersen]

On 2022-05-06 11:25, Henrik K wrote:

On Fri, May 06, 2022 at 11:08:21AM +0200, Niels Kobschätzki wrote:

Hi,

I have a setup where the spamassassin-servers have actually no access 
to the

data of the mail-servers. Now I was looking into having per user
bayes-databases and saw that I can do that with a SQL-database. I have 
already
a small galera-cluster and I wonder if spamassassin will work with it 
because

of the limitations galera has.
The limitations are:

  * only innodb
  * unsupported explicit locking
  * a primary key on all tables is necessary
  * no XA transactions
  * no reliance on auto-increment

Does anyone have experience with such a setup?


I see no reason why it wouldn't work, none of the limitations should 
apply

to SpamAssassin.


fair, its just that redis is more prefered to bayes imho, and postgresql 
is high performance without being memory hungry

Re: Spamassassin with Galera as SQL-Backend?

[Henrik K]

On Fri, May 06, 2022 at 11:08:21AM +0200, Niels Kobschätzki wrote:
> Hi,
> 
> I have a setup where the spamassassin-servers have actually no access to the
> data of the mail-servers. Now I was looking into having per user
> bayes-databases and saw that I can do that with a SQL-database. I have already
> a small galera-cluster and I wonder if spamassassin will work with it because
> of the limitations galera has.
> The limitations are:
> 
>   * only innodb
>   * unsupported explicit locking
>   * a primary key on all tables is necessary
>   * no XA transactions
>   * no reliance on auto-increment
> 
> Does anyone have experience with such a setup?

I see no reason why it wouldn't work, none of the limitations should apply
to SpamAssassin.

Spamassassin with Galera as SQL-Backend?

[Niels Kobschätzki]

Hi,

I have a setup where the spamassassin-servers have actually no access to the 
data of the mail-servers. Now I was looking into having per user 
bayes-databases and saw that I can do that with a SQL-database. I have already 
a small galera-cluster and I wonder if spamassassin will work with it because 
of the limitations galera has.
The limitations are:
- only innodb
- unsupported explicit locking
- a primary key on all tables is necessary
- no XA transactions
- no reliance on auto-increment

Does anyone have experience with such a setup?

Best,

Niels

signature.asc
Description: OpenPGP digital signature

Re: SPF skipped for whitelisted relay domain

[Benny Pedersen]

On 2022-05-06 05:35, Kevin A. McGrail wrote:

Hi Alex, sometimes I see this when the envelope from doesn't match the
header from. So what you think might pass SPF does not. That's my only
guess from looking at the example you posted. That example looked like
it would work perfectly.


we wait for spamassassin 4.0.0 :=)

amavisd does not know anything about spf btw


X-Comment: SPF skipped for whitelisted relay domain -
client-ip=13.110.6.221; helo=smtp14-ph2-sp4.mta.salesforce.com [1];
envelope-from=re...@support.meridianlink.com; receiver=


mail::spf does not know this header, its seen as no spf is done

set pypolicyspf to add A-R headers

Re: SPF skipped for whitelisted relay domain

[Matus UHLAR - fantomas]

On 05.05.22 18:01, Alex wrote:

I'm trying to understand why some domains are not whitelisted even
though they pass SPF and are in my local welcomelist_auth entries. I'm
using policyd-spf with postfix, and it appears to be adding the
following header:

X-Comment: SPF skipped for whitelisted relay domain -
client-ip=13.110.6.221; helo=smtp14-ph2-sp4.mta.salesforce.com;
envelope-from=re...@support.meridianlink.com; receiver=


you seem to have domain listed in whitelist policyd-spf whitelist.
salesforce.com probably?

I'm not sure if this is needed, policyd-spf could add Received-SPF: header 
that SA could use (and avoid duplicate lookups)



I realize this may not necessarily be directly related to SA, but it's
apparently affecting my ability to process SPF headers with
amavisd/SA, and I hoped someone could help.

What's happening where the mail passes SPF but still bypasses my
welcomelist entries? My skip_addresses list doesn't include this
particular IP:
skip_addresses =
139.138.56.0/24,127.0.0.0/8,:::127.0.0.0/104,::1,52.128.98.0/24,74.203.184.0/24,74.200.60.0/24,209.222.82.0/24,12.15.90.10


My welcomelist entry in SA for this specific email is as:
welcomelist_auth re...@support.meridianlink.com


is this in spamassassin's local.cf ?


The amavisd headers show it passed SPF:

Return-Path: 
X-Spam-Status: No, score=-2.491 tagged_above=-200 required=5
   tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
   DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, EXTRACTTEXT=0.001,
   FMBLA_HELO_OUTMX=-0.01, FMBLA_RDNS_OUTMX=-0.01,
   HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, LOC_CDIS_INLINE=0.1,
   LOC_IMGSPAM=0.1, RCVD_IN_DNSWL_NONE=-0.0001,
   RCVD_IN_SENDERSCORE_90_100=-0.6, RELAYCOUNTRY_US=0.01,
   SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TXREP=0.016] autolearn=disabled

This one didn't need to be added to the welcomelist, but others do.
The last header received before reaching our server is as:

Received: from smtp14-ph2-sp4.mta.salesforce.com
(smtp14-ph2-sp4.mta.salesforce.com [13.110.6.221])
   (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
   (No client certificate requested)
   by mail01.example.com (Postfix) with ESMTPS id 5FC7010024E93
   for ; Thu,  5 May 2022 12:01:59 -0400 (EDT)

salesforce is also listed in their SPF record:
$ dig +short txt support.meridianlink.com
"v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com -all"


SPF_PASS idicates that the SPF hit. 


however, posting full headers could help us a bit.

--
Matus UHLAR - fantomas, uh...@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.
"They say when you play that M$ CD backward you can hear satanic messages."
"That's nothing. If you play it forward it will install Windows."