> Le 8 oct. 2015 à 01:48, Viktor Dukhovni a écrit :
>
> […]
> There no such thing as a "DUNNO" condition. That's an access
> keyword in access(5) maps that short-circuits searches for
> less-specific keys. There is no generally applicable DUNNO.
> […]
> The table in question is not an access table, it returns a list of
> logins. There could a login named "DUNNO". Furthermore, you're
> forgetting the outer loop with the full address, and then various
> partial address forms like the address without its extension, …
Bang!
I should avoid to send anything when being too tired to even being able to
assess what I just wrote…
Once again, sorry for the noise.
As far as my glorious algorithm scheme is concerned, I meant something like
this:
for each map
sender address not found
continue
sender address found
owner matches
return (corresponding owners)
else
continue
return ()
This would be a tweak of the current algorithm, which seems to be similar to:
for each map
sender address not found
continue
sender address found
return (corresponding owners)
return ()
Of course, with the adaptations required for the full then partial matches.
> […]
>
> There's no "ambiguity" table order matters, first match wins. The
> first table overrides the second table, ... Except that partial
> keys can make that complicated, if the second table can match
> partial keys for which only the full key appears in the first table.
Precisely, my "feature request" would help to make such a configuration line
smtpd_sender_login_maps <map1>, <map2>, […]
unambiguously interpretable: an union of the involved maps.
But I guess all of this stems from a very specific problem I was trying to
solve.
Kind of egoistic concern. ;-)
Best regards,
Axel
