Mailhost configuration problem, identified internal IP as source

[deviantchild]

I just want to add a non-technical update regarding this issue and how it relates to me:-

After initially receiving a lot of spam through a mailhost which was not secure and, as a result, users used to get mail-bombed with spam at the rate you see some blog commenting reduced to (which is what prompted my signing up to the SpamCop service) with that host now defunct I've never suffered a lot through my other hosts once I'd begun reporting the occasional spam.

For a long time I've had next to no spam reaching the mailboxes of my current hosts, with only the occasional legitimate mail getting accidentally relegated to trash/junk folders at their end.

Recently I've experienced a resurgence in spam but nothing like I assume careless web form-fillers find themselves with.

While I only receive one spam in my mail client inbox around every five days, I will state that, of a month's expectance of an average of six spam mails, only one of those six will be able to be parsed by SpamCop correctly.

Add to this that it would have been likely that I would have still received that one parsable spam mail regardless of the new crop and the fact that, of the new crop, 100% seem to exhibit these non-parsable characters I would suspect foul play over an accident.

I'm not complaining.

From my explanation, you can see I now get next to no spam mail compared to many others - and that started to take effect as soon as I began forwarding and reporting with SpamCop [thanks :-) ] - yet, this post is simply to encourage to perhaps not treat this as an accident related to a "badly coded mass-mailer" as previously suggested.

Wow!

That was a large post about nothing-much-at-all.

Oh well.

"Cheers", anyway.

Bye for now.

[Farelf]

...

While I only receive one spam in my mail client inbox around every five days, I will state that, of a month's expectance of an average of six spam mails, only one of those six will be able to be parsed by SpamCop correctly.

Add to this that it would have been likely that I would have still received that one parsable spam mail regardless of the new crop and the fact that, of the new crop, 100% seem to exhibit these non-parsable characters I would suspect foul play over an accident.

...

Thanks deviantchild. Yes, have to admit that is a reasonable supposition based on what you are experiencing. These things come and go and if "they" are so specialised then history (as also in biology) shows they are more likely to "go" sooner rather than later. Given your spam mix it seems quite feasible for you to remove the offending character before submission (since such an edit has apparently been given the green light). It may not be so feasible for other reporters. CESmail have asked for samples (without the edit), just to reiterate for other readers coming in late - http://forum.spamcop.net/forums/index.php?...p;f=4&id=49

[deviantchild]

An update:-

The original "goofy" character mails ceased after I manually edited them out in order to parse and submit reports.

Unfortunately, I have now begun to receive new mails which won't parse, yet I cannot see the corruption in these.

One of them was a fake PayPal phishing mail which really needs to be reported before they dupe too many victims.

[MyNameHere]

An update:-

The original "goofy" character mails ceased after I manually edited them out in order to parse and submit reports.

Unfortunately, I have now begun to receive new mails which won't parse, yet I cannot see the corruption in these.

One of them was a fake PayPal phishing mail which really needs to be reported before they dupe too many victims.

I guess you could contact CESmail support as before with these new ones. Thinking about it, I really think Cisco would be the people who need to see this, though.

[Farelf]

An update:-

The original "goofy" character mails ceased after I manually edited them out in order to parse and submit reports.

Unfortunately, I have now begun to receive new mails which won't parse, yet I cannot see the corruption in these.

One of them was a fake PayPal phishing mail which really needs to be reported before they dupe too many victims.

It has to be in there somewhere. Even a blank (hex20) in the wrong place will cause that error (per this topic title), as shown by this failed parse for headers I dummied:

http://www.spamcop.net/sc?id=z5893545859zb...c73516257b050bz

Can you see that problem extra blank in that one? Would love to see the tracking URL for one of your problem parses (you can copy the URL before dismissing the parse, otherwise it is not retrievable in cases where the parse has failed with no offer to report). If you want more eyes on these new ones ... you just have to post the detail.

The forum software 'helpfully' removes leading blanks when you post here, one of the reasons tracking URLs are preferred. But I suspect the 'corruption' is no longer in the leading character, it may be as in my example above. In which case even just posting the headers here (with personal identification munged) would be sufficient for the purpose.

But obviously if there are low-life losers actually reading these pages as a free tutorial on how to fox SC that might not be a good idea ... I don't believe that is the case (there are far more productive spamming business models for those that might be bothered by SC than to write tailored forgeries) but that's just my guess - and we are allowing at least the possibility of hypothetical losers when losers, by definition, are nowhere near being optimal performers.

[MyNameHere]

But obviously if there are low-life losers actually reading these pages as a free tutorial on how to fox SC that might not be a good idea ... I don't believe that is the case (there are far more productive spamming business models for those that might be bothered by SC than to write tailored forgeries) but that's just my guess - and we are allowing at least the possibility of hypothetical losers when losers, by definition, are nowhere near being optimal performers.

I suppose instead of posting to this forum and trying to solve it ourselves, we could just inform the powers that be (see this announcement).

I still think the problem is with the SpamCop parser--that the CESmail service is probably not messing up the headers, so maybe ask CESmail to forward the non-parsing emails directly to Cisco/SpamCop.

[deviantchild]

I suppose instead of posting to this forum and trying to solve it ourselves, we could just inform the powers that be (see this announcement).

I still think the problem is with the SpamCop parser--that the CESmail service is probably not messing up the headers, so maybe ask CESmail to forward the non-parsing emails directly to Cisco/SpamCop.

Thanks.

I'll wait for another to fall over before submitting as per "this announcement".