Re: Concept of SMTP-connectors
From: Rudy Steyaert (rudy_steyaert_at_hotmail.com)
Date: 11/29/04
- Next message: Alan: "Sharing SMTP address space after adding an E2K server to a 5.5 site?"
- Previous message: Mark Arnold [MVP]: "Re: What would you do?"
- In reply to: Rich Matheisen [MVP]: "Re: Concept of SMTP-connectors"
- Next in thread: Rich Matheisen [MVP]: "Re: Concept of SMTP-connectors"
- Reply: Rich Matheisen [MVP]: "Re: Concept of SMTP-connectors"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 29 Nov 2004 09:15:52 +0100
Thanks Rich I think I get it now.
One final question to conclude (and because I'm greedy :O))
1) Suppose I have following connectors each with their own user-restrictions
...
Connector A - address-space * - shedule 8am to 10am
Connector B - address-space * - shedule 8pm to 10pm
Then ...
Message at 9 am - if user is allowed by connector A - otherwise fail
Message at 9 pm - if user is allowed by connector B - otherwise fail
Message at 11 am will always fail - no matter who sends it.
2) No connectors ... all messages will pass
Is that correct ?
"Rich Matheisen [MVP]" <richnews@rmcons.com.NOSPAM.COM> wrote in message
news:89ekq0taq1h6bl57sampili1jni66h9e5a@4ax.com...
> "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: Alan: "Sharing SMTP address space after adding an E2K server to a 5.5 site?"
- Previous message: Mark Arnold [MVP]: "Re: What would you do?"
- In reply to: Rich Matheisen [MVP]: "Re: Concept of SMTP-connectors"
- Next in thread: Rich Matheisen [MVP]: "Re: Concept of SMTP-connectors"
- Reply: Rich Matheisen [MVP]: "Re: Concept of SMTP-connectors"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
