Evaluation of maps in local or virtual address classes

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

Evaluation of maps in local or virtual address classes

Patrick Ben Koetter
Maps in $relay_recipient_maps are evaluated as lists - only the LHS is
examined to determine if a recipient is listed and therefore a valid
recipient.

Does the same apply for local_recipient_maps, virtual_alias_maps and
virtual_mailbox_maps when Postfix tries to determine if a given recipient is
a valid recipient?

I'm asking because I am trying to figure out what I need to do to accept
messages for local/virtual mumble domains and have them sent off to a LMTP
server afterwards.

Sending them off to a LMTP server is a transport map job:

[hidden email]       lmtp:localhost

But what do I do to tell Postfix [hidden email] is a valid recipient?

Can I reuse my transport map and add it to local_recipient_maps,
virtual_alias_maps or virtual_mailbox_maps as required?

p@rick

--
The Book of Postfix
<http://www.postfix-book.com>
saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>
Reply | Threaded
Open this post in threaded view
|

Re: Evaluation of maps in local or virtual address classes

Victor Duchovni
On Sun, Jan 04, 2009 at 09:31:42PM +0100, Patrick Ben Koetter wrote:

> Maps in $relay_recipient_maps are evaluated as lists - only the LHS is
> examined to determine if a recipient is listed and therefore a valid
> recipient.

Only used in smtpd(8) where no rewriting takes place, just address
validation, so nothing useful can be done with the RHS.

> Does the same apply for local_recipient_maps,

Ditto.

> virtual_alias_maps

Well, in smtpd(8) the RHS is ignored, and the table is used across all
address classes. In cleanup(8), this is used for rewriting of all
recipient addresses and the RHS is clearly not ignored.

> and virtual_mailbox_maps

in smtpd(8) used only for address validation, in virtual(8) used to
select the right mailbox, but there in some cases virtual mailbox
delivery is handled by other delivery agents, and in that case the
table's RHS is not used.

> I'm asking because I am trying to figure out what I need to do to accept
> messages for local/virtual mumble domains and have them sent off to a LMTP
> server afterwards.

Only virtual(5) RHS values will be used.

If you rewrite from an external virtual alias domain to the LMTP server's
internal domain, you don't any tables other than virtual_alias_maps,
and the external domain is typically a virtual alias domain.

If the LMTP delivery domain is the same as the external domain, use
virtual_mailbox_maps with RHS values that are not used by Postfix.


> Sending them off to a LMTP server is a transport map job:
>
> [hidden email]       lmtp:localhost

The correct syntax (if the default port is OK) is:

    [hidden email]       lmtp:inet:localhost

Why per-recipient transport lookups? Often better to rewrite to a domain
where the entire domain is handled by lmtp(8).

> But what do I do to tell Postfix [hidden email] is a valid recipient?

Use virtual_mailbox_maps.

> Can I reuse my transport map and add it to local_recipient_maps,
> virtual_alias_maps or virtual_mailbox_maps as required?

Don't add $transport_maps to virtual_mailbox_maps, but if per-recipient
transport entries are the right solution, use a common table that you
add to both:

        lmtp_user_transport_maps = <maptype>:<mapname>
        transport_maps = ... $lmtp_user_transport_maps
        virtual_mailbox_maps = ... $lmtp_user_transport_maps

Provided the same users will never reach virtual(8), the fact that
the RHS is transport-valued rather than mailbox-path-valued is not
a problem.

--
        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:[hidden email]?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.
Reply | Threaded
Open this post in threaded view
|

Re: Evaluation of maps in local or virtual address classes

Patrick Ben Koetter
* Victor Duchovni <[hidden email]>:

...

> > Sending them off to a LMTP server is a transport map job:
> >
> > [hidden email]       lmtp:localhost
>
> The correct syntax (if the default port is OK) is:
>
>     [hidden email]       lmtp:inet:localhost


Maybe its just me, but I had not looked for this notation in lmtp(8), but in
transport(8), where I was looking for transport examples. May I suggest an
example of this is added to transport(5)?


> Why per-recipient transport lookups? Often better to rewrite to a domain
> where the entire domain is handled by lmtp(8).

Agreed. In my case I am after a mixed domain - some mails go to typical
mailboxes and some will be sent of to a LMTP server.


> > But what do I do to tell Postfix [hidden email] is a valid recipient?
>
> Use virtual_mailbox_maps.
>
> > Can I reuse my transport map and add it to local_recipient_maps,
> > virtual_alias_maps or virtual_mailbox_maps as required?
>
> Don't add $transport_maps to virtual_mailbox_maps, but if per-recipient
> transport entries are the right solution, use a common table that you
> add to both:
>
> lmtp_user_transport_maps = <maptype>:<mapname>
> transport_maps = ... $lmtp_user_transport_maps
> virtual_mailbox_maps = ... $lmtp_user_transport_maps

That's what I had had on my mind. Thanks.


> Provided the same users will never reach virtual(8), the fact that
> the RHS is transport-valued rather than mailbox-path-valued is not
> a problem.

That's exactly what I had hoped to hear.


p@rick


--
The Book of Postfix
<http://www.postfix-book.com>
saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>
Reply | Threaded
Open this post in threaded view
|

Re: Evaluation of maps in local or virtual address classes

Victor Duchovni
On Mon, Jan 05, 2009 at 12:42:10AM +0100, Patrick Ben Koetter wrote:

> * Victor Duchovni <[hidden email]>:
>
> ...
>
> > > Sending them off to a LMTP server is a transport map job:
> > >
> > > [hidden email]       lmtp:localhost
> >
> > The correct syntax (if the default port is OK) is:
> >
> >     [hidden email]       lmtp:inet:localhost
>
>
> Maybe its just me, but I had not looked for this notation in lmtp(8), but in
> transport(8), where I was looking for transport examples. May I suggest an
> example of this is added to transport(5)?

No, the syntax of the nextop is transport dependent, each delivery agent
documents the nexthop syntax it supports. The right place to find LMTP
nexthop syntax is in the lmtp(8) manpage.

> > Why per-recipient transport lookups? Often better to rewrite to a domain
> > where the entire domain is handled by lmtp(8).
>
> Agreed. In my case I am after a mixed domain - some mails go to typical
> mailboxes and some will be sent of to a LMTP server.

What is the address class of the "typical" mailboxes? If this is "local",
you need to extend local_recipient_maps, not virtual_mailbox_maps.

> > Use virtual_mailbox_maps.
> >
> > > Can I reuse my transport map and add it to local_recipient_maps,
> > > virtual_alias_maps or virtual_mailbox_maps as required?
> >
> > Don't add $transport_maps to virtual_mailbox_maps, but if per-recipient
> > transport entries are the right solution, use a common table that you
> > add to both:
> >
> > lmtp_user_transport_maps = <maptype>:<mapname>
> > transport_maps = ... $lmtp_user_transport_maps
> > virtual_mailbox_maps = ... $lmtp_user_transport_maps
>
> That's what I had had on my mind. Thanks.

Provided the other mailboxes are also virtual.

--
        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:[hidden email]?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.
Reply | Threaded
Open this post in threaded view
|

per recipient transport [Was: Evaluation of maps in local or virtual address classes]

mouss-4
In reply to this post by Victor Duchovni
Victor Duchovni a écrit :
> [snip]
> Why per-recipient transport lookups? Often better to rewrite to a domain
> where the entire domain is handled by lmtp(8).
>

is there a benefit in avoiding per recipient transports? or said
otherwise: is there a way to tell postfix to only lookup domains?


>> But what do I do to tell Postfix [hidden email] is a valid recipient?
>
> Use virtual_mailbox_maps.
>
>> Can I reuse my transport map and add it to local_recipient_maps,
>> virtual_alias_maps or virtual_mailbox_maps as required?
>
> Don't add $transport_maps to virtual_mailbox_maps, but if per-recipient
> transport entries are the right solution, use a common table that you
> add to both:
>
> lmtp_user_transport_maps = <maptype>:<mapname>
> transport_maps = ... $lmtp_user_transport_maps
> virtual_mailbox_maps = ... $lmtp_user_transport_maps
>
> Provided the same users will never reach virtual(8), the fact that
> the RHS is transport-valued rather than mailbox-path-valued is not
> a problem.
>

Reply | Threaded
Open this post in threaded view
|

Re: per recipient transport [Was: Evaluation of maps in local or virtual address classes]

Victor Duchovni
On Mon, Jan 05, 2009 at 03:31:52AM +0100, mouss wrote:

> Victor Duchovni a ?crit :
> > [snip]
> > Why per-recipient transport lookups? Often better to rewrite to a domain
> > where the entire domain is handled by lmtp(8).
> >
>
> is there a benefit in avoiding per recipient transports?

Simplicity, also reduces temptation to do LDAP or SQL transport lookups,
which are problemactic under load, because qmgr latency cannot be
ammortized via concurrency (there is only one queue manager).

> or said otherwise: is there a way to tell postfix to only lookup domains?

No.

--
        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:[hidden email]?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.
Reply | Threaded
Open this post in threaded view
|

Re: per recipient transport [Was: Evaluation of maps in local or virtual address classes]

mouss-4
Victor Duchovni a écrit :

> On Mon, Jan 05, 2009 at 03:31:52AM +0100, mouss wrote:
>
>> Victor Duchovni a ?crit :
>>> [snip]
>>> Why per-recipient transport lookups? Often better to rewrite to a domain
>>> where the entire domain is handled by lmtp(8).
>>>
>> is there a benefit in avoiding per recipient transports?
>
> Simplicity, also reduces temptation to do LDAP or SQL transport lookups,

unfortunately, this is exactly what I want to do: put everything in *sql
to ease mgmt. of course, it is possible to dump the sql data, but I am
talking about a web UI where I'd prefer the web app no have any
privileges. I guess a cron (to dump data) is the best I can do if I
don't want to write an "update" daemon?

> which are problemactic under load, because qmgr latency cannot be
> ammortized via concurrency (there is only one queue manager).
>
>> or said otherwise: is there a way to tell postfix to only lookup domains?
>
> No.
>

Reply | Threaded
Open this post in threaded view
|

Re: per recipient transport [Was: Evaluation of maps in local or virtual address classes]

Victor Duchovni
On Mon, Jan 05, 2009 at 03:49:55AM +0100, mouss wrote:

> Victor Duchovni a ?crit :
> > On Mon, Jan 05, 2009 at 03:31:52AM +0100, mouss wrote:
> >
> >> Victor Duchovni a ?crit :
> >>> [snip]
> >>> Why per-recipient transport lookups? Often better to rewrite to a domain
> >>> where the entire domain is handled by lmtp(8).
> >>>
> >> is there a benefit in avoiding per recipient transports?
> >
> > Simplicity, also reduces temptation to do LDAP or SQL transport lookups,
>
> unfortunately, this is exactly what I want to do: put everything in *sql
> to ease mgmt. of course, it is possible to dump the sql data, but I am
> talking about a web UI where I'd prefer the web app no have any
> privileges. I guess a cron (to dump data) is the best I can do if I
> don't want to write an "update" daemon?

There is nothing wrong with *SQL or LDAP for virtual alias lookups,
these happen in parallel in cleanup(8). This is why I encourage per-user
routing via rewriting (legacy Sendmail-style) with coarse routing via
fixed domain mappings in transport(5).

The (ideally small) transport should not use *SQL unless you can ensure
that lookup latency is very low under a wide range of conditions. Just
observe that each recipient address is subject to multiple transport
lookups (various truncated keys), and the queue manager needs to
resolve (via trivial-rewrite) each and every message recipient to
a transport:nexthop.

--
        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:[hidden email]?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.
Reply | Threaded
Open this post in threaded view
|

Re: per recipient transport [Was: Evaluation of maps in local or virtual address classes]

Wietse Venema
In reply to this post by mouss-4
mouss:

> Victor Duchovni a ?crit :
> > On Mon, Jan 05, 2009 at 03:31:52AM +0100, mouss wrote:
> >
> >> Victor Duchovni a ?crit :
> >>> [snip]
> >>> Why per-recipient transport lookups? Often better to rewrite to a domain
> >>> where the entire domain is handled by lmtp(8).
> >>>
> >> is there a benefit in avoiding per recipient transports?
> >
> > Simplicity, also reduces temptation to do LDAP or SQL transport lookups,
>
> unfortunately, this is exactly what I want to do: put everything in *sql
> to ease mgmt. of course, it is possible to dump the sql data, but I am
> talking about a web UI where I'd prefer the web app no have any
> privileges. I guess a cron (to dump data) is the best I can do if I
> don't want to write an "update" daemon?

High-latency maps such as LDAP and SQL are OK for smtpd or cleanup
(because these processes run in parallel) but not trivial-rewrite
(because there is only one qmgr).  This applies not only to transport
maps but also to maps that define address classes.

        Wietse