Search the Community

Showing results for tags 'parsing'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Discussions & Observations
    • Announcements
    • Start Here - before you make your first Post
    • How to use .... Instructions, Tutorials
    • Going to make your first post here?
    • SpamCop Reporting Help
    • SpamCop Blocklist Help
    • SpamCop Email System & Accounts
    • Mailhost Configuration of your Reporting Account
    • New Feature Request
    • SpamCop Lounge
    • Geek/Tech Things
    • Suggested Tools and Applications
    • Testing
    • FAQ Under Construction

Calendars

  • Community Calendar

Found 3 results

  1. I have had a few spams recently (windward casino) that spamcop gave error message: at the end of "Finding links in message body" I did some exploration, and discovered that the problem seems to be the way the spam emails are constructed. They are multipart/alternative, and the alternative header blocks are ending with a line containing a single space. Deleting that space in the body of the content lets spamcop parse the body correctly. --Section.«guid» Content-Type: text/plain Winward Casino: US Players, … That *blank* line is really a space. Deleting the space character allows the "Finding links" to work again. Example: https://www.spamcop.net/sc?id=z6408256844z01c6f10262d93f7fd6bc56e589ea4e33z I understand that the original purpose of that message, was due to an error in the user handling the copy/paste/forward of the emails in such a way that email header was no longer accurate. However, in this case, the "couldn't parse head" is really the multipart header in the body of the message. That was not really clear from the context.
  2. I'm trying to report a "work at home" spam (probably money mule recruiting). Spamcop refuses to report it saying there's no date. Actually there is a Date: header, but with a date in the future. My guess is that's confusing spamcop. If I look at the unsubmitted report, it doesn't show that message any more. Why is Spamcop trusting the easily forgeable Date: header? The only definitive time is in the last trusted Received; header Here's the headers:
  3. It seems that Spamcop fails parsing URLs in Multipart spam. Since about a week or so if there is Multipart declared in the headers and the text/html with some URLs in the body Spamcop fails to see the URLs. Is there a problem?