Announcement

Collapse
No announcement yet.

Recipient Policies for SMTP "FROM" address with no internal mailboxes

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Recipient Policies for SMTP "FROM" address with no internal mailboxes

    Daniel, I've read both of your tutorials (excellent, BTW) at http://www.petri.com/configure_speci...ange_users.htm and http://www.petri.com/configure_excha...er_domains.htm. I'm still unsure about how to configure my setup. Allow me to explain.

    I own (for example) 123.com, and 456.com. 123.com's mail is hosted by a 3rd party with POP access. 456.com's mail is run from my exchange server. I have an e-mail account [email protected] which is a forward to [email protected]. I would like to have my exchange server set up in a way that when I send an e-mail, it appears as if it is coming from [email protected], and when people reply it will reply to there which in turn forwards to my exchange account at [email protected]. To do this I have modified the default recipient policy and added "@123.com" as an SMTP address, and then made it the default in the Properties-E-mail Addresses dialog box of my e-mail account in AD.

    Sometimes when sending mail to other users on the 123.com domain, Exchange assumes that it is a local mailbox and fails when sending the message. I was wondering if I had it configured wrong. Maybe I shouldn't be adding anything to the Default Recipient Policy, rather just add an SMTP e-mail address of @123.com to the Properties-E-mail Addresses dialog box of my AD account.

    How would you recommend I do this?

    Thank you.

  • #2
    Re: Recipient Policies for SMTP "FROM" address with no internal mailboxes

    What you want to do is called "shared SMTP namespace":

    Here are some articles about it:

    http://technet.microsoft.com/en-us/l...b2b09502e.aspx

    http://www.msexchange.org/tutorials/...e-Sharing.html
    Cheers,

    Daniel Petri
    Microsoft Most Valuable Professional - Active Directory Directory Services
    MCSA/E, MCTS, MCITP, MCT

    Comment


    • #3
      Re: Recipient Policies for SMTP "FROM" address with no internal mailboxes

      Thank you Daniel. I read through both articles but I don't believe they are addressing my issue. Those 2 articles are referring to if (for example) my exchange server was RECEIVING mail for both 123.com and 456.com but it needed to route the mail coming in to 456.com to another mail provider. This is not the case. Rather, INCOMING mail to 123.com goes to my exchange server, and INCOMING mail to 456.com goes to the other 3rd party provider. That's fine for my purposes. But all I need to do is FAKE the FROM and REPLY-TO addresses of my outgoing mail on Exchange to look like it's coming from 456.com - that is why I set up an SMTP address in the Default Recipient Policy. The problem becomes when I SEND and e-mail to a user on 456.com who's mailbox is hosted on the 3rd part's server, Exchange will sometimes think that the user is local and try delivering the message locally, and when it can't find the user it sends an NDR. Really I want it to deliver the message using DNS.

      My question is what would be the proper way to configure this. I know there seems to be 2 ways to get this to happen. One is to create the SMTP address ("@456.com") in the Default Recipient Policy, and then to set it as default in the users E-mail Addresses Properties in the AD. Another way to do it seems to be just creating a new SMTP address in the Properties of the user in AD. This will affect that user only - so it seems.

      So how would I do this?

      Thanks for taking the time to answer my question.

      -Eli

      Comment


      • #4
        Re: Recipient Policies for SMTP "FROM" address with no internal mailboxes

        I normally hate when people *BUMP* a thread, but instead of creating a new one, I am re-posting my question in as clear a format as possible.

        domain.com's mail is being run by a 3rd party. domainmail.com's mail is being run by me and my exchange server. I have a user who wants to use both mailboxes, which would mean he would be [email protected] and [email protected], but he wants that when he sends an e-mail from Exchange, that it makes as if it is coming from [email protected]. So I created him his own private SMTP address of [email protected] and set it as primary. Now, when I send an e-mail to [email protected] from my own exchange account, it goes straight into his exchange inbox instead of going out to the internet and sending it via DNS to domain.com which is what I want it to be doing so that Jeff get's his e-mail to his regular POP3 3rd party e-mail inbox. The reason why, obviously, this e-mail is going direct is since exchange finds a [email protected] mailbox on the local machine.

        Is there a way to tell exchange that all e-mail to domain.com should be sent using DNS, even though it finds a local SMTP address for that e-mail?

        Thank you very much.

        -Eli

        Comment


        • #5
          Re: Recipient Policies for SMTP "FROM" address with no internal mailboxes

          No, there isn't a way to do this.

          When you compose an email and submit it to Exchange, amongst other things, Exchange will run thru its categorizer. The first thing the categorizer will do is determine from the resolved name in the To: field is, where to send the mail. Exchange will determine if the email address (or domain) is one it is responsible for.

          It will discover that domain.com is one it is responsible for, and in particular that [email protected] is a local mailbox, and so it will deliver the message to the local mailstore. If it were a domain that it was not responsible for, then it would next query your DNS servers...

          As long as you've told Exchange that it is responsible for domain.com, then the categorizer can't behave any differently (as it is a logical way to behave for a domain that it 'owns') and can't be modified to do what you want.

          Comment


          • #6
            Re: Recipient Policies for SMTP "FROM" address with no internal mailboxes

            Originally posted by robbyb View Post
            As long as you've told Exchange that it is responsible for domain.com, then the categorizer can't behave any differently (as it is a logical way to behave for a domain that it 'owns') and can't be modified to do what you want.
            But I have not told Exchange that it is responsible for that domain (in the Default Recipient Policies), rather I have added a personal SMTP address in that users Properties dialog box.

            Even though I didn't add it to the Default Recipient Policy it will still not use DNS to send out the e-mail?

            Thanks

            Comment


            • #7
              Re: Recipient Policies for SMTP "FROM" address with no internal mailboxes

              Ah. I've re-read your post and I understand a bit better. Sorry.

              So domain.com is not your Exchange Server's responsibility. Just domainmail.com.

              But the categorizer will still behave in pretty much the way you don't want I'm afraid.

              One of its primary aims is to sort out where to send mail and it will do this by firstly analysing the recipient mail. It will see [email protected] and know that it resolves to an object in Active Directory. AD tells the categorizer that the mailbox is local, and so it does not need to use DNS (apart from maybe to use a local DNS Server to tell it where the local Exchange Server is, if it is not the server the categorizer is running on, if you see what I mean).

              The cat will still only behave this way because it is cost effective, and could, in some circumstances, prevent looping.

              If Jeff could associate another email address to his POP address, say [email protected] then you could do a server rule to copy any messages that arrive at Jeff's Exchange mailbox to [email protected] and that would work.

              It's a bit convoluted and depends on if the ISP could sort out that extra address, but it's all I can think of, I'm afraid...

              robbyb

              Comment

              Working...
              X