Jump to content

Mailhost configuration problem, identified internal IP as source


deviantchild

Recommended Posts

Mailhost configuration problem, identified internal IP as source

Mailhost:

Please correct this situation - register every email address where you receive spam

No source IP address found, cannot proceed.

Hi, all.

Recently I've begun to receive spam again after many years of being relatively spam free.

I'm receiving a spam to one of my mail accounts every one or two days, which is more than I'm happy with.

Normally I may get one spam in a blue moon and reporting it via SpamCop nips it in the bud and I receive no more.

Though recently I haven't been able to report any and the same type of spam continues as stated above.

Can anyone explain why SpamCop reports there is no IP, or states that the spam comes from my own self?

I haven't touched the settings of SpamCop for the longest time, not since I initially set up an account a long while ago.

Does anyone have any suggestions? It seems as though, until I can sort this, I will continue to receive this same type of spam every day or so.

Please bear in mind that I know nothing of the internal workings of mail systems (I'm just a regular guy who despises commercial impositions) so, with any advice, could you guide me through steps and terminologies used?

I am very computer savvy (computers themselves) just not familiar with the workings of specific softwares and protocols such as mail.

Thanks in advance.

Link to comment
Share on other sites

Hi, deviantchild,

...If I understand correctly, Don does not look at PMs, so e-mail to the address listed in his "sig" is probably the best way to go.

...Although it will probably result in a lot of hits, not all of which will be relevant, you may wish to do a search (there's a search text box near the top of each SpamCop Forum page between a white button labeled "Search for -->" and a blue button labeled "GO") for the text "No source IP address found, cannot proceed" to see discussions of the message. From what you've described, it sounds as if the spam may have originated from another user of the same e-mail service you use. Don will no doubt be able to find the actual cause.

Link to comment
Share on other sites

Part of Dom's reply was this:-

This line in the headers with the goofy characters is the problem. You can delete the characters before reporting if you want.

Received: from

However, I couldn't find how the obfuscation was happening.

Here's what I wrote in a responding pm:-

While trying to find out how to delete the weird characters, I enabled header view in Thunderbird.

I couldn't see anything strange so clicked the button to forward the message, which seems to invoke an INLINE forwarding instead of the ATTACHMENT forwarding which is mandatory for correct SpamCop forwarding.

With an attachment forwarding I don't get the header rundown, as the message is contained separately, but with the inline forwarding I then see the full breakdown due to headers being viewable.

Here is what I get for the last spam I submitted to SpamCop:-

I'm not going to post the header here but I'll post one line which looked odd to me, though I know nothing about mail systems and protocols:-

Received-SPF: none (domain of sotcm.com does not designate permitted sender hosts)
Link to comment
Share on other sites

Delete the goofy characters?

Doesn't this violate the SpamCop policy of never altering the spam messages?

By the way, I just got one with the same problem and the same kind of goofy characters, and SpamCop gave me the same rejection message. Based on this thread, I deleted the offending characters and was able to report it successfully.

This looks like a SpamCop parser problem. I hope it can be fixed, or every spammer out there will just add these goofy characters and defeat the reporting process.

:(

Link to comment
Share on other sites

The only way I can edit these spam mails is to save them externally from Thunderbird and open them with a text editor, before correction, saving and reopening the file with Thunderbird again.

This obfuscation is deliberate.

When opened in a simple text editor, one will find that those characters display the same text "Received: From" in a smaller font than the rest of the text.

One has to backspace a couple more times to remove the invisible page markup command, before entering it again in correctly formatted text, the same as the rest of the file.

As MyNameHere suggests, although this is evidently intentional obfuscation on behalf of spammers, surely editing files in this manner brings genuine submittal into question.

Link to comment
Share on other sites

The only way I can edit these spam mails is to save them externally from Thunderbird and open them with a text editor, before correction, saving and reopening the file with Thunderbird again.

This obfuscation is deliberate.

When opened in a simple text editor, one will find that those characters display the same text "Received: From" in a smaller font than the rest of the text.

One has to backspace a couple more times to remove the invisible page markup command, before entering it again in correctly formatted text, the same as the rest of the file.

As MyNameHere suggests, although this is evidently intentional obfuscation on behalf of spammers, surely editing files in this manner brings genuine submittal into question.

ThuderBird email should show headers by

"Ctrl & U"

Together a pop-up appears accuratly showing body and text

Link to comment
Share on other sites

Another way is to click on the "View full message" link on the SpamCop parser report, then copy everything below the hash marks, edit it somewhere, then paste it back into the reporting box.

Assuming this is okay with the powers that be.

:blink:

Essentially, that is what I was doing.

ThuderBird email should show headers by

"Ctrl & U"

Together a pop-up appears accuratly showing body and text

Yeah, that's simply the shortcut key. The mail still needs to be saved elsewhere in order to be edited as a text file.

Link to comment
Share on other sites

<side note begins>

Hmmmm..... the copy of Thunderbird I use has options for both "Forward" and "Forward as"

<side note ends>

So does mine. I don't see the relevance. If you read the whole thread you'll notice I only mentioned that in respect of viewing headers. This is not any related issue, though I know some fall foul of errors because they attempted to submit inline attachments to SpamCop.

Link to comment
Share on other sites

  • 1 month later...

Another way is to click on the "View full message" link on the SpamCop parser report, then copy everything below the hash marks, edit it somewhere, then paste it back into the reporting box.

Assuming this is okay with the powers that be.

:blink:

I received another of these the day before yesterday, but only picked it up yesterday, so missed my time slot when it bounced and can now no longer report it.

Next time, I'll try to be quicker doing what MyNameHere suggests above.

The issue was the same; the following obfuscated line:

Received: from

Might they alter the code of the parser, or could there be many opportunities for obfuscations such as this, turning it into a coding game of cat and mouse every time the method is altered by the bad guys?

Link to comment
Share on other sites

I received another of these the day before yesterday, but only picked it up yesterday, so missed my time slot when it bounced and can now no longer report it.

Next time, I'll try to be quicker doing what MyNameHere suggests above.

The issue was the same; the following obfuscated line:

Received: from

Might they alter the code of the parser, or could there be many opportunities for obfuscations such as this, turning it into a coding game of cat and mouse every time the method is altered by the bad guys?

Yup!

Just now received another like this, and this time I resubmitted quickly with the necessary manual edit and got the scumbags.

Link to comment
Share on other sites

Well done deviantchild. The parser always has had problems with mangled header declarations, once it could be put off even with very slightly mangled X-headers, as this "subtle" one showed:

http://forum.spamcop.net/forums/index.php?...post&p=2665

THAT experience showed it to be a passing peculiarity, in retrospect probably more a case of a defective mass-mailer sсript than anything deliberate on the part of the spammer (the usual "business model" has no time for subtlety, it's all about delivery volume with reduced reliance on individual source IP addresses thanks to botnets). In any event, it soon stopped, hopefully your problem spam will do the same.

Link to comment
Share on other sites

Glad you bumped this topic, as now I see it's probably the same problem seen in:

unicode sequence knocks out spamcop processing

http://forum.spamcop.net/forums/index.php?showtopic=13918

and in:

Just reported my own server!

http://forum.spamcop.net/forums/index.php?showtopic=13946

Connecting the dots. The parser's inability to deal with those characters caused me to report my own server, which had never had a report before.

Also, I'm a little surprised at the nonchalant suggestion from Don that it's OK to edit the headers before reporting, haven been slapped down here before when suggesting such a controversial procedure. Hmmm....

DT

Link to comment
Share on other sites

Also, I'm a little surprised at the nonchalant suggestion from Don that it's OK to edit the headers before reporting, haven been slapped down here before when suggesting such a controversial procedure. Hmmm....

Well, I guess there was enough skepticism expressed, so when no lightning bolts came from on high, some of us continued to do the minor surgery of removing the odd characters. It isn't anything like changing or inserting an IP address.

But I agree with your sentiment in another thread:

Unfortunately, that doesn't really solve the problem for those of us who pay for CESMail SpamCop email accounts and prefer to use the "Report as spam" links in the webmail system. That's a perk that we're paying for, and it's now dangerously broken.

and similar sentiments the third thread on this issue.

Point is, however, that CESMail is not strictly part of SpamCop, so we're paying CES for something, and SpamCop is messing it up. I suggest we ask CES to beat on Cisco's door and ask for something to be done. Otherwise, we will inevitably end up reporting ourselves from time to time. Not good.

I just sent this message via the Problem feature of the CES/SpamCop mail service:

Please review this thread and other threads mentioned therein:

http://forum.spamcop.net/forums/index.php?showtopic=13831

The bottom line is, there are some spam messages that are configured so that when reported through Quick Reporting, the parser incorrectly reports the spam to our own hosting services.

Cisco/SpamCop does not appear to think this is a problem, but it does render this nifty (_paid_) feature of the CES/SpamCop service unusable, unless we like being reported as spammers.

So I would like you (CES) to add your voice to ours in asking SpamCop to do something about this problem.

Thanks!

Link to comment
Share on other sites

<snip>

Also, I'm a little surprised at the nonchalant suggestion from Don that it's OK to edit the headers before reporting, haven been slapped down here before when suggesting such a controversial procedure.

<snip>

...Presuming you meant Don's post in Just reported my own server!:
>- Received: from 192.168.0.53 ([192.168.0.53])

The problem is caused by the odd characters in that "Received" line. I don't know why.

If you remove them, the spam will process properly.

- Don D'Minion - SpamCop Admin -

- Service[at]Admin.SpamCop.net -

I suppose it's ambiguous enough that it could be interpreted as a "nonchalant suggestion ... that it's OK to edit the headers before reporting" but my guess would be that it's either a carefully considered (and explicitly granted) exception to the ban against "Material changes to spam" (more about which may be found in a SpamCop FAQ article with that label -- DT, that reference for others; I know you don't need it :) <g>) or a suggestion to facilitate manual reporting, the parse results for which should be canceled rather than used to complete the reporting process through SpamCop.
<snip>

I just sent this message via the Problem feature of the CES/SpamCop mail service:

...A similar note sent to the SpamCop Deputies at deputies[at]admin.spamcop.net would probably be appropriate, as well.
Link to comment
Share on other sites

CESmail support would like examples of the spam messages with "goofy characters" causing SpamCop to parse them incorrectly.

They asked that we create a separate webmail folder, put the offending spam messages in it, then email support with the SpamCop account name (I suppose that means the email address) and the folder name and explain what the problem is, and they will look at it.

Please send an email directly to SpamCop Support (support-cases at spamcop.net> and use "Re: (Case 55538) [Problem Report] SpamCop parser affecting Quick Reporting" as the subject line.

Thanks!

Link to comment
Share on other sites

Cisco/SpamCop sent me a reply saying that they are aware of the problem and working on it. They would like to figure out how the characters are getting into the headers in the first place and prevent that, but their engineers are trying to get the parser to handle them anyway.

CESmail (SpamCop webmail) indicated that they will be looking at any examples we send to be sure the characters are not coming from the CES servers.

Link to comment
Share on other sites

Thanks again. Let's continue with just this one topic for the funky headers causing problems. Nobody seems to really have a handle on the mechanism of this fault yet, but as I pointed out earlier (in this topic) there have been header issues affecting the parser going back to at least 2004 - though admittedly not with the dire consequences lately noted. Locking the three other topics for the moment with link to this one (previous post).

Steve

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...