Exchange 2007 is not relaying pop mail......killing me!!!!!

[SBSguy]

I have an 07 mail server with a single domain, single forest. So I will call that domain EXCHANGEMAIL for now. I also have a pop domain that I will call POPMAIL for now. I need to be able to send an email to user@POPMAIL.com, and have it send to mail.PUBLICDOMAIN.com into EXCHANGEMAIL server. I have set up all the connectors that I can think of, and still it will not relay from the outside world. It will from the inside, but I get this from the outside......
Subject: FW: pop account email
Sent: 9/10/2008 11:38 AM

The following recipient(s) could not be reached:

'user1' on 9/10/2008 11:39 AM
550 5.7.1 Unable to relay

'user2' on 9/10/2008 11:39 AM
550 5.7.1 Unable to relay

Any help would be greatly appreciated. Thanks in advance. Also, I have much more specific info upon request. thanks

Rob

 

[ShackDaddy]

Have you added that POPMAIL domain to your Accepted Domains list in the Org\Hub settings area? That would be necessary if your server is going to receive mail for that domain. Otherwise you will get that relay message.

Dave Shackelford
Shackelford Consulting

 

[SBSguy]

yes,
That was done, and it is not set as authoritative... it is set as a relay. Anything else???? here is another tid bit of info.....

In the POPMAIL case, we have POP/SMTP clients (e.g. outlook setup with a POP/SMTP account) connecting from potentially ANYWHERE and trying to send. The more I think about this, the less I understand it... Im not sure how it worked before. What is supposed to happen is that we connect via POP/SMTP to EXCHNGEMAIL and send using username.popmail.com. What happens instead is, if the destination is an internal exchange mailbox, everything is fine, but if it is external to pubicdomain.com, we get unable to relay from EXCHNGEMAIL. Here are some email headers that show partly what is going on. These are from the outlook test message that you get when you setup an account in outlook, which was successful because it was sent within our exchange environment. Note in particular the portions Ive highlighted.....
Received: from computername (xx.xx.xxx.152) by mail.publicdomain.com (192.168.10.21)
with Microsoft SMTP Server id 8.1.291.1; Sat, 13 Sep 2008 08:14:46 -0600
From: <user@popmail.com>
To: <user@popmail.com>
Subject: =?utf-8?B?TWljcm9zb2Z0IE9mZmljZSBPdXRsb29rIFRlc3QgTWVzc2FnZQ==?=
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Message-ID: <f6c66489-fce2-4c67-bdf6-ce43ee2dedb7@exchngemail.publicdomain.com>
Return-Path: user@popmail.com
Date: Sat, 13 Sep 2008 08:14:46 -0600
X-MS-Exchange-Organization-PRD: popmail.com
X-MS-Exchange-Organization-SenderIdResult: None
Received-SPF: None (exchngemail.publicdomain.com: user@popmail.com does not
designate permitted sender hosts)
X-MS-Exchange-Organization-SCL: 3
X-MS-Exchange-Organization-PCL: 2
X-MS-Exchange-Organization-Antispam-Report: DV:3.3.6908.600;SID:SenderIDStatus None;OrigIP:xx.xx.xxx.152

let me know if this helps.... pretty darn complicated to me

 

[58sniper]

What is supposed to happen is that we connect via POP/SMTP to EXCHNGEMAIL

You don't send with POP3

and send using username.popmail.com. What happens instead is, if the destination is an internal exchange mailbox, everything is fine, but if it is external to pubicdomain.com, we get unable to relay from EXCHNGEMAIL.

If you're attempting to send to a popmail.com account, and that is local to Exchange, fine. But if the popmail.com account is external to Exchange, that could be a problem if the popmail.com domain name appears in a recipient policy in Exchange. That's because Exchange will believe it's authoritative for that domain name, and can't resolve the external address to an internal account. That's by design.



Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[SBSguy]

ok,
isn't that what the 3 options are for in the "accepted domains" tab. 1 is for authoritative, 2 is for relay internally, and 3 is for relay externally. I have this one set to number 2 for internal relay. The exchange server is set as the only authoritative domain. Am I understanding this right?

 

[SBSguy]

let me try and make this just a little clearer:

1) I am at home on my comcast account. I sent a message from my home account ( not part of work network) to user@popmail.com. The message gets kicked with the above mentioned undeliverable.

2) I am at work, and in my outlook client I have 2 mail entries. The first is an exchange account from EXCHANGEMAIL. The second is a pop account from POPMAIL.

These 2 mail domains are on the same server, 1 is authoritative, 1 is a relay. I can send out(externally) from my POPMAIL account all day. I can send and receive internally from my POPMAIL account all day. What I cannot do is receive from an external address to my POPMAIL account.

Hopefully this is clearer than the possible mud I described before. Thanks again for your help.

 

[ShackDaddy]

So you've set up two email accounts in Outlook: one with the Exchange server and one POP3 account? What did you put in for the servername in the POP3 account?

And how about on the outside: do the MX records for both domains point to the same place? Ultimately, the same IP? Or are they different locations?

It sounds to me like you might have mixed two separate things up:

Your POPMAIL MX record points out to a server that's not the same server as your other domain. Because of that, you have a POP3 mail setup in your work Outlook, and it retrieves and sends mail from that remote server.

Additionally, because you've configured Exchange 2007 internally with POPMAIL domain name and given your mailbox an additional email address in that domain, mail you send internally gets routed to you.

Start simple. Try changing the Accepted Domain type to authoritative and see what happens to inbound emails. Do other people outside of your organization use the POPMAIL domain, or is it all yours and all users will have mailboxes on your Exchange server? If the latter is true, you want to have the MX records point to the same place as EXCHANGEDOMAIN's do and configure the Accepted Domain to be authoritative.

Dave Shackelford
Shackelford Consulting

 

[SBSguy]

ok,
Thanks for working with me on this....
POP account is mail.POPMAIL.com The mx record points to 63.xx.xxx.xx. Exchange account is mail.EXCHANGEMAIL.com The mx record points to the same 63.xx address. Both accounts are on the same server. The POP account is not for users internally to the company.... we use our exchange mail. The POP account is a support email account for clients to send in inquiries or support questions to the company.

So, Joe user in Alaska ( who is using my product, but is not part of my company) sends me an email about his product. he uses the email address of user@POPMAIL.com. That email is supposed to hit my email server ( since that is where it is pointing), and be delivered to my email client via POP3. instead it gets kicked back to him, and he freezes to death.

I understand the part about it looping back internally, that makes sense. it makes sense that I can send out via this address because of how my send connector in configured. Do you still think that I should make the change to an authoritative account? Thanks again

 

[58sniper]

Why on earth would you do it that way? Why not just add another domain name to the recipient policy and get rid of POP3 all together? Unless I'm missing something, I can't see the reason for using POP3. Internal users shouldn't be connecting to Exchange via POP3. Ever. It's slow, outdated, and not as secured.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[ShackDaddy]

Rob, can you talk a little bit about what benefit you are trying to get from having a separate POP account in your Outlook to get client emails from? Are you trying to keep emails from clients completely separate from internal emails in your Outlook? Or are they ultimately all combined in a single mailbox? That division could be more easily accomplished with a simple rule.

If this were my business, this is how I would do it.

- Set up both MX records to point to the same place
- Add the client-support domain name to my Accepted Domains list as Authoritative (which you should do now in any case)
- Add the addresses from the client-support domain that you want to use (rob@popmail.com or support@popmail.com or whatever) to the Email Addresses list on your user account.

If you are really doing all these acrobatics to ensure that you are able to use whichever reply address is appropriate, then using a single mailbox does make it more difficult. I've used this tool before to get around that issue:

http://www.ivasoft.biz/smartreply2007.shtml

Or you could also keep the separate mailboxes, but delegate access to the POPMAIL mailbox to your main user account and just open it from within your Outlook directly and skip the whole POP3 account setup completely. If you give yourself Send-As perms on the POPMAIL account, you will be able to send out replies that will show the POPMAIL account as the reply address.

Dave Shackelford
Shackelford Consulting

 

[SBSguy]

Ok,
I got it working. As is usually the case..... it was something very small. I do understand that this is not the most efficeint....or effective way to do things, but it made sense because we have multiple products that we support internally. Each of these products has a support address both for phone, and for email. We set up the POP in order to be able to reply from support@POPMAIL.com.... and we have multiple "support@POPMAIL.com" addresses. Anyway.... I understand it's not perfect, but at least it works now. By the way, the fix was this: I had created a receive connector for the internal relay, and under the permissions I had only checked the first 2 boxes... which are internal users, and exchange users. I had not checked "exchange servers". When I did this, it gave the authoritative server access to the internal relay connector, at it worked perfectly. Thanks for all of your comments!!! Until next time.

Rob