Re: SMTP mailflow problem

"Andrew" <> wrote in message
news:7b29f7cc-54d0-432a-9b74-...
>I deleted his account and made a new one with an Exchange mailbox and
> it works fine. Having him use OWA would be a good solution but he
> uses Outlook Express on his laptop to get mail from the hosting
> provider. Since there is no pop server here the only way I could
> provide him with mail using Exchange is running Outlook over a VPN.
> There should be a simple solution to this - I'm just not well versed
> enough in Exchange it seems.
>
> Anybody care to take another stab at it?


I was trying to say that earlier, that is to create a mailbox-enabled
account for him.

You can use Outlook Anywhere (also known as RPC/HTTP). See if the following
help.

How can I configure RPC over HTTP/S on Exchange 2003 (single server
scenario)?
http://www.petri.co.il/configure_rpc...gle_server.htm

How can I test RPC over HTTP/S on Exchange 2003?
http://www.petri.co.il/testing_rpc_o...connection.htm

Troubleshooting RPC over HTTP Communications
http://technet.microsoft.com/en-us/l...EXCHG.65).aspx

Ace

Andrew wrote:
> I deleted his account and made a new one with an Exchange mailbox and
> it works fine. Having him use OWA would be a good solution but he
> uses Outlook Express on his laptop to get mail from the hosting
> provider. Since there is no pop server here the only way I could
> provide him with mail using Exchange is running Outlook over a VPN.
> There should be a simple solution to this - I'm just not well versed
> enough in Exchange it seems.
>
> Anybody care to take another stab at it?

"Method 1 of KB321721 works", as I said a few days ago. You said in your
original post, and again here, that he collected mail from the external
host, and he would obviously need to continue to do that without an SBS
account.

Should you later wish to give another non-employee an email account on
your domain, no further adjustments to SBS or Exchange would need to be
made.

--
Joe

"Andrew" <> wrote in message
news:d99dd2d7-93fe-4b61-bcac-...
> Thanks again for all the help.
>
> I did exactly what Method 1 says to do. Then at Step 4 I create the
> SMTP connector, click forward to smart host, put the external domain's
> SMTP server hostname in as the smart host, add the local bridgehead
> server, then add the external domain name as the address space and
> check "allow relay to these domains".
>
> When I do that and monitor the queues, all the SMTP mail gets routed
> through the new connector - that is, also mail that is addressed to
> other domains besides our external domain.
>
> It's getting stuck in that queue also. I check the SMTP logs and the
> external SMTP server (network solutions) is giving me a relaying
> denied response. I guess I can fix that by going to Outbound Security
> and setting it to basic authentication once I get the routing figured
> out but why is ALL the internet mail getting sent through the new
> connector?
>
> Shouldn't it only get messages for the namespace it's configured for?
>
> The Default SMTP connector has a lower cost and is set to send mail
> using DNS. That works fine when there isn't another connector. When
> I make the new connector I give it a higher cost - shouldn't that make
> Exchange try to use the default connector first to send mail and then
> when it can't relay to the external domain then shouldn't it check the
> connector with the next highest cost and see that this one allows
> relaying to that domain?
>


Well, kind of. If an address matches the address space on more than one
connector, such as if one is configured with a * and the other is configured
with a specific address space, such as domain.com, and the email recipient
is domain.com, it will choose the domain.com connector first no matter the
cost, unless there's a restriction such as msg size limit or shedule.

Therefore, if it is not routing it properly, it appears something is not
configured properly. I remember you mentioning it, but just to make sure, I
assume you've already removed your public domain name from your Default
Recipient Policy, then added it back in based on Method 1, Steps 1 and 2 in
KB321721, as well as relaying allowed in the shared address space connector
properties.

FYI, as for message routing, the following is a copy/paste from th MOC
1572C, Exchange 2000 courseware that explains mail routing criteria, which
applies for all Exchange versions.

===========
Selection Criteria
Exchange 2000 takes all possible routes for a message to a remote routing
group or address space from the link state table and then removes all routes
from the identified routes list that do not meet the following conditions:


The message must not exceed any limitations of the connectors that make
up each route, such as message size or priority.


All connectors that make up the route to the remote destination must be in
the UP state.


If there are two address spaces that can deliver a message, the closest
match
is chosen.

From the routes that meet the above requirements, Exchange 2000 selects the
route with the lowest combined cost to the destination routing group or
address
space. Exchange 2000 then forwards the message to the next hop in that
route.
The next hop may be either a connector’s bridgehead server in the routing
group or, if the connector is on the local computer running Exchange 2000, a
bridgehead server on the other end of the local connector. A server at each
hop
along the route engages in the routing and selection process until a message
reaches its destination.
====

Ace

Andrew wrote:
> Thanks again for all the help.
>
> I did exactly what Method 1 says to do. Then at Step 4 I create the
> SMTP connector, click forward to smart host, put the external domain's
> SMTP server hostname in as the smart host, add the local bridgehead
> server, then add the external domain name as the address space and
> check "allow relay to these domains".
>
> When I do that and monitor the queues, all the SMTP mail gets routed
> through the new connector - that is, also mail that is addressed to
> other domains besides our external domain.
>
> It's getting stuck in that queue also. I check the SMTP logs and the
> external SMTP server (network solutions) is giving me a relaying
> denied response. I guess I can fix that by going to Outbound Security
> and setting it to basic authentication once I get the routing figured
> out but why is ALL the internet mail getting sent through the new
> connector?
>
> Shouldn't it only get messages for the namespace it's configured for?
>
> The Default SMTP connector has a lower cost and is set to send mail
> using DNS. That works fine when there isn't another connector. When
> I make the new connector I give it a higher cost - shouldn't that make
> Exchange try to use the default connector first to send mail and then
> when it can't relay to the external domain then shouldn't it check the
> connector with the next highest cost and see that this one allows
> relaying to that domain?
>
No, it's the other way around, you do want mail to try the other
connectors first and the default last.

The very first thing Exchange (or any mail server) will try to do is to
match its own mailboxes, as local delivery is always preferable to
external delivery. If it doesn't find a match, you want it to check SMTP
connectors until it does find a match, with the default '*' tried last.
That way, the recipients without Exchange mailboxes on the the public
email domain, for which Exchange is not authoritative, will get sent out.

Something you could try is to switch the new connector to DNS, as you
have relaying trouble, that way the receiving server will not see your
connection as relaying but of straight email sending. There's not really
much difference as far as sending email over the Internet goes, the
instruction to use a smarthost on the new connector is a hangover from
the more general use of connectors to route between a number of internal
mail servers, minimising DNS traffic. Unless, of course, the receiving
server will not accept your mail for other reasons...

--
Joe

"Andrew" <> wrote in message
news:595a3e22-8ee7-4d58-ac8b-...
> Many thanks. For the Nth time it worked temporarily and then started
> bouncing mail with relaying not allowed.
>
> I will try to reconfigure another connector this evening and try to
> use DNS instead of smarthost and hopefully that will do it. The extra
> connector makes sense.....I just can't get it to actually work.
>
> Joe - are you saying that I should make the new SMTP connector have a
> lower cost than the default connector? *Something* was making the
> internet mail flow through the new connector instead of the default -
> I'm still not sure what.


If a connector has an address space that matches the recipient address in an
email, the routing engine will choose the connector with that address space,
no matter what the cost is, unless there are other restrictions such as size
or schedule.

Apparently something was misconfigured. You can use Message tracking to
follow the flow.

However, I feel that you are trying to make numerous Exchange configuration
system changes to avoid creating a single mail-enabled user account, which I
am not raelly sure if it is truly worth all the changes in my book. But of
course that is my personal and professional opinion, but more importantly,
it is totally up to you in which direction you want to take this.

Ace

Andrew wrote:
> Many thanks. For the Nth time it worked temporarily and then started
> bouncing mail with relaying not allowed.
>
> I will try to reconfigure another connector this evening and try to
> use DNS instead of smarthost and hopefully that will do it. The extra
> connector makes sense.....I just can't get it to actually work.
>
> Joe - are you saying that I should make the new SMTP connector have a
> lower cost than the default connector? *Something* was making the
> internet mail flow through the new connector instead of the default -
> I'm still not sure what.

No, I don't bother altering costs.

I'm not managing to explain this very well.

Any mail that actually uses the default connector *must* flow through
the others first, to check whether it matches their criteria. Default is
what's left when all the other connectors have refused to take the mail
after having been given the chance. If the mail went to the Default
connector first, it would all queue or go out that way and the
additional connectors would never be tried. Further connectors don't get
tried once the match criteria for one connector are satisfied, even if
the recipient then refuses the mail. That's a different issue.

Did you not say that the mail for this particular domain was getting
stuck in the queue because the receiving server would not accept it?
What about all the other mail, is it falling through the new connector
and being sent by the original Default connector? If so, what you have
is not a routing problem but a mail acceptance problem.

I did actually have this problem long ago, having set up Exchange
according to the KB article, when the external host started demanding
authentication. There was some initial trouble so I removed the
smarthost reference and switched the new connector to DNS until the
problem got sorted out. That way, as far as the receiving server is
concerned, you're not trying to relay, you're sending to a recipient for
whom it owns a mailbox. That never needs authentication.

--
Joe

"Andrew" <> wrote in message
news:d4dd1be3-c646-41d4-b26f-...
> Yeah that's exactly what I just did and it appears (again) to be
> working fine. Actually I left the smarthost reference in the Default
> SMTP virtual server but I set the authentication back to anonymous - I
> don't think it hurts anything to have that there..that is, I don't
> think it will try to forward anything. Then I created the new SMTP
> connector, left the cost at 1, set the address space, checked allow
> relay to these domains (which I think is there to keep Exchange from
> interpreting it as a relay - doesn't mean it's going to relay it to
> the external smtp server), added the local bridgehead server, and left
> it set to use DNS. Then I restarted the Exchange Routing Service and
> SMTP.
>
> I sent two test messages and it worked fine - I can tell it's using
> the connector because it creates a queue for it that sticks around for
> a while. I can see the message getting accepted in the SMTP log. I
> just hope it stays working this time.
>
> Thanks again for all your responses. This definitely helped my
> understanding of Exchange routing.


Let's hope it stays active!

Ace

"Andrew" <> wrote in message
news:c1af9923-34ad-47da-aec5-...
>I checked it this morning and the queue for that connector had 60
> messages in it - all addressed to various people. I had to delete it
> again so that the messages would route through the default connector.
> I still don't have a clue why it works at first and then starts
> failing again. It worked perfectly last night. It would send the
> message faster than I could see it in the queue.
>
> As soon as I deleted the connector all the mail went out fine through
> the default connector. Weird, huh?


Yep. Hard to tell what can be going on without an actual hands on look. But
then again, you know what I would do to fix it.

:-)

Ace

"Andrew" <> wrote in message
news:11a2bfd2-63ff-4465-9cd3-...
>> Yep. Hard to tell what can be going on without an actual hands on look.
>> But
>> then again, you know what I would do to fix it.
>>
>> :-)
>>
>> Ace
>
> I know, i know....but believe me I have good reasons for trying to do
> it this way - some of which I can't mention here. The configuration
> is not a complicated one really - it's a regular SBS2003 install - the
> only difference being the shared address space. Everyone has a .local
> and a .com address and there's the one extra recipient policy because
> of that but otherwise it's normal. I'm not having any problems with
> the POP3 connector or receiving mail.


I understand you're probably under political pressure. No problem that you
can't mention specifics. The shared address space is what's going on.

Another thought - I would imagine to just create a contact inAD to the guy's
Yahoo or Hotmail private account, and have him configure his private account
to forward it to his company email address, which will go to your provider,
so this way you don't have to worry about the shared address space
configuration.

Ace