Mailhosts problem

[dbiel 0]

First I would munge your personal info as indicated below for security/privacy reasons.

Here is a full cut and paste of the headers sent to a friend.

Return-Path: <xxxxxxxx[at]Imagineering-Online.com>

Received: from mxsf14.cluster1.charter.net ([10.20.201.214])

          by mtao03.charter.net

          (InterMail vM.6.01.03.03 201-2131-111-105-20040624) with ESMTP

          id <20041126182103.KZPZ4925.mtao03.charter.net[at]mxsf14.cluster1.charter.net>

          for <drcatchka[at]charter.net>; Fri, 26 Nov 2004 13:21:03 -0500

Received: from mxip06.cluster1.charter.net (mxip06a.cluster1.charter.net [209.225.28.136])

            by mxsf14.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id iAQIKkaV026328

            for <xxxxxxxx[at]charter.net>; Fri, 26 Nov 2004 13:21:02 -0500

Received: from imagineering-online.com (HELO IMAGINEERING-1.Imagineering) (67.52.0.101)

  by mxip06.cluster1.charter.net with ESMTP; 26 Nov 2004 13:20:49 -0500

X-Ironport-AV: i="3.87,112,1099285200";

d="scan'217,208"; a="448877149:sNHT18105068"

Content-class: urn:content-classes:message

MIME-Version: 1.0

Content-Type: multipart/alternative;

            boundary="----_=_NextPart_001_01C4D3E4.A703E8E5"

Subject: Testing

Date: Fri, 26 Nov 2004 12:20:46 -0600

X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0

Message-ID: <0659149ACA1AAE4F8C66D6E60A40D4520494FC[at]imagineering-1.Imagineering>

X-MS-Has-Attach:

X-MS-TNEF-Correlator:

Thread-Topic: Testing

thread-index: AcTT5KYoJ+1XuinZT22xmtfvFRxt3g==

From: "xxxxxx" <xxxxxxx[at]Imagineering-Online.com>

To: "xxxxxx" <xxxxxxx[at]charter.net>

I would profer the suggestion that this is a very common setup, used by many (100's) of our customers.  If this would make Spamcop unusable to them, you are taking away a very important spam management tool, and hope you will reconsider.

20596[/snapback]

Thanks for posting this as it help to understand what domain you are actually using to receive mail.

Imagineering-Online.com is the domain name that you use to receive mail from the outside world.

SpamCop and the parser are not actually having a problem with your non qualified internal domain, but is having a major problem with the fact that your mail server fails to append the necessary received lines.

You have an incoming mail server for "Imagineering-Online.com" that is being identifed to the outside world as

Received: from firewall.Imagineering ([67.10.47.249]) by IMAGINEERING-1.Imagineering with Microsoft SMTPSVC(6.0.3790.211);
  Mon, 1 Nov 2004 21:07:07 -0600
Received: from cs671047-249.houston.rr.com ([67.10.47.249]) by firewall.Imagineering; Mon, 01 Nov 2004 21:07:02 -0600 (Central Standard Time)

When it receives mail from the outside world, it adds a received line correctly identifing the sender but fails to properly identify itself.

The next received line is creating the biggest problem Received: from firewall.Imagineering ([67.10.47.249]) By listing the original senders IP addresses rather than its own address it makes it impossible for the parser to find "firewall.Imagineering"

Remember that the parser reads the headers in reverse order and attempts to validate each address. It can deal with internal domains IF they are properly identified. But when then identify themselves using somebody elses IP address, it creates problems.

When checking your MX records the following was found:

Your 1 MX record is:
10 mail.imagineering-online.com. [TTL=3600] IP=67.52.0.101 [TTL=3600] [US]

Yet this mail server is not identified in the headers of your inbound messages.

It would appear that mail coming from the outside world goes to:

10 mail.imagineering-online.com. IP=67.52.0.101 but this is never revealed in the headers.

Please outline what is necessary to get the 'exception' discussed above please.

Contact "deputies <at> spamcop.net" but as long as your corporate mail server hides its true identity I doubt that they will be able to help.

[Ellen 0]

Again only SpamCop is having a problem with this...do you see a theme THERE?

20605[/snapback]

I thought I took care of this problem -- if not I need to see a tracking url.

[dbiel 0]

The following is a more detailed reply from Ellen

Your system is stamping a bad header -- it lists the IP of the connecting

server in the header where it gets the mail from the firewall instead of the

firewall IP. Nonetheless the parse is correct assuming that the spam was

received from a RoadRunner IP. Here is the tracking URL:

http://www.spamcop.net/sc?id=z688227457zdb...a138f1e4e4187fz

As I said, I fixed the problem several days ago by adding

IMAGINEERING-1.Imagineering to the mailhost even though that is not a fully

qualified domain name/expanded domain name.

The parser comment that there is a possible forgery and that the supposed

receiving system not associated with your mailhosts is due to the incorrect

header stamped by IMAGINEERING-1.Imagineering and the fact that the actual

injecting IP is in that header when it shouldn't be. However the parse

appears to be correct.

The forums display of the url, for some unknown reason, insists on using

"...." in the middle of it so you have to click it from within the forum to

get the parse page to come up.

Ellen

SpamCop

Please include all previous correspondence with replies

[Imagineering 0]

I thought I took care of this problem -- if not I need to see a tracking url.

20613[/snapback]

Here is one from today...

http://www.spamcop.net/sc?id=z703011027zf3...0a3655da34714ez

[Wazoo 0]

And yet, even after all the discussion, the exact same problem still remains;

Received: from firewall.Imagineering ([69.108.117.198]) by IMAGINEERING-1.Imagineering with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Dec 2004 16:39:10 -0600

Received: from adsl-69-108-117-198.dsl.irvnca.pacbell.net ([69.108.117.198]) by firewall.Imagineering; Wed, 15 Dec 2004 16:39:08 -0600 (Central Standard Time)

Looking at that set of lines, one of them is obviously using the wrong IP address to identify the server involved. I wonder which one it is this time? No, wait, I need wonder no more .. it's exactly as has been pointed out several times thus far ... lack of a FQDN associated with someone else's IP

[Ellen 0]

Here is one from today...

http://www.spamcop.net/sc?id=z703011027zf3...0a3655da34714ez

21446[/snapback]

What's wrong with the parse? Looks OK to me unless you are saying that you are:

adsl-69-108-117-198.dsl.irvnca.pacbell.net ([69.108.117.198])

[StevenUnderwood 0]

What's wrong with the parse?

I think he is complaining about the message in orange:

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

Will not trust anything beyond this header

[Ellen 0]

I think he is complaining about the message in orange:

21517[/snapback]

um OK

[dbiel 0]

After doing some more checking myself, I have found that Imagineering's problem is a bit more wide spread that it first appeared. I tried adding my own company email to my webhost file and found the same problem. Many companies have felt that there was no need to register all the internal servers handling incoming mail and felt that it was ok to alter the use of the received lines to meet internal requirements. This works perfectly fine until one tries to reverse trace an email from within the internal servers. One can always delete the internal headers and start from the point that the message left the internet and entered the intranet. But to do so is a violation of the SpamCop rules. SpamCop has been very accomodating in making "fixes" that work around the problem. But we have to remember that these "fixes" do NOT fix any problem with the SpamCop parser, they simply work around problems with incorrect headers added by the users company servers. Therefor we can not expect the parse to look normal and the "Possible forgery. Supposed receiving system not associated with any of your mailhosts" may appear in a strange place. Where it shows up is not important. The important thing to to check the parse as see if it is reporting the correct source of the message and not one our your internal servers.

Parsing header:

0: Received: from firewall.Imagineering ([69.108.117.198]) by IMAGINEERING-1.Imagineering with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Dec 2004 16:39:10 -0600

Hostname verified: adsl-69-108-117-198.dsl.irvnca.pacbell.net

mail.imagineering-online.com received mail from sending system 69.108.117.198

1: Received: from adsl-69-108-117-198.dsl.irvnca.pacbell.net ([69.108.117.198]) by firewall.Imagineering; Wed, 15 Dec 2004 16:39:08 -0600 (Central Standard Time)

Hostname verified: adsl-69-108-117-198.dsl.irvnca.pacbell.net

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

Will not trust anything beyond this header

Tracking message source: 69.108.117.198:

Take a look at the line I marked in red. This line would not appear in a normal parse but has been added here to deal with the problem of the "bad" IP in the received line #0 where firewall.Imagineering identifies itself with the IP address of the server that first entered the company primary mail server which is not listed at all in the headers.

Many thanks to Ellen and SpamCop for being willing to create "fixes" that allow corporate email users to use SpamCop when the Corporate mail servers refuse to follow standard internet protocol for writting headers internally!!!!!!!!

Note: this will be an ongoing problem as the Corporate mail servers are actually set up correctly for the standard sending and receiveing of email from the internet. They just fail to folow those same standards for their own interal servers for incomming mail only. They do use correct standards for their outgoing mail (refer to the previous post in this thread) and as such are technically in compliance with internet standards.

[Wazoo 0]

Although "reports are not being sent to my network administrator" .. I believe the FAQ entry at http://www.spamcop.net/fom-serve/cache/13.html pretty much states the story as far as use of the SpamCop parser. As I've noted before, what 'you' do within your nrtwork is your own business, but when playing with others, certain rules must be followed. Though Ellen "made a fix" that allows some details to be overlooked, even she's pointed out that the internal routing is non-standard .. again, from the SpamCop parser viewpoint.

And yet anothe FAQ, though the title doesn't match, the details of this specific issue are in fact addressed here also --> http://www.spamcop.net/fom-serve/cache/99.html