Possible forgery. Supposed receiving system not as

[Epoch]

I have just activated the new Mailhosts beta on my account. I have gone in and registered all the email addresses and mailhosts I currently have access to through SpamCop.

I have also been getting inundated within the last several weeks by bogus "Returned Mail" where a spammer has decided to try a little revenge by spoofing the "return-path" header using my current email address.

Before I activated the beta, I could strip out the spam in the bounce messages and file reports using the "Report spam" option. NOW when I try to report it after activating the beta mailhost system I get the following message:

Possible forgery. Supposed receiving system not associated with any of your mailhosts

It ceases to process the item at this point and WILL NOT allow me to report the spam. It also give me the same message when trying to forward to the link shown in the Report spam option.

Can I DEactivate the beta and continue filing these "bounce" spams? They have been going to the appropriate ISPs and mail hosts before all this began.

[StevenUnderwood]

Before I activated the beta, I could strip out the spam in the bounce messages and file reports using the "Report spam" option.

That is against spamcops rules and you could be jeopardizing your account by revealing that fact. That spam was sent to someone else, so you are not supposed to report it using spamcop. You can manually parse the original spam and use spamcop to determine where to send manual reports. You can also use spamcop to determine the source of the bounce and manually report to that ISP requesting they stop the practice of bouncing to forged addresses.

[Epoch]

That is against spamcops rules and you could be jeopardizing your account by revealing that fact.  That spam was sent to someone else, so you are not supposed to report it using spamcop.  You can manually parse the original spam and use spamcop to determine where to send manual reports.  You can also use spamcop to determine the source of the bounce and manually report to that ISP requesting they stop the practice of bouncing to forged addresses.

20242[/snapback]

I had been manually parsing the reports and double checking to make sure no reports were going against the IP that generated the bounce notice. I have been a user of Spamcop for many years and have kept up with their "do's" and "do not's" as far as making sure spam reports properly reflect the spammer and not innocent recipients, and go to the appropriate entities. Luckily nobody has reported MY email as the spammer so far (the address he is using for his "Return-path").

Surely I have a right to report a spammer fraudulently using MY email address as the source?

[Wazoo]

Not sure that you have been keeping up ... you may want to go through the FAQ again .. there have been many changes over time, and fairly recently, a number of them have been "touched" .... reporting of bounces was a major change ... now not allowed at all ...

[Epoch]

Not sure that you have been keeping up ... you may want to go through the FAQ again .. there have been many changes over time, and fairly recently, a number of them have been "touched" .... reporting of bounces was a major change ... now not allowed at all ...

20245[/snapback]

<sigh> Okay then. set filters to "dump bounce reports" and delete it is then.

Shame, that.

[turetzsr]

I had been manually parsing the reports and double checking to make sure no reports were going against the IP that generated the bounce notice.

20243[/snapback]

...Really? Seems to me that you would want to complain to the admin of the IP that generated the bounce to ask her/him to stop doing that to you and other innocent parties whose e-mail address is forged in the spammer's "From" or "Return" line. IMHO, it's very poor netiquette. The proper thing to do is to issue a 500-level SMTP reject.

<snip>

Surely I have a right to report a spammer fraudulently using MY email address as the source?

20243[/snapback]

...Absolutely! Just not using SpamCop's automated system to generate and send complaints (SpamCop FAQ: On what type of email should I (not) use SpamCop?). You can use the SpamCop parser to get an idea of who to send them to, yourself.

[Epoch]

...Really?  Seems to me that you would want to complain to the admin of the IP that generated the bounce to ask her/him to stop doing that to you and other innocent parties whose e-mail address is forged in the spammer's "From" or "Return" line.  IMHO, it's very poor netiquette.  The proper thing to do is to issue a 500-level SMTP reject.

...Absolutely!  Just not using SpamCop's automated system to generate and send complaints (SpamCop FAQ: On what type of email should I (not) use SpamCop?).  You can use the SpamCop parser to get an idea of who to send them to, yourself.

20250[/snapback]

Undrerstood. I just wish there was a way to manually report the massive amounts of forgeries as quickly and efficiently as would be possible using Spamcop.

I would be willing to pay a bit extra if there was an option that would be able to generate a report that would only report me as the reporter with no mention of the Spamcop system. I am just sick and tired of the spammers having the upper hand in all this. <Insert flaming anti-spammer comments here>

[turetzsr]

Undrerstood. I just wish there was a way to manually report the massive amounts of forgeries as quickly and efficiently as would be possible using Spamcop.

I would be willing to pay a bit extra if there was an option that would be able to generate a report that would only report me as the reporter with no mention of the Spamcop system. I am just sick and tired of the spammers having the upper hand in all this.  <Insert flaming anti-spammer comments here>

20256[/snapback]

...You could always write your own and become as rich and famous as Julian.... <big g>

[Epoch]

...You could always write your own and become as rich and famous as Julian....  <big g>

20257[/snapback]

"Dammit Jim! I'm a network doctor, not a coder!"

Ok... that kills this thread.

[StevenUnderwood]

Ok... that kills this thread.

This is not NNTP so those rules do not apply

[jevans]

Ok... that kills this thread. 

20279[/snapback]

Well not for me, sorry.

I've registered our catch-all account, "nobody <at> dreampower-arf.com" because we get tons of spam to spoofed or obsolete email accounts.

When I try to report spam to an old account like "fosters <at> dreampower" I get the typical ""Possible forgery" message. an example is

http://www.spamcop.net/sc?id=z696989154z75...ab68c3e081fcb6z

It appears that, in this example, the alias "Foreverfriends" was delivered to the account "nobody" via 218.17.238.161. Since I'm a mere programmer, and not the administrator at my Host, Cybercon, please have patience when you explain to me what I need to do here.

Merci!

Jim Evans

dreampower-arf.com

[jevans]

another example:

http://www.spamcop.net/sc?id=z697820008zd1...330256baf4492ez

[StevenUnderwood]

Well the first one is too old to report right now. THe second was still active but I cancelled it so it would not be reported improperly.

Both of these messages have the received line similiar to:

1: Received: from unknown (HELO COMMONOR-180247) (218.17.238.161) by 0 with SMTP;

1: Received: from 229-3-112.adsl.terra.cl (200.112.3.229) by 0 with SMTP;

Do all of your messages have this "by 0 with SMTP;" line in the headers? If so, then something in your mail route is not announcing itself properly and that needs to be fixed.

If not, then these spam are trying to fool parsers with a fake line and it should be reported as it is. That message is just a warning to look closer at the results.

[Ellen]

another example:

http://www.spamcop.net/sc?id=z697820008zd1...330256baf4492ez

20727[/snapback]

The parses look OK to me -- admittedly the headers stamped by your ISP are a bit odd but the parser seems to find the injection.

[jevans]

The parses look OK to me -- admittedly the headers stamped by your ISP are a bit odd but the parser seems to find the injection.

20755[/snapback]

Ellen, from all previous posts, you seem to be a brilliant person.

Since I am not, I give up. here is another example:

http://www.spamcop.net/sc?id=z698302837z2a...be7c0d61261140z

Steve Underwood was right that all of these rejects include the line "received by xxxx() by 0 with SMTP;"

I'll just delete my mailhosts and return to the old school. When this BS is required, I will probably just fade into the background (again!)

thanks all, and best regards

Jim

[StevenUnderwood]

You don't have to delete your mailhost configuration. I also agree that it appears to be correctly finding the source. Some spammers place bogus received lines trying to confuse reporters. SPamcop is NOT fooled.

What you did not answer is whether ALL your messages (not just the spam) have the received line including "by 0 with SMTP;". If so, then something in your configuration is not correct and we could work on that with you.

My guess is that is is simply one spammer sending all of these (probably with the same software inserting the bogus line) and that your normal email does not include the bogus header.

In the last example, you should simply look closer at that line. If your ISP is NOT ameritech.net, then everything is fine. If it is, the parser may have messed up, particularly if that address is YOUR IP address.

[jevans]

What you did not answer is whether ALL your messages (not just the spam) have the received line including "by 0 with SMTP;".  If so, then something in your configuration is not correct and we could work on that with you.

Oh, oops, thanks Steve. I misunderstood the question. Yes, all messages appear to have "received...by 0". Below are headers from a message directly to my personal account (you can see received from mx.aol by 0)

(When the parser stops at that line, doesn't it miss the header that has the originating spammer?)

PS: My ISP is Cybercon (bestnet.net). I assume I will need to direct them to modify their config?

Here are the headers:

Return-Path: <Linda[snip]aol.com>

Delivered-To: udreampower-arf.com-jevans[snip]dreampower-arf.com

Received: (qmail 11707 invoked by uid 2458); 2 Dec 2004 01:18:48 -0000

Received: from 205.188.157.38 by mail4.cybercon.com

(envelope-from <Linda[snip]aol.com>, uid 504) with qmail-scanner-1.23

(f-prot: 4.4.0/3.14.10. Clear:RC:0(205.188.157.38):. Processed in

0.320279 secs); 02 Dec 2004 01:18:48 -0000

Received: from imo-d06.mx.aol.com (205.188.157.38) by 0 with SMTP; 2 Dec 2004

01:18:47 -0000

Received: from Linda[snip]aol.com by imo-d06.mx.aol.com

(mail_out_v37_r3.8.) id s.7e.5deffce0 (3699) for

<jevans[snip]dreampower-arf.com>; Wed, 1 Dec 2004 20:18:43 -0500 (EST)

From: Linda[snip]aol.com

Message-ID: <7e.5deffce0.2edfc773[at]aol.com>

Date: Wed, 1 Dec 2004 20:18:43 EST

Subject: Re: Photos

To: jevans[snip]dreampower-arf.com

[snip]

[StevenUnderwood]

(When the parser stops at that line, doesn't it miss the header that has the originating spammer?)

No. The parser is saying the receiving server "0" is not in your mailhosts configuration (which it probably is not). However, you'll notice that cybercon has already entered the same receiving address in the first header they append so that address is already found. In your example 205.188.157.38.

Received: from 205.188.157.38 by mail4.cybercon.com

Received: from imo-d06.mx.aol.com (205.188.157.38) by 0 with SMTP;

The way it reads now, mail4 received the message from the source then server "0" received the message from the source, but the source had already handed it off so this does not make sense.

My ISP is Cybercon (bestnet.net). I assume I will need to direct them to modify their config?

Yes I would ask them where that second unneccessary header is coming from.

Best of luck and keep us posted.

[Ellen]

Ellen, from all previous posts, you seem to be a brilliant person.

Since I am not, I give up.  here is another example:

http://www.spamcop.net/sc?id=z698302837z2a...be7c0d61261140z

Steve Underwood was right that all of these rejects include the line "received by xxxx() by 0 with SMTP;"

I'll just delete my mailhosts and return to the old school.  When this BS is required, I will probably just fade into the background (again!)

thanks all, and best regards

Jim

20792[/snapback]

Thanks for the complement but not hardly :-)

Looking at the parse:

1) Received: from 68.74.181.25 by mail7.cybercon.com

that is your ISP/host getting the mail from 68.74.181.25. What is 68.74.181.25?

host 68.74.181.25 (getting name) = adsl-68-74-181-25.dsl.emhril.ameritech.net. So it;s a dsl line -- maybe a compromised machine with a virus/worm running an SMTP server or maybe a proxy or maybe a real SMTP server, no way to know. But the likelihood is compromised machine *unless* this is a server at your office or a server run by some buddy of yours that forwards mail to your cybercon account.

We can trust this received header because we trust your ISP

2) Received: from adsl-68-74-181-25.dsl.emhril.ameritech.net (68.74.181.25) by 0 with SMTP; 1 Dec 2004 20:25:02 -0000

This header is somewhat borked -- we already know that cybercon got the mail from 68.74.181.25. This header says some unknown server got it from the same place. This is probably some server at cybercon stamping another header -- nowadays with the number of virus/spam servers inserted into networks there are some strange mail pathways and headers being stamped. The 'by 0" looks like its a qmail header as it is real common for people to forget to tell qmail the FQDN of the server and to let it stamp by 0 instead. In any case it doesn't change where the cybercon server got the mail from.

3) Return-Path: "Arline Honeycutt" <jksebvtwoog[at]hotmail.com>

Received: from 221.41.124.41 (EHLO asmtp-a063f31.pas.sa.earthlink.net) (128.104.36.140) by mta126.mail.sc5.yahoo.com with SMTP; Sat, 27 Nov 2004 03:17:50 -0700

Received: from cs2428108-152.houston.rr.com ([128.144.68.136]) by asmtp-a063f31.pas.sa.earthlink.net with asmtp (Exim 4.34) id 1CHgCb-0006ma-P5; Sat, 27 Nov 2004 03:17:50 -0700

Received: by 168.154.140.82 with HTTP; Sat, 27 Nov 2004 06:36:10 -0700 (PDT)

Assuming you don't have an account on a dsl line belonging to ameritech forwarding to you (see #1 above) then this is all forged. And if you do then the #2 header above is real borked because it should show that it received the mail from yahoo. In any case not having fallen off the turnip truck recently I have a problem believing that yahoo got mail from an earthlink server who got it from an rr server who somehow sucked it up from some random IP in Korea. Surprised they didn't tuck an AOL server in there also :-)

So the parser is correct in what it finds unless you tell me you have some account on a dsl line forwarding to your cybercon account.

I don't see any reason to delete your mailhosts as it looks to me like the parser is finding the correct injection unless you have a forwarding account in which case you need to add it to mailhosts ... spammers like to throw in random forged headers.

[deathtospam]

Ellen,

Why am I getting the following? I have definitely registered all my mailhosts.

SpamCop v 1.404 © Ironport Systems Inc., 1998-2005 , All rights reserved.

Here is your TRACKING URL - it may be saved for future reference:

http://www.spamcop.net/sc?id=z724793383z79...83c3ae8ecfb997z

Skip to Reports

Return-Path: <Steven.Dillon[at]hurting.com>

Received: from fed1rmgxi04.cox.net ([220.86.106.38])

by fed1rmmtai14.cox.net

(InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP

id <20050124233958.BETG15125.fed1rmmtai14.cox.net[at]fed1rmgxi04.cox.net>;

Mon, 24 Jan 2005 18:39:58 -0500

Received: from [68.6.19.3] (really [220.86.106.38]) by fed1rmgxi04.cox.net

(InterMail vG.1.00.00.00 201-2136-104-20040331) with SMTP

id <20050124233956.DBRV18792.fed1rmgxi04.cox.net[at][68.6.19.3]>;

Mon, 24 Jan 2005 18:39:56 -0500

Received: from WQEWI-ES14 (220.86.106.38) by 220.86.106.38; Mon, 24 Jan 2005 18:40:36 -0500

From: "Mickey Bassett" <Steven.Dillon[at]hurting.com>

To: x

Cc: x, x, x, x, x, x, x, x, x, x, x

Subject: Account # 233177X

Date: Mon, 24 Jan 2005 18:40:36 -0500

MIME-Version: 1.0

Content-Type: multipart/alternative;

boundary="Java.OYMCL.114331835087896579"

X-Priority: 3

X-MSMail-Priority: Normal

Message-Id: <9[6

Message-Id: <20050124233956.DBRV18792.fed1rmgxi04.cox.net[at][68.6.19.3]>

View entire message

Parsing header:

0: Received: from fed1rmgxi04.cox.net ([220.86.106.38]) by fed1rmmtai14.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050124233958.BETG15125.fed1rmmtai14.cox.net[at]fed1rmgxi04.cox.net>; Mon, 24 Jan 2005 18:39:58 -0500

No unique hostname found for source: 220.86.106.38

Cox received mail from sending system 220.86.106.38

1: Received: from [68.6.19.3] (really [220.86.106.38]) by fed1rmgxi04.cox.net (InterMail vG.1.00.00.00 201-2136-104-20040331) with SMTP id <20050124233956.DBRV18792.fed1rmgxi04.cox.net[at][68.6.19.3]>; Mon, 24 Jan 2005 18:39:56 -0500

No unique hostname found for source: 220.86.106.38

Possible forgery. Supposed receiving system not associated with any of your mailhosts

Will not trust anything beyond this header

Tracking message source: 220.86.106.38:

Routing details for 220.86.106.38

[refresh/show] Cached whois for 220.86.106.38 : gman[at]kt.co.kr ip[at]ns.kornet.net abuse[at]kornet.net

Using best contacts abuse[at]kornet.net

Yum, this spam is fresh!

Message is 2 hours old

220.86.106.38 not listed in dnsbl.njabl.org

220.86.106.38 not listed in dnsbl.njabl.org

220.86.106.38 not listed in cbl.abuseat.org

220.86.106.38 not listed in dnsbl.sorbs.net

220.86.106.38 not listed in relays.ordb.org.

220.86.106.38 not listed in query.bondedsender.org

220.86.106.38 not listed in iadb.isipp.com

No body provided, check format of submission

[StevenUnderwood]

Unless kornet is part of your configured mail path there is nothing wrong with that parse...

0: Cox received mail from sending system 220.86.106.38

1: You will notice this line says it received the message from the same source as above, which is not physically possible. This line is probably forged by the spammer or an incorrectly configured server at your ISP (Cox).

[Wazoo]

Not sure what you might need specifically from Ellen either, concurring with Steven's comments. What exactly was your "problem" with the parse (hoping that you aren't reacting to the fact that you only submitted a set of headers, no body .. also keying on the two Message-ID: lines, the first one looking like the broken crap usually identified in the complaints from folks about receiving "blank" spams ..???)

[Ellen]

The comments added by the parser are slightly opaque ... that comment about supposed system not associated -- refers to IP 220.86.106.38 which issued a bogus helo as the cox mailserver. The comment is meant as an alert in case you hadn't defined all your mailhosts but other than that it doesn't mean you have a problem. And, indeed, that IP is the source of the spam and the parser targets it correctly. The next received header is forged or some silly way that cox stamps received headers.

In any case, the parser found the correct injection point. It's almost miraculous how it manages to trudge thru slightly bizarre headers ....