I host a web site and email for a local charity. They have a fixed-ip dsl service at their office, but their domain name resolves to one of my ip addresses. Their domain name is in my local domains list, and they can receive email just fine. When they send email from their office to someone outside of their domain, however, SpamFilter detects this as a relay, blocks it, and issues the expected error message.

I would like to create the equivalent of a trust relationship, or essentially add their ip address to a white list that lets them relay - otherwise it appears that they cannot send email to outside persons/organizations now that I've installed SpamFilter.

Is there a way to accomplish this, and I've possibly just not figured it out yet? Could I put their fully qualified domain name with the ip address in reverse order in the white list to do this? Thus far my experimentation hasn't yielded a solution, so any advice would be appreciated very much!

Tx,

Robert

Thanks Dan. I'd already tried that, but SpamFilter still rejects Kathleen's email with the relay error message. I actually changed the word "send" to "relay" to prompt me when I saw it, so I can confirm that's where the error message is being generated from.

I am using the outside ip address from their dsl router, which I know is passed through our firewall. I see it in the Raptor logs. So I presume that the same ip is getting passed thru to SpamFilter.

Thoughts? Anything else that I should look at?

Tx,

Robert

Robert,

I am wondering if this is related to your previous post.  Do you, in fact have DNS set up?

Dan

Dan,

SBC uses authentiated smtp, but they cannot authenticated when users are behind firewalls. Their solution is to turn off the firewall (really!). I may be able to solve this at the charity's site b/c their network is simpler than mine, but I need to pursue both solutions in parallel so that I'll end up with at least one that works.

My network architecture is as follows for inbound smtp traffic:

dsl router --> Raptor firewall --> SpamFilter --> MS Exchange Server

Outbound is:

MS Exchange --> Raptor firewall ...

The address space between router and Raptor is routable. The address space inside the firewall is non-routable. SpamFilter and Exchange are on the same w2k server, and the same internal ip address, but different ports.

So to answer your specific questions, Exchange handles all outbound smtp, and anything that SpamFilter forwards goes directly and only to Exchange.

Robert

Dan,

I have DNS set up, and pop/smtp/web/etc. have been running. I just did some additonal testing, and I think I'm seeing what you're connecting about my posts. Exchange wasn't using the ip information that it was getting from the firewall - or maybe it was, and that's why it was always an uncontrolable open relay. SpamFilter is looking at that non-routable address that it's getting passed, and is saying (1) country n/a and (2) you can't relay because your address doesn't match any approved domains and (3) you can't relay because your ip is not on the exception list. This explains why putting Kathleen's ip in the whitelist didn't work. Of course, if I put the internal address in the white list... no, we won't go there.

Most folks must run SpamFilter behind a firewall, so I am guessing that their firewalls pass the IP address of the source rather than the internal ip of the firewall? If I recall correctly, ours has always passed the internal interface address. I am thinking that I have a configuration problem because SpamFilter is seeing the non-routable address for *every* transaction, but clearly is only passing traffic that is directed to internal domains. That later part works, as I'm getting your emails.

I need to do more investigation here. Thanks for seeing that!

Robert

Dan,

I wanted to post a huge THANKYOU for picking up on the relationship between my selective relay problem and my other post about the country N/A message.

We have been running with a configuration error on our firewall since it was set up, and have experienced a variety of specific things that didn't work right. Because the major services worked, I kept looking at the individual applications for solutions. What we needed was an appropriate set of Address Transforms defined on our firewall so that internal hosts would see the actual external client's ip address. Now the SpamFilter features work as they should, and it's clear already that several other inbound access-related issues will be solved as well.

Again, THANK YOU!!!!

Robert

Robert,

No problem ... I take it you are off and running now?

Dan

Dan,

Yes I am. Spam attacks are down to next to nothing, and none are getting thru. I'll test the selective relay further over the weekend, but my local external ip tests were spot on. Thanks!!

Robert