Re: double backslash in the log messages

2024-05-22 Thread Vincent Lefevre
On 2024-05-21 13:42:23 -0400, Bill Cole wrote:
> On 2024-05-21 at 11:00:57 UTC-0400 (Tue, 21 May 2024 17:00:57 +0200)
> Vincent Lefevre 
> is rumored to have said:
> 
> > While testing a rule with SpamAssassin 4.0.0 under Debian/stable
> > (I wasn't aware of allow_user_rules yet, but this is not the issue
> > I'm reported):
> > 
> > 2024-05-21T16:42:42.792136+02:00 joooj spamd[219339]: config: not
> > parsing, 'allow_user_rules' is 0: header LOCAL_TO_LORIA ToCc =~
> > /loria\\.fr/i
> > 2024-05-21T16:42:42.793753+02:00 joooj spamd[219339]: config: failed to
> > parse line in /srv/d_joooj/home/vinc17/.spamassassin/user_prefs (line
> > 192): header LOCAL_TO_LORIA ToCc =~ /loria\\.fr/i
> > 
> > while I just had /loria\.fr/i (with a single backslash) in my
> > user_prefs config file.
> > 
> > Is there a reason to have a double backslash in the log messages
> > or is this a bug?
> 
> It is intentional to assure that log messages (which may include strings
> from tainted sources) have all common meta-characters escaped.

After looking at the source (Logger.pm), these are actually control
and non-ASCII characters that are escaped so that they can be printed.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


double backslash in the log messages

2024-05-21 Thread Vincent Lefevre
While testing a rule with SpamAssassin 4.0.0 under Debian/stable
(I wasn't aware of allow_user_rules yet, but this is not the issue
I'm reported):

2024-05-21T16:42:42.792136+02:00 joooj spamd[219339]: config: not parsing, 
'allow_user_rules' is 0: header LOCAL_TO_LORIA ToCc =~ /loria\\.fr/i
2024-05-21T16:42:42.793753+02:00 joooj spamd[219339]: config: failed to parse 
line in /srv/d_joooj/home/vinc17/.spamassassin/user_prefs (line 192): header 
LOCAL_TO_LORIA ToCc =~ /loria\\.fr/i

while I just had /loria\.fr/i (with a single backslash) in my
user_prefs config file.

Is there a reason to have a double backslash in the log messages
or is this a bug?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Re: Score 0.001

2024-05-11 Thread Vincent Lefevre
On 2024-05-11 20:26:59 +0200, Thomas Barth wrote:
> Am 2024-05-11 19:24, schrieb Loren Wilton:
[...]
> > > found in
> > > 
> > > X-Spam-Status: No, score=5.908 tagged_above=2 required=6.31
> > > tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
> > > DKIM_VALID_EF=-0.1, DMARC_PASS=-0.001, FSL_BULK_SIG=0.001,
> > > HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=2.43,
> > > RAZOR2_CHECK=1.729,
> > > SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_ABUSE_SURBL=1.948]
> > 
> > Why is your score threshold for spam 6.31? By default it is 5, and that
> > message would have been spam.
> 
> 6.31 has been the default value on a Debian system for ages and is based on
> the experience of the “spam analysts”.

No, Debian has not changed the default, which is 5.0, as I can see
for your message (here, on a Debian/stable machine):

X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on joooj.vinc17.net
X-Spam-Status: No, score=-17.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,DMARC_PASS,HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H4,
RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,USER_IN_DEF_SPF_WL
autolearn=ham autolearn_force=no version=4.0.0

The value 6.31 does not even appear in the spamassassin source
package.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Re: spamd: still running as root

2023-10-30 Thread Vincent Lefevre
On 2023-10-30 16:45:31 +, Linkcheck via users wrote:
> I have just updated Debian to Bookworm in order to install SA 4. Very few
> problems so far but the postfix log is giving:
> 
> "spamd: still running as root: user not specified with -u, not found, or set
> to root, falling back to nobody"
> 
> I am not sure where to specify an appropriate user (and possibly how and
> what). Help, please?
> 
> In /etc/default/spamassassin I have...

AFAIK, /etc/default/spamassassin is no longer used. The config
file in Debian is now "/etc/default/spamd". This is what I have
on my new bookworm machine.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Re: subscribe to blacklist for domains

2022-08-23 Thread Vincent Lefevre
On 2022-08-23 14:31:55 +0100, Martin Gregorie wrote:
> Fair enough: I did say that some of this was off the top pf my head at
> the end of a longish day.
> 
> Would doing the lookup trick on the URL in the Message-ID header be any
> more reliable?

DNS Lookup checking is valid only for IP -> FQDN -> IP, not
FQDN -> IP -> FQDN, whatever the FQDN.

Note also that the Message-ID is not a URL, just some kind of
identifier with some syntax and that must be unique. In general,
you shouldn't assume anything on the right-hand side of a
Message-ID. RFC 5322 just says:

  As with addr-spec, a liberal syntax is given for the right-hand side
  of the "@" in a msg-id. However, later in this section, the use of a
  domain for the right-hand side of the "@" is RECOMMENDED.

In particular, it doesn't need to be resolvable, and there are
good reasons for which this may not be the case. For instance,
the Message-ID may be generated on the machine from which the
message is sent, with some internal hostname on the right-hand
side (this is better to ensure unicity), thus is not resolvable.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Re: subscribe to blacklist for domains

2022-08-23 Thread Vincent Lefevre
On 2022-08-18 19:40:33 +0100, Martin Gregorie wrote:
> - extract the domain name from the incoming mail's From header and use 
>   it to find the domain IP. Use that IP to do a reverse domain lookup.
> 
> - if the reverse lookup fails, or the domain it retrieved does not match
>   the one in the From address, send a bare 550 REJECT because the failed
>   reverse lookup implies the sending domain is a forgery. 

It doesn't. There are IPs that host several domains, e.g. in case
of shared web hosting. For instance, I have 2 domains vinc17.net
and vinc17.org, and both are handled by the same machine, thus
with a single IP address. So, necessarily, the reverse lookup will
not match for one of these domains.

BTW, for spamassassin.apache.org, it resolves to 151.101.2.132, but
the reverse lookup fails.

And anyway, this is about mail, so the only thing that could really
be considered is the MX. But the MX domains may be different from
the "From:" domain, even if the domain has its own range of IP
addresses. For instance:

$ dig -t mx ens-lyon.fr
[...]
;; ANSWER SECTION:
ens-lyon.fr.6754IN  MX  20 mxc.relay.renater.fr.
ens-lyon.fr.6754IN  MX  20 mxd.relay.renater.fr.
ens-lyon.fr.6754IN  MX  20 mxa.relay.renater.fr.
ens-lyon.fr.6754IN  MX  20 mxb.relay.renater.fr.
[...]

The only thing that you may want to do is a reverse lookup of the
client IP, then check that the answer resolves back to the IP (among
the answers, as there may be several IP addresses).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Re: subscribe to blacklist for domains

2022-08-23 Thread Vincent Lefevre
On 2022-08-18 12:11:04 -0400, Kris Deugau wrote:
> Mmm.  So how would you, as sender or sender's mail provider, troubleshoot a
> message rejected with "550 Too spammy"?  I have seen several rejections that
> were equally clear and to the point, without divulging any particular detail
> about what, exactly, was objectionable.

I doubt that spammers take 550 messages into account, or even read them.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Re: subscribe to blacklist for domains

2022-08-17 Thread Vincent Lefevre
On 2022-08-16 12:05:43 -0400, Kris Deugau wrote:
> Vincent Lefevre wrote:
> > On 2022-08-15 10:39:05 -0400, Kris Deugau wrote:
> > > Vincent Lefevre wrote:
> > > > Rejecting mail (instead of accepting it and dropping it) is useful
> > > > in case of false positives.
> > > 
> > > I'm a bit torn on this.
> > > 
> > > On the one hand, yes, the sender now knows for sure their message didn't 
> > > get
> > > through*.
> > > 
> > > On the other hand, the sender now calls *their* outgoing mail provider to
> > > complain "You wouldn't let my message through!", and trying to explain to
> > > someone that no, really, we can't do anything about this because it's the
> > > recipient's system that doesn't like you is sometimes painfully 
> > > tedious.
> > 
> > Well, the outgoing mail provider (or IP address supplier) is sometimes
> > the culprit, e.g. by letting spam out.
> 
> True.  But if spam filters everywhere were perfect, spam wouldn't be such a
> big problem.
> 
> And, quite reasonably, most rejections for spam include very little or no
> detail, so aside from DNSBL-based rejections the sending platform has
> essentially zero information beyond "the receiving system doesn't like us".
> Which can't be troubleshot from the sending side without at least some kind
> of feedback from the receiving side.

Minimal information should at least be included with the 550 status.
This is also useful for the receiving side in order to know whether
the antispam rules are effective (by checking the logs).

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Re: subscribe to blacklist for domains

2022-08-16 Thread Vincent Lefevre
On 2022-08-15 11:33:53 -0400, Greg Troxel wrote:
> Vincent Lefevre  writes:
> > On 2022-08-13 14:05:43 -0400, joe a wrote:
> >> On 8/13/2022 12:38 PM, Martin Gregorie wrote:
> >> . . .
> >> > 2) There's no mandatory need to REJECT spam. It has always been up to
> >> > the recipient to decide whether to return it to the sender or not.
> >> 
> >> Agreed in part.  I see returning SPAM to sender as an exercise in futility
> >> or perhaps further enabling.  But I do prefer labeling as SPAM to outright
> >> rejection in many cases.
> 
> Be careful in "returning".  There is replying with 550 and not accepting
> it, which ensures that *you* are not generating backscatter, and there
> is sending a bounce later.   I think that if you're going to reject it,
> you should 550 it.

Yes, this is a 550 SMTP reply.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Re: subscribe to blacklist for domains

2022-08-16 Thread Vincent Lefevre
On 2022-08-15 10:39:05 -0400, Kris Deugau wrote:
> Vincent Lefevre wrote:
> > Rejecting mail (instead of accepting it and dropping it) is useful
> > in case of false positives.
> 
> I'm a bit torn on this.
> 
> On the one hand, yes, the sender now knows for sure their message didn't get
> through*.
> 
> On the other hand, the sender now calls *their* outgoing mail provider to
> complain "You wouldn't let my message through!", and trying to explain to
> someone that no, really, we can't do anything about this because it's the
> recipient's system that doesn't like you is sometimes painfully tedious.

Well, the outgoing mail provider (or IP address supplier) is sometimes
the culprit, e.g. by letting spam out.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Re: subscribe to blacklist for domains

2022-08-13 Thread Vincent Lefevre
On 2022-08-13 19:09:26 -0400, joe a wrote:
> On 8/13/2022 4:52 PM, Vincent Lefevre wrote:
> > Well, if you don't reject the mail with the reason that the address
> > is invalid, the spammer could deduce that the address is valid
> > (at least potentially valid). By not rejecting spam, the spammer
> > could think that the spam arrived at its destination and would
> > validate the address.
> 
> Rejecting mail for an invalid recipient was not my concern.  In the case of
> an invalid email address is certainly proper to inform the sender of that
> fact.
> 
> I could even agree that informing senders of "false positives" is useful as
> well, but doing that via a "REJECT" would seem burdensome. REJECT-ing email
> that is flagged by one of the DNS RBL thingies still seems to me to be
> wasted effort and possibly counter productive.

There may be false positives. For instance, the mail server
(smarthost) of my laboratory occasionally gets flagged by RBLs
because the accounts of some users gets compromised and start
to become a spam relay. But the smarthost still sends legitimate
mail and the sender should be able to know that mail he has sent
is rejected because of the blacklists.

> Why waste your own system resources to help a scoundrel?  Drop them and be
> done.

The resources of the recipient are not wasted: the only difference
is the status code returned to the sender. The resources of the
sender may be "wasted", but:
  * If the message is legitimate (false positive), this allows the
sender to know that the message has not been received.
  * If the message is really spam, this may waste the resources of
the spammer, but who cares...

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Re: subscribe to blacklist for domains

2022-08-13 Thread Vincent Lefevre
On 2022-08-13 14:05:43 -0400, joe a wrote:
> On 8/13/2022 12:38 PM, Martin Gregorie wrote:
> . . .
> > 2) There's no mandatory need to REJECT spam. It has always been up to
> > the recipient to decide whether to return it to the sender or not.
> 
> Agreed in part.  I see returning SPAM to sender as an exercise in futility
> or perhaps further enabling.  But I do prefer labeling as SPAM to outright
> rejection in many cases.

Rejecting mail (instead of accepting it and dropping it) is useful
in case of false positives.

> > 3) It would be rather trivial to return spam to sender with a suitable
> > admonishment but I decided that its not worth my time to write such
> > a discriminator and maintain yet another set of rules about what gets
> > quarantined and what gets returned: better to quarantine it so
> > it can be analysed with the mk 1 eyeball.
> 
> To add my comment, returning SPAM, assuming it even reaches the original
> sender, may serve only to assure them of the effectiveness of their campaign
> to reach valid addresses. In effect "helping" them.

Well, if you don't reject the mail with the reason that the address
is invalid, the spammer could deduce that the address is valid
(at least potentially valid). By not rejecting spam, the spammer
could think that the spam arrived at its destination and would
validate the address.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Re: getting waring from spamassassin.apache.org

2022-07-13 Thread Vincent Lefevre
On 2022-07-13 09:17:41 -0400, Bill Cole wrote:
> On 2022-07-13 at 05:14:19 UTC-0400 (Wed, 13 Jul 2022 11:14:19 +0200)
> Philipp Ewald 
> is rumored to have said:
> 
> > Yesterdax i got a waring, because of a bounced massage.
> > Is this normal thats this Waring was from 2021?
> 
> I do not know what caused it, but I also got 2 such notices which
> both were from 2020.
> 
> My guess would be that there was a stuck mail queue of such notices
> somewhere in the Apache mailing list infrastructure that got unstuck
> somehow. Possibly related to a migration project for mailing lists that the
> ASF Infra team has warned us was in progress a few weeks ago.

I also got several such notices, but for subversion.apache.org
mailing-lists, from 2019 and 2020. So indeed, this seems to be
global to Apache mailing-lists.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Re: shit from serverion

2022-07-11 Thread Vincent Lefevre
On 2022-06-30 13:34:56 +, Pedro David Marco wrote:
>>On Thursday, June 30, 2022, 09:12:59 AM GMT+2, Benoit Panizzon 
>  wrote:  >>All my attempts to reach out to 
> ab...@serverion.com or any other
> >contacts found on their website remained unreplied.
> 
> When a company does that  they deserve to be sent to /dev/null

It is probably useless to contact them: Having many IP addresses
blacklisted by major RBLs for months means that they do not care.
This is the case for serverion: my logs show many rejects due to
zen.spamhaus.org and b.barracudacentral.org. This includes snowshoe
spam (sent by consecutive IP addresses during the same day).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Re: shit from serverion

2022-06-29 Thread Vincent Lefevre
On 2022-06-29 13:14:58 +, Marc wrote:
> Today I decided to spend some time getting all the ip's[1] (these
> are all /24 thus you have to add 164.215.103.1-164.215.103.255) of
> serverion, who is sending out constant stream of crap. I thought
> about posting it here so you do not need to do this work. If you do
> some random checks, you can see this looks weird[2]. Do as you
> please with this info.

FYI, I'm rejecting them at the postfix level. Here are all the blocks
from which I've received spam and blocked afterwards:

# Serverion / Des Capital B.V. (2021-08 / 2022-05)
2.56.56.0/22 REJECT Blacklisted (SERVER-2-56-56-0 / Serverion BV, NL)
2.58.148.0/22 REJECT Blacklisted (SERVER-2-58-148-0 / Serverion BV, NL)
31.210.20.0/24 REJECT Blacklisted (SERVER-31-210-20-0 / Serverion BV, NL)
31.210.22.0/24 REJECT Blacklisted (SERVER-31-210-22-0 / Serverion BV, NL)
37.0.8.0/21 REJECT Blacklisted (SERVER-37-0-8/12-0 / Serverion BV, NL)
45.85.90.0/24 REJECT Blacklisted (SERVER-45-85-90-0 / Serverion BV, NL)
45.133.1.0/24 REJECT Blacklisted (SERVER-45-133-1-0 / Serverion BV, NL)
45.134.23.0/24 REJECT Blacklisted (SERVER-45-134-23-0 / Serverion BV, NL)
45.144.225.0/24 REJECT Blacklisted (SERVER-45-144-225-0 / Serverion BV, NL)
45.144.226.0/24 REJECT Blacklisted (SERVER-45-144-226-0 / Serverion BV, NL)
62.197.136.0/24 REJECT Blacklisted (SERVER-62-197-136-0 / Serverion BV, NL)
85.202.168.0/24 REJECT Blacklisted (SERVER-85-202-168-0 / Serverion BV, NL)
107.182.131.0/24 REJECT Blacklisted (Serverion LLC, DE)
136.144.41.0/24 REJECT Blacklisted (SERVER-136-144-41-0 / Serverion BV, NL)
185.102.170.0/23 REJECT Blacklisted (SERVER-185-102-170-0 / Serverion BV, NL)
185.239.242.0/24 REJECT Blacklisted (SERVER-185-239-242-0 / Serverion BV, NL)
193.233.182.0/24 REJECT Blacklisted (Serverion / Des Capital B.V., NL)
194.31.98.0/24 REJECT Blacklisted (SERVER-194-31-98-0 / Serverion BV, NL)
194.99.45.0/24 REJECT Blacklisted (SERVER-194-99-44-0 / Serverion BV, NL)
195.133.18.0/24 REJECT Blacklisted (US-DELIS-20210528 / Des Capital B.V., NL)
195.133.38.0/24 REJECT Blacklisted (Serverion, NL)
195.133.39.0/24 REJECT Blacklisted (Serverion, NL)
212.192.216.0/22 REJECT Blacklisted (Serverion, NL)
212.192.244.0/22 REJECT Blacklisted (Serverion, NL)

I check the logs from time to time, and I haven't see any
false positive (in the sense that the few logged data give
a good indication of real spam).

I have the same kind of things for DATACLUB, DigitalOcean, EONIX,
LAYER-HOST, RootLayer and UCLOUD-NET (though spam from DATACLUB IPs
seems to have stopped, and also almost for EONIX).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Re: message with autolearn=no is ignored by sa-learn

2022-06-14 Thread Vincent Lefevre
On 2022-06-14 13:39:29 +0200, Reindl Harald wrote:
> Am 14.06.22 um 13:36 schrieb Vincent Lefevre:
> > When? The message has autolearn=no, so it wasn't trained when
> > passed via SpamAssassin while it was received. Then it was in
> > my main mailbox, where there's no training
> 
> spam messages often appear more than once

I had searched for other copies in my "junk" mailbox, but forgot
that when the spam score was too high, I was directly discarding
the message instead of storing it to this mailbox.

Indeed, I can see in my logs that I received several of them,
including with autolearn=spam, with very high spam scores for
all of them.

Sorry for the noise.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Re: message with autolearn=no is ignored by sa-learn

2022-06-14 Thread Vincent Lefevre
On 2022-06-14 12:13:10 +0200, Reindl Harald wrote:
> Am 14.06.22 um 11:52 schrieb Vincent Lefevre:
> > On a machine with spamassassin 3.4.6 under Debian 11, a new spam
> > arrived, and the headers showed:
> > 
> > X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on joooj.vinc17.net
> > X-Spam-Level: 
> > X-Spam-Status: No, score=4.9 required=5.0 
> > tests=BAYES_50,HTML_IMAGE_RATIO_02,
> >  HTML_MESSAGE,KHOP_HELO_FCRDNS,MIME_HTML_ONLY,SPF_HELO_NEUTRAL,
> >  SPF_NEUTRAL,T_SCC_BODY_TEXT_LINE,URIBL_BLACK,YOUR_DELIVERY_ADDRESS
> >  autolearn=no autolearn_force=no version=3.4.6
> > X-Spam-Language: en
> > 
> > Since it has autolearn=no, I assume that it wasn't learnt as spam.
> > So I piped it to "sa-learn --spam --no-sync", but I got
> > 
> > Learned tokens from 0 message(s) (1 message(s) examined)
> > 
> > Why "from 0 message(s)"?
> 
> because the exactly same message was likely already trained

When? The message has autolearn=no, so it wasn't trained when
passed via SpamAssassin while it was received. Then it was in
my main mailbox, where there's no training.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


message with autolearn=no is ignored by sa-learn

2022-06-14 Thread Vincent Lefevre
Hi,

On a machine with spamassassin 3.4.6 under Debian 11, a new spam
arrived, and the headers showed:

X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on joooj.vinc17.net
X-Spam-Level: 
X-Spam-Status: No, score=4.9 required=5.0 tests=BAYES_50,HTML_IMAGE_RATIO_02,
HTML_MESSAGE,KHOP_HELO_FCRDNS,MIME_HTML_ONLY,SPF_HELO_NEUTRAL,
SPF_NEUTRAL,T_SCC_BODY_TEXT_LINE,URIBL_BLACK,YOUR_DELIVERY_ADDRESS
autolearn=no autolearn_force=no version=3.4.6
X-Spam-Language: en

Since it has autolearn=no, I assume that it wasn't learnt as spam.
So I piped it to "sa-learn --spam --no-sync", but I got

Learned tokens from 0 message(s) (1 message(s) examined)

Why "from 0 message(s)"?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)