Mailing List Archive

On 18 Dec 2019, at 22:34, Philip wrote:

> How do I white list this mailing list for some reason all the messages
> are now going to spam.

If you can whitelist on arbitrary headers:

List-Id: <users.spamassassin.apache.org>
Delivered-To: mailing list users@spamassassin.apache.org

If you know what exactly is causing the "going to spam" problem, maybe
you can fix that...

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

Philip skrev den 2019-12-19 04:34:
> How do I white list this mailing list for some reason all the messages
> are now going to spam.

X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
localhost.junc.eu
X-Spam-Status: No, score=-2.0, required=5.0, Autolearn=no
autolearn_force=no,
LastExt=207.244.88.153 Shortcircuit=no,none
X-Spam-Rules_score: BAYES_00=-1.9,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1,MAILING_LIST_MULTI=-1,RCVD_IN_DNSWL_NONE=-0.0001,
SPF_HELO_NONE=1.1,SPF_PASS=-0.1
X-Spam-Rules_token: Tokens: new, 63; hammy, 80; neutral, 64; spammy, 2.
X-Spam-Flag: No
X-Spam-dcc_result: linode 104; Body=3 Fuz1=3 Fuz2=3
X-Spam-Relay-Country: US ** ** US ** ** NZ
X-Spam-Uri-Domains-Ham: treads.nz
X-Spam-ASN: AS30633 207.244.64.0/18

not so bad here

if you have dovecot with sieve make a maillist rule BEFORE one that puts
mails in spam folder

or maybe just give more score negative to MAILING_LIST_MULTI ?

On Thu, Dec 19, 2019 at 11:15:42AM +0100, Benny Pedersen wrote:
> Philip skrev den 2019-12-19 04:34:
> >How do I white list this mailing list for some reason all the messages
> >are now going to spam.
>
> X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on localhost.junc.eu
> X-Spam-Status: No, score=-2.0, required=5.0, Autolearn=no
> autolearn_force=no,
> LastExt=207.244.88.153 Shortcircuit=no,none
> X-Spam-Rules_score: BAYES_00=-1.9,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,
> DKIM_VALID_AU=-0.1,MAILING_LIST_MULTI=-1,RCVD_IN_DNSWL_NONE=-0.0001,
> SPF_HELO_NONE=1.1,SPF_PASS=-0.1
> X-Spam-Rules_token: Tokens: new, 63; hammy, 80; neutral, 64; spammy, 2.
> X-Spam-Flag: No
> X-Spam-dcc_result: linode 104; Body=3 Fuz1=3 Fuz2=3
> X-Spam-Relay-Country: US ** ** US ** ** NZ
> X-Spam-Uri-Domains-Ham: treads.nz
> X-Spam-ASN: AS30633 207.244.64.0/18
>
> not so bad here
>
> if you have dovecot with sieve make a maillist rule BEFORE one that puts
> mails in spam folder
>
> or maybe just give more score negative to MAILING_LIST_MULTI ?

Normal SA rules will hit USER_IN_DEF_SPF_WL, due to "def_whitelist_auth
*@*.apache.org". Have you cleared these or why is it not hitting for you?

hermes.apache.org[207.244.88.153] which sends these list mails is also
supposed to hit RCVD_IN_DNSWL_HI, not _NONE? Your setup seems wonky.

On Thu, Dec 19, 2019 at 12:43:43PM +0200, Henrik K wrote:
>
> hermes.apache.org[207.244.88.153] which sends these list mails is also
> supposed to hit RCVD_IN_DNSWL_HI, not _NONE? Your setup seems wonky.

Answering myself, DNSWL uses firsttrusted, so you've probably have some
Apache stuff in trusted_networks..

I'm kind of surprised that DNSWL is not using lastexternal.

Henrik K skrev den 2019-12-19 11:43:

>> or maybe just give more score negative to MAILING_LIST_MULTI ?
>
> Normal SA rules will hit USER_IN_DEF_SPF_WL, due to "def_whitelist_auth
> *@*.apache.org". Have you cleared these or why is it not hitting for
> you?

if trusted_networks includes apache org ip ?

> hermes.apache.org[207.244.88.153] which sends these list mails is also
> supposed to hit RCVD_IN_DNSWL_HI, not _NONE? Your setup seems wonky.

see above, i can live with the problem of not reject emails from
maillists

postfix smtpd_milter_maps is nice with me

On 19.12.19 16:34, Philip wrote:
>Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by
> fantomas.fantomas.sk (8.15.2/8.15.2/Debian-14~deb10u1) with SMTP id
> xBJ3YZWh032473 for <uhlar@fantomas.sk>; Thu, 19 Dec 2019 04:34:44 +0100
>To: users@spamassassin.apache.org
>From: Philip <philip@treads.nz>
>Subject: White listing this mailing list.
>
>How do I white list this mailing list for some reason all the messages
>are now going to spam.

one of ways is not to pass mail received from 207.244.88.153 to
spamassassin.

--
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.
Linux is like a teepee: no Windows, no Gates and an apache inside...

Matus UHLAR - fantomas skrev den 2019-12-19 12:03:

> one of ways is not to pass mail received from 207.244.88.153 to
> spamassassin.

loosing bayes ham training

>Matus UHLAR - fantomas skrev den 2019-12-19 12:03:
>
>>one of ways is not to pass mail received from 207.244.88.153 to
>>spamassassin.

On 19.12.19 12:30, Benny Pedersen wrote:
>loosing bayes ham training

not needed when you don't scan.

And I don't recommend training bayes with mailing list data, especially not
SA-users.


--
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.
How does cat play with mouse? cat /dev/mouse

On Thu, 19 Dec 2019 12:49:34 +0200
Henrik K wrote:

> On Thu, Dec 19, 2019 at 12:43:43PM +0200, Henrik K wrote:
> >
> > hermes.apache.org[207.244.88.153] which sends these list mails is
> > also supposed to hit RCVD_IN_DNSWL_HI, not _NONE? Your setup seems
> > wonky.
>
> Answering myself, DNSWL uses firsttrusted, so you've probably have
> some Apache stuff in trusted_networks..
>
> I'm kind of surprised that DNSWL is not using lastexternal.

Matus UHLAR - fantomas skrev den 2019-12-19 14:00:

> not needed when you don't scan.
>
> And I don't recommend training bayes with mailing list data, especially
> not
> SA-users.

how to tell spamassassin that maillist should not be bayes learned when
sa still is used on that maillists would be helpfull to all then

maybe tflags MAILLIST noautolearn

sorry have not tryed it yet since i see no point

Sorry, sent the previous one accidently.

On Thu, 19 Dec 2019 14:36:28 +0000
RW wrote:

> On Thu, 19 Dec 2019 12:49:34 +0200
> Henrik K wrote:
>
> > On Thu, Dec 19, 2019 at 12:43:43PM +0200, Henrik K wrote:
> > >
> > > hermes.apache.org[207.244.88.153] which sends these list mails is
> > > also supposed to hit RCVD_IN_DNSWL_HI, not _NONE? Your setup
> > > seems wonky.
> >
> > Answering myself, DNSWL uses firsttrusted, so you've probably have
> > some Apache stuff in trusted_networks..
> >
> > I'm kind of surprised that DNSWL is not using lastexternal.

Because the trusted network outside of the internal network is trusted
not to be under the control of a spammer, but you can't generally
trust what's relayed through it. Forwarders that are listed at
all usually have a low level of trust, often lower than the trust
of the last external.

What surprises me is that a list server is in RCVD_IN_DNSWL_HI which
I'd expect to be dominated by transactional mail.

On Thu, Dec 19, 2019 at 02:58:42PM +0000, RW wrote:
>
> Because the trusted network outside of the internal network is trusted
> not to be under the control of a spammer, but you can't generally
> trust what's relayed through it. Forwarders that are listed at
> all usually have a low level of trust, often lower than the trust
> of the last external.

But there might not be a "forwarder" (originating mail server) in the chain.
For that reason, trusted_networks usage is quite vague (not to mention all
that documentation about "not spammer controlled, yadda yadda" which doesn't
actually tell when and why one is supposed to use it).

As an example, I might add hermes.apache.org to trusted_networks, to exclude
it's IP from blacklist checks. Along with perhaps some other IPs to hit
ALL_TRUSTED for whitelisting purposes. I can't think of any other reason to
use trusted_networks for third party networks?

The above doesn't imply that I want to check DNSWL for some random
"forwarder" down the chain, which might not even be there. Or if there is
one, it might have lower or non-existing DNSWL score like you mentioned.
Then again, it might have a better DNSWL score. So actually we should query
both lastexternal and firsttrusted, so both have a chance of hitting DNSWL.

But if one wanted to check the forwarders after hermes.apache.org properly,
it would make more sense to add it in internal_networks, since practicall it
acts as the outer MX for you. That would enable proper blacklist checks
too.

> What surprises me is that a list server is in RCVD_IN_DNSWL_HI which
> I'd expect to be dominated by transactional mail.

What's strange about it? It rarely passes through spam (atleast for me) and
is properly maintained. Isn't it all about the ham/spam ratio that's seen
originating from that IP?

On Thu, Dec 19, 2019 at 06:01:37PM +0200, Henrik K wrote:
>
> But if one wanted to check the forwarders after hermes.apache.org properly,
> it would make more sense to add it in internal_networks, since practicall it
> acts as the outer MX for you. That would enable proper blacklist checks
> too.

Thinking about it more, atleast SPF would break, so not the best idea.. :-)

On 2019-12-19 17:04, Henrik K wrote:

> Thinking about it more, atleast SPF would break, so not the best idea..
> :-)

X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
localhost.junc.eu
X-Spam-Status: No, score=-10.2, required=5.0, Autolearn=ham
autolearn_force=no,
LastExt=207.244.88.153
X-Spam-Rules_score: DKIM_SIGNED=-0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,
HEADER_FROM_DIFFERENT_DOMAINS=0.25,MAILING_LIST_MULTI=-3.1,
RCVD_IN_DNSWL_NONE=-0.1,SPF_HELO_NONE=1.2,SPF_PASS=-0.001,TXREP=0.401,
USER_IN_DEF_SPF_WL=-7.5,USER_IN_WHITELIST=-1
X-Spam-Rules_token:
X-Spam-Flag: No
X-Spam-dcc_result: mx 1480; Body=3 Fuz1=3 Fuz2=3
X-Spam-Uri-Domains-Ham: hege.li
X-Spam-ASN: AS30633 207.244.64.0/18

i see no problem :)

On Thu, 19 Dec 2019 18:01:37 +0200
Henrik K wrote:

> But if one wanted to check the forwarders after hermes.apache.org
> properly, it would make more sense to add it in internal_networks,
> since practicall it acts as the outer MX for you. That would enable
> proper blacklist checks too.

Mostly that's the best thing to do, but there can be cases where it's
not possible to distinguish between an MX handover and submission into
the third-party network. In that case it may be better to avoid the
risk of running last-external checks on mail clients.

RW wrote:
> On Thu, 19 Dec 2019 18:01:37 +0200
> Henrik K wrote:
>
>> But if one wanted to check the forwarders after hermes.apache.org
>> properly, it would make more sense to add it in internal_networks,
>> since practicall it acts as the outer MX for you. That would enable
>> proper blacklist checks too.
>
> Mostly that's the best thing to do, but there can be cases where it's
> not possible to distinguish between an MX handover and submission into
> the third-party network. In that case it may be better to avoid the
> risk of running last-external checks on mail clients.

I take a more restrictive interpretation of the SA trust path settings.

- msa_networks is our mail servers that accept mail submissions from our
customers.
- internal_networks adds the rest of our core mail-handling servers -
note, not all of our servers!
- trusted_networks adds the rest of our core server network and a
splattering of third party mail hosting systems that our customers have
domain mail with, forwarded to their ISP mailbox with us. I've also
included a couple of outbound-filtering mail clusters, so that DNSBL
checks look at the actual sender's mail system, not the filtering platform.

The domain-forwarder IP list is hardly exhaustive; just IPs for those
customers who have reported FPs or FNs to us and I've seen enough
samples to spot the forwarder.

It's been working well for us, and I can use -lastexternal or
-firsttrusted to tweak the semantics of which relay handover a DNSBL
lookup inspects.

Adding too many systems to trusted_networks means you end up checking a
lot of end-user mail-submitting IPs on things like the Spamhaus PBL.

Aside from the outbound-filtering platforms, the relationship I feel
should be targeted with the trust path settings is where the sender's
mail system hands the message over to the primary recipient's system.
So adding the Apache listserv is wrong, because messages sent through
the list are sent to *the list*, and then from the list *to each of us*.

(All that said, I happen to skip SA entirely for this and most other
lists, with procmail recipies that file listmail in the appropriate
folder based on List-Id or some other suitable header, ahead of the
procmail recipe that calls SA.)

-kgd