> On 2015-03-13, at 09:15, Gilles Chehade <[email protected]> wrote: > > 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.
Aa, I see. Didn't think of that. Obvious :) > > > 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. > > Okay, I actually had a hard time figuring out the difference between alias/virtual/recipient but this explains it more clearly. So basically "recipient" is the same as virtual with the exception that the rule wont match if the recipients isn't in the given table. Thanks for the explanation! Take care, Eric > > -- > 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]
signature.asc
Description: Message signed with OpenPGP using GPGMail
