Report Ends With "Parsing Header:"

[MIG]

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

[nh905]

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

[MIG]

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

[nh905]

@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

[MIG]

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

[gnarlymarley]

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.

[Jelmer Jellema]

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

[MIG]

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

[gnarlymarley]

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.

[gnarlymarley]

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...

[MIG]

13 hours ago, gnarlymarley said:

it would be nice if the parser was fixed...

G🦗H furiously nodding head in agreement!

 

 

[Jelmer Jellema]

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

[Jelmer Jellema]

On 6/20/2019 at 1:41 PM, MIG said:

never fear Jelmer, you're never alone!

That's such a warm feeling!

[Tesseract]

Meanwhile, nearly all the spam that makes it into my inbox is now of this variety.

[MIG]

On 6/25/2019 at 11:07 PM, Jelmer Jellema said:

That's such a warm feeling!

🤗

[MIG]

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

[MIG]

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

 

 

[Tesseract]

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

[MIG]

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

[RobiBue]

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...

[gnarlymarley]

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

[Jelmer Jellema]

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

[RobiBue]

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)

[MIG]

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 

[nh905]

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