> > Well, that's what Ed was saying I think. I'm saying let all mail for > local > > recipients be delivered locally and let mail for the unix users be > forwarded > > to the server they reside in. But, that means that any mail sent and > > delivered to local recipients would not go through your filtering > rules... > > but as you allude below, if you had 2 unix mail servers, you'd implement > > filtering on the second one. That's basically what I'd recommend for > > Exchange as well... using what product depends entirely on the needs. > But > > treat Exchange the same as you would any other mail server. > > Yeah, this seems to be the option I keep coming back to. Even in the > article you sent, this is the result. Setting up the mail rules on > Exchange > will be a bear, though. They use Sendmail here & my co-worker is > currently > rewriting the rules to have graduated levels of filtering for different > users. Once he sets up the rules (how he's doing it is still up in the > air) > maybe I'll be able to do something with that.
Siegfried Weber has some nice sample event sinks at www.cdolive.com. Quite a bit of message filtering could be done using event sinks and if designed well, could be created in a single console to apply to both sendmail and Exchange. But, if the sendmail box is the Mx record for all internal domains, you could filter most spam and such there. User to user spam on the Exchange server itself is pretty rare... well, ok not rare but can be handled differently than anonymous spam. > > > A couple people suggested that they use EXIM to do just that. Boss > said > > > no > > > dice, until proven an only option. But, sheesh, if it's the only way, > I'm > > > so not finding a way in exchange to do it. It's just a screwy unusual > > > setup > > > that exchange designers likely didn't anticipatae. > > > > I'd be using the 3rd option in this Q article: Q260973. > > Righ, I've tried this. & I guess if I'm going to allow local delivery > (which I'm still trying not to) I'll set it up this way. If you want users to be able to see each other in the GAL and schedule meetings and such, you'll want local delivery... trust me. > > > The way I understand our sendmail is that the filters can be applied > to > > > local delivery mail. So, setting up a second unix mail server, no > > > problem, > > > copy the filter program on to that machine. There's no routing mail > > > around > > > in circles generally. The filter program is SOOOO dang complex (ever > used > > > sendmail? Yikes) to recreate it in Exchange would be a bigger headache > > > than > > > this (though, at this point I just can't imagine that). > > > It would suit me just fine to have it hit our MX record box, split it > & > > > send > > > mail to the unix box or to the exchange box dependent on where the > > > recipient > > > is & cut out the forward. However, I'm not allowed to change the > setup, > > > already asked. > > > > All they'd need to do is set up a .forward file on the unix box for the > > recipients who have mailboxes on Exchange. Which I imagine they're doing > > already... if not you've got some serious problems that likely none of > us > > will be able to resolve. > > This is what we're doing. I keep having people suggesting to me that it's > inefficient to do a .forward because it's one more hop. But, while I > agree, > we get some undenyable benefits from doing the forward (as my boss pointed > out in detail), so that's really going to stay the setup. That's fine more or less. Could potentially be a pain with thinks like mail enabled public folders, but it's workable. > > > It would suit me just fine to say, tough luck if people have your > > > exch.mydomain.com address & you choose to no longer use exchange, it's > > > just > > > like cancelling any e-mail account anywhere, you will always have > > > lingering > > > people with the old address. > > > > No need to do that if you follow the Q article I referenced IMO. > > Yep, I think you're right. It's a lot cleaner to have people not know the > exch.mydomain.com address & just work with the one they've had for so > long. > I was just frustrated & in a "just screw it" mood on that e-mail. > > > >It's life, it's just the way it goes. > > > Unfortunately, I'm not the boss, by any stretch of the imagination. & > > > until > > > I exhaust every other posibility, he won't even consider changing the > > > setup. > > > Everything is already integrated efficiently with the billing system, > we > > > do > > > hosting, domains are automated, mail associated with them > > > automated...changing the setup (which is extremely efficient when you > take > > > Exchange out of the picture) would be a mess. > > > > Is this for providing hosted Exchange to users? If so, the design is > even > > more fundamentally flawed IMO. I think your bosses really need to take a > > step back and figure out what the objectives are with regards to > providing > > Exchange services and then work on implementing it with those design > goals > > in mind. It's certainly possible to provide mailboxes on multiple > platforms > > (even in a hosted environment) in an efficient manner, but the plan has > to > > be well thought out and tested. Sounds like they want you to throw a > bunch > > of paint at a wall and come up with a masterpiece... possible, but > highly > > unlikely. > > Well, I'm not sure how it's fundamentally flawed... > Yes it is for providing Exchange as an option to e-mail accounts we > already > host. They already have the unix account, for dial-up, for domain > hosting, > for e-mail hosting. They have to have an account on our unix system, > there's no way around that. The uniqueness of user names has to be > accross > all platforms (so [EMAIL PROTECTED] has to be the same user as > [EMAIL PROTECTED]). Everything is tied together through the billing > system. > So, I'd have to be able to sign up a user, enter them once, select what > kind > of services they are getting (unix domain hosting, w2k domain hosting, > unix > email account, exchange account, etc) and have a script automatically > generate everything. Now, all of this already works, been working for > years, but I need to integrate windows 2000 services (such as domain > hosting > & exchange 2000) into the mix. Well, I've know a few folks who've worked for ASPs (which is a different side of a similar coin) and have also worked with and researched solutions for ISPs who want to integrate Exchange and Windows offerings into their services... including things like how to properly provision accounts, how to offer mail services across multiple platforms, how to provide different levels of Exchange functionality to particular users or groups and how to integrate with billing systems like OptiGold and Billmax. In none of those scenarios was rerouting local mail even discussed... so either I was way off base or your situation is totally unique or someone is trying to fit a square peg in a round hole. > Proving to be an absolute blast so far (*sarcasm definitely applied here). > :-) But I'm learning a lot. :-) > > Thanks for the advice. :-) I'm not saying what you're looking to do can't be done (not delivering mail for local recipients locally), and I'd happily charge you large sums of money to achieve it. However, I strongly believe that there is a high probability that the initial design was flawed in a manner which has led you to this point. _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED]
