Re: Help with RegEx Rule
On 20/09/15 03:07, Dave Funk wrote: Notes: 1) Due to SA pre-processing collapsing body into one long line, cannot match on '^' repeatedly, need to look for '\n' as line break indicator. Find start of a line and then following repeats of ".\n" Dave, I need to see the mail message as spamassassin see's it so as to create some *awesome* rules; is there a tool that will let me convert my ASCII representation of an email message into a file in the rawbody format or any other format for that matter? Thanks, ak.
Re: Investigating facebook spam
On Tue, 6 Oct 2015 17:05:48 -0400 Kevin A. McGrail wrote: > On 10/6/2015 5:01 PM, Jered Floyd wrote: > > Ah; good eyes! > > > > That KAM_FACEBOOK rule is dangerous. > The behavior of forwarding content which effectively is the same as a > forgery is where the danger lies... If this is behavior that users > are performing, of course then there needs to be appropriate reaction > but overall, forwarding emails is going to cause issues with a ton of > domains and should be discouraged entirely. Assuming that Facebook applies DKIM consistently, I think it would be better to replace: (SPF_FAIL + DKIM_ADSP_ALL >=1) with DKIM_ADSP_ALL && ! (SPF_PASS && __ENV_AND_HDR_FROM_MATCH) This eliminates most of the FPs caused by broken SPF without creating any extra scope for forgery. The full rule is then: meta KAM_FACEBOOKMAIL __KAM_FACEBOOKMAIL2 || __KAM_FACEBOOKMAIL1 && DKIM_ADSP_ALL && !(SPF_PASS && __ENV_AND_HDR_FROM_MATCH) (The use of __ENV_AND_HDR_FROM_MATCH is really a bit too strict - it might be useful to have an extra eval rule that only checks the domains.)
Re: Investigating facebook spam
On Thu, 8 Oct 2015 13:13:57 +0100 RW wrote: > On Tue, 6 Oct 2015 17:05:48 -0400 > Kevin A. McGrail wrote: > > > On 10/6/2015 5:01 PM, Jered Floyd wrote: > > > Ah; good eyes! > > > > > > That KAM_FACEBOOK rule is dangerous. > > The behavior of forwarding content which effectively is the same as > > a forgery is where the danger lies... If this is behavior that users > > are performing, of course then there needs to be appropriate > > reaction but overall, forwarding emails is going to cause issues > > with a ton of domains and should be discouraged entirely. > > > Assuming that Facebook applies DKIM consistently, I think it would be > better to replace: > > (SPF_FAIL + DKIM_ADSP_ALL >=1) > > with > > DKIM_ADSP_ALL && ! (SPF_PASS && __ENV_AND_HDR_FROM_MATCH) I didn't think that through, there's no scenario where SPF helps, so all that's needed is: meta KAM_FACEBOOKMAIL __KAM_FACEBOOKMAIL2 || __KAM_FACEBOOKMAIL1 && DKIM_ADSP_ALL
Re: Investigating facebook spam
On Thu, 8 Oct 2015 13:59:31 +0100 RW wrote: > On Thu, 8 Oct 2015 13:13:57 +0100 > RW wrote: > > > On Tue, 6 Oct 2015 17:05:48 -0400 > > Kevin A. McGrail wrote: > > > > > On 10/6/2015 5:01 PM, Jered Floyd wrote: > > > > Ah; good eyes! > > > > > > > > That KAM_FACEBOOK rule is dangerous. > > > The behavior of forwarding content which effectively is the same > > > as a forgery is where the danger lies... If this is behavior that > > > users are performing, of course then there needs to be appropriate > > > reaction but overall, forwarding emails is going to cause issues > > > with a ton of domains and should be discouraged entirely. > > > > > > Assuming that Facebook applies DKIM consistently, I think it would > > be better to replace: > > > > (SPF_FAIL + DKIM_ADSP_ALL >=1) > > > > with > > > > DKIM_ADSP_ALL && ! (SPF_PASS && __ENV_AND_HDR_FROM_MATCH) > > I didn't think that through, there's no scenario where SPF helps, so > all that's needed is: Actually, come to think of it, there is a scenario where the internal network incorporates a third-party forwarding server that doesn't rewrite the envelope-from, but does break DKIM, but that is pretty rare. Either version is an improvement over the current rule.
charset=utf-16 tricks out SA
Content-Type: text/plain; charset=utf-16 Content-Transfer-Encoding: base64 no custom body rules hit like they do for ISO/UTF8 :-( signature.asc Description: OpenPGP digital signature
Re: charset=utf-16 tricks out SA
Please open a bug especially if this is seen in the wild! On 10/8/2015 11:34 AM, Reindl Harald wrote: Content-Type: text/plain; charset=utf-16 Content-Transfer-Encoding: base64 no custom body rules hit like they do for ISO/UTF8 :-(
Re: Help with RegEx Rule
On 20/09/15 03:07, Dave Funk wrote: Notes: 1) Due to SA pre-processing collapsing body into one long line, cannot match on '^' repeatedly, need to look for '\n' as line break indicator. Find start of a line and then following repeats of ".\n" Dave, I've been creating my own regular expressions (*with Regex Buddy despite some nay sayers here*) and they are working well. However, there are a few that seem to not hit on my test messages. In order to troubleshoot further, I need to see the message the way SpamAssassin see's it; is there a tool that will let me convert my saved email (*I view the email source in Thunderbird and save to files for testing*) into the rawbody format so I can test my regex? I do not want to post the email nor the rule to avoid the watchful spammers! Thanks, ak.
Re: Help with RegEx Rule
On 10/9/2015 12:07 AM, AK wrote: On 20/09/15 03:07, Dave Funk wrote: Notes: 1) Due to SA pre-processing collapsing body into one long line, cannot match on '^' repeatedly, need to look for '\n' as line break indicator. Find start of a line and then following repeats of ".\n" Dave, I've been creating my own regular expressions (*with Regex Buddy despite some nay sayers here*) and they are working well. However, there are a few that seem to not hit on my test messages. In order to troubleshoot further, I need to see the message the way SpamAssassin see's it; is there a tool that will let me convert my saved email (*I view the email source in Thunderbird and save to files for testing*) into the rawbody format so I can test my regex? I do not want to post the email nor the rule to avoid the watchful spammers! Thanks, ak. AK, Perhaps you'll have more luck looking at the debug output from SA itself? Something like spamassassin -t -D < email.mbox 2>&1 | grep -i RULE Regards, KAM
Re: Help with RegEx Rule
On 09/10/15 15:10, Kevin A. McGrail wrote: Perhaps you'll have more luck looking at the debug output from SA itself? Something like spamassassin -t -D < email.mbox 2>&1 | grep -i RULE Nope, no luck there either; did not see mention of my rule (though it's located inside /etc/spamassassin/local.cf). There are no lint errors either. Despite the bad rep RegexBuddy has here with some users, the rules I build with it for my bash/perl scripts work well. It's just that I have no idea how the email is transformed by spamassassin prior to processing; if I did, it would shed light on why one of my rawbody rules isn't working! I'll keep digging with Google in the meantime. Cheers, ak.
