One domain in multiple storage

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

One domain in multiple storage

Dima Veselov
Greetings,

I have a domain, let's say example.com and my virtual users (stored in
LDAP) are located in different cities. I would like to store their mail
closer to them and we have enough servers. My question is - what is the
best practice to configure users to achieve that?

My current configuration is:
DN: uid=john,ou=People,dc=example,dc=com
uid: john
initials: j.smith
mail: [hidden email]

I also have Postfix LDAP aliases pointed to "uid" and "initials" to calculate
virtual user mail and then it find mailbox via "mail"->uid, then the message
is dropped into mailbox with name "john" respectively.

If I would change mail attribute to something like [hidden email]
and I will have transport map for moscow.example.com - will it work?
And more interesting question - would [hidden email] be just a
technical address which will never be seen except technical headers?

--
Sincerely yours,
Dima Veselov
Physics R&D Establishment of Saint-Petersburg University
Reply | Threaded
Open this post in threaded view
|

Re: One domain in multiple storage

Viktor Dukhovni
On Mon, Jun 29, 2020 at 08:15:36PM +0300, Dima Veselov wrote:

> I have a domain, let's say example.com and my virtual users (stored in
> LDAP) are located in different cities. I would like to store their mail
> closer to them and we have enough servers. My question is - what is the
> best practice to configure users to achieve that?
>
> My current configuration is:
> DN: uid=john,ou=People,dc=example,dc=com
> uid: john
> initials: j.smith
> mail: [hidden email]

The "mail" attribute is widely required to hold the *primary* persistent
public email address of the organisational user, and so should not be
tied to a specific point-in-time mailstore location.  Therefore, the
above value of "mail" is the correct form.

> I also have Postfix LDAP aliases pointed to "uid" and "initials" to calculate
> virtual user mail and then it find mailbox via "mail"->uid, then the message
> is dropped into mailbox with name "john" respectively.

The "uid" attribute is too "flat" for use in routing email to
distributed mail stores.  Therefore you need a second
email-address-valued attribute that holds the destination mailbox
address:

    uid: ivan
    initials: i.denisovich
    mail: [hidden email]
    maildrop: [hidden email]

At any site other than moscow, the "moscow.example.com" domain would be
remote, and email to the user will be forwarded via SMTP.  However, at
the "moscow.example.com" site, the domain would be considered "local",
and local aliases(5) would rewrite the address to "ivan" (possibly
with an appropriate @domain suffix), and deliver to the user's mailbox.

--
Sincerely yours,
Dima Veselov
Physics R&D Establishment of Saint-Petersburg University
Reply | Threaded
Open this post in threaded view
|

Re: One domain in multiple storage

Dima Veselov
On 29.06.2020 21:22, Viktor Dukhovni wrote:

>> I have a domain, let's say example.com and my virtual users (stored in
>> LDAP) are located in different cities. I would like to store their mail
>> closer to them and we have enough servers. My question is - what is the
>> best practice to configure users to achieve that?
>>
>> mail: [hidden email]
>
> The "mail" attribute is widely required to hold the *primary* persistent
> public email address of the organisational user, and so should not be
> tied to a specific point-in-time mailstore location.  Therefore, the
> above value of "mail" is the correct form.

Yes, that sounds a real concern, thank you.

>> I also have Postfix LDAP aliases pointed to "uid" and "initials" to calculate
>> virtual user mail and then it find mailbox via "mail"->uid, then the message
>> is dropped into mailbox with name "john" respectively.
>
> The "uid" attribute is too "flat" for use in routing email to
> distributed mail stores.  Therefore you need a second
> email-address-valued attribute that holds the destination mailbox
> address:
>
>      uid: ivan
>      initials: i.denisovich
>      mail: [hidden email]
>      maildrop: [hidden email]
>
> At any site other than moscow, the "moscow.example.com" domain would be
> remote, and email to the user will be forwarded via SMTP.  However, at
> the "moscow.example.com" site, the domain would be considered "local",
> and local aliases(5) would rewrite the address to "ivan" (possibly
> with an appropriate @domain suffix), and deliver to the user's mailbox.

That is what I am wondering most about. Do we really have to rewrite
anything? Or you just mean aliases(5) will find proper mailbox to drop
mail in?

--
Dima Veselov
Physics R&D Establishment of Saint-Petersburg University
Reply | Threaded
Open this post in threaded view
|

Re: One domain in multiple storage

Viktor Dukhovni
On Tue, Jun 30, 2020 at 12:05:27AM +0300, Dima Veselov wrote:

> > The "uid" attribute is too "flat" for use in routing email to
> > distributed mail stores.  Therefore you need a second
> > email-address-valued attribute that holds the destination mailbox
> > address:
> >
> >      uid: ivan
> >      initials: i.denisovich
> >      mail: [hidden email]
> >      maildrop: [hidden email]
> >
> > At any site other than moscow, the "moscow.example.com" domain would be
> > remote, and email to the user will be forwarded via SMTP.  However, at
> > the "moscow.example.com" site, the domain would be considered "local",
> > and local aliases(5) would rewrite the address to "ivan" (possibly
> > with an appropriate @domain suffix), and deliver to the user's mailbox.
>
> That is what I am wondering most about. Do we really have to rewrite
> anything? Or you just mean aliases(5) will find proper mailbox to drop
> mail in?

Yes, rewrites are the best way to do this.  Aliases(5) is not the right
mechanism, because it only applies to local(8) delivery, which you
should avoid except perhaps at the actual destination mailstore.  And
ever there, you're better off with LMTP or another virtual mailbox
delivery mechanism.

Use local(8) *ONLY* for mail to pipes and ":include:" lists with
owner aliases.

Ordinary address -> address rewriting should be done via virtual(5)
not aliases(5).

What I am describing above is best-practice.  It is of course possible
to kludge something together with aliases(5), ... but I strongly
recommend against it.

--
    Viktor.