> Le 6 oct. 2015 à 00:12, Viktor Dukhovni a écrit :
>
> […]
>
> That's because you're not showing the full contents of the SQL
> table. If the order matters, the SQL table contains a conflicting
> key.
Hello Viktor,
Thanks for your patience.
Now that you say it, that could well be the problem.
Indeed, augmenting my simplified example, I have something like this:
from_address login
============ =====
[email protected] jdoe
[email protected] info
[email protected] emurphy
# from_address login
[email protected] emurphy
If I correctly interpret your comment, that would mean that once the db query
finds the production:
[email protected] => (info)
postfix would immediately conclude that user emurphy isn’t allowed to send with
sender address "[email protected]", without looking further in the hash table.
Looking back at the documentation: "Tables will be searched in the specified
order until a match is found".
Word "match" is thus to be taken here in the narrowest sense: just a matching
address, not a matching (address, login name) pair. Moreover, when a matching
address is found, the lookup chain is immediately halted with a binary
reject/accept decision.
Hmmm… I guess I should thus create an additional table and make use of a single
db query, based on an UNION, for implementing that idea of "exceptions". But I
don’t really like the idea. Would there be a nicer way?
Anyway, it thus seems that I misinterpreted the documentation.
And that I should have posted all that affair to the users list.
Sorry for the noise,
Axel
