Jump to content

Mailhosts problem


Recommended Posts

We are using spamcop for the reporting of our spam.

We have a Checkpoint firewall, and an exchange server behind it (not uncommon by any means).

We have the firewall set to preserve the sender information when examining any of the incoming mail, which has worked just fine for spamcop reporting prior to this mailhosts system. We recently signed on for the mailhost program, and have always gotten the message that the "...host was not found, and that it will not trust anything in the header beyond this point..."

It then reports the firewall.domainname (ip address). The problem is that the IP address is not one of ours. I can only assume that it is the sender's IP, but why is it being associated with our host then? To be truthful, I am not seeing any benefit in the new system. We wanted to get a head start on this since it has been stated that you intend to make this a requirement, but it hasn't worked. We have added all of the hosts, but continue to have these issues. Further, we are unclear as to the impact that this is having on the actual reporting of the spam.

Is there any wy to get off the mailhost system?

Link to comment
Share on other sites

signed on for the mailhost program

????? There is no "signing on" ... the MailHost thing is a configuration of your data points referencing the flow of your incoming e-mail.

have always gotten the message that the "...host was not found, and that it will not trust anything in the header beyond this point...

indicates that you have been reporting spam prior to completing and verifying that the MailHost configuration has been completed and is "good"

We have the firewall .... It then reports the firewall.domainname (ip address). The problem is that the IP address is not one of ours.

Logically speaking, this makes no sense at all. And without a sample of what you are trying to describe (please use the Tracking URL provided) there isn't any way to even guess at what you are trying to say here ...

We have added all of the hosts, but continue to have these issues

but did you do it in sequence? Again, with no data to go on, it's all a guessing game from this end.

we are unclear as to the impact that this is having on the actual reporting of the spam

How can you be unclear as to the results? You are clearly stating that reporting for you is not working now. Or are you suggesting that you are still hitting the "Send Reports Now" buttons even though the results are wrong?

Is there any wy to get off the mailhost system?

Delete your MailHosts is the standard answer, but .... sorting out what went wrong would be the wiser path to take.

Link to comment
Share on other sites

Not quite sure how your configuration works but does your system add a received header to the spams showing it receiving the mail? Send me a couple of tracking urls from parses and your registered SC email address and I will look at what is happening.

Link to comment
Share on other sites

  • 2 weeks later...

If I have been in any way unclear, I apologize. Here is an example posting.

SpamCop v 1.383 © SpamCop.net, Inc. 1998-2004 All Rights Reserved

spam Header

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

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

0: 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

Hostname verified: cs671047-249.houston.rr.com

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

1: 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)

Hostname verified: cs671047-249.houston.rr.com

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

Will not trust anything beyond this header

Tracking message source: 67.10.47.249:

Routing details for 67.10.47.249

[refresh/show] Cached whois for 67.10.47.249 : abuse[at]rr.com

Using abuse net on abuse[at]rr.com

abuse net rr.com = abuse[at]rr.com

Using best contacts abuse[at]rr.com

Sorry, this email is too old to file a spam report. You must report spam within 2 days of receipt. This mail was received on Mon, 1 Nov 2004 21:07:07 -0600

Message is 2.5 days old

Reports regarding this spam have already been sent:

Re: 67.10.47.249 (Administrator of network where email originates)

Reportid: 1279187236 To: abuse[at]rr.com

Reportid: 1279187237 To: spamcop[at]imaphost.com

--------------------------------------------------------------------------------

Report another spam?

Welcome, **********.

Your average reporting time is: 6 hours; Great!

Add fuel to your account

Please help support this service - buy some reporting fuel today. Fuel is used as you report spam to bypass the nag screen.

Unreported spam Saved: Report Now

Link to comment
Share on other sites

The only thing "needed" in your last post was the Tracking URL. Also missed was that Ellen had requested / suggested a sample of more than one Tracking URL to be sent directly to her.

The data offered isn't sufficient to clear things up for me, except to say that it doesn't look to me like things are working as someone apparently wanted them to work. One could start with something normally called a FQDN - Fully Qualified Domain Name ... is this "Imagineering" thing a .com, .net, .biz, etc. .... just one little thing ... is it hosted on an rr.com server? Why does the same IP show up in both Received header lines, other than making the assumption that something is very wrong in the handling of the e-mail? Are you posting from a system anywhere near the one you are having these problems with? Are you an administrator for any of the systems involved?

Link to comment
Share on other sites

Ok I do not see it reporting the firewall address - there actually is no way to even know the firewall address from the headers. For some reason when your system stamps the topmost received header it uses the IP of the connecting server in that header instead of it's own IP or an internal IP. It then stamps a second received header showing the source of the spam. The parser seems to cope with the topmost header even tho it would be much better if the header was correct. I looked at several of the spams that you have reported and they all seem to be reporting to the correct injection.

Also I should mention that the second received header does not have the FQDN (fully qualified domain name) in the "by" clause which it should have. The headers are just enough non-RFC compliant that while the parser parses them correctly now it is possible that at some point in the future it might have a problem with them if the parse logic is made stricter. I am not saying that will happen but it is always a possibility.

Link to comment
Share on other sites

Thank you for your contributions, but I am still unclear as to what it is that we need to do to remove the ..."possible forgery...not associated with any of your mailhosts..." Single label domain names are fairly common... 'production', 'development', etc are used internally, and I am assuming that this is what you are referring to.

The internal domain is 'Imagineering'. The domain externally is 'imagineering-online.com'

Another note (not necessarily relevant to this conversation) we are not receiving the notification emails when a new post is made to this message. Never have. I can check to see if it is being caught in a filter, but need to know the from address. The seetings in the profile indicate that we should be getting them, so not sure where the problem lies. So it takes us a little while to respond, since we don't know that there is anything to respond to.

Thanks

Imagineering

Link to comment
Share on other sites

I'm not sure about who is reading what, doing what, looking at what .... I see a ton load of questions not answered, pointers to issues not really taken as "hints" of things to fix, yet more issues added to the mix.

You say "single-label domains" are normal. I would only suggest that "internally" .. maybe your network does this. In the real world and dealing with "external" resources, a "single-label domain" just doesn't exist. A single word does not carry enough data to be seen in the real world as a Domain .. something to do with the definition of the word and how it gets used to actually "find" that Domain.

Link to comment
Share on other sites

Thank you for your contributions, but I am still unclear as to what it is that we need to do to remove the ..."possible forgery...not associated with any of your mailhosts..."  Single label domain names are fairly common... 'production', 'development', etc are used internally, and I am assuming that this is what you are referring to. 

The internal domain is 'Imagineering'.  The domain externally is 'imagineering-online.com'

Another note (not necessarily relevant to this conversation) we are not receiving the notification emails when a new post is made to this message.  Never have.  I can check to see if it is being caught in a filter, but need to know the from address.  The seetings in the profile indicate that we should be getting them, so not sure where the problem lies.  So it takes us a little while to respond, since we don't know that there is anything to respond to.

Thanks

Imagineering

19830[/snapback]

The possible forgery/not assiocaiated with your mailhosts is standard parser commentary when the parser finds an Ip/domain not associated with your defined mailhosts.

I might also mention that in received headers the "by" clause should contain the FQDN of the receiving mailserver.

In any case assuming that those are the only received headers and that rr IP is not part of your mail system then the parser found the injection point. If it is part of your configuration then there are missing received headers.

Link to comment
Share on other sites

The possible forgery/not assiocaiated with your mailhosts is standard parser commentary when the parser finds an Ip/domain not associated with your defined mailhosts.

I might also mention that in received headers the "by" clause should contain the FQDN of the receiving mailserver.

In any case assuming that those are the only received headers and that rr IP is not part of your mail system then the parser found the injection point. If it is part of your configuration then there are missing received headers.

20016[/snapback]

To All:

Thank you again for replying, but nobody here has made any suggestions about what you think we should do about this. As was previously stated, mail is stoped at the gateway (firewall.imagineering), making sure that the rules that apply to mail are enforced. It is then passed to the mail server (with the original sender IP intact) for processing. The mail flow and rules appear to work just fine, since there are no sending and delivery problems (Though we have not gotten any emails from this board). This means, as you have said that something is not associated with a correct mailhost...but what? We have tried a number of different posibilities with the same result. Please provide suggestions to resolve the problem(s), as opposed to bantering on about single lable domains, or anything else that ultimately is not going to help.

Link to comment
Share on other sites

To All:

Thank you again for replying, but nobody here has made any suggestions about what you think we should do about this.

A bit off .. there are at least two of us pointing to bad data in the headers, one going further to mention that perhaps there are some lines missing from those headers based on looking at your previous spam submittals ... and yet you say no one has suggested anything ..????

The mail flow and rules appear to work just fine,

And again, what you do "internally" with your e-mail is entirely up to you. However, if you want to drag an outside resource into the midst of things, then you must play by the rules that are being used by the rest of "the world" ....

Please provide suggestions to resolve the problem(s), as opposed to bantering on about single lable domains, or anything else that ultimately is not going to help.

I posed some suggestions based on what's "here" ... Ellen has looked at your "history" and mentioned the same "item" as a probable issue, pointed out at least one one other possibility ....

Link to comment
Share on other sites

What the gentleman has is a very common configuration on corporate intranets...

firewall.imagineering is a FQDN -- but only inside his LAN. .imagineering is the top-level domain they use within their LAN, and the internal mail servers use names with that domain.

Those names cannot be expected to be able to be resolved on the open Internet, as they only work inside his LAN. That doesn't change the fact that servers inside his LAN act as mail relays before the mail gets to him.

However, from previous experience, I believe spamcop's parser IS smart enough to recognize IP addresses that are in a private address space and write off that Received header as an internal mail server if the IP is displayed and in a private range. The headers your server is generating are putting the IP address of the original sender in that spot instead of the IP address of the server it received the mail from. That's the part that's throwing off the parser.

Link to comment
Share on other sites

What the gentleman has is a very common configuration on corporate intranets...

firewall.imagineering is a FQDN -- but only inside his LAN.  .imagineering is the top-level domain they use within their LAN, and the internal mail servers use names with that domain.

Those names cannot be expected to be able to be resolved on the open Internet, as they only work inside his LAN.  That doesn't change the fact that servers inside his LAN act as mail relays before the mail gets to him.

However, from previous experience, I believe spamcop's parser IS smart enough to recognize IP addresses that are in a private address space and write off that Received header as an internal mail server if the IP is displayed and in a private range.  The headers your server is generating are putting the IP address of the original sender in that spot instead of the IP address of the server it received the mail from.  That's the part that's throwing off the parser.

20331[/snapback]

Thanks for the reply. When the rest of the points are flushed out it looks like a new item may be needed to be added to the FAQ

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)

Until the corporate mail server is changed to identify itself properly and add the standard internet headers, it would appear that this user and others like him will be unable to use the SpamCop reporting system.

To Imagineering, could you send a message from your coporate address to yourself or a friend outside of your corporate intranet and post the headers for that to see what the outgoing headers look like?

Link to comment
Share on other sites

<snip>Until the corporate mail server is changed to identify itself properly and add the standard internet headers, it would appear that this user and others like him will be unable to use the SpamCop reporting system.

<snip>

20349[/snapback]

...IIUC, that is not true -- the solution is to get an exception approved and implemented by writing to the deputies as described in one or more of the pinned items in this forum.
Link to comment
Share on other sites

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

Return-Path: <Jeffrey.MacMillan[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 <drcatchka[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: "Jeffrey G. MacMillan" <Jeffrey.MacMillan[at]Imagineering-Online.com>

To: "Catherine Kiraly" <drcatchka[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.

Link to comment
Share on other sites

much easier to submit it to the parser and provide a Tracking URL .... just dealing with all the white space is distracting, the line wrap issues compound the issue ... I'll make a stab that you feel that your internally defined Domain somehow fits the "Internet" model of a Fully Qualified Domain Name ... sorry, it doesn't.

Link to comment
Share on other sites

much easier to submit it to the parser and provide a Tracking URL .... just dealing with all the white space is distracting, the line wrap issues compound the  issue ... I'll make a stab that you feel that your internally defined Domain somehow fits the "Internet" model of a Fully Qualified Domain Name ... sorry, it doesn't.

20597[/snapback]

There are two "domain names" that need to be considered here. The external domain is fully qualified (imagineering-online.com). The internal domain, which differs from the external domain name (imagineering) is not fully qualified, and other than being part of the hostname of the internal sending server, is not part of the mail path (received from line indicates imagineering-online.com, which is fully qualified)

Again, the ONLY problem we are having is the error on submission that states it is not coming from a trusted mailhost. We are NOT having problems with and mail transmission of any sort, nor are there any reception problems. If there is a problem with the use of a separate internal domain with a single name, it is a Spamcop interpretation of the infomation that is the source of that problem. It should also be clear that there will be a great many people who will be having this problem with Spamcop if this is the case. Microsoft has quite a few knowledgebase articles on configuring single label domain names that discuss this type of configuration.

dbiel asked for a pasted in header above, and that is what we provided for them.

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

Link to comment
Share on other sites

Who to contact, how to get a waiver, etc ..... again, found in the Pinned items within this Forum, try those tagged with "read before posting" for instance ...

Had you read through those, you'd have noted that the person you'd probably be dealing with has already posted in this Topic, in response to your issues ... here's a couple of highlights of her previous postings;

Ellen Nov 4 2004, 08:37 PM

Also I should mention that the second received header does not have the FQDN (fully qualified domain name) in the "by" clause which it should have. The headers are just enough non-RFC compliant that while the parser parses them correctly now it is possible that at some point in the future it might have a problem with them if the parse logic is made stricter. I am not saying that will happen but it is always a possibility.

Ellen Nov 10 2004, 08:06 PM

I might also mention that in received headers the "by" clause should contain the FQDN of the receiving mailserver.

Surely, you should see a theme growing here. As I've said before, what you do within your network is your issue, but sliding your internal configuration stuff to the outside world and expecting it to fly just isn't going to work. I'm not going to try to figure out which knowledgebase articles you might be referring to that might deal with trying to use a one-word 'domain' label other than on an internal network. Maybe Ellen can do something manually to the database (though doubting that a bit or she'd probably have done it at the time of her first posting)

As far as your provided headers, I'm not going to speak for dbiel, I'm just pointing out that all the white space and line-wrap issues make it hard to walk through .. how about you at least edit the white space out?

Link to comment
Share on other sites

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

In this case, it is up to the receiving server whether it wants to accept your messages. To a computer, it looks like you are attempting to forge your computer name (the HELO line of your server does not match the rDNS of the IP trying to connect) which is enough for some servers to reject your connection. Not many I would suspect, but I am aware of a couple that are this strict in what the receive.

However, this part of the thread (your outgoing path) will have nothing to do with how spamcop processes your incoming messages when you submit them. Also, while I know that this type of network naming was common several years ago, all of the companies which I deal with have changed over to using the same domains (some with additional sub domains) as their internet presense.

Link to comment
Share on other sites

In this case, it is up to the receiving server whether it wants to accept your messages.  To a computer, it looks like you are attempting to forge your computer name (the HELO line of your server does not match the rDNS of the IP trying to connect) which is enough for some servers to reject your connection.  Not many I would suspect, but I am aware of a couple that are this strict in what the receive.

However, this part of the thread (your outgoing path) will have nothing to do with how spamcop processes your incoming messages when you submit them.  Also, while I know that this type of network naming was common several years ago, all of the companies which I deal with have changed over to using the same domains (some with additional sub domains) as their internet presense.

20603[/snapback]

Unable to do this (use the same inside and outside) due to the character limit presented by microsoft.

Link to comment
Share on other sites

Surely, you should see a theme growing here.  As I've said before, what you do within your network is your issue, but sliding your internal configuration stuff to the outside world and expecting it to fly just isn't going to work.  I'm not going to try to figure out which knowledgebase articles you might be referring to that might deal with trying to use a one-word 'domain' label other than on an internal network.  Maybe Ellen can do something manually to the database (though doubting that a bit or she'd probably have done it at the time of her first posting)

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

Link to comment
Share on other sites

Unable to do this (use the same inside and outside) due to the character limit presented by microsoft.

What application has the limit? I have a configuration using 8.9.5.3 characters (location.company.domain.tld) with no problem. This is Windows itself, however, not Exchange (we use Lotus Notes and our mail servers are configured only with the domain.tld).

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...