Re: spam subject marking
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 smime.p7s Description: S/MIME Cryptographic Signature
Re: spam subject marking
On 2022-11-16 at 06:46:57 UTC-0500 (Wed, 16 Nov 2022 06:46:57 -0500) Greg Troxel 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 b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire signature.asc Description: OpenPGP digital signature
Re: spam subject marking
On 2022-11-15 at 15:16:49 UTC-0500 (Tue, 15 Nov 2022 20:16:49 +) Marc 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 b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: spam subject marking
On 2022-11-15 at 21:45:52 UTC-0500 (Tue, 15 Nov 2022 18:45:52 -0800) Loren Wilton 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 b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: spam subject marking
On 2022-11-16 at 08:01:12 UTC-0500 (Wed, 16 Nov 2022 06:01:12 -0700) Grant Taylor via users 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 b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire signature.asc Description: OpenPGP digital signature
Re: spam subject marking
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 smime.p7s Description: S/MIME Cryptographic Signature
Re: spam subject marking
Greg Troxel 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. signature.asc Description: PGP signature
Re: spam subject marking
"Grant Taylor via users" 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. me too signature.asc Description: PGP signature
Re: spam subject marking
On Tue, Nov 15, 2022 at 9:46 PM Loren Wilton 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.
Re: spam subject marking
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.
Re: spam subject marking
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 smime.p7s Description: S/MIME Cryptographic Signature
RE: spam subject marking
> 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?
Re: spam subject marking
On 2022-11-15 at 05:04:08 UTC-0500 (Tue, 15 Nov 2022 10:04:08 +) Marc 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 b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: spam subject marking
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 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 ;) >
RE: spam subject marking
> > 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 ;)
RE: spam subject marking
> >> 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.
RE: spam subject marking
> >> > >> 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.
RE: spam subject marking
> > 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.
RE: spam subject marking
> > 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.
RE: spam subject marking
> > > > 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
spam subject marking
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?
