Charlie Watts wrote:
[]
> I'm very interested in Michael's non-recursive virtual map idea/patch,
> because I have a semi-lame hack right now to avoid delayed bounces.

Another misunderstanding in this and related threads. Virtual_maps
are NOT "recursive" (I choosed wrong word at a first place, maybe
this is cause of confusion. "Recursive" should be something like
"matching all sub-domains by default", that is). Or, in other words
virtual_maps are recursive as them expanded recursively, i.e. result
of one lookup tried again until found. But if you list virt.dom in
virtual_maps, any.virt.dom will NOT be matched. In fact, there are
some issues addressed here (look to other messages in this thread,
I summarized the proposed solutions). Concerning virtual_domains
et al, I said about splitting virtual_maps to two parameters, one
lists *domains* only that are postfix-style virtual domains, and
second acts as "global aliases", listing only *addresses*, to have
finer control over things in there. "Non-recursive" (or, better
speaking, "not matching sub-domains") is an issue with $relay_domains
and all smtpd UCE restrictions: check_{client,helo,sender,recipient}_access.
Most irritating one is relay_domains, and we was encountered already
a big trouble with that (our mailsystem stopped working while I manually
deleted deferred queue).

> Michael - I keep intending to try your patch and idea, but haven't gotten
> around to it.

Ah, thanks -- at least one another person pays some attention to all
this. While you (or me) have some misunderstanding... :)

> Wietse, being able to do non-recursive lookups in virtual-maps would be a
> nice feature. My users are not in the password database; I am using
> courier-imap's userdb. I have a transport map sending mail for
> maildrop.my_domain to the maildrop delivery program.

So you must list this domain in relay_domains and in transport_maps,
nothing to do with virtual, yes?

>
> In order to bounce mail for non-existant local users, I'm doing this in a
> virtual map for each user:
>
> real_userfrontier.net real_usermaildrop.frontier.net
>
> (maildrop.frontier.net does not have a "magic" virtual map entry; It only
> has the transport entry. This is a kluge to break out of the recursion.)

You can't break recursion here -- not in official postfix, and not
with patches/suggestions/proposals made to related issues so far.
And here is an answer to my question above -- no.

> This means that I've had to put my accounts into userdb as both
> frontier.net and as maildrop.frontier.net. It also means that bounces
> from the maildrop delivery agent are generated with
> "maildrop.frontier.net".
>
> I wish that I could do this, in a non-recursive map, instead:
>
> real_userfrontier.net real_userfrontier.net

Aha, here it is. The issue addressed here is that qmgr wan't look
virtual domain in transport maps. Yes, this is at least somewhat
non-logical and unexpected, and this IS addressed here.

> This way I could mark recipient addresses as OK without having to
> (visibly) re-write them. I'm looking at using the per-user patch to do
> something like this, meanwhile:
>
> real_userfrontier.net OK
>
> And just list -all- acceptable recipient E-mail addresses. I don't want to
> do this until I get moved to LDAP, though.
>
> I notice more and more folks asking about courier and cyrus and other mail
> storage systems. This, or something similar, would be a nice feature for
> enterprise/ISP users.

Yes.

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

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