All Activity
This stream auto-updates
- Past hour
-
A similar lock-up has been noted when a link in the body contains '..' for example some_domain..com The answer seems to be 1) report all other pending spam in you queue then 2) <delete all> pending spam waiting to be reported. This should get the offending spam out of the list of spam waiting to be reported. At this point the spam is over 11 days old so there is nothing else to do.
- Today
-
Removed post duplicated after "504 Gateway Timeout".
-
This report is still showing up as an Unreported spam Saved.
-
Did you see/follow the link More information on this error.. ? Some SC philosophy handling miss formed/formatted email/spam is provided. What you suggest may seem to be trivial, but if you read many old post, you will see this forum is full of "trivial" fixes suggested for one or another intentional trick or dumb error that trips up the parser. The question becomes 'how much time should be spent tracking errors made by spammers or their software tools?' Gmail has the objective to generate a display for each email a client receives no matter how god-offal (people would scream if 'trailing white space' caused no display). If on occasion they get one wrong, nothing is lost and they can claim 'The email is wrong but we tried.' On the other hand, if SC tries to correct an error and the effort results in an incorrect accusation, the credibility of SC is lost. I might also suggest "New Feature Request"
-
Maybe the initial post was not clear enough. The post was because SC was not parsing the body of the spam email, not because it was get the wrong reporting address. Unless can not find any links is the same as wrong address. What I see is that the post has been moved **to** "Spamcop Reporting Help", while I thought I had initially put it in the "Routing/Report address issues". Which is the reverse of what @Lking seems to say. Neither seems to be quite correct, but I could not find a place to report that the parser is (partially) unable to handle an email that was submitted with full content. And with a trivial solution. Once the start of an alternative block is detected by the parser, trim trailing white space until the end of the header (for the block) is found. That should allow this type of email content to be parsed, without breaking anything else. Given the messages I got, I assume that the parser currently does not see that line with a space as the end of the header, and keeps reading more lines expecting more header content. Which then fails. But it seems to work just fine in gmail.
-
The reports for a certain spam mail just stop in the middle during URL parsing. So no reporting is possible. I tried it a couple of times, but the problem persists. I would not care much for a single spam mail, but seeing a mail defeating the parser is a little bit disturbing. Report: https://www.spamcop.net/sc?id=z6408418846z7e91cf9e63150bfe45a50e344f01f306z Mail: https://pastebin.com/2wj4jFtY
-
So instead of fixing this, the answer is "Just don't report that?"
- Yesterday
-
Moved from "Reporting help" => "Routing/Report address issues" Other post in the sub forum identify corrected addresses for given IP/IP blocks.
-
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.
-
Abuse contact for 143.95.0.0 - 143.95.255.255 is abuse[at]athenixinc.com
- Last week
-
Thanks for helping! The reason was a bad account password
-
Looking at the spams, it would appear that the spammer is adding the X-Originating-IP header to confuse the matter. I do not see that IP listed in any Received lines. As it stands, I can trust any spam as far back as my border server. I cannot trust it past that. My border server will have the logs with the IP that for whom I need to report. They in turn can use their logs and pass it up to their suspected source.
-
When submitting the numerous African scam emails to SC, SC inconsistently detects the X-Originating-IP address that is contained in most of them. Below are some examples. I'd say that about 10% of X-Originating-IP addresses listed in emails submitted to SC are detected and reported by SC. For the rest of those IP addresses, it requires manual email submission outside of SC to the abuse contacts. Why does SC detect and report so few of the X-Originating-IP addresses? (detected X-Originating-IP )X-Originating-IP: 41.85.176.110https://www.spamcop.net/sc?id=z6403748467z699c93e5f840844ede2b8d8d2a237554zX-Originating-IP: 41.85.176.110https://www.spamcop.net/sc?id=z6404117097zb4a331cc2a42604adca1ee392ccaabc0z(did NOT detect X-Originating-IP - NOTE that I tried removing the brackets and did a test submission, but the IP address was still not detected)X-Originating-IP: [41.86.234.162]https://www.spamcop.net/sc?id=z6406866999z99adf4922fa966b5fed68ebaf3b2fd37zX-Originating-IP: [41.85.161.155]https://www.spamcop.net/sc?id=z6406728731z23dd15f2eb5e25f40a46806c87083ddaz
- Earlier
-
If SpamCop mailhosts don't work for you or your company, reporting through SpamCop is not a option sorry.
-
Ew. That is obviously not a universal solution to the problem. Please explain why IPs less than 127.255.255.255 work, but domains greater than 128.0.0.1 don't?
-
Sound to me like you and Others each need to configure your/their individual reporting account mailhost to reflect the path(s) their email takes. All accounts are independent so configuration of one reporting account will not affect another. One reporting account at a time.
-
So this might where the confusion is. Yes and yes. *I* report spam from a single spamcop account for all email I have access to: Yahoo!, Gmail, etc, and my work email. *Others* in my company report spam to their work email (as well as to their personal email, most likely) using their own spamcop accounts. So, if it is as simple as registering the misflagged host as a mailhost, how can we do that for *ALL* reporters without mucking up their personal spamcop accounts? (I get the sense reading the warnings that a mailhost is only valid for the one account setting it up, and once you go down that route you must set it up for ALL mailhosts you include in reports.)
-
Yes, the mailhost for each reporting account needs to be configured. However, reading between the lines, are several people reporting using the same SpamCop reporting account? The reporting mailhost does not involve the mailbox but the path to the mailbox. For example, personally I report spam from all mailboxes on four different domains using only one reporting account. All the email is serviced by the same host so the path for all email for all the domains is the same; a fairly simple mailhost configuration. The configuration is more involved where email from several domains (gmail, me, yahoo...) are all forwarded to a single account and reported from there.
-
I'm going to say this again, this isn't just me, it's the entire company. Everyone who reports spam through spamcop is getting this problem. Solving it only for me with my email (a) only fixes it for my reporting and (b) makes it harder when I have to report through other emails.
-
Your problems should end if you just used SpamCops mailhost program? Just requires you to have your email address to be sent a validation which identifiess your mailhost This belongs in the just "too easy" basket? You are making reporting hard for yourself!
-
Ok, I did a bit of hacking and have found two variants of the same header, one that "works" and one that "fails". https://www.spamcop.net/sc?id=z6406368915z3c233e5f6b35df52e43f378d28d0b9f2z This one parses "correctly" by picking up the IP of the originator. https://www.spamcop.net/sc?id=z6406369049zc70613d15e81e38ceff9ce99252dac8ez This one parses incorrectly, by picking up the intermediate IP (in this case, I randomly picked an IP, which happens to be NASA.) The one difference is the top (newest) Received: line: 127.163.151.35 (parses correctly) vs 129.163.151.35 (parses incorrectly and flags NASA). Ideas? Received: from null.net (129.163.151.35) by s03.null.net (255.254.253.252); 07 Sep 2017 10:55:26 -0400 Received: from null.com ([255.254.253.252]) by esa3.null.edu with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Sep 2017 10:55:21 -0400 From: User <User@bogusemail.com> To: "x" <x> Subject: This is spam! Date: Thu, 7 Sep 2017 14:55:18 +0000 Message-ID: <6c29________________________2fda@anywheres.au> Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_6c296c4007fa2384928b5c7de3d02fdasmtp13abcdefgcom_" MIME-Version: 1.0 Body of Message
-
I assume your question is why? The way I read the results is: When the parser got to 3: received and found the entry was incorrectly formatted (no date) it backed up to 2 which is an internal handoff. Of course if 3 in incorrect 4, can't be trusted either. Wouldn't want to report yourself - internal handoff - which leaves the untrusted/trivial forgery which "we" wouldn't want to report
-
https://www.spamcop.net/sc?id=z6406269155z2179a6c2238e07779015ef8b2b5c81b0z Tracking message source: 154.118.7.2: Routing details for 154.118.7.2 Report routing for 154.118.7.2: abuse@spectranet.com.ng This email contains no date
-
just needs your ONE email address? Not every email address (unless a different domain addy) SpamCop will send you a verification email for each host which you copy and past into top link For Fastmail I got two validate emails from SpamCop which identifies all mailhosts
-
This is bigger than just me. It's my entire company. The problem is emails sent to my company through these filters, not my personal emails. Entering mailhosts for me only solves the problem for me, and creates a risk for my personal emails. Sorry, please help me figure out what else might be causing it.
