Re: Concept of SMTP-connectors
From: Rich Matheisen [MVP] (richnews_at_rmcons.com.NOSPAM.COM)
Date: 11/28/04
- Next message: Doug: "Mailbox move hangs while "saving changes to the dir" in Exch Wiz."
- Previous message: KIWI: "Re: IMF Objects and Counters"
- In reply to: Rudy Steyaert: "Re: Concept of SMTP-connectors"
- Next in thread: Rudy Steyaert: "Re: Concept of SMTP-connectors"
- Reply: Rudy Steyaert: "Re: Concept of SMTP-connectors"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 28 Nov 2004 16:14:55 -0500
"Rudy Steyaert" <rudy_steyaert@hotmail.com> wrote:
>Thanks for your comments, they are greatly appreciated (since 1997 in my
>first 5.5 days if I remember well).
I think you're right. :(
>"Rich Matheisen [MVP]" <richnews@rmcons.com.NOSPAM.COM> wrote in message
>> If you have just ONE virtual server. :) Otherwise they are ALL
>> available to use for outbound traffic. The use of the SMTP Connector,
>> in this situation, would be to make sure that outbound messages are
>> sent to just ONE (if that's all the outbound IP addresses you have) of
>> the virtual servers no matter from which server the message
>> originated.
>
>Upon a message arriving at the server, which mechanism decides to select a
>connector instead of going over the virtual server directly?
Let's assume that you don't mean a message arriving at the server from
a SMTP client. If you _did_ mean a SMTP client then you need to
distinguish between a message addressed to one of the domain for which
you have a Recipient Policy and one for which you do not.
>Why should it
>make this 'detour' after all ?
As I said, if you have only ONE virtual server then there's no need
for a SMTP connector (although my preference is to have one no matter
how many virtual servers are present),
>It can go right over the virtual server like
>it does when no connectors exist.
There's no "detour". The SMTP Connector is just a control mechanism,
it doesn't really "touch" the message at all. Think of the old IMS and
then remove the things that controlled access, delivery options, and
address space values (the _outbound_ controls). Put those
*administrative* things into a SMTP Connector and leave all the
management of fqdn, access, relay control and connectivity in the
virtual server (the _inbound_ controls).
>If a connector where mandatory there
>would be not doubt, now there are ambiguous ways, if you know what I mean.
Well, then, think of the SMTP Connector as mandatory and you'll remove
the ambiguity. :)
>The default behaviour of the virtual server if no connector exists, I think
>that's what confuses me the most.
If you don;t require any control over outbound mail then there's no
need for SMTP connectors.
With just one virtual server the need for a SMTP connector isn't
imperative. But, if you ran a larger organization, you'd quickly
discover the need to manage the connectivity OUT of the organization.
Not all the servers would be able to deliver mail outside the compnay,
although each of them has an active virtual server. If you didn't use
a SMTP connector the mail would remain on the local server which would
continuously try to deliver the mail directly. That attempt would, of
course, fail because the firewall rules would prevent all but a few of
the machines for estblishing connections on port 25 outside the
company.
To control this, you'd have at least one SMTP Connector that had an
address space of "*" and selected the virtual servers that *could*
send messages out of the company as "Local bridgehead servers".
>>>But as soon as a connector is configured mail
>>>always flows over the connector. Is this right ?
>>
>> Well, sort of. The message "flow" in and out of a virtual server. The
>> Connector just directs outbound messages in a particular, or
>> selective, way.
>
>So a message arrives at the server. Some mechanism (is it the MTA?) looks
>for a suitable connector (based upon which criteria ?). If there is none,
>the message goes directly over the virtual server ? But, as soon as there
>is at least one connector, the message is evaluated first by the rules that
>exist for them.
>>
>>>Is suppose this is domain bound?
>>
>> It can be, but I don't know what you mean by that. :)
>
>Domain-bound... I mean, if I host for instance domain A and domain B, can I
>have a separate connector for domain A and another for domain B.
You can if you restrict the access to the connector. But it's
controlled by the access list, not by the domain.
>But
>perhaps I am all wrong about that ? This is obviously a property of the
>virtual server and not of the connector, or is it for both ? Pfff... I'd
>better restudy the theory :o)
You need to separate the "inbound" and "outbound" mail flow to get a
better idea about what you're trying to accomplish. The virtual server
is used for both, but the connector is used only to manage outbound
mail.
>>>I mean, if I have several domains to
>>>serve, can I have a connector for one domain and no connector for the
>>>other
>>>domain (using the virtual server as a default).
>>
>> You might be able to accomplish that by placing access control lists
>> on the connectors. But the connector directs OUTBOUND messages. Using
>> the "Address Space" wouldn't be appropriate. I'm not sure, with only
>> one virtual server, what you'd accomplish by trying to do that,
>> either. Remember, the connector deals with outbound messages and I'm
>> pretty sure you'd want to be able to send to ALL domains. That would
>> mean you'd have the same address space on each connector (probably a
>> "*").
>
>If it's not the address-space, where do connectors differentiate from each
>other ?
If you discount the address space, the "Delivery Retrictions" would
control which connector was used -- but that's by user (or group), not
by domain.
>Are they all evaluated one by one until a suitable is found ?
Yes. The functioning is similar to the way the IMS was selected by the
MTA -- except the MTA doesn't do the selecting any more.
>And, of
>course if none is found, the message is rejected (but that leaves me with
>the situation where there is none at all).
That's no different to the way it worked in Exchange 5.5 -- except you
wouldn't have a message bouncing between servers until it died whil
looking for a suitable IMS. :)
-- Rich Matheisen MCSE+I, Exchange MVP MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm
- Next message: Doug: "Mailbox move hangs while "saving changes to the dir" in Exch Wiz."
- Previous message: KIWI: "Re: IMF Objects and Counters"
- In reply to: Rudy Steyaert: "Re: Concept of SMTP-connectors"
- Next in thread: Rudy Steyaert: "Re: Concept of SMTP-connectors"
- Reply: Rudy Steyaert: "Re: Concept of SMTP-connectors"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
