spam tailored for circumventing SpamCop

[Bomarc]

I've been getting more spam that is tailored to circumvent SpamCop.  The latest one has two 'exploits' ... one is a limitation of SC (that shouldn't exist); the other is a new 'bug'. 

Three key areas that impede SC reporting:

• Bug: eMail subject line that causes the email body to not be processed.  
  How / do you want me to report this?  (As it has header info; I don't want to post it in a public forum)
• It's been raised before, and I'll raise it again:  The hard limitation of links needs to be re-though and  re-designed.  

This same message as #1; they had over 900 lines of "https://products.office.com/en-us/products..." which were obviously intended to circumvent SC reporting. 

Suggested fix (for each item .. If number exceed):

1. Remove duplicates; as duplicate email's checked and are not set; not counting duplicates would be a big first step.
2. Remove known URL's that a) don't accept reports or b) known "red herring" URL's (microsoft.com as an example)  
3. If max is still exceed .. report only the first "n"  - or - allow me to choose which "n" should be reported; with them all disabled

 

• Rethink the max char limited.  Another circumvention technique is to add a substantial amount of html / formatting / white space at the top of the body.  When SC truncates (at max chars); the URL's are below that line; and they don't get reported.

Suggested fix: 

1. Pre-process email to ignore/strip/remove non-visible HTML/white space before truncate and/or search for URL's before truncate.

I realize that a great deal of this is "the way it's always been".  The spammers are getting around that; and SC needs to be updated to handle the new tactics.

 

[petzl]

2 hours ago, Bomarc said:

How / do you want me to report this?  (As it has header info; I don't want to post it in a public forum)

Can you "doctor" info to hide what you don't want seen, get a tracking URL then cancel submit?

bit blind without tracking URL or headers, sounds like a Botnet DoS attack?

[Bomarc]

Here is the subject line  (which seemed to cause the problem):

Subject: RE:  xxxxxxxxxx =?UTF-32?B?UQAAAA==?==?UTF-32?B?dQAAAA==?==?UTF-32?B?YQAAAA==?==?UTF-32?B?bAAAAA==?==?UTF-32?B?aQAAAA==?==?UTF-32?B?ZgAAAA==?==?UTF-32?B?eQAAACAAAAA=?==?UTF-32?B?dAAAAG8AAAAgAAAAQwAAAA==?==?UTF-32?B?YQAAAA==?==?UTF-32?B?cgAAAA==?==?UTF-32?B?cgAAAHkAAAAgAAAAYQAAACAAAABHAAAA?==?UTF-32?B?dQAAAA==?==?UTF-32?B?bgAAACAAAABMAAAA?==?UTF-32?B?ZQAAAA==?==?UTF-32?B?ZwAAAA==?==?UTF-32?B?YQAAAA==?==?UTF-32?B?bAAAAA==?==?UTF-32?B?bAAAAA==?==?UTF-32?B?eQAAAC4AAAAgAAAAUwAAAA==?==?UTF-32?B?dAAAAA==?==?UTF-32?B?YQAAAA==?==?UTF-32?B?cgAAAA==?==?UTF-32?B?dAAAACAAAABmAAAA?==?UTF-32?B?bwAAAA==?==?UTF-32?B?cgAAACAAAABGAAAA?==?UTF-32?B?UgAAAA==?==?UTF-32?B?RQAAAA==?==?UTF-32?B?RQAAACAAAABUAAAA?==?UTF-32?B?bwAAAA==?==?UTF-32?B?ZAAAAA==?==?UTF-32?B?YQAAAA==?==?UTF-32?B?eQAAAA==?==?UTF-32?B?IQAAAA==?=
 

 

[petzl]

3 hours ago, Bomarc said:

Here is the subject line  (which seemed to cause the problem):

Don't see why that would not be parsed by SpamCop (it does for Gmail spam detection)

What is affecting SpamCop is the header spoofing of spammers in Gmail
If Gmail spam

copy from including this line down

ARC-Authentication-Results: i=1; mx.google.com;

[kae]

One additional observation that I've noticed is that spammers are inflating their HTML content with a lot of white space padding.  It would be nice if, after parsing the headers, the spamcop engine would reduce the padding with a regex replacement expression like

s/[ \t][ \t]*/ /g

That would get rid of all the extra garbage which isn't useful anyway and will probably allow a lot less truncation of email.  Just a thought.

[JohnS]

agree. looking forward to the changes, if they happen.