Forwarding to internal servers

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Forwarding to internal servers

Jim Nalepa - US

Hello,

 

I am looking for assistance with the following scenario.

 

We have two mail locations that we would like to route mail based on an ldap attribute. 

 

The LDAP attribute that is being queried is the internal email address of the user:

  [hidden email]

  [hidden email]

 

Is it possible to rewrite the users email address to the internal address and use MX

of the rewritten address to direct the mail?  If so what postfix function should be used?

 

Example:

[hidden email] -> mx.example.com --Forwarded--> mail.server1.example.com

[hidden email] -> mx.example.com --Forwarded--> mail.server2.example.com

 

Thanks in advance,

Jim

Reply | Threaded
Open this post in threaded view
|

Re: Forwarding to internal servers

jeffrey j donovan
<base href="x-msg://371/">
On Nov 27, 2012, at 10:13 AM, Jim Nalepa - US <[hidden email]> wrote:

Hello,
 
I am looking for assistance with the following scenario.
 
We have two mail locations that we would like to route mail based on an ldap attribute. 
 
The LDAP attribute that is being queried is the internal email address of the user:
 
Is it possible to rewrite the users email address to the internal address and use MX
of the rewritten address to direct the mail?  If so what postfix function should be used?
 
Example:
 
Thanks in advance,
Jim

Hi jim,

check out transport maps


from my experience. I moved away from ldap(network lookups) for transport  and switched to a db(local file), each relay has the same transport list. My system was quicker with delivery and lookups.


-j
Reply | Threaded
Open this post in threaded view
|

RE: Forwarding to internal servers

Jim Nalepa - US
<base href="x-msg://371/">

Jeffrey,

 

Thanks for the prompt response.

We are heavily invested in ldap (used centrally throughout network) and would hate to replicate, and maintain two instances of the db.

 

Any other thoughts?

 

Thanks,

Jim

From: jeffrey j donovan [mailto:[hidden email]]
Sent: Tuesday, November 27, 2012 10:29 AM
To: Jim Nalepa - US
Cc: [hidden email]
Subject: Re: Forwarding to internal servers

 

 

On Nov 27, 2012, at 10:13 AM, Jim Nalepa - US <[hidden email]> wrote:



Hello,

 

I am looking for assistance with the following scenario.

 

We have two mail locations that we would like to route mail based on an ldap attribute. 

 

The LDAP attribute that is being queried is the internal email address of the user:

 

Is it possible to rewrite the users email address to the internal address and use MX

of the rewritten address to direct the mail?  If so what postfix function should be used?

 

Example:

 

Thanks in advance,

Jim

 

Hi jim,

 

check out transport maps

 

 

from my experience. I moved away from ldap(network lookups) for transport  and switched to a db(local file), each relay has the same transport list. My system was quicker with delivery and lookups.

 

 

-j

Reply | Threaded
Open this post in threaded view
|

Re: Forwarding to internal servers

Viktor Dukhovni
On Tue, Nov 27, 2012 at 03:49:42PM +0000, Jim Nalepa - US wrote:

> Thanks for the prompt response.
> We are heavily invested in ldap (used centrally throughout network)
> and would hate to replicate, and maintain two instances of the db.
>
> Any other thoughts?

The standard advice is:

        - Use LDAP for virtual_alias_maps and other rewriting done by
          cleanup(8)

        - Use indexed files for transport_maps and other lookups made
          by trivial-rewrite(8).

If you want different users in the same domain to be delivered to
different mailbox servers and want to follow this advice, you use
virtual_alias_maps (via LDAP is fine) to rewrite:

        mail: [hidden email]
        mailalternateaddress: [hidden email]
        mailalternateaddress: [hidden email]
        maildrop: [hidden email]

any one of a user's email addresses to the unique address of the
underlying mailbox:

        domain = example.com
        query_filter = (|(mail=%s)(mailalternateaddress=%s))
        result_attribute = maildrop

fancy features for handling LDAP lists are described in LDAP_README.html
and ldap_table(5).

The transport table is then largely unnecessary, but in some cases
you want a common first hop that depends on the mailbox hostname,
in which case something like:

        imap1.example.com smtp:mailhub.example.com
        ...

can be handled via small indexed tables on each MTA.

--
        Viktor.