Re: CONTENT_AFTER_HTML: better not discuss formatting!!

2022-02-08 Thread John Hardin
On Tue, 8 Feb 2022, Loren Wilton wrote: Are you talking about the use of m'' as the regex delimiter? Yes. It will probably work just fine for the foreseeable future, as long as the input validation of rules files is lenient. I think you may have a very hard time removing the m matching

Re: CONTENT_AFTER_HTML: better not discuss formatting!!

2022-02-08 Thread Loren Wilton
Are you talking about the use of m'' as the regex delimiter? Yes. It will probably work just fine for the foreseeable future, as long as the input validation of rules files is lenient. I think you may have a very hard time removing the m matching delimiters from SA. I suspect there are at l

Re: CONTENT_AFTER_HTML: better not discuss formatting!!

2022-02-08 Thread Bill Cole
On 2022-02-08 at 13:14:06 UTC-0500 (Tue, 8 Feb 2022 13:14:06 -0500) Kris Deugau is rumored to have said: [...] > Are you talking about the use of m'' as the regex delimiter? Yes. It will probably work just fine for the foreseeable future, as long as the input validation of rules files is lenien

Re: CONTENT_AFTER_HTML: better not discuss formatting!!

2022-02-08 Thread Kris Deugau
Bill Cole wrote: On 2022-02-08 at 04:28:16 UTC-0500 (Tue, 8 Feb 2022 01:28:16 -0800) Loren Wilton is rumored to have said: No, I added that after observing multiple spams with random garbage after the closing HTML tag in the HTML body part. Presumably it was an attempt at Bayes poison, check

Re: CONTENT_AFTER_HTML: better not discuss formatting!!

2022-02-08 Thread Bill Cole
On 2022-02-08 at 04:28:16 UTC-0500 (Tue, 8 Feb 2022 01:28:16 -0800) Loren Wilton is rumored to have said: >> No, I added that after observing multiple spams with random garbage after >> the closing HTML tag in the HTML body part. Presumably it was an attempt at >> Bayes poison, checksum avoidan

Re: CONTENT_AFTER_HTML: better not discuss formatting!!

2022-02-08 Thread Greg Troxel
John Hardin writes: > On Mon, 7 Feb 2022, Greg Troxel wrote: > >> and then I got a reply back with the content he was trying to send etc. >> But, it had: >> >> * 2.5 CONTENT_AFTER_HTML More content after HTML close tag >> >> but one was only text/plain and I could see nothing wrong. read

Re: CONTENT_AFTER_HTML: better not discuss formatting!!

2022-02-08 Thread Loren Wilton
No, I added that after observing multiple spams with random garbage after the closing HTML tag in the HTML body part. Presumably it was an attempt at Bayes poison, checksum avoidance, or some other filter evasion technique. I'll tighten it up. FWIW, here is the rule I use. It obviously could

Re: CONTENT_AFTER_HTML: better not discuss formatting!!

2022-02-07 Thread John Hardin
On Mon, 7 Feb 2022, Loren Wilton wrote: But, it had: * 2.5 CONTENT_AFTER_HTML More content after HTML close tag but one was only text/plain and I could see nothing wrong. reading 72_active.cf I found: rawbody__CONTENT_AFTER_HTML/<\/htnl>\s*[a-z0-9]/i > which fires on

Re: CONTENT_AFTER_HTML: better not discuss formatting!!

2022-02-07 Thread John Hardin
On Mon, 7 Feb 2022, Greg Troxel wrote: and then I got a reply back with the content he was trying to send etc. But, it had: * 2.5 CONTENT_AFTER_HTML More content after HTML close tag but one was only text/plain and I could see nothing wrong. reading 72_active.cf I found: rawbody

Re: CONTENT_AFTER_HTML: better not discuss formatting!!

2022-02-07 Thread Loren Wilton
But, it had: * 2.5 CONTENT_AFTER_HTML More content after HTML close tag but one was only text/plain and I could see nothing wrong. reading 72_active.cf I found: rawbody__CONTENT_AFTER_HTML/<\/htnl>\s*[a-z0-9]/i > which fires on a text/plain part that discusses html formatti

CONTENT_AFTER_HTML: better not discuss formatting!!

2022-02-07 Thread Greg Troxel
(Instances of html have been changed to htnl in this message to avoid tripping the rule I'm talking about.) A legit message arrived at my server, for me and another user, and it scored 8 for them and I think about 11 for me. This is really unusual. The big issues were: Sent by sendgrid: point