>
> Ok, it seems that now I understand what happened here. Uhh, how that
> ugly, that is! :( -- the only words comes to mind...

        Yes, the combined sendmail/postfix style domain is a hack.
Still it does solve a definite problem: unknown users are bounced, while
still allowing some addresses to be qualified with the virtual domain.
There was also a requirement to do this with just a single table (LDAP)
mapping known users to a valid "maildrop".

        Post virtual rewrite rejected addresses cannot bounce with a 5xx
response in "smtpd", because "smtpd" cannot base it's accept/reject
decision on the (recursive 1 -> many) output of virtual rewrites. The
virtual rewrites happen in cleanup after the recipients are accepted.
On the other hand, recipient rejection based on the cleaned up address
is much more robust, as it interacts well with cases where there are
many different ways of representing a single mailbox.

>
> So, the real solution here is just to consult $transport_maps for
> virtual domains too, right? And probably allow "mixed-style"
> virtual maps that have OK on right side (and REJECT, [45]xx etc),
> to be usable in conjunction with check_recipient_access.
> Interesting point... Well, can all the above be made using
> check_recipient_access? I.e. instead of having *virtual* domains
> (either postfix or sendmail style), list all valid addresses in
> every domain in check_recipient_access map with OK result, and
> have catch-all entries for whole domain with "554 User unknown"
> result. And have usual *address* mapping via virtual_maps when
> needed and have appropriate transport_maps. Ohoh, that will be
> difficult for large addresslist, esp. if stored in ldap (only
> way here is to "cache" data in appropriate form in local hash:
> or whatether files -- again, somewhat ugly.)
>

        Transport_maps is not appropriate as a source of virtual
domains. Virtual domains are "owned" by the administrator of the
server, domains in the transport table simply use a non-default
transport (e.g. UUCP). The real issue is that some configurations are
complex and the multiple rewrite mechanisms (access, canonical,
masquerade, virtual, alias, virtual_mailbox) though each simple in its
own right, provide enough rope to do most of the useful fancy tricks of
sendmail.cf. Trying to shoe-horn everything into a smaller number of
tables, will make things simpler, at the cost of reducing flexibility.

        Right now Postfix is much simpler than sendmail for typical
installs, yet still flexible enough for more complex installs without
becoming as complex as sendmail. I would argue that the goal should be
not so much to remove maps, or add a macro language, but rather to
provide new mechanisms to exploit maps that are backwards compatible
(hence do not force any configurations to become more complex) and add
flexibility without overly high implementation costs.

        The fact that the routing and access control in Postfix is
entirely table based is its primary strength. We can build on this
strength by using current and future tables in cleaner and/or more
sophisticated ways.

        So how would one allow "smtpd" to reject recipients in a way
that is more directly tied to the contents of the virtual map and the
implied set of Postfix-style virtual domains? Here is one possible
strategy (can anyone think of others?):

        1. Subject to an explicit domain filter (which by default
matches the logic in smtpd_checks.c), fully resolve addresses in domains
that match the filter (via canonical, masquerade, virtual, transport,
alias, ...) during the SMTP transaction.

        2. If the resulting expanded recipient list contains only
invalid recipients (error transport, Postfix-style virtual domains or
non-existent local users) reject the recipient. Otherwise accept the
recipient.

        This is quite complex to implement, but results in consistent
semantics, where the administrator does not need to manually match up
the various maps with the "smtpd" access control strategy.
Implementation issues aside for the moment, does anyone else buy the
notion that access and routing should be essentially one and the same,
that bouncing a recipient can in most cases be simply a matter of
rewriting the address to something invalid, and that the routing maps
(canonical, masquerade (not really a map), ...) can subsume some of the
functionality of recipient_restrictions, thereby avoiding the need to
keep the two in sync.

-- 
	Viktor.
-
To unsubscribe, send mail to majordomopostfix.org with content
(not subject): unsubscribe postfix-users

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]