On Tue, Oct 06, 2015 at 06:22:59PM +0200, Axel Luttgens wrote:
> > 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.
>
> Now that you say it, that could well be the problem.
> Indeed, augmenting my simplified example, I have something like this:
>
> from_address login
> ============ =====
> jonh....@example.com jdoe
> i...@example.com info
> ed.mur...@example.com emurphy
>
> # from_address login
> i...@example.com emurphy
>
> If I correctly interpret your comment, that would mean that once the db query
> finds the production:
>
> i...@example.com => (info)
>
> postfix would immediately conclude that user emurphy isn�t allowed to send
> with sender address "i...@example.com", without looking further in the
> hash table.
Correct, that's how "<mumble>_maps" features work in Postfix, first
match wins.
> 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.
Of course, the table layer does not know how the data will be used.
> Moreover, when a matching address is found, the lookup chain is immediately
> halted
> with a binary reject/accept decision.
That's a property of the sender<->login interface, unauthorized
logins are denied access.
--
Viktor.
