On Fri, Mar 07, 2014 at 08:40:29AM +0000, John Cox wrote:
> Hi
>
> >> Is there any chance we could have a rule of the form
> >>
> >> accept for any virtual no-bounce <vmap> relay
> >>
> >> such that if the virtual lookup fails then processing continues to the
> >> next line rather than generating a bounce message. This would
> >> simplify the generation of forwarding tables.
> >>
> >
> >the "processing continues" is not going to happen because it leads to
> >issues:
> >
> > accept for any virtual no-bounce <vmap> relay
> > accept for any relay
> >
> >and suddenly instead of failing you match another rule that was not
> >meant to be matched, and the mail gets relayed instead of being
> >rejected.
>
> Actually that is exactly what I want to happen - I really don't see
> the issue. I can cope with rules that fall through (or don't if
> marked quick) in pf.conf and I can cope with it here.
>
Well you don't see the issue for your use-case, the issue is that
for pretty much every other use-case this is not what's desired.
We discussed shortly a new kind of rules with eric@ yesterday, it
is not too hard to implement so maybe we'll go that path. It is
inspired by PF:
match for any virtual <vmap> tag MATCHED
accept tagged MATCHED for any virtual <vmap> relay
accept for any relay
this way you would only match the relay rule if the match rule has
properly set the tag.
we're not going to implement this for the time being, it still has
to be discussed and the semantics clearly defined, but that's
something that is likely to happen in the future.
> >> Maybe
> >>
> >> accept for recipient <vmap> virtual <vmap> relay
> >>
> >> would do, where the 2nd entry in the vmap is ignored would do?
> >>
> >> What I'm trying to avoid is having to list users that I want forwarded
> >> twice: once in a filter and once in a vmap, as that always leads to
> >> mismatches and confusion. The solution would (of course) be to have
> >> script that auto-generates the appropriate files but I'd much rather
> >> avoid that level of complexity if I can.
> >>
> >
> >
> >technically this can be made to work if using a backend that can
> >share a table between different kinds of lookups (sql, ldap, ...)
> >some people are using the same table for credentials and userbase
> >using the sqlite backend for instance
>
> I'd really prefer not to have to have an entire database setup just to
> run my MTA
>
Yup, understood, but at the moment there's no other solution if you don't
want to duplicate your table contents
--
Gilles Chehade
https://www.poolp.org @poolpOrg
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
