Re: SMTP mailflow problem

Hi Andrew:

Merv has given you the fix for a problem that should'nt exist, imo.

But I am always interested in the reasons organizations do what they do,
so if you don't mind can you give us an idea why this user does not use the
company mail server?

Thanks.

-
Larry
Please post the resolution to your
issue so others may benefit
-
Get Your SBS Health Check at
www.sbsbpa.com


> I'm using SBS 2003 and our internet mail is hosted externally. All
> our users have Exchange mailboxes except one. That one user still has
> an email address using the same corporate domain but he just uses the
> webmail at the host's site.
>
> The problem is when someone tries to email him from within our LAN
> (using the Exchange SMTP server) then Exchange bounces it with 550 -
> relaying not allowed. Any suggestions on how to fix this?
>

> On Oct 26, 5:44*pm, Larry Struckmeyer[SBS-MVP] <lstruckme...@mis-
> wizards.com> wrote:
>> Hi Andrew:
>>
>> Merv has given you the fix for a problem that should'nt exist, imo. *
>>
>> But I am always interested in the reasons organizations do what they do,
>> so if you don't mind can you give us an idea why this user does not use the
>> company mail server?
>
> The reason is that he's a temporary consultant and there weren't
> enough licenses on the server - that and he really doesn't need access
> to any files on the server....he just needs company email to deal with
> some clients. It also has to do with scope - I'm not getting paid any
> extra to manage an account & a laptop for this guy.
>
> The way it's setup right now is how it's described in the second link
> above. I've got the default recipient policy and another higher
> priority one called "user addresses". Both policies list @company.com
> and @company.local with the .com one set as the primary. The only
> difference in the "user addresses" policy is that the "This Exchange
> organization is responsible for all mail delivery to this address"
> checkbox for the @company.com address space is unchecked.
>
> At first I thought the problem might be that the guy doesn't have an
> account in AD & that I needed to make one for him and make it "mail-
> enabled" but not "mailbox-enabled". Now I'm pretty sure it's the
> connector that's the problem because of the checkbox "Allow messages
> to be relayed to these domains". Our default Small Business SMTP
> Connector does not have that checked. It lists * for domains.
>
> I can't remember why that recipient policy is needed - can someone
> refresh my memory? What happens when that "user addresses" policy
> isn't there?
>
> Anyway, a message arrives for the consultant and Exchange can't find a
> match for it because he doesn't have an AD account. Exchange is also
> not authoritative for the @domain.com namespace because of the "user
> addresses" policy. So Exchange checks the connectors and DNS. I'm
> pretty sure this is where it fails but I'm still at a loss for the
> best way to fix it. It seems like if I make a connector or modify the
> default one to allow relays to the company.com domain, it might cause
> problems. I know I'm probably not understanding this right but it
> seems like that might cause interoffice mail to go through the
> internet (which is, I think, the reason that "user addresses" policy
> was created - to prevent that).
>
> OK tell me if I'm on the right track here. I just hit the modify
> button on the "user addresses" recipient policy and the filter was set
> to only "Users with Exchange Mailbox". There's another checkbox under
> that to modify the query to include "Users with external email
> addresses". So I'm thinking the right way to fix this might be to
> create a "mail-enabled" user account for him and check that checkbox
> which would make that recipient policy affect his account. But that
> would give him a @domain.local address also. Would this matter? Even
> if it did fix it I still can't quite understand this process
> completely.
>
> Ugh. Please help me understand this. And thank you for your help.

I'm with Larry here with curiousity regarding such mail configurations.
Interesting reason, and interestingly as well what you've tried to
circumvent it, err, try to get it to work.

The only real fix is you will need to create a mailbox-enabled user
account, otherwise internally, no one can send him email. Your Exchange
server is authorative for domain.com (the external name), therefore, it
expects the account to be local, not on some other server. Your POP3
connector pulls mail from that server and matches it up with internal
recipients. Keep in mind, the POP3 connector is a "pull-only"
connector. Exchange expects the account to be internal.

You don't have to configure the user's laptop. Just instruct the user
to use the SBS' OWA (webmail) to participate with mail. He won't be
able to logon to the domain with his laptop, however he can with
someone else's machine, if he really wanted to. You can limit that as
well, with restricting what workstations he can log into, in his AD
account. Just put a dummy machine name in it.

--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Please reply back to the newsgroup or forum for collaboration benefit
among responding engineers, and to help others benefit from your
resolution.

Ace Fekay, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE &
MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer

For urgent issues, please contact Microsoft PSS directly. Please check
http://support.microsoft.com for regional support phone numbers.

"Andrew" <> wrote in message
news:df635ff7-abc6-43ec-a162-...
> The Exchange server is *not* authoritative for domain.com. I really
> don't want this guy to have access to this server. I know I could fix
> it by doing so but I shouldn't have to. I'm using this as a learning
> experience and at a certain point I'll do whatever it takes to fix it,
> but I have good reasons for wanting things to be setup this way.
> There *is* a way to do this without giving this guy an exchange
> mailbox or giving him server access.


No, can't think of any other way other than removing @domain.com. Even
though it's unchecked, it's a proxy address, therefore Exchange will not
look further.

Ace

Andrew wrote:
> The Exchange server is *not* authoritative for domain.com. I really
> don't want this guy to have access to this server. I know I could fix
> it by doing so but I shouldn't have to. I'm using this as a learning
> experience and at a certain point I'll do whatever it takes to fix it,
> but I have good reasons for wanting things to be setup this way.
> There *is* a way to do this without giving this guy an exchange
> mailbox or giving him server access.

Method 1 of KB321721 works. I've been running one of two SBS-based
networks sharing an externally-hosted domain for a few years now, and
trust me, sending mail from a user in one network definitely does result
in its arriving at the external host. I would assume that the other SBS
has been configured in the same way, as I gave its admin a link to
KB321721 when it was first installed. The first method is more
appropriate for most purposes, as it does not require Exchange to be
aware of the 'other' users individually.

There are two recipient policies in use: the priority 1 policy is the
new one, with no filter rules and the shared domain as its primary. The
second policy, of 'lowest' priority, is as far as I can recall,
unchanged except for one detail. So the filter rules consist of just
(mailnickname=*).

The one change, and it may be counter-intuitive, is to set the *local*
SBS domain name as primary. Exchange remains authoritative for this
local domain. Sent email still uses the shared domain name, as the no.1
policy has priority.

The additional SMTP Connector is essential. Quote:
"If you do not add the SMTP connector with the shared address space, any
incoming e-mail that is destined to the shared SMTP address space is
interpreted as an attempt to relay."
The address space for the new connector is the shared domain, the
address space for the default connector remains "*".

--
Joe

"Joe" <> wrote in message
news:%...
> Andrew wrote:
>> The Exchange server is *not* authoritative for domain.com. I really
>> don't want this guy to have access to this server. I know I could fix
>> it by doing so but I shouldn't have to. I'm using this as a learning
>> experience and at a certain point I'll do whatever it takes to fix it,
>> but I have good reasons for wanting things to be setup this way.
>> There *is* a way to do this without giving this guy an exchange
>> mailbox or giving him server access.
>
> Method 1 of KB321721 works. I've been running one of two SBS-based
> networks sharing an externally-hosted domain for a few years now, and
> trust me, sending mail from a user in one network definitely does result
> in its arriving at the external host. I would assume that the other SBS
> has been configured in the same way, as I gave its admin a link to
> KB321721 when it was first installed. The first method is more appropriate
> for most purposes, as it does not require Exchange to be aware of the
> 'other' users individually.
>
> There are two recipient policies in use: the priority 1 policy is the new
> one, with no filter rules and the shared domain as its primary. The second
> policy, of 'lowest' priority, is as far as I can recall, unchanged except
> for one detail. So the filter rules consist of just (mailnickname=*).
>
> The one change, and it may be counter-intuitive, is to set the *local* SBS
> domain name as primary. Exchange remains authoritative for this local
> domain. Sent email still uses the shared domain name, as the no.1 policy
> has priority.
>
> The additional SMTP Connector is essential. Quote:
> "If you do not add the SMTP connector with the shared address space, any
> incoming e-mail that is destined to the shared SMTP address space is
> interpreted as an attempt to relay."
> The address space for the new connector is the shared domain, the address
> space for the default connector remains "*".
>
> --
> Joe


Good article!

Ace

I have solved this problem this way
http://support.microsoft.com/default.aspx/kb/300681

This allows your exchange server to send email to external recipients whith
the same domain. You will be able to email him even though he is not a user
on the server. This way you have no license or security issues.

"Ace Fekay [MCT]" wrote:

> "Joe" <> wrote in message
> news:%...
> > Andrew wrote:
> >> The Exchange server is *not* authoritative for domain.com. I really
> >> don't want this guy to have access to this server. I know I could fix
> >> it by doing so but I shouldn't have to. I'm using this as a learning
> >> experience and at a certain point I'll do whatever it takes to fix it,
> >> but I have good reasons for wanting things to be setup this way.
> >> There *is* a way to do this without giving this guy an exchange
> >> mailbox or giving him server access.
> >
> > Method 1 of KB321721 works. I've been running one of two SBS-based
> > networks sharing an externally-hosted domain for a few years now, and
> > trust me, sending mail from a user in one network definitely does result
> > in its arriving at the external host. I would assume that the other SBS
> > has been configured in the same way, as I gave its admin a link to
> > KB321721 when it was first installed. The first method is more appropriate
> > for most purposes, as it does not require Exchange to be aware of the
> > 'other' users individually.
> >
> > There are two recipient policies in use: the priority 1 policy is the new
> > one, with no filter rules and the shared domain as its primary. The second
> > policy, of 'lowest' priority, is as far as I can recall, unchanged except
> > for one detail. So the filter rules consist of just (mailnickname=*).
> >
> > The one change, and it may be counter-intuitive, is to set the *local* SBS
> > domain name as primary. Exchange remains authoritative for this local
> > domain. Sent email still uses the shared domain name, as the no.1 policy
> > has priority.
> >
> > The additional SMTP Connector is essential. Quote:
> > "If you do not add the SMTP connector with the shared address space, any
> > incoming e-mail that is destined to the shared SMTP address space is
> > interpreted as an attempt to relay."
> > The address space for the new connector is the shared domain, the address
> > space for the default connector remains "*".
> >
> > --
> > Joe
>
>
> Good article!
>
> Ace
>
>
> .
>

"Keith Schmeichel" <> wrote in
message news:7F49E0B7-D288-45D5-887A-...
>I have solved this problem this way
> http://support.microsoft.com/default.aspx/kb/300681
>
> This allows your exchange server to send email to external recipients
> whith
> the same domain. You will be able to email him even though he is not a
> user
> on the server. This way you have no license or security issues.
>
> "Ace Fekay [MCT]" wrote:

I've never been fond of the POP3 connector. I feel it adds unnecessary
complications. However, in many installations, it may be the answer, but I
would look at ways to eliminate it and configure Exchange to be authorative
for the domain name and directly receive mail from the internet.

In any event, the POP3 connector exists, and I'm glad to see there are KB
articles to address certain scenarios. Thanks for posting that article!

Ace

Ace Fekay [MCT] wrote:
> "Joe" <> wrote in message
> news:%...
>
>
> Good article!
>

Thanks. No, I didn't remember the details, I had to remote in and check.

As far as POP3 goes, no argument there, but it's the other half of the
domain which controls IT policy and went the POP3 route. This side
doesn't use the SBS POP3 connector, as I was completely unable to make
that work reliably. Sometimes it would, sometimes it wouldn't.

So there's a bit of alien software in there, nowadays using SSL, and
delivering to Exchange by SMTP. Along with the ability to use
Envelope-To:, this solves pretty well all the customary POP3 problems.

--
Joe

"Joe" <> wrote in message
news:u9BN3J$...
> Ace Fekay [MCT] wrote:
>> "Joe" <> wrote in message
>> news:%...
>>
>>
>> Good article!
>>
>
> Thanks. No, I didn't remember the details, I had to remote in and check.
>
> As far as POP3 goes, no argument there, but it's the other half of the
> domain which controls IT policy and went the POP3 route. This side doesn't
> use the SBS POP3 connector, as I was completely unable to make that work
> reliably. Sometimes it would, sometimes it wouldn't.
>
> So there's a bit of alien software in there, nowadays using SSL, and
> delivering to Exchange by SMTP. Along with the ability to use
> Envelope-To:, this solves pretty well all the customary POP3 problems.
>
> --
> Joe


Glad you came up with a solution. :-)

"Andrew" <> wrote in message
news:4dd1881f-26a4-4abb-a194-...
> Ok, I did what I mentioned might work earlier. I made a user account
> for him but did not create an Exchange mailbox. I then "mail-enabled"
> his account - called "establish an external email address" in the
> wizard. I then modified the "user addresses" policy to include users
> with external email addresses in addition to users with Exchange
> mailboxes.
>
> Then I deleted his .local email address from his user object and
> disabled further recipient policy updating for him. I don't think
> that was necessary but I'm not sure.
>
> With it setup this way, I can send him mail from within the LAN using
> either the GAL or by typing in his smtp address.


The .local is the internal address. Usually we keep that enabled. Creating a
mail-enabled account requires to give the account an external email address.
What email address did you give the account?

Ace