Jump to content

cciu

Members
  • Content Count

    27
  • Joined

  • Last visited

Everything posted by cciu

  1. [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
  2. 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
  3. 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
  4. It's been a couple of months, so just thought I'd check in to see if there's any love on this request.... :-)
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. Thanks; posted it to New Features just now.
  10. 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
  11. 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.
  12. 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.
  13. Interestingly, just had the same thing happen with "HTTP://", not mixed case but all uppercase. Perhaps the parser only likes all lowercase....
  14. 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".
  15. 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.
  16. I've found manual reporting of abused links to the address abuse[at]bit.ly to be extremely responsive, timely and helpful. Unfortunately, their powers-that-be haven't managed to change the WHOIS info so that SpamCop's abuse reports properly go to abuse[at]bit.ly yet....they still go to abuse[at]ntt.net So I thought I'd include abuse[at]bit.ly in the extra notification field when I report abuse bit.ly links....but SpamCop dev/nuls them, with no explanation as to why. So my question: can SpamCop not dev/nul that address, or at least explain why they're doing that? Presuming that bit.ly abuse is as responsive to SpamCop reports as they are to me personally, is it possible to override the WHOIS info and report bit.ly links to abuse[at]bit.ly? Thanks, John
  17. LOL, thanks I know what dev/null is...my BS in Computer Science taught me that circa 1982. I'm wondering why abuse[at]bit.ly has been dev/null'd, i.e. why SpamCop refuses to send reports to that address, and if that refusal can be reconsidered. Considering the tons of bit.ly spam that I'm seeing, I thought someone here might know already, or a SpamCop deputy might answer here for everyone's benefit, so I started here in the forums first. If I don't get a response, I appreciate the direct email for the deputies and will try that. Thanks, John
  18. Yeah, looks like SpamCop gives priority to what WHOIS says over what Abuse.net says. Not sure if that's by design or what.... The further question is why SpamCop is dev/null'ing abuse[at]bit.ly John
  19. cciu

    Difficulty parsing geocities.com

    Well, it doesn't seem to be a server load issue....I'm trying to report a spam containing http://uk.geocities.com/iorgo15348ingmar84674/ here at 5:50am Eastern, and I'm at about 30 reloads with no luck yet. http://www.spamcop.net/sc?id=z860485271zcd...2536b093528e03z I'm off to report it manually, but just thought I'd add to the thread on this problem.
  20. cciu

    Difficulty parsing geocities.com

    I've seen this same issue with geocities links in particular, and have had to reload many more than 27 times (just out of pure bloodymindedness) to get it to work. It seems random, but that's just my perception. Unless someone thinks that Yahoo is specifically targeting SpamCop DNS or whois or whatever queries (which I haven't heard mention of), then this seems more like some kind of bug in SpamCop's production parsing engine than the other issues that have been discussed in the FAQs. I'm glad that the programmers are looking at it...this seems like an easily reproducible issue and thus should be interesting for a programmer to isolate and hopefully eliminate.
  21. I'm considering rejecting all ServePath IP addresses on my mailserver, which I try to do whenever I encounter a smaller ISP that refuses or bounces SpamCop reports. The explanation of why an abuse address is devnulled is usually pretty clear in the reporting system's technical details, but there's no reason specified for abuse[at]servepath.com I searched SpamCop, these forums, and the web for info on what's going on with SpamCop and ServePath, but didn't see anything conclusive. Does anyone know what's going on with ServePath and SpamCop before I block them?
  22. Oops, ok, got it now. I haven't yet reported it to FirstClass, so I'll be able to give them the correct info. Thanks again for your expertise and help in straightening out what's truly a header and what's not.
  23. I've noticed that SpamCop doesn't correctly parse the links in the HTML below. The dashes and long number following the </html> tag seems to trigger the problem. If I delete that before I submit the message, SpamCop properly parses the HTML and finds the link. With the dashes and number there, SpamCop claims that there are no links. <html> <head> </head> <body> <p><font size="4">We carry all the prescription and non prescription drugs you could want. From Valium, cialis, viagra and everything else. No prior doctor prescription is required and we can save you up to 50% over your local pharmacy. Give us a try by <a href="http://www.allnewdeals.com"> going here</a> and just have a look around. You will get your medication the next day and we can always refill them as you need. So <a href="http://www.allnewdeals.com">come on in</a> and have a look around. You will find what you are looking for.</font></p> <p> </p> <p> </p> <p><font size="4">nostalgic allow cult screen cornet sundial china caesar baylor triplicate paternoster sleuth pharmaceutic gem bellman involuntary grieve percussive johannesburg henderson crotch assemblage twain valois veal poultry o'leary about scot chastity apathy balmy depose decedent baden bolshevist sanction beret bootstrapping hastings droopy catholic brook ricochet fisherman repression bombay refer steppe docile nil honda stir flintlock drizzle groom shepard asphalt decide whoever convulsion mist mt crt alps klaxon applied buttonhole cargill camelopard cheesy cysteine quartz minneapolis rodgers winkle judicature songbook yardstick desolate shaky contrive hyperboloidal fifteen commissariat </font></p> remove http://www.offerspages.com/qog345/pr/rf.html </body> </html> ----911846668031164--
  24. I wasn't understanding what you meant originally. Some reading of the postings in the NNTP resources, as you suggested, brought the solution. I didn't realize that the "header" (as reported by my FirstClass email system) was including what is considered the body of the message. I got some new versions of similar messages today, and by putting a blank line between the following lines: X-Mailer: AOL 4.0 for Windows US sub 161 MIME-Version: 1.0 ...it works like a charm, and doesn't require changing the body in any way. Looks like I've got a feature request for FirstClass to work on: getting that blank line right. Thanks for pointing me in the right direction. FWIW, I didn't read the NewsGroups first because the "SpamCop forum" page (http://members.spamcop.net/help.shtml) suggests that the new web-based forums are the new, improved, and preferred way to get help. I'll look at Newsgroups anyway the next time!
  25. Sorry, not me. I'll head over there and check it out though. It's not surprising: I've gotten over 20 of these types of messages, so it's likely that other people are experiencing the same bug in SpamCop's HTML parser. FWIW, it's not a lack of a line between header and body, as I'm using the separate header and body submission form. Also, removing the line with the dashes and number in it at the end resolves the problem, without changing anything with blank lines between header and body. I still say the parsing engine should see a link in there, regardless of any silly things that the spammers do to try to make it non-standard.
×