postmap -q return code not very clear when using 'catch all' with smtp_generic_maps

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

postmap -q return code not very clear when using 'catch all' with smtp_generic_maps

Geert Lorang
Hi,

I have to use a relayhost (not managed by me) that only accepts 1 address
from me.

So I configured smtp_generic_maps:

glorang:~# postconf -n |grep -e relayhost -e generic
relayhost = relayhost.be
smtp_generic_maps = hash:/etc/postfix/generic

glorang:~# cat /etc/postfix/generic
@mydomain.be  [hidden email]

Now try to lookup [hidden email]:

glorang:~# postmap -q [hidden email] /etc/postfix/generic
glorang:~# echo $?
1

So no output (no match found) and return value > 0, so you would expect
this can't work, but in fact it just works. I would expect that "postmap
-q [hidden email] /etc/postfix/generic" returns accepted@... in
every case (and return code 0), but it doesn't?

If this is by design maybe add this somehow in the docs...

Regards,
Geert Lorang

Reply | Threaded
Open this post in threaded view
|

Re: postmap -q return code not very clear when using 'catch all' with smtp_generic_maps

Barney Desmond
On 20 February 2010 01:40, Geert Lorang <[hidden email]> wrote:

> glorang:~# cat /etc/postfix/generic
> @mydomain.be  [hidden email]
>
> Now try to lookup [hidden email]:
>
> glorang:~# postmap -q [hidden email] /etc/postfix/generic
> glorang:~# echo $?
> 1
>
> So no output (no match found) and return value > 0, so you would expect
> this can't work, but in fact it just works. I would expect that "postmap
> -q [hidden email] /etc/postfix/generic" returns accepted@... in
> every case (and return code 0), but it doesn't?
>
> If this is by design maybe add this somehow in the docs...

The trick is that postmap is "dumb" - it doesn't know *why* you're
searching, so it doesn't strip the local part. This confuses people
sometimes because using `postmap -q` isn't the same as what Postfix
does, Postfix does a lot more.

The lookup mechanism is entirely generic, it's just key->value
mappings. It doesn't know what an email address is, or what it looks
like. The apparent deficiency here isn't a matter of by-design or
not-by-design, it's just not a consideration.

As you've probably guessed by now, if you think like Postfix, you'll
get what you expect.

glorang:~# postmap -q @mydomain.be /etc/postfix/generic
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: postmap -q return code not very clear when using 'catch all' with smtp_generic_maps

Noel Jones-2
On 2/19/2010 8:49 AM, Barney Desmond wrote:

> On 20 February 2010 01:40, Geert Lorang<[hidden email]>  wrote:
>> glorang:~# cat /etc/postfix/generic
>> @mydomain.be  [hidden email]
>>
>> Now try to lookup [hidden email]:
>>
>> glorang:~# postmap -q [hidden email] /etc/postfix/generic
>> glorang:~# echo $?
>> 1
>>
>> So no output (no match found) and return value>  0, so you would expect
>> this can't work, but in fact it just works. I would expect that "postmap
>> -q [hidden email] /etc/postfix/generic" returns accepted@... in
>> every case (and return code 0), but it doesn't?
>>
>> If this is by design maybe add this somehow in the docs...
>
> The trick is that postmap is "dumb" - it doesn't know *why* you're
> searching, so it doesn't strip the local part. This confuses people
> sometimes because using `postmap -q` isn't the same as what Postfix
> does, Postfix does a lot more.
>
> The lookup mechanism is entirely generic, it's just key->value
> mappings. It doesn't know what an email address is, or what it looks
> like. The apparent deficiency here isn't a matter of by-design or
> not-by-design, it's just not a consideration.
>
> As you've probably guessed by now, if you think like Postfix, you'll
> get what you expect.
>
> glorang:~# postmap -q @mydomain.be /etc/postfix/generic
> [hidden email]

This is documented in the "TABLE SEARCH ORDER" section of each
postfix table-related feature.  See
http://www.postfix.org/generic.5.html
or the other "Table-driven mechanisms" listed in
http://www.postfix.org/postfix-manuals.html

   -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: postmap -q return code not very clear when using 'catch all' with smtp_generic_maps

Geert Lorang
In reply to this post by Barney Desmond
On 19/02/2010 15:49, Barney Desmond wrote:

> On 20 February 2010 01:40, Geert Lorang<[hidden email]>  wrote:
>    
>> glorang:~# cat /etc/postfix/generic
>> @mydomain.be  [hidden email]
>>
>> Now try to lookup [hidden email]:
>>
>> glorang:~# postmap -q [hidden email] /etc/postfix/generic
>> glorang:~# echo $?
>> 1
>>
>> So no output (no match found) and return value>  0, so you would expect
>> this can't work, but in fact it just works. I would expect that "postmap
>> -q [hidden email] /etc/postfix/generic" returns accepted@... in
>> every case (and return code 0), but it doesn't?
>>
>> If this is by design maybe add this somehow in the docs...
>>      
> The trick is that postmap is "dumb" - it doesn't know *why* you're
> searching, so it doesn't strip the local part. This confuses people
> sometimes because using `postmap -q` isn't the same as what Postfix
> does, Postfix does a lot more.
>    

Oh. I thought postmap would do the same as Postfix. Thanks for clarifying!

Geert

Reply | Threaded
Open this post in threaded view
|

Re: postmap -q return code not very clear when using 'catch all' with smtp_generic_maps

mouss-4
Geert Lorang a écrit :

> On 19/02/2010 15:49, Barney Desmond wrote:
>> On 20 February 2010 01:40, Geert Lorang<[hidden email]>  wrote:
>>  
>>> glorang:~# cat /etc/postfix/generic
>>> @mydomain.be  [hidden email]
>>>
>>> Now try to lookup [hidden email]:
>>>
>>> glorang:~# postmap -q [hidden email] /etc/postfix/generic
>>> glorang:~# echo $?
>>> 1
>>>
>>> So no output (no match found) and return value>  0, so you would expect
>>> this can't work, but in fact it just works. I would expect that "postmap
>>> -q [hidden email] /etc/postfix/generic" returns accepted@... in
>>> every case (and return code 0), but it doesn't?
>>>
>>> If this is by design maybe add this somehow in the docs...
>>>      
>> The trick is that postmap is "dumb" - it doesn't know *why* you're
>> searching, so it doesn't strip the local part. This confuses people
>> sometimes because using `postmap -q` isn't the same as what Postfix
>> does, Postfix does a lot more.
>>    
>
> Oh. I thought postmap would do the same as Postfix. Thanks for clarifying!
>

postfix search order is context dependent. postmap doesn't know if you
are trying a check_client_access, check_sender_access, resolving a
virtual alias or looking for a domain class...