There is a registry setting called "No Local Delivery" that was used for Message Journaling back in the Exchange 5.5 days. This article references this - http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q239427.
Don't know if this is still around in Exchange 2000 or not. Mike ----- Original Message ----- From: "Wendy Reetz" <[EMAIL PROTECTED]> To: "Exchange Discussions" <[EMAIL PROTECTED]> Sent: Monday, August 12, 2002 9:16 AM Subject: Re: Help stopping local delivery > Chris, > > I'd just thought of writing event sinks to solve the local delivery problem > on Friday, but haven't had a chance to look into it. > I must admit, the boss said "this is how I want it done" & I've been trying > to do it that way. I think a step back would be a good idea. I'm going to > look for some of that research on ISPs & Exchange you mentioned. If you > know a good resource to speed up the search, I'd greatly appreciate it. > > Thanks, > > Wendy > > ----- Original Message ----- > From: "Chris Scharff" <[EMAIL PROTECTED]> > To: "Exchange Discussions" <[EMAIL PROTECTED]> > Sent: Friday, August 09, 2002 6:45 PM > Subject: RE: Help stopping local delivery > > > > > > 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] > _________________________________________________________________ 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]
