MIG Posted May 10, 2019 Share Posted May 10, 2019 (edited) Hey Tesseract, Thank you! " common factor seems to be an invalid host name both for starting with . and for containing @ " I agree, using account with MailHosts configured - my results match yours, using an account without MailHosts, the results are: https://www.spamcop.net/sc?id=z6545556269zcc99c68f6b5503a9beee14fed8dfa944z https://www.spamcop.net/sc?id=z6545556709z3accdd54783b338901c40c748bee5947z https://www.spamcop.net/sc?id=z6545556992za7eece61ab47f04741f34bc8b0d86b17z 🤔 G🦗 H Edited May 10, 2019 by MIG Quote Link to comment Share on other sites More sharing options...
nh905 Posted June 2, 2019 Author Share Posted June 2, 2019 I am seeing an increasing number of spam with "Received: from localhost (127.0.0.1) by .<domain>", almost all from Russian. I can consistently get Spamcop to report the spam by removing the dot before the domain, but this is time-consuming given the volume. I am trying to automate the editing and reporting process but running into a few issues. I reported the problem to Spamcop on May 17th but heard nothing back. Does anyone have ideas on how to get this issue resolved by spamcop.net? Thanks, Norbert Quote Link to comment Share on other sites More sharing options...
MIG Posted June 2, 2019 Share Posted June 2, 2019 (edited) 1 hour ago, nh905 said: I am seeing an increasing number of spam with "Received: from localhost (127.0.0.1) by .<domain>", almost all from Russian. I can consistently get Spamcop to report the spam by removing the dot before the domain, but this is time-consuming given the volume. I am trying to automate the editing and reporting process but running into a few issues. I reported the problem to Spamcop on May 17th but heard nothing back. Does anyone have ideas on how to get this issue resolved by spamcop.net? Thanks, Norbert Hi Norbet, May we have some SC Tracking URLs please? From the top of the SC Parser: Looks like: https://www.spamcop.net/sc?id=z6550829312z28b288e7765aed3250e66e22878787e8z & are you using a SC account with MAILHOSTS configured? Please let us know? Thanks! G🦗 H Edited June 2, 2019 by MIG Quote Link to comment Share on other sites More sharing options...
nh905 Posted June 2, 2019 Author Share Posted June 2, 2019 @MIGsee https://www.spamcop.net/sc?id=z6551810734z18e8e17fdf9218b1235dc26a129e99c9z. Removing the period in front of the host in "Received: from localhost (127.0.0.1) by .7E3tTgaTrxrjG0@track.list-manage7.net id MgFLi65tFAWB" results in Spamcop parsing the headers properly. I configured Mailhosts. some years ago. Thanks, Norbert Quote Link to comment Share on other sites More sharing options...
MIG Posted June 6, 2019 Share Posted June 6, 2019 On 6/3/2019 at 4:38 AM, nh905 said: @MIGsee https://www.spamcop.net/sc?id=z6551810734z18e8e17fdf9218b1235dc26a129e99c9z. Removing the period in front of the host in "Received: from localhost (127.0.0.1) by .7E3tTgaTrxrjG0@track.list-manage7.net id MgFLi65tFAWB" results in Spamcop parsing the headers properly. I configured Mailhosts. some years ago. Thanks, Norbert Hello Norbet, Sorry it's taken a while to get to this (partly thinking/pondering) I parsed using SC NOMAILHOSTS account result: https://www.spamcop.net/sc?id=z6552696162zc69a145cc755ec5c7e058df9f70058bbz & I then did as you did, removed . result: https://www.spamcop.net/sc?id=z6552701693z0f0a16068c0f32eb79bf213e6cee702az Both methods result in a successful parse 85.119.145.133 still@mits.ru 54.183.130.144 abuse@hootsuite.com --------------------------------------------------------- So, unless I'm mistaken, we've concluded the parser can process if the . is removed and or can process using a NO-MAILHOSTS configured account. To SCFA & SCA (still 🤔 if they're one and the same or just share a 🛏) **Is the . issue a real SC issue & fixable or a perceived issue? ** What is it about SC accounts with MAILHOSTS configued that SC is unable to process spams with . issue? Surely , as . issue keeps presenting, it fit's the criteria for: attention/review, at the very least? 🙏G🦗H🙏 ---------------------------------------- Just for interest: Digging (deeper) 85.119.145.133 https://www.abuseipdb.com/check/85.119.145.133 abuse@selectel.ru on 54.183.130.144 https://www.talosintelligence.com/reputation_center/lookup?search=54.183.130.144 = ow.ly = abuse@amazonaws.com https://www.virustotal.com/gui/url/8ef4ed0e21da1546109e27b2b861d6ddf0bcccc8fa5a52f45866699ee3ed5db1/detection https://www.virustotal.com/gui/ip-address/54.67.120.65/summary Quote Link to comment Share on other sites More sharing options...
gnarlymarley Posted June 8, 2019 Share Posted June 8, 2019 On 6/6/2019 at 7:31 AM, MIG said: So, unless I'm mistaken, we've concluded the parser can process if the . is removed and or can process using a NO-MAILHOSTS configured account. Yes. I suspect the function that they expect that rather than the parser dying, it would come up with something like "Not one of your mailhosts". Then they could continue their submissions with one account that has mailhosts enabled. Quote Link to comment Share on other sites More sharing options...
Jelmer Jellema Posted June 19, 2019 Share Posted June 19, 2019 On 6/8/2019 at 3:05 PM, gnarlymarley said: Yes. I suspect the function that they expect that rather than the parser dying, it would come up with something like "Not one of your mailhosts". Then they could continue their submissions with one account that has mailhosts enabled. Even though this .issue appears with mailhosts enabled, I don't think it has anything to do with the dotted entry not being a mailhost. Remove the dot and it parsed fine, even though the host mentioned is not a mailhost of the SC user. So my (quite uninformed, I admit) opinion is that the .issue crashed the code that checks for mailhosts, so the best message would be "error parsing for mailhosts, continuing with mailhosts disabled"... In my opinion as a SC user, I think "manually remove the dot" is no solution. We forward a lot of spam to SC, and cannot manually edit each of them, also because we forward it to SA-learn as well and I am not sure if changing the content of the mail will changes the Bayes detection. Finally: Am I the only one to suspect the .issue is created by spammers to make it impossible for SC to parse the spam? Jelmer Quote Link to comment Share on other sites More sharing options...
MIG Posted June 20, 2019 Share Posted June 20, 2019 22 hours ago, Jelmer Jellema said: (1) the best message would be "error parsing for mailhosts, continuing with mailhosts disabled" (2)I think "manually remove the dot" is no solution. (3) Am I the only one to suspect the .issue is created by spammers to make it impossible for SC to parse the spam? (1) Agreed, some of SCParsers "informatiion/feedback" is very obtuse, incorrect and a few other things. Not sure there's a priority on tweaking SC feedback, sadly, despite our pleadings. (2) Agreed Jelmer, and even tho it's presumptive of me, I think the majority of folks here, who've encountered the . "out damm dot!", also agree with you. (3) No, I'm pretty sure I've seen similar commentary from other folks - never fear Jelmer, you're never alone! Cheers! G🦗H Quote Link to comment Share on other sites More sharing options...
gnarlymarley Posted June 21, 2019 Share Posted June 21, 2019 On 6/20/2019 at 5:41 AM, MIG said: (3) No, I'm pretty sure I've seen similar commentary from other folks - never fear Jelmer, you're never alone! Jelmer, I get this occasionally too. I had some communication with the SpamCop Admins in 2017, but I am not sure if that is when I first saw it. Being that some folks called it a dot or period or {DOT}, it does make searching the forum difficult. Since spammers do not always get the reports (their ISP does and doesn't always pass it on), they probably do not know for sure what is caught by spamcop. Quote Link to comment Share on other sites More sharing options...
gnarlymarley Posted June 24, 2019 Share Posted June 24, 2019 On 6/21/2019 at 9:30 AM, gnarlymarley said: I get this occasionally I have located "Reporting form not loading fully afterparsing spam" from 2018, so this issue is pre-V5.0. I don't see any solutions on that post. My solution was to have two account setup and if I see a dot at the beginning of the hostname, I send the spam to the non-mailhosts account. On 6/8/2019 at 7:05 AM, gnarlymarley said: I suspect the function that they expect that rather than the parser dying, it would come up with something like "Not one of your mailhosts" By this comment, I meant that it would be nice if the parser was fixed... Quote Link to comment Share on other sites More sharing options...
MIG Posted June 25, 2019 Share Posted June 25, 2019 13 hours ago, gnarlymarley said: it would be nice if the parser was fixed... G🦗H furiously nodding head in agreement! Quote Link to comment Share on other sites More sharing options...
Jelmer Jellema Posted June 25, 2019 Share Posted June 25, 2019 (edited) 20 hours ago, gnarlymarley said: By this comment, I meant that it would be nice if the parser was fixed... That would be nice!! As I told before, we also send the mails to our own parser, which hands them over to sa-learn. I am looking into a small addon for this scri_pt, which would send the mail to spamcop as well, after checking for and fixing any .domain issues... I'm a bit busy, but will try to do this soon. It can't be more than a few (extra) lines of code. Because of the fact that this parser scri_pt was first built somewhere around 2007, It will be in Perl though. Still going strong 🙂 Edited June 25, 2019 by Jelmer Jellema Quote Link to comment Share on other sites More sharing options...
Jelmer Jellema Posted June 25, 2019 Share Posted June 25, 2019 On 6/20/2019 at 1:41 PM, MIG said: never fear Jelmer, you're never alone! That's such a warm feeling! Quote Link to comment Share on other sites More sharing options...
Tesseract Posted July 5, 2019 Share Posted July 5, 2019 Meanwhile, nearly all the spam that makes it into my inbox is now of this variety. Quote Link to comment Share on other sites More sharing options...
MIG Posted July 6, 2019 Share Posted July 6, 2019 On 6/25/2019 at 11:07 PM, Jelmer Jellema said: That's such a warm feeling! 🤗 Quote Link to comment Share on other sites More sharing options...
MIG Posted July 6, 2019 Share Posted July 6, 2019 (edited) 14 hours ago, Tesseract said: Meanwhile, nearly all the spam that makes it into my inbox is now of this variety. May we have a/some tracking URLs please Tesseract? Cheers, G🦗H Edited July 6, 2019 by MIG Quote Link to comment Share on other sites More sharing options...
MIG Posted July 6, 2019 Share Posted July 6, 2019 On 6/25/2019 at 11:05 PM, Jelmer Jellema said: That would be nice!! As I told before, we also send the mails to our own parser, which hands them over to sa-learn. I am looking into a small addon for this scri_pt, which would send the mail to spamcop as well, after checking for and fixing any .domain issues... I'm a bit busy, but will try to do this soon. It can't be more than a few (extra) lines of code. Because of the fact that this parser scri_pt was first built somewhere around 2007, It will be in Perl though. Still going strong 🙂 G🦗H loves perl(s). Does that mean it will be able to be incorporated into SC Parser Jelmer? Cheers! G🦗H Quote Link to comment Share on other sites More sharing options...
Tesseract Posted July 7, 2019 Share Posted July 7, 2019 On 7/6/2019 at 11:11 PM, MIG said: May we have a/some tracking URLs please Tesseract? Cheers, G🦗H I don't think there's really anything more to learn from them at this point, as it's the same behaviour documented earlier in the thread with the same type of invalid hostname in the messages. But here are two from today: https://www.spamcop.net/sc?id=z6558374359zf6c6bc297b1bf5ec039668d1d2ea7f81z https://www.spamcop.net/sc?id=z6558374020zba4d5b7c0c1112bc566769c280cda976z Quote Link to comment Share on other sites More sharing options...
MIG Posted July 8, 2019 Share Posted July 8, 2019 (edited) 10 hours ago, Tesseract said: I don't think there's really anything more to learn from them at this point, as it's the same behaviour documented earlier in the thread with the same type of invalid hostname in the messages. Hello Tesseract, Thanks! (G🦗H did have the same thought), however, it's always fun to have new toys to play with even if they're the same toys! Parsing the 1st spam/tracking URL, without hosts, https://www.spamcop.net/sc?id=z6558422807zd2525b6f74678b5e8a4df150cb699739z Parsing the 1st spam/tracking URL, without hosts: https://www.spamcop.net/sc?id=z6558423020z31cbae589deaec37fb6972c626c7c239z May I ask, have you contacted SCA, Richard? Some folks are reporting SCA are fixing, account HOST configuration issue, on a case by case basis. Please let us know? Cheers G🦗H Edited July 8, 2019 by MIG Quote Link to comment Share on other sites More sharing options...
RobiBue Posted July 8, 2019 Share Posted July 8, 2019 10 hours ago, Tesseract said: I don't think there's really anything more to learn from them at this point, as it's the same behaviour documented earlier in the thread with the same type of invalid hostname in the messages. But here are two from today: https://www.spamcop.net/sc?id=z6558374359zf6c6bc297b1bf5ec039668d1d2ea7f81z https://www.spamcop.net/sc?id=z6558374020zba4d5b7c0c1112bc566769c280cda976z atchooly.... is there a reason why the first From line doesn't have a colon ":" From bounce@menshealth.com Mon Jul 8 01:35:59 2019 Return-Path: <bounce@menshealth.com> X-Original-To: x Delivered-To: x in my book, that would be a reason for failure... Quote Link to comment Share on other sites More sharing options...
gnarlymarley Posted July 8, 2019 Share Posted July 8, 2019 (edited) 3 hours ago, RobiBue said: is there a reason why the first From line doesn't have a colon ":" From bounce@menshealth.com Mon Jul 8 01:35:59 2019 Return-Path: <bounce@menshealth.com> X-Original-To: x Delivered-To: x in my book, that would be a reason for failure.. The first line is not supposed to have a colon. It is the mbox begin header that allows multiple emails messages to populate a single file (I believe this is RFC4155). I myself have submitted these in the past without the parser hanging, but I do not have an example of a good parse readily available. When I come across one, I can post the proof that the parser is okay with the first line. A little further down, I see the proper From: with the colon. From: Best deal Here is a good parse that has the mbox line intact: https://www.spamcop.net/sc?id=z6539474280z193289084e1307447d9bce67061eecfbz Edited July 8, 2019 by gnarlymarley found a good parse with the From without a colon Quote Link to comment Share on other sites More sharing options...
Jelmer Jellema Posted July 8, 2019 Share Posted July 8, 2019 On 7/6/2019 at 3:25 PM, MIG said: G🦗H loves perl(s). Does that mean it will be able to be incorporated into SC Parser Jelmer? I'm afraid I am not looking into that. I just thought I fixed our "parse and report spam" scri_pt to check for the .issue before sending it to spamcop. What we do now: Any received spam (either by us or by trusted clients who can report it to us) is send to spamcop and our "leerspam" parser (learn spam) Spamcop is then handled through the web interface for checking and reporting The leerspam parser will check the attachments and feed them to sa-learn What I want to change (when I have time) Any received spam is send to a new "report spam" parser, as an attachment The "report spam" parser will check the attachments and feed them to sa-learn It will also check the attachments, when needed fix the .issue, and send them to spamcop The essential part of this essay being when I have time, as always. Regards, Jelmer Quote Link to comment Share on other sites More sharing options...
RobiBue Posted July 8, 2019 Share Posted July 8, 2019 7 hours ago, gnarlymarley said: [...] mbox begin header that allows multiple emails messages to populate a single file (I believe this is RFC4155). /me/ stands corrected. Thank you 😊. wasn’t aware that the headers could share importance with a DB file structure (mbox in this case) Quote Link to comment Share on other sites More sharing options...
MIG Posted July 8, 2019 Share Posted July 8, 2019 5 hours ago, Jelmer Jellema said: I'm afraid I am not looking into that. I just thought I fixed our "parse and report spam" scri_pt to check for the .issue before sending it to spamcop. What we do now: Any received spam (either by us or by trusted clients who can report it to us) is send to spamcop and our "leerspam" parser (learn spam) Spamcop is then handled through the web interface for checking and reporting The leerspam parser will check the attachments and feed them to sa-learn What I want to change (when I have time) Any received spam is send to a new "report spam" parser, as an attachment The "report spam" parser will check the attachments and feed them to sa-learn It will also check the attachments, when needed fix the .issue, and send them to spamcop The essential part of this essay being when I have time, as always. Regards, Jelmer Hello Jelmer, Yep, noted the emphasis on "when I have time"🙂. The "essay" is a good read, even tho I'm disappointed it will be good to know if the solution works, let us know, when you have time😉 Cheers! G🦗H Quote Link to comment Share on other sites More sharing options...
nh905 Posted September 8, 2019 Author Share Posted September 8, 2019 I am starting to see more examples where SpamCop is not parsing lines similar to "Received: from localhost (127.0.0.1) by .7E3tTgaTrxrjG0@track.list-manage7.net id MgFLi65tFAWB". I can successfully resubmit the spam by manually removing the dot/period, but the new reporting mechanism requires that I paste the headers separate from the body text. How do we get this issue escalated to someone at SpamCop.net who can get the parser updated? Thanks, Norbert Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.