Question on how to do a complicated (for me) setup
Kurt Buff
Because of the 8th layer of the OSI stack, I'm contemplating setting
up a fairly complicated system for our 3 offices, which are scattered
across the world - US, UK and AU, the HQ being in our US office.
I'm running Maia Mailguard over Postfix now at the US office, serving
as a gateway to our Exchange server.
Each office has its own Exchange server, and messages are replicated
from the US office via Exchange to the other offices.
But I'd like to distribute Maia Mailguard, with each office having a
local installation, and each office serving as an MX point.
This requires that I separate out recipients by office, and have each
Postfix installation submit only local emails to the local
installation of Maia, and forward mail destined for the other offices
to the other Postfix installations. I intend to do this over our VPN
tunnels, so they come across via our internal network, rather than via
the open Internet, as this would seem to simplify the Maia
Mailguard/SpamAssassin setup, as well as allow us to take advantage of
a fully-meshed network in case a VPN link between one pair of the
offices is down but the others are communicating (it's happened...)
This would seem to further break down into two separate problems, I think:
1) Extracting the email addresses from AD/Exchange and differentiating
users by office, thus allowing me to populate each Postfix instance
with the correct set of recipients
and
2) Setting up all three Postfix instances to route mail correctly
between themselves.
Am I working in the right direction here? Does anyone care to comment,
and give pointers on how to do this?
I've got The Book of Postfix, and am paying it careful attention, but
I'm not finding what I want in there.
Any help would be appreciated.
Kurt
Jason Ledford
While we migrate postfix is going to be the mail hub and route email to
the appropriate servers.
I am exporting records from our mail server and exchange and parsing and
combining on the postfix machine. The postfix install uses transport
maps to tell what email goes where
fakeuser@mydomain smtp:[mailserver_destination_ip]
so postfix checks its transport list and each user has an entry
specifing what server is the final destination.
if you need to see any of my parsing scripts (since they add appropriate
smtp:[XX.XX.XX.XX] entries) let me know and I would be happy to share.
Yours is much more complicated then mine but it seems like the transport
maps is what you would need.
--
Jason Ledford
The Biltmore Company
(828) 225-6127
Victor Duchovni
> 1) Extracting the email addresses from AD/Exchange and differentiating
> users by office, thus allowing me to populate each Postfix instance
> with the correct set of recipients
Your choices are:
- per-recipient nexthop selection. A transport table maps each user
to right regional Exchange front-end. This can in files or via LDAP
to AD if the right attributes can be found there.
us...@example.com relay:[gateway-of-user.example.com]
- virtual alias rewriting, each user gets a mailbox-specific address
that is in a sub-domains that is routed to the right office. The
additional address is not the primary address of the user but is
used for mail routing:
Schema:
cn: First Last
SAMAccountName: flast
mail: first...@example.com
proxyAddresses: SMTP:first...@example.com
proxyAddresses: smtp:fl...@us.exchange.example.com
attribute_x: fl...@us.exchange.example.com
Postfix LDAP virtual(5) table:
... AD server settings ...
query = proxyAddresses=smtp:%s
result_attribute = attribute_x
the hypothetical "attribute_x" stores the mailbox-specific address,
rather than the primary (global) email address of the user. This is
also cloned as an "smtp:..." proxyAddresses value.
Finally, the transport table defines a single nexthop for each of
us.exchange.example.com, au.exchange.example.com, ...
My recommendation is to use virtual rewriting, provided you can cobble
together some management tools to generate the right data in LDAP,
or periodically generated flat-files based on LDAP and perhaps additional
data sources.
--
Viktor.
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majo...@postfix.org?body=unsubscribe%20postfix-users>
If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
MacShane, Tracy
> From: owner-pos...@postfix.org
> [mailto:owner-pos...@postfix.org] On Behalf Of Victor Duchovni
> Sent: Friday, 19 October 2007 10:59 AM
> To: postfi...@postfix.org
> Subject: Re: Question on how to do a complicated (for me) setup
>
> On Thu, Oct 18, 2007 at 05:14:35PM -0700, Kurt Buff wrote:
>
> > 1) Extracting the email addresses from AD/Exchange and
differentiating
> > users by office, thus allowing me to populate each Postfix instance
> > with the correct set of recipients
>
> Your choices are:
>
> - per-recipient nexthop selection. A transport table maps each
user
> to right regional Exchange front-end. This can in files or via
LDAP
> to AD if the right attributes can be found there.
>
> us...@example.com relay:[gateway-of-user.example.com]
>
We use a method similar to this in our infrastructure. We have a script
that extracts the "name", "proxyAddresses" and "msExchHomeServerName"
attributes from each mailbox-enabled user in the AD (asynchronously,
every hour). We use Perl scripts to munge the information into Postfix
maps. We use the the first two attributes to generate our
relay_recipients maps (I'm thinking of using the "mail" attribute for
relay_recipients, and using the proxy_addresses in a virtual_aliases
map, but I'm not sure of any benefits). We use all the attributes to
generate the transport map with entries for each alias that points to
the correct Exchange server in the organisation.
us...@example.com relay:[exch1.example.com]
user....@example.com relay:[exch1.example.com]
us...@example.com relay:[exch2.example.com]
There is also a bit of code that generates transport entries for
mail-enabled groups, since these do not haave a msExchHomeServerName
value.
The other method Victor suggests looks interesting, but the above method
works well for our organisation, since it was relatively simple for a
n00b to implement, and for some reason the powers-that-be have a
religious objection to Exchange edge servers (we have to deliver to each
mailbox server individually), not that we'd actually use them on the
Internet-facing edge - I suppose the rationale is that we have two
gateway servers; we don't need any edge servers just for the Exchange
org.
If you want some info on the Perl and bash scripts we use to generate
the map files, feel free to ask.
Kurt Buff
> On Thu, Oct 18, 2007 at 05:14:35PM -0700, Kurt Buff wrote:
>
> > 1) Extracting the email addresses from AD/Exchange and differentiating
> > users by office, thus allowing me to populate each Postfix instance
> > with the correct set of recipients
>
> Your choices are:
>
> - per-recipient nexthop selection. A transport table maps each user
> to right regional Exchange front-end. This can in files or via LDAP
> to AD if the right attributes can be found there.
>
> us...@example.com relay:[gateway-of-user.example.com]
This looks promising, if some other attribute can be found that
indicates which site the user is linked to.
> - virtual alias rewriting, each user gets a mailbox-specific address
> that is in a sub-domains that is routed to the right office. The
> additional address is not the primary address of the user but is
> used for mail routing:
>
> Schema:
> cn: First Last
> SAMAccountName: flast
> mail: first...@example.com
> proxyAddresses: SMTP:first...@example.com
> proxyAddresses: smtp:fl...@us.exchange.example.com
> attribute_x: fl...@us.exchange.example.com
>
> Postfix LDAP virtual(5) table:
>
> ... AD server settings ...
> query = proxyAddresses=smtp:%s
> result_attribute = attribute_x
>
> the hypothetical "attribute_x" stores the mailbox-specific address,
> rather than the primary (global) email address of the user. This is
> also cloned as an "smtp:..." proxyAddresses value.
This seems to require user provisioning in AD beyond standard setup.
> Finally, the transport table defines a single nexthop for each of
> us.exchange.example.com, au.exchange.example.com, ...
>
> My recommendation is to use virtual rewriting, provided you can cobble
> together some management tools to generate the right data in LDAP,
> or periodically generated flat-files based on LDAP and perhaps additional
> data sources.
I will be investigating this. Thanks!
Kurt
Kurt Buff
That's very nice. I'm definitely asking.
Much appreciated.
Kurt
Julian Cowley
> On 10/18/07, Victor Duchovni <Victor....@morganstanley.com> wrote:
>> Your choices are:
>>
>> - per-recipient nexthop selection. A transport table maps each user
>> to right regional Exchange front-end. This can in files or via LDAP
>> to AD if the right attributes can be found there.
>>
>> us...@example.com relay:[gateway-of-user.example.com]
>
> This looks promising, if some other attribute can be found that
> indicates which site the user is linked to.
We also use a scheme similar to the above using transport_maps. We have a
set of incoming MX mail servers that run SpamAssassin, etc., then relay
the mail onto another set of mailbox servers for delivery. All of the
users are under the same domain name.
While using per-recipient transport_maps looks simple on the face of it,
the details of the mail routing can be tricky. For instance, consider the
case when a user on one mailbox server sends mail to a user on another
mailbox server. Since all of the users are in the same domain, the mail
will be tried to delivered locally on the source mailbox server. I solved
this using mailbox_transport_maps to redirect to the right server (I'm
sure there are other solutions). It gets even more complicated when you
have to consider which servers will do alias expansion and how to avoid
doing it more than once.
>> - virtual alias rewriting, each user gets a mailbox-specific address
>> that is in a sub-domains that is routed to the right office. The
>> additional address is not the primary address of the user but is
>> used for mail routing:
I wish we had gone ahead and used this virtual alias rewriting instead.
The mail routing is cleaner and simpler to understand, and if you combine
it with smtp_generic_maps for outgoing delivery (as mouss points out
occasionally), you can rewrite the address back to the user's original
email address and users won't see the internal domain name used for mail
routing. I haven't used this method yet, but the more I look at it the
better it seems.
--
You can forward truly to your success! You are the capability!
Kurt Buff
> On Fri, 19 Oct 2007, Kurt Buff wrote:
> > On 10/18/07, Victor Duchovni <Victor....@morganstanley.com> wrote:
> >> Your choices are:
> >>
> >> - per-recipient nexthop selection. A transport table maps each user
> >> to right regional Exchange front-end. This can in files or via LDAP
> >> to AD if the right attributes can be found there.
> >>
> >> us...@example.com relay:[gateway-of-user.example.com]
> >
> > This looks promising, if some other attribute can be found that
> > indicates which site the user is linked to.
>
> We also use a scheme similar to the above using transport_maps. We have a
> set of incoming MX mail servers that run SpamAssassin, etc., then relay
> the mail onto another set of mailbox servers for delivery. All of the
> users are under the same domain name.
>
> While using per-recipient transport_maps looks simple on the face of it,
> the details of the mail routing can be tricky. For instance, consider the
> case when a user on one mailbox server sends mail to a user on another
> mailbox server. Since all of the users are in the same domain, the mail
> will be tried to delivered locally on the source mailbox server. I solved
> this using mailbox_transport_maps to redirect to the right server (I'm
> sure there are other solutions). It gets even more complicated when you
> have to consider which servers will do alias expansion and how to avoid
> doing it more than once.
This seems to make sense, at least when the postfix boxes aren't
acting as mail gateways for Exchange server. OTOH, if the users are
interacting primarily with an Exchange infrastructure, mail routing
within that is pretty invisible, due to the AD infrastructure. At
least is in mine, anyway.
> >> - virtual alias rewriting, each user gets a mailbox-specific address
> >> that is in a sub-domains that is routed to the right office. The
> >> additional address is not the primary address of the user but is
> >> used for mail routing:
>
> I wish we had gone ahead and used this virtual alias rewriting instead.
> The mail routing is cleaner and simpler to understand, and if you combine
> it with smtp_generic_maps for outgoing delivery (as mouss points out
> occasionally), you can rewrite the address back to the user's original
> email address and users won't see the internal domain name used for mail
> routing. I haven't used this method yet, but the more I look at it the
> better it seems.
I have to reserve judgment, as I'm not sophisticated enough in my
understanding yet to comment. The first alternative, given Tracy
McShane's explanation of his setup, seems understandable and doable to
me, so I'm leaning heavily towards it.
Kurt