Hi guys.

Recently I found out that you can set SMTP address for your users with domain that is NOT in your accepted Domains. 

Example: example.com is not in your accepted domains, Add SMTP:john@example.com to user john. Then Send an Email to john@example.com form inside organization.

the email will be received by john and wont go to edge servers...

This behavior is wiered. and will cause alot of problems. this email address will be treated like its inside organization.

Another thing is on transport rules when you set a rule for users that are outside organization john will trigger the rule.

Please fix this mess.

Thanks.

Farhad

Hi

Can you provide more information, "please fix this mess", are you directing this to someone or you asking a question?

:)

Hi Ed and everybody and let's forget about whom is our friend directing. I think he is angry with this :)

and this is my problem too. It is very bad that a smtp address set on a mailbox is considered inside even if there is no accepted domain for that. Even if I set test@yahoo.com, since this address is inserted in Active Directory database, exchange will consider it inside and destined emails to it won't be sent to edge servers. this is what I think many people are unaware of. See this from mxexchange.org

http://www.msexchange.org/articles-tutorials/exchange-server-2010/management-administration/accepted-domains-part1.html

" For example, if I wanted an SMTP address on a mailbox that ends with the domain name of neilhobson.com, I must ensure that neilhobson.com is configured as an authoritative accepted domain "

So is this some kind of a fatal mistake? a bug or is there any option and solution to change this?

BTW, I'm facing the problem in Exchange 2010 SP3 (donno whether it exists on Exchange 2013 or not)

Thanks to all

• Edited by MohammadG 13 hours 11 minutes ago Typos

But why would you set an SMTP address on a user that isn't something you control?  If Exchange is pulling the information from your Domain Controller, why wouldn't it consider that address as internal to your organization? Besides if you give someone an SMTP address you don't own when someone replies to it it won't make it back your organization b\c the mx records would point someplace else.  

You're doing something that wouldn't work anyway.  There's no way you can protect people from doing everything that won't work or that you shouldn't do.  

But why would you set an SMTP address on a user that isn't something you control?  If Exchange is pulling the information from your Domain Controller, why wouldn't it consider that address as internal to your organization? Besides if you give someone an SMTP address you don't own when someone replies to it it won't make it back your organization b\c the mx records would point someplace else.  

You're doing something that wouldn't work anyway.  There's no way you can protect people from doing everything that won't work or that you shouldn't do.

:)

Hi Ed and everybody and let's forget about whom is our friend directing. I think he is angry with this :)

and this is my problem too. It is very bad that a smtp address set on a mailbox is considered inside even if there is no accepted domain for that. Even if I set test@yahoo.com, since this address is inserted in Active Directory database, exchange will consider it inside and destined emails to it won't be sent to edge servers. this is what I think many people are unaware of. See this from mxexchange.org

http://www.msexchange.org/articles-tutorials/exchange-server-2010/management-administration/accepted-domains-part1.html

" For example, if I wanted an SMTP address on a mailbox that ends with the domain name of neilhobson.com, I must ensure that neilhobson.com is configured as an authoritative accepted domain "

So is this some kind of a fatal mistake? a bug or is there any option and solution to change this?

BTW, I'm facing the problem in Exchange 2010 SP3 (donno whether it exists on Exchange 2013 or not)

Thanks to all

• Edited by MohammadG Thursday, June 18, 2015 6:16 PM Typos

:)

Hi Ed and everybody and let's forget about whom is our friend directing. I think he is angry with this :)

and this is my problem too. It is very bad that a smtp address set on a mailbox is considered inside even if there is no accepted domain for that. Even if I set test@yahoo.com, since this address is inserted in Active Directory database, exchange will consider it inside and destined emails to it won't be sent to edge servers. this is what I think many people are unaware of. See this from mxexchange.org

http://www.msexchange.org/articles-tutorials/exchange-server-2010/management-administration/accepted-domains-part1.html

" For example, if I wanted an SMTP address on a mailbox that ends with the domain name of neilhobson.com, I must ensure that neilhobson.com is configured as an authoritative accepted domain "

So is this some kind of a fatal mistake? a bug or is there any option and solution to change this?

BTW, I'm facing the problem in Exchange 2010 SP3 (donno whether it exists on Exchange 2013 or not)

Thanks to all

• Edited by MohammadG Thursday, June 18, 2015 6:16 PM Typos

:)

Hi Ed and everybody and let's forget about whom is our friend directing. I think he is angry with this :)

and this is my problem too. It is very bad that a smtp address set on a mailbox is considered inside even if there is no accepted domain for that. Even if I set test@yahoo.com, since this address is inserted in Active Directory database, exchange will consider it inside and destined emails to it won't be sent to edge servers. this is what I think many people are unaware of. See this from mxexchange.org

http://www.msexchange.org/articles-tutorials/exchange-server-2010/management-administration/accepted-domains-part1.html

" For example, if I wanted an SMTP address on a mailbox that ends with the domain name of neilhobson.com, I must ensure that neilhobson.com is configured as an authoritative accepted domain "

So is this some kind of a fatal mistake? a bug or is there any option and solution to change this?

BTW, I'm facing the problem in Exchange 2010 SP3 (donno whether it exists on Exchange 2013 or not)

Thanks to all

• Edited by MohammadG Thursday, June 18, 2015 6:16 PM Typos

Hi Farhad,

Thank you for your question.

First of all, we could add any STMP address to user account, but if we want to change the primary SMTP address into xxx@example.com, we must create accept domain.

By my testing, when we add john@example.com to john, the email was received by john and do not go to Edge server. It is by design. So we should be patient to add SMTP address.

If there are any questions regarding this issue, please be free to let me know.

Best Regard,

Jim

Hi Jim

It is by design and that's all by Microsoft? adding SMTP address from any domain you like with no accepted domain? and we cannot change that? It is simply awful.

Don't you think Microsoft guys should fix this very soon? which I think should be very simple with an update or hotfix? or at least correct too many books and articles? :(

and at last are you sure there is no workaround for this (let me call it this shame :| ) ?

• Edited by MohammadG 3 hours 2 minutes ago Typo

Hi Jim

It is by design and that's all by Microsoft? adding SMTP address from any domain you like with no accepted domain? and we cannot change that? It is simply awful.

Don't you think Microsoft guys should fix this very soon? which I think should be very simple with an update or hotfix? or at least correct too many books and articles? :(

and at last are you sure there is no workaround for this (let me call it this shame :| ) ?

• Edited by MohammadG Friday, June 19, 2015 4:25 AM Typo

Hi Jim

It is by design and that's all by Microsoft? adding SMTP address from any domain you like with no accepted domain? and we cannot change that? It is simply awful.

Don't you think Microsoft guys should fix this very soon? which I think should be very simple with an update or hotfix? or at least correct too many books and articles? :(

and at last are you sure there is no workaround for this (let me call it this shame :| ) ?

• Edited by MohammadG Friday, June 19, 2015 4:25 AM Typo

Hi Jim

It is by design and that's all by Microsoft? adding SMTP address from any domain you like with no accepted domain? and we cannot change that? It is simply awful.

Don't you think Microsoft guys should fix this very soon? which I think should be very simple with an update or hotfix? or at least correct too many books and articles? :(

and at last are you sure there is no workaround for this (let me call it this shame :| ) ?

• Edited by MohammadG Friday, June 19, 2015 4:25 AM Typo

If you think that it's that big of a problem, I would suggest contacting MSFT support.  Chances are you won't get a code fix just by posting on t

If you think that it's that big of a problem, I would suggest contacting MSFT support.  Chances are you won't get a code fix just by posting on t

Hi Farhad,

Thank you for your question.

First of all, we could add any STMP address to user account, but if we want to change the primary SMTP address into xxx@example.com, we must create accept domain.

By my testing, when we add john@example.com to john, the email was received by john and do not go to Edge server. It is by design. So we should be patient to add SMTP address.

If there are any questions regarding this issue, please be free to let me know.

Best Regard,

Hi Farhad,

Thank you for your question.

First of all, we could add any STMP address to user account, but if we want to change the primary SMTP address into xxx@example.com, we must create accept domain.

By my testing, when we add john@example.com to john, the email was received by john and do not go to Edge server. It is by design. So we should be patient to add SMTP address.

If there are any questions regarding this issue, please be free to let me know.

Best Regard,

Hey guys

First of all , I'm not gonna answer this "ed" guy.

Second, If we can get someone from the exchange team on this thread it would be awesome.

Thanks

Farhad

Hey guys

First of all , I'm not gonna answer this "ed" guy.

Second, If we can get someone from the exchange team on this thread it would be awesome.

Thanks

Farhad

This is the way Exchange has always worked. Kinda cool huh? In the old days, before transport rules, if you wanted to block the ability of an internal user to send to a specific external SMTP address, you could just create a contact or mailbox with that SMTP address and it would never leave the org.

This is the way Exchange has always worked. Kinda cool huh? In the old days, before transport rules, if you wanted to block the ability of an internal user to send to a specific external SMTP address, you could just create a contact or mailbox with that SMTP address and it would never leave the org.

This is the way Exchange has always worked. Kinda cool huh? In the old days, before transport rules, if you wanted to block the ability of an internal user to send to a specific external SMTP address, you could just create mailbox with that SMTP address and it would never leave the org.

if you want a direct anwer then you shouldnt post questions like you have. This is the exchange forum, if you unhappy with the responses then log a PS1 call with Microsoft so you can take your frustrations out on them, we are here to help but dont like when you blast off at someone or something because you not happ

if you want a direct anwer then you shouldnt post questions like you have. This is the exchange forum, if you unhappy with the responses then log a PS1 call with Microsoft so you can take your frustrations out on them, we are here to help but dont like when you blast off at someone or something because you not happ

This is the way Exchange has always worked. Kinda cool huh? In the old days, before transport rules, if you wanted to block the ability of an internal user to send to a specific external SMTP address, you could just create a contact or mailbox with that SMTP address and it would never leave the org.

This is the way Exchange has always worked. Kinda cool huh? In the old days, before transport rules, if you wanted to block the ability of an internal user to send to a specific external SMTP address, you could just create a contact or mailbox with that SMTP address and it would never leave the org.

This is the way Exchange has always worked. Kinda cool huh? In the old days, before transport rules, if you wanted to block the ability of an internal user to send to a specific external SMTP address, you could just create a contact or mailbox with that SMTP address and it would never leave the org.

This is the way Exchange has always worked. Kinda cool huh? In the old days, before transport rules, if you wanted to block the ability of an internal user to send to a specific external SMTP address, you could just create a contact or mailbox with that SMTP address and it would never leave the org.

This is the way Exchange has always worked. Kinda cool huh? In the old days, before transport rules, if you wanted to block the ability of an internal user to send to a specific external SMTP address, you could just create a contact or mailbox with that SMTP address and it would never leave the org.

Hi guys,

As Eds said, if we want to an external email address to receive email, we create a contact in a generally.

In addition, I will tell something which you are mentioned:

If we add an external email address, then we send to external email address in organization. once Exchange will retrieve AD database to check ii it is in AD database, Exchange will deliver this email to the STMP primary email address which include this specific external email address, Exchange will not deliver this email to Edge even external.

If there are any questions regarding this issue, please be free to let me know.

Best Regard,

Jim

Hi guys,

As Eds said, if we want to an external email address to receive email, we create a contact in a generally.

In addition, I will tell something which you are mentioned:

If we add an external email address, then we send to external email address in organization. once Exchange will retrieve AD database to check ii it is in AD database, Exchange will deliver this email to the STMP primary email address which include this specific external email address, Exchange will not deliver this email to Edge even external.

If there are any questions regarding this issue, please be free to let me know.

Best Regard,

Jim

Hi Mohammad and Farhad,

You have got some valid points, this came to my mind as well long back. Seen it this way across versions, it has to be something why its like that.

Atleast the "New Email Address Policy" doesn't allow you to add @yahoo.com

Hi,

Cases when this issue might arise in normal scenarios: (And ofcourse might go un-noticed,due to its above discussed nature)

1. Rogue Administrator

2. Typo in Batch scripts

3. Inexperience helpdesk personnel adds email alias instead of creating Contact

4. Old email address policy decommisioned or changed\deleted. (This is the big one) or migration to new SMTP domain maybe.

To answer why its still there, one of my possible explainations using point no. 4.

We had a nice working @domain.com via an accepted domain and email address policy. Under current design if you remove an accepted domain or email address policy, nothing much happens and life goes on with the users, mail flow continues.

Lets consider if removing\changing the Accepted domain @domain.com, stops Exchange from receiving email on the SMTP Aliases configured as that @domain.com.

So when point4 would be executed in a single domain environment, there will be a chaos, with NDRs and numorous helpdesk calls. You will have overhead of removing\updating all those thousands of email addresses  unplanned on mass scale.

If it was planned nothing to worry, all would be fine. But having the potential to crash your environment might be one of the reasons I believe its like the way it is. Atleast better than few users getting\not getting emails to their external accounts, that you would gradually figure out anyways and fix.

I would love to hear more, similar possibilites, why its there.

Satyajit is correct. 

As an aside, in Office 365, we enforce this at the provisioning layer, however, this creates an unfortunate situation when a domain is retired - basically it can't be retired without removing the domain from all mailboxes first.  This behavior must be enforced in Office 365, but most administrators would find this difficult in the on-premises environment.  Especially when you think about mergers and divestures, this type of enforcement could create problems.  Office 365, by the way, also does not use address book policies.  Most larger environments also have specific provisioning scripts or apps or DirSync which could easily prevent this type of accident.

If you want a remote user for non-accepted domain to exist in the GAL, then use mail user or mail contact object instead of mailbox.  Alternately, depending on the details of your environment, you could use rules or other transport features like OpenDomainRouting to change the behavior so that this is no longer possible.

Also, while we do accept feedback, and your point of view is understood and respected, Exchange has always worked this way.  Personally, I have never heard this complaint before.  So this type of request would be a "design change", not a "bug" because it could impact thousands of customers who may depend on it working a certain way today.  Changes like this are not made lightly.

If you want it to change or want to pursue workarounds which do exist, I suggest a support ticket will likely be necessary.

Regards,

Scott

• Edited by ScottL [MSFT]Microsoft employee, Moderator 14 hours 50 minutes ago
• Marked as answer by Andy DavidMVP, Moderator 14 hours 44 minutes ago

Satyajit is correct. 

As an aside, in Office 365, we enforce this at the provisioning layer, however, this creates an unfortunate situation when a domain is retired - basically it can't be retired without removing the domain from all mailboxes first.  This behavior must be enforced in Office 365, but most administrators would find this difficult in the on-premises environment.  Especially when you think about mergers and divestures, this type of enforcement could create problems.  Office 365, by the way, also does not use address book policies.  Most larger environments also have specific provisioning scripts or apps or DirSync which could easily prevent this type of accident.

If you want a remote user for non-accepted domain to exist in the GAL, then use mail user or mail contact object instead of mailbox.  Alternately, depending on the details of your environment, you could use rules or other transport features like OpenDomainRouting to change the behavior so that this is no longer possible.

Also, while we do accept feedback, and your point of view is understood and respected, Exchange has always worked this way.  Personally, I have never heard this complaint before.  So this type of request would be a "design change", not a "bug" because it could impact thousands of customers who may depend on it working a certain way today.  Changes like this are not made lightly.

If you want it to change or want to pursue workarounds which do exist, I suggest a support ticket will likely be necessary.

Regards,

Scott

Thanks Scott

But as I said this is a very bad behavior and should be fixed or at least be an option to choose. it is not rational to make mail contacts for all external users.

You mentioned, If I am right, that there are some methods to prevent this, would you please explain more or give us links about those kind of scripts, transport rules or opendomainrouting to resolve this issue?

and at last, again I believe this is not correct for Microsoft to wait for tickets to improve its products. I am evaluating exchange 2010 now so I do not have a support from Microsoft but I think MS guys should check these issues and present workarounds.

Thanks again Scott for your patience and answer

and BTW, this should be corrected in many books (MSpress and others). this is the minimum action to be done whether you call it a bug or a design type, the correct situation should be stated in references.

Satyajit is correct. 

As an aside, in Office 365, we enforce this at the provisioning layer, however, this creates an unfortunate situation when a domain is retired - basically it can't be retired without removing the domain from all mailboxes first.  This behavior must be enforced in Office 365, but most administrators would find this difficult in the on-premises environment.  Especially when you think about mergers and divestures, this type of enforcement could create problems.  Office 365, by the way, also does not use address book policies.  Most larger environments also have specific provisioning scripts or apps or DirSync which could easily prevent this type of accident.

If you want a remote user for non-accepted domain to exist in the GAL, then use mail user or mail contact object instead of mailbox.  Alternately, depending on the details of your environment, you could use rules or other transport features like OpenDomainRouting to change the behavior so that this is no longer possible.

Also, while we do accept feedback, and your point of view is understood and respected, Exchange has always worked this way.  Personally, I have never heard this complaint before.  So this type of request would be a "design change", not a "bug" because it could impact thousands of customers who may depend on it working a certain way today.  Changes like this are not made lightly.

If you want it to change or want to pursue workarounds which do exist, I suggest a support ticket will likely be necessary.

Regards,

Scott

• Edited by ScottL [MSFT]Microsoft employee, Moderator Wednesday, July 01, 2015 4:36 PM
• Marked as answer by Andy DavidMVP, Moderator Wednesday, July 01, 2015 4:42 PM

Satyajit is correct. 

As an aside, in Office 365, we enforce this at the provisioning layer, however, this creates an unfortunate situation when a domain is retired - basically it can't be retired without removing the domain from all mailboxes first.  This behavior must be enforced in Office 365, but most administrators would find this difficult in the on-premises environment.  Especially when you think about mergers and divestures, this type of enforcement could create problems.  Office 365, by the way, also does not use address book policies.  Most larger environments also have specific provisioning scripts or apps or DirSync which could easily prevent this type of accident.

If you want a remote user for non-accepted domain to exist in the GAL, then use mail user or mail contact object instead of mailbox.  Alternately, depending on the details of your environment, you could use rules or other transport features like OpenDomainRouting to change the behavior so that this is no longer possible.

Also, while we do accept feedback, and your point of view is understood and respected, Exchange has always worked this way.  Personally, I have never heard this complaint before.  So this type of request would be a "design change", not a "bug" because it could impact thousands of customers who may depend on it working a certain way today.  Changes like this are not made lightly.

If you want it to change or want to pursue workarounds which do exist, I suggest a support ticket will likely be necessary.

Regards,

Scott

• Edited by ScottL [MSFT]Microsoft employee, Moderator Wednesday, July 01, 2015 4:36 PM
• Marked as answer by Andy DavidMVP, Moderator Wednesday, July 01, 2015 4:42 PM

Hi Satyajit

Thanks for the reply, 

You made your point, It will cause a chaos if you remove accepted domain for exmaple.com. it will cause a chaos if you mess up your DNS, For example you remove a DNS zone completely, or decomission all domain controllers of a domain. Should we change the behaviour of the whole system because an administrator can make a horrible mistake? I guess not.

And to the ed guy, Your attitude is typical among microsoft ppl, you make a bad decision and you force it to consumers, " its by design, it always worked this way" ... 

Hi Satyajit

Thanks for the reply, 

You made your point, It will cause a chaos if you remove accepted domain for exmaple.com. it will cause a chaos if you mess up your DNS, For example you remove a DNS zone completely, or decomission all domain controllers of a domain. Should we change the behaviour of the whole system because an administrator can make a horrible mistake? I guess not.

And to the ed guy, Your attitude is typical among microsoft ppl, you make a bad decision and you force it to consumers, " its by design, it always worked this way" ...