> Le 6 oct. 2015 à 18:35, Viktor Dukhovni <[email protected]> a écrit :
>
> […]
>
> Correct, that's how "<mumble>_maps" features work in Postfix, first
> match wins.
Hello Viktor,
It’s me again.
Not that I want to argue for the purpose of arguing, just perhaps for some kind
of feature request I’m currently unable to correctly formulate.
> […]
>
> Of course, the table layer does not know how the data will be used.
Indeed, I understand the general table lookup algorithm is somehow involved.
On the other hand, we are here explicitly in the context of a
smtpd_sender_login_maps.
I mean, this could be a hint to tweak the algorithm so as to implicitely make
use of a "DUNNO" condition; something like:
for each table
sender address not found
continue
sender address found
owner matches
return OK
else
return DUNNO
return REJECT
Otherwise, the only unambiguous case for having
smtpd_sender_login_maps <map1>, <map2>, […]
is when all of the involved maps are disjoint ones (no common sender
addresses), since ordering of <map1>, <map2>, […] would then have no meaning.
> […]
> That's a property of the sender<->login interface, unauthorized
> logins are denied access.
Yes, ultimately, yes.
But the verdict depends of how the juxtaposition of <map1>, <map2>, […] is to
be interpreted: union, or kind of implicit sequential parsing.
If the latter, this could appear as quite restrictive, even unuseful (unless
the deliberate purpose is to avoid someone to shoot in his own foot).
Not sure I managed to convey what I meant. :-(
Thanks again for your attention,
Axel
