Exchange Email Resolution Problem

[jdyer]

The only way anyone will understand is if I explain the whole situation so here it goes.

We've just implemented this Magic Enterprise software. (I don't recommend it!) In order for this web based application to accept email we configured an account on the Magic server with a POP3 Internet Email account connecting to my Exchange 2000 Mail Server. The reason I'm using POP3 instead of just regular MAPI is because we need emails to come into the (POS) Magic Application in SMTP format instead of MAPI so Magic can interpret the sender of the message. Not only this but Magic can only support one mailbox. So in order for us to configure Magic to handle multiple email addresses is by assigning the 'magic' account email aliases and basing business rules (conditions within magic) to trigger based on those aliases. Well my problem resides here. If I send an email to alias@domain.com it goes to the Magic account and creates a ticket properly. If some end user sends an email to alias@domain.com, magic drops the email because Exchange resolves the email address to it's parent account's primary email address before the business rule can process. For domain admins such as myself, everything works fine. For anyone else, exchange automatically resolves email aliases to their parent account;s primary email address which causes the business rule to fail.

If anyone needs more information, I'll be willing to talk to anyone over the phone, or whatever. I'm getting pretty frustrated. The bottom line is why does Exchange automatically change the email address from an account's email alias to it's primary email account for end users and not domain admins?

Jeff

 

[Marcs41]

For one, domain admins are not to be compared withe 'regular' user.
Exchange will always use the default domain, the primary address.

But, if you are so frustrated and unhappy with that product, why don't you dismiss it?

Marc
[sub]If 'something' 'somewhere' gives 'some' error, expect random guesses or no replies at all. Please specify details.
Free Tip: The F1 Key does NOT destroy your PC![/sub]
How Do I Get Great Answers To my Tek-Tips Questions? See faq219-2884

 

[jdyer]

First, it's not my decision regarding the application. Second, if Exchange always uses the Primary Address than why does it not resolve for us (domain admins) and it does for regular users? The rule is triggered based on the address in the "TO:" field of the email. When us domain admins send an email to the system it triggers the rule using a secondary email address. When end users send email to the system, Exchange resolves the secondary smtp address to it's primary address which causes the email to be dropped by the system for not triggering a rule. Again this is because the Magic application's mail listen rule is triggered by the account's secondary email address and not it's primary.

Scenario:

Exchange Setup
Exchange Account: <account name>
Exchange Account Primary Address: accountname@domain.com
Exchange Account Secondary Address: whatever@domain.com

Magic Setup
If <Address To:> = whatever@domain.com then
create ticket

If I send an email to whatever@domain.com, it triggers the rule matching the condition and the ticket is created. If an end user sends to whatever@domain.com, the email is resolved to accountname@domain.com, thus causing the conditions to fail in the rule and as a result a ticket is not created.

I hope this clarifies.
Jeff

 

[Marcs41]

I do not know the internal workings of that 'Magic' application, but the rule in testing something is the same for anyhying: use a 'normal' user account to test.

If you use any admin account, or something with more rights or non-standard settings, your test are going to reflect something unrealistic, and that does not only apply for Exchange.

I can understand it is not your decision, but if something does not do what it is supposed to do, is it normal it is brought to the attention of whoever decided it, and thus bring that decision in discusson? After all, whoever decide it must (should) have tested it before aquiring it.

If that application can only work with secondary addresses, what would that applicaton do when there are no secondary addresesses?
Sounds a bit strange to me, so either the application is worthless, or it is configured wrong.


Marc
[sub]If 'something' 'somewhere' gives 'some' error, expect random guesses or no replies at all. Please specify details.
Free Tip: The F1 Key does NOT destroy your PC![/sub]
How Do I Get Great Answers To my Tek-Tips Questions? See faq219-2884

 

[jdyer]

Trust me I know. I can't possibly explain all the strings involved. I just need to know if there is a way to set in Exchange to not resolve email addresses to the account name.

This application was purchased by an employee that is not part of the IT group and has signed the contract. We now own the software and need to adapt and overcome given it's short comings. The application wasn't designed to handle email the way we need it to work. We're just trying to improvise.

Jeff

 

[Marcs41]

You can improvise all you want, but you are not going to cripple Exchange to suit some 'crappy' application are you?
Exhange WILL resolve the name, that is what Exchange is for.

If you want a workaround, the only thing I can see is to use Outlook Express to send to that app and cheat on the address.

 

[jdyer]

Well actually my original theory has been fluked. Now there are a few other users (non-admins) that have been able to send messages into the application without the email address being resolved thus causing the app to create an incident based on the content of the message. So now it makes me wonder further why Exchange is so inconsistent. Sometimes it resolves the addresses from the secondary address to the primary and sometimes it doesn't. Therefore Exchange DOESN'T ALWAYS resolve the name and if that's what Exchange is for, it's not doing it's job.

 

[jdyer]

I've figured out the problem and why Exchange has been resolving the emails to the account's primary email address. Those that had mailboxes located in the same storage group as the Magic Account's mailbox all worked fine. Those individuals that had mailboxes located within a different storage group, when sending emails to the magic account, Exchange resolved the email to it's primary email address instead of using the original email address specified. That is the answer I was looking for.

 

[Marcs41]

Well, good you got that figured out, but remember, Exchange will always use the primary address, the others are for incoming mail.