On Thu, Mar 12, 2015 at 10:41:05AM +0100, Eric Ripa wrote:
> An update on this thread in case anyone is interested or search for the same.
>
> I never found any resolution to let OpenSMTPD rely on getpwnam (and thus
> ypldap).
>
> I traced the rules and lookup further and my only suspicion is that it's
> ypldap causing the odd behavior with getpwnam. In the end I took another
> approach and created a virtual user table mapping to the system users
> (fetched by ypldap) + added all aliases in the same virtual user map. Now I
> get proper Invalid Recipient replies and nothing stuck in the queue. I build
> the virtual user table with a simple Python LDAP script.
>
> This solution actually is better in the end as it allows my client to have
> more fine-grained control over mail accounts, aliases and group-mail aliases.
>
> -------
>
> I do however have a question left:
>
> In my trials I briefly had the configuration as follows:
> accept tagged for domain <domains> alias <aliases> deliver to lmtp
> "/var/dovecot/lmtp"
> accept tagged for domain <domains> virtual <vusers> deliver to lmtp
> "/var/dovecot/lmtp"
>
> But everything ended up in the first rule, and even though the alias map
> didn't contain any of the recipients it never went to the virtual user rule
> and all mails stayed in "Temporary lookup failure".
>
> I solved it by combining my alias and virtual user maps, but if I understand
> it correctly the above should have worked.. or? Maybe it's the ypldap ghost..
>
This is expected, and here's a short explanation why.
Imagine the following ruleset:
accept from local for domain poolp.org alias <a> deliver to mbox
accept from local for any relay
Now imagine that address [email protected] exists and not [email protected].
When mailing [email protected], we match the first rule since it is meant
to handle domain poolp.org and we find the user, good.
When mailing [email protected], we match the first rule for the same reason
however this time we don't find the user. What would happen if we jumped
to the next rule and tried to evaluate it ?
accept from local for any relay
We match it and the recipient we were supposed to reject is now relayed,
causing a loop while at it. It's not possible to cascade, it can't work.
It needs to be able to find an unambiguous rule that can return a reject
and abort the ruleset evaluation.
With that in mind, let's see how you could achieve what you want ;-)
The key is the "unambiguous" word I used above.
Your problem is that once a rule is matched, it is that rule which will
take the decision. In your case, you have two rules that match the same
destination domains and since recipients are not taken into account, it
means you never get a chance to match the second rule. The first one is
going to reject recipients it doesn't know.
What you need to do is prevent the first rule from being matched at all
for addresses which are meant to match the second rule. You should have
a look at "recipient" keyword:
accept from local for domain <a> recipient <r> [...]
accept from local for domain <a> [...]
This would only match first rule when the recipient is part of the <r>
table so that other recipients match the second rule.
--
Gilles Chehade
https://www.poolp.org @poolpOrg
--
You received this mail because you are subscribed to [email protected]
To unsubscribe, send a mail to: [email protected]
