Last visited

Community Reputation

About cciu

Ah, I am an idiot. Thanks for all the quick help, it put me on the right track to figure this out.
It was indeed on my end: Office 365 is by default set to dump any outgoing message containing malware into the bitbucket, with no notification to the sender (!). Since the same malware filter operates on the way in as on the way out, you'd expect that it wouldn't catch much (unless you have an infected machine, which is not the case here), but one of the spam messages I was reporting did indeed come in with malware that O365 didn't detect....but when I tried to send it to SpamCop it did detect it.
I set the Malware filter to tell the sender (duh) and now if that happens again I'll be notified.
Sorry for the noise and thank you to all for putting me on the right track to figure this out!
John

I've been reporting spam for quite awhile by sending the spam as attachments all on one message to my SpamCop reporting address.
It has worked fine up until about a week ago, when the submitting of many (20 or so) messages via email seems to have broken. I can successfully submit a fewer amount of attached messages (I've tried one or two).
When I submit many attached spams, it seems to go to the bitbucket: I get nothing back, no error email, no bounce, nothing. Nothing shows up as reportable in my member account.
There is nothing coming back to my "spam" folder; it doesn't seem to be filtered. We use Office 365 and I did a Message Trace to be sure that it wasn't being filtered out at the server level for some reason, and confirmed that nothing was filtered out. I saw the notifications coming in from SpamCopy about the submissions that had just one or two attachments, but nothing about the submissions with 20 or so.
Again, this exact scenario was working fine up until a week or so ago, and nothing has changed on my end that I can see.
Any suggestions for how to troubleshoot and resolve this? Please don't suggest that I start submitting spam in ones and twos....it's bad enough that the processing step is so inefficient (per my Feature Request about the bugged and inefficient SpamCop submission loop), but this will make it even more time-consuming and inefficient.
Thanks,
John

Ok, even though apparently the Quick Reporting feature is not dependent on SpamCop Mail (the statement at that link must be incorrect), I'm really not jonesing to submit spam without a verification step: that seems dangerous to me, from a mis-reporting, friendly-fire perspective.
I truly think the verification step is necessary and I'm not advocating avoiding it.
I just think that step should be made to Not Suck™, by:
fixing the needless details that vertically pollute the UI (even when "Technical Details" is unchecked) fixing the useless step where it takes you back to "Report Now" even when there's more spam in the queue to report.

The loop is necessary. The double-loop that I originally posted about is definitely not: it's just unfortunate or obsolete design.
I agree that it's often all too easy to report innocent bystanders, which is why it's all the more important to give the option of a clean, minimalist design that doesn't require incessant scrolling up and down, etc.
All the extraneous stuff on the screen doesn't enhance the reporting process and the need to visually distingush between what should and shouldn't be reported, it impairs that process.
The web devs need to take a hard look at the output of a spam report and whittle it down to the necessities (what is and isn't required for accurate reporting) and make that an option for normal spam reporting. Do we sometimes need all the gory details to figure something out? Absolutely. But not with every....bloody....spam.
It's been this way forever and sometimes it's difficult to step back and rethink the original assumptions, but it's time.
Thanks, but I'm not a SpamCop Mail user and have no aspirations as such: I just want to contribute to the effort as quickly and efficiently as possible, while keeping a very high level of accuracy and a very low level of false reporting. The current reporting interface needlessly impedes that process.

Hence the need for, and presence of the checkbox. But the checkbox should either do what it claims (remove all the technical details when they're not desired, which it does not currently do), or be changed to something more granular, perhaps a technical detail level of 1 through 3, for example.
The technical details are not required to properly report spam....I don't need to see Routing Details or watch SC Recursing the Multipart, blah, blah, blah unless I'm particularly interested in those details (which I sometimes am)....yet they often still show up when the checkbox is unchecked.
The feature is semi-broken.....the typical logging options are well-established and well-understood in many systems and apps; it's not all that subjective.
Regardless, even if it is that subjective, a proper control for it is needed to handle that subjectivity....that's the point of user-controlled options.

I agree; while I understand the need to review the information for each spam (to ensure that we're not reporting legit links that are used as part of spam, like news stories), it could be much more condensed. Even without the "technical details" option, it's still way too verbose for what we need.

[Re-posted with minor changes here, after discussion in SpamCop Reporting Help]
I recently starting submitting a lot more spam via email and then processing it via the website and wondered why the process isn't streamlined.
For example, after I receive the confirmation that SpamCop has received my emails for processing, I go to the website and login, then click the Report Now link. That gives me a spam to look over and report, which I do, using the Send spam Report(s) Now button.
At that point, since I have other messages waiting to process, I'd expect the site to just process another spam and present me with the details page and another Send spam Report(s) Now button. But instead I'm back to the original start page, having to click the Report Now link yet again. It's a wasted page-load for the server, a wasted wait and click for the user, and wasted time all around; while it isn't much, when you do it daily for 15-30 spam messages, it really gets old.
Could the processing be changed to automatically load the next spam for processing, if there's one waiting?
Thanks,
John

Makes sense. Is posting the suggestion to change it here the correct place to do it, or should I post it in the "New Features" section? It's not really a new feature, more of a correction to an old design, but I'd like to get it on someone's radar....it would save a ton of reporter time and clicks over the enormous number of spam messages that we collectively report.

I recently starting submitting a lot more spam via email and then processing it via the website and wondered why the process isn't streamlined.
For example, after I receive the confirmation that SpamCop has received my emails for processing, I go to the website and login, then click the "Report Now" button. That gives me a spam to look over and report, which I do, using the "Send spam Report(s) Now" button.
At that point, since I have other messages waiting to process, I'd expect the site to just process another spam and present me with the details page and another "Send spam Report(s) Now" button. But instead I'm back to the original home page, having to click the "Report Now" button yet again. It's a wasted page and a wasted click, which isn't much, but when you do it daily for 15-30 spam messages, it really gets old, and IMO it's just a minor design flaw.
Any agreement that it should be changed to just keep giving that second spam details page over and over until all the spam is processed?
Or is there some reason that the site designers decided to put this inefficiency into the process on purpose?
Thanks,
John

Thanks for the advice and concern, but the salient part of that quote, "by design", sufficiently clarifies it for this case: there's no way that it's "by design" that the mixed-case "hTtP" isn't recognized as a valid scheme (and in fact is misinterpreted as some kind of email parameter), whereas "HTTP" or "http" is recognized. It's very clearly a parser bug and therefore by definition not "by design".

My apologies, I should have munged it.
You may want to look up the definition of "material change". Changing the case of "hTtP" to "http" is certainly not such a change by any definition of that phrase.

There has been spam coming in with HTML bodies like this:
The parser looks at the <A> tag and for some reason throws an error about "Remove email parameters" and refuses to report the link:
However, simply changing the scheme from the mixed-case "hTtP", to consistent case "http" or "HTTP" allows the parser to correctly parse and report the link.
This appears to be a bug in the parser: it should be able to handle any text case in which the scheme might appear.