Mailing List Archive

> >
> > I am having repeated occurances of ***SPAM*** in the subject, maybe it
> is good to stop adding ***SPAM*** if there are already 10 in the
> subject?
>
> ask the sending admin why in the world he still continues to blow out
> that crap instead trash it
>
> if there are already two in the subject i reject them with postfix
> header rules

What are you on about? This is for the developers to re-think their design if it is necessary to keep adding ****SPAM****

>
> and i told you that it's useful when a message already passed multiple
> hops which flagged it as spam to outright reject it
>
> /^Subject: .*\*\*\*\*\*spam\*\*\*\*\* \*\*\*\*\*spam\*\*\*\*\*/ REJECT
> Administrative Prohibition (Subject)

A message is either spam or not, and is marked as spam or not. I don't see how telling me 3 times it is spam has any relevance. If you value the information created by multiple servers processing the message, then this information should be passed differently.

>
> Am 15.11.22 um 11:48 schrieb Marc:
> >>
> >> and i told you that it's useful when a message already passed
> multiple
> >> hops which flagged it as spam to outright reject it
> >>
> >> /^Subject: .*\*\*\*\*\*spam\*\*\*\*\* \*\*\*\*\*spam\*\*\*\*\*/
> REJECT
> >> Administrative Prohibition (Subject)
> >
> > A message is either spam or not
>
> that's not how spam filtering works
>
> multiple signs of spam leading to marking a message as spam

This is not relevant for the discussion on whether or not to have spamassassin add multiple times '**spam**' to the subject.


> > and is marked as spam or not
>
> good filters don't only mark messages but reject them
>
> > I don't see how telling me 3 times it is spam has any relevance.
>
> how comes that you don't see the relevance of the sending system already
> thought it was spam and instead jerect it still continued to send the
> trash out?

This is not relevant for the discussion on whether or not to have spamassassin add multiple times '**spam**' to the subject.

> > If you value the information created by multiple servers processing
> the message, then this information should be passed differently
>
> and how do you imagine that in a cahin of indepdenent systems?

My first thought would be by adding headers. If I had a chain of 3 servers processing a message by spamassassin. The first 2 would only add scores in the header and the last one would do the calculation upon which is decided to have the message visibly marked as spam for the recipient.

> >>
> >> multiple signs of spam leading to marking a message as spam
> >
> > This is not relevant for the discussion on whether or not to have
> spamassassin add multiple times '**spam**' to the subject.
>
> your spamassassin only adds it one time

Yes I know, and lazy users do not remove it in replies, that is how you get multiple occurances.

> >> spamassassin add multiple times '**spam**' to the subject.
> >>
> >> your spamassassin only adds it one time
> >
> > Yes I know, and lazy users do not remove it in replies, that is how
> you get multiple occurances
>
> than it's "Subject: **spam** Re: **spam**" and the only relevant
> information for you is the first because that's from your system

modifications to the subject I see only as relevant to the recipient.

Email users really don't have a clue what is added by whom. Users that leave our spam marked subject in the email replies, generate even issues why other people are receiving their email marked as spam.

> just because on a random place in the middle of the subject **spam**
> appears musn't supress the flagging of my own filter

Indeed that is why a solution for development could be something like

if spam
check if there is in the beginning of the subject a string that matches the 'rewrite_header' as configured in local.cf, if not add, if it is there skip.

I think the situation I am describing is quite often occurring. I wonder what others think of this.

>
> When a *user* replies it's not at the beginning
> it's "Re: **spam**"

:) Indeed, and in other languages it is even different, but I think developers get the point ;)

Apache SpamAssassin it's both an API and a program. In my installation, I
do not use it to do any subject modifications and I use a milter called
mime defang to do that using my own logic.

You can also configure spam d/Spam seed not to modify the subject.

If you would like similar headings removed from spams though why email is
getting multiple would be a question, patches are welcome for consideration.

Regards, KAM

On Tue, Nov 15, 2022, 07:01 Marc <Marc@f1-outsourcing.eu> wrote:

> >
> > When a *user* replies it's not at the beginning
> > it's "Re: **spam**"
>
> :) Indeed, and in other languages it is even different, but I think
> developers get the point ;)
>

On 2022-11-15 at 05:04:08 UTC-0500 (Tue, 15 Nov 2022 10:04:08 +0000)
Marc <Marc@f1-outsourcing.eu>
is rumored to have said:

> I am having repeated occurances of ***SPAM*** in the subject, maybe it is good to stop adding ***SPAM*** if there are already 10 in the subject?

That's an entirely local choice, controlled by the rewrite_header config parameter. It is NOT enabled by default. Talk to whoever is adding that to your mail.

You might want to point out to them that rewrite_header breaks any DKIM signature on mail, in addition to cluttering the Subject if misclassified mail is part of a conversation.

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

> You might want to point out to them that rewrite_header breaks any DKIM
> signature on mail,

Hmmm, good point, not really thought about this even. Are email clients complaining about this?

> in addition to cluttering the Subject if
> misclassified mail is part of a conversation.

So the alternative is adding a header and move it to the spam folder automatically on the basis of the header?

Currently I just want to 'warn' users that the message is possible spam, they can decide to move such emails automatically to a spam folder by enabling a sieve rule.
What would be an alternative method to keep such functionality without altering the subject?

On 11/15/22 1:16 PM, Marc wrote:
> Hmmm, good point, not really thought about this even. Are email
> clients complaining about this?

Few email clients are testing DKIM. Some servers are testing DKIM.
Some systems are mis-treating DKIM failure as something more sever than
the specification allows.

> So the alternative is adding a header and move it to the spam folder
> automatically on the basis of the header?

Adding the header, yes.

Altering where the message is delivered is completely independent and
outside of SpamAssassin purview.

> Currently I just want to 'warn' users that the message is possible
> spam, they can decide to move such emails automatically to a spam
> folder by enabling a sieve rule.

I suspect any visible modification you make to the message will also
likely break DKIM in the same way.

You can attach the unmodified message to a wrapper message, and add
whatever text you want in the wrapper message. This is an exercise left
up to the reader. ;-)

> What would be an alternative method to keep such functionality without
> altering the subject?

Adding headers is the most common thing that I see. Then let the email
client decide what action, if any, to take based on that header's contents.



--
Grant. . . .
unix || die

> So the alternative is adding a header and move it to the spam folder
> automatically on the basis of the header?
>
> Currently I just want to 'warn' users that the message is possible spam,
> they can decide to move such emails automatically to a spam folder by
> enabling a sieve rule.
> What would be an alternative method to keep such functionality without
> altering the subject?

If SA sees the message and classifies it as spam, it normally adds (from an
example)
X-Spam-Flag: YES
X-Spam-Level: ********
X-Spam-Status: Yes, score=8.2 required=5.0
tests=BAYES_50=0.8,DKIM_SIGNED=0.1,

It should be trivial to look for the "X-Spam-Flag: YES" line.

On Tue, Nov 15, 2022 at 9:46 PM Loren Wilton <lwilton@earthlink.net> wrote:

>
> If SA sees the message and classifies it as spam, it normally adds (from
> an
> example)
> X-Spam-Flag: YES
> X-Spam-Level: ********
> X-Spam-Status: Yes, score=8.2 required=5.0
> tests=BAYES_50=0.8,DKIM_SIGNED=0.1,
>
> It should be trivial to look for the "X-Spam-Flag: YES" line.
>
> And most mail clients and platforms let you key off of this for
redirecting email to a spam folder.

"Grant Taylor via users" <users@spamassassin.apache.org> writes:

> On 11/15/22 1:16 PM, Marc wrote:
>> Hmmm, good point, not really thought about this even. Are email
>> clients complaining about this?
>
> Few email clients are testing DKIM. Some servers are testing
> DKIM. Some systems are mis-treating DKIM failure as something more
> sever than the specification allows.

Can you expand on that? A DKIM failure means that one can't establish
that the message came from the domain, and this leads to:

decline to apply whitelist_from_dkim

perhaps, if one has data that most things with that From: have valid
dkim sigs, give it some spam points.

in spam filtering and

if there is a DMARC policy, and it fails SPF also, file as spam or
reject

Are you saying tht some MTAs outright reject on DKIM failure, in the
absence of DMARC?

I did just get a bounce message in reply to a message I sent here,
complaining that my message failed DKIM (maybe the list munged it) and
SPF (ok; the list is not in general authorized to send mail from my
domain) and therefore was being rejected (but I do not currently publish
a DMARC policy).

Not really this topic, but I think mailing lists really need to be set
up to not break DKIM. The kids all want us to use forums anyway, and
DKIM-breaking and spam filtering issues, really doesn't help.

>> Currently I just want to 'warn' users that the message is possible
>> spam, they can decide to move such emails automatically to a spam
>> folder by enabling a sieve rule.
>
> I suspect any visible modification you make to the message will also
> likely break DKIM in the same way.

Agreed. Really the MUA needs support for a spam-marking header, or to
file messages with such headers into a separate mailbox/folder/whatever.

>> What would be an alternative method to keep such functionality
>> without altering the subject?
>
> Adding headers is the most common thing that I see. Then let the
> email client decide what action, if any, to take based on that
> header's contents.

<aol>me too</>

Greg Troxel <gdt@lexort.com> writes:

> I did just get a bounce message in reply to a message I sent here,
> complaining that my message failed DKIM (maybe the list munged it) and
> SPF (ok; the list is not in general authorized to send mail from my
> domain) and therefore was being rejected (but I do not currently publish
> a DMARC policy).

Update: my messages to the list, as I received them, both this one and
the one that provoked the bounce, have valid DKIM signatures as
determined by inbound processing on my MTA.

So while my rant about DKIM and lists stands in general, I apologize for
casting aspersions on this list: it appears to be working well as far as
not breaking DKIM, at least for senders without DMARC.

On 11/16/22 4:46 AM, Greg Troxel wrote:
> Can you expand on that?

I'll try.

My understanding is that few MUAs test DKIM signatures /client/ /side/.
-- The only exception that I'm aware of is that there was a Thunderbird
add-on that would test DKIM signatures /client/ /side/. Almost all DKIM
/testing/ / /checking/ that I'm aware of is /receiving/ MTA side.

> A DKIM failure means that one can't establish that the message came
> from the domain, and this leads to:

Sure.

> decline to apply whitelist_from_dkim
>
> perhaps, if one has data that most things with that From: have valid
> dkim sigs, give it some spam points.

My understanding is that /per/ /RFCs/ a failing DKIM signature is to be
treated the same as if there is no DKIM signature.

Or said another way, DKIM is only supposed to be a /positive/
/assertion/ if / when a DKIM signature validation passes. DKIM is
supposed to not be negative.

Please correct me if I'm wrong.

> in spam filtering and
>
> if there is a DMARC policy, and it fails SPF also, file as spam
> or reject

N.B. DMARC is vastly different from, but still potentially reliant upon
DKIM.

> Are you saying tht some MTAs outright reject on DKIM failure, in the
> absence of DMARC?

I have seen evidence of postmasters /mis/configuring their MTAs to
behave the /opposite/ /of/ /what/ /RFCs/ /prescribe/.

> I did just get a bounce message in reply to a message I sent here,
> complaining that my message failed DKIM (maybe the list munged it)
> and SPF (ok; the list is not in general authorized to send mail from
> my domain) and therefore was being rejected (but I do not currently
> publish a DMARC policy).

I'm not getting on my what mailing list managers should and should not
do horse in this email. ;-)

> Not really this topic, but I think mailing lists really need to be
> set up to not break DKIM.

TL;DR: I believe that mailing list managers are an email terminus; end
of my message and the start of a new message substantively based on my
message.

> The kids all want us to use forums anyway,

It's healthy to want things. It's an indication that you have opinions
and are not a sheepeople.

> and DKIM-breaking and spam filtering issues, really doesn't help.

I've found that when both email terminus (termini?) behave properly,
DKIM is not an issue. At worst, a failing DKIM signature is treated as
if the DKIM signature doesn't exist. At best, a passing DKIM signature
adds credence to a message / it's source.

> Agreed. Really the MUA needs support for a spam-marking
> header, or to file messages with such headers into a separate
> mailbox/folder/whatever.

I would assume that any contemporary MUA worth it's disk space does, and
has for 10-15 years, understands various spam filter headers asserting
status. E.g. Thunderbird has built in support for SpamAssassin,
Bogofilter, DSPAM, POPFile, and SpamPal.



--
Grant. . . .
unix || die

On 2022-11-15 at 21:45:52 UTC-0500 (Tue, 15 Nov 2022 18:45:52 -0800)
Loren Wilton <lwilton@earthlink.net>
is rumored to have said:

>> So the alternative is adding a header and move it to the spam folder automatically on the basis of the header?
>>
>> Currently I just want to 'warn' users that the message is possible spam, they can decide to move such emails automatically to a spam folder by enabling a sieve rule.
>> What would be an alternative method to keep such functionality without altering the subject?
>
> If SA sees the message and classifies it as spam, it normally adds (from an example)
> X-Spam-Flag: YES
> X-Spam-Level: ********
> X-Spam-Status: Yes, score=8.2 required=5.0 tests=BAYES_50=0.8,DKIM_SIGNED=0.1,
>
> It should be trivial to look for the "X-Spam-Flag: YES" line.

Calling the addition of those headers "normal" is a possibly a bit misleading.

Such configuration is *common* but is an entirely local choice. There are 4 'add_header' directives in the default prefs distributed in the rules package. However, many sites use configurations that DO NOT add any headers or 'glue' that ignores the message modifications and may or may not add similar headers (e.g. milters that embed SA rather than use a separate spamc.)


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

On 2022-11-15 at 15:16:49 UTC-0500 (Tue, 15 Nov 2022 20:16:49 +0000)
Marc <Marc@f1-outsourcing.eu>
is rumored to have said:

>> You might want to point out to them that rewrite_header breaks any DKIM
>> signature on mail,
>
> Hmmm, good point, not really thought about this even. Are email clients complaining about this?
>
>> in addition to cluttering the Subject if
>> misclassified mail is part of a conversation.
>
> So the alternative is adding a header and move it to the spam folder automatically on the basis of the header?

Yeah, you CAN do that.

I just reject anything deemed spam outright. That way, false positives (which are extremely bad and should not be quiet) are never silent due to my systems' behavior. The sending MTA gets an explicit 5xx reply and should be transmitting that back to the human sender as a DSN, so they can try to fix the problem. Dropping suspected spam into a "spam folder" just gives for wanted mail a new place to die unseen.

(That's just my personal opinion, not a policy of the SA PMC, which doesn't take any positions on how individual sites apply SA results.)

> Currently I just want to 'warn' users that the message is possible spam, they can decide to move such emails automatically to a spam folder by enabling a sieve rule.
> What would be an alternative method to keep such functionality without altering the subject?

Use SA's "add_header" feature. It is on by default, but depending on which 'glue' you use to integrate SA and which distribution package you use you may not be seeing the modification by add_header.


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

On 2022-11-16 at 06:46:57 UTC-0500 (Wed, 16 Nov 2022 06:46:57 -0500)
Greg Troxel <gdt@lexort.com>
is rumored to have said:

> Not really this topic, but I think mailing lists really need to be set
> up to not break DKIM.

Easier said than done.

I'm on an absurd number of mailing lists, and MOST are not entirely DKIM-safe. I have not seen this list or any other ASF list break DKIM but I have not checked rigorously. A similar example is the Postfix-Users list, which very occasionally does some necessary restructuring of mail, breaking signatures. I suspect similar corner cases exist here: e.g. mail arriving with 8-bit encoding may cause a re-encode.

Obviously, any list that adds tags to Subject, munges From, forces or deletes Reply-To, or reflows text (rare, but it happens...) will clobber DKIM. Some sites "oversign" headers that lists should be adding (the whole List-* zoo) which basically is a footbullet.

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

On 2022-11-16 at 08:01:12 UTC-0500 (Wed, 16 Nov 2022 06:01:12 -0700)
Grant Taylor via users <gtaylor@tnetconsulting.net>
is rumored to have said:

> Or said another way, DKIM is only supposed to be a /positive/ /assertion/ if / when a DKIM signature validation passes. DKIM is supposed to not be negative.

That's ABSOLUTELY CORRECT.

DKIM is known to be fragile in transit. It has ALWAYS been known to be fragile in transit. If you want a signature for repudiation purposes, you need *at least* DMARC on top or some other more robust signing mechanism.


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

On 11/17/22 9:00 AM, Bill Cole wrote:
> Easier said than done.

It's actually quite easy to do. But most people don't want to do what I
think should be done.

IMHO, the email list itself is a 1st class / proper entity that you are
emailing or reading email from. -- I'm not emailing Bill or Greg or
Marc or any specific individual when I type this reply.

Treat the mailing list as an individual that receives / reads / types /
sends email messages. The mailing list is an SMTP terminal point. It
is the end exclusive or the start of a message.

The new messages that it generates may be substantially based on content
in messages that it received. But that's still a new message.

As such, messages from the mailing list should reflect the mailing list
and not pretend or lie or fudge or fake that they are anyone else.

But that's my opinion and it's an unpopular one. But it's also one that
is completely 100% compatible with SPF / DKIM / DMARC / etc. (Assuming
that the mailing list / it's MTA apply said security to the new messages
that it originates.)



--
Grant. . . .
unix || die