dovecot - Jul 2010 - OT dovecot w/postfix, mysql , postfix does unnecessary lookups

I know this unnecessary lookups question is really a postfix one, but
I'm curious if anyone else sees the behaviour of
postfix continuing looking up users after it clearly have got its answer
that it is  "not a local domain" response.


(this msg is an extract from what I sent to WV some time ago, with him
showing absolutely no interest, I got bored tonight so thought I'd throw
it on this list since the question remains valid today)

     30 Query       SELECT 1 FROM virtual_domains WHERE
name='example.net' AND active ='1'
     31 Query       SELECT destination FROM view_aliases WHERE
email='someuser at example.net'


Should that not have ended its lookups at Q30 and not gone on to ask Q31
which it now knows is not local?


Secondly,  it seems to do "double lookups" of destination and email
before it gets to dovecots deliver, has anyone else ran a log on mysql
and seen same? I'm trying to work out why, since it already has its
answer by Q54 and Q55, it is doing Q56 and Q57, which seem pointless...

     54 Connect    
     54 Query       SELECT destination FROM view_aliases WHERE
email='laura at example.com'
     55 Connect     
     55 Query       SELECT email FROM view_users WHERE
email='laura at example.com'
     
     56 Connect     
     56 Query       SELECT destination FROM view_aliases WHERE
email='laura at example.com'
     57 Connect     
     57 Query       SELECT email FROM view_users WHERE
email='laura at example.com'


So, it to me appears postifx does more work then it needs too since it
already knows the answer, I consider this a flaw in postfix, yet perhaps
I am the only one seeing it hence why WV couldnt give a shit.

just curious if anyone has noted same or not....

Noel Butler wrote:
> (this msg is an extract from what I sent to WV some time ago, with him
> showing absolutely no interest, I got bored tonight so thought I'd
throw
> it on this list since the question remains valid today)
> 
>      30 Query       SELECT 1 FROM virtual_domains WHERE
> name='example.net' AND active ='1'
>      31 Query       SELECT destination FROM view_aliases WHERE
> email='someuser at example.net'
> 
> 
> Should that not have ended its lookups at Q30 and not gone on to ask Q31
> which it now knows is not local?
The above is just a couple of SQL statements.

How are you performing the recipient validation?

Postconf -n output and some logs of a complete transaction showing the
'problem' would be instructive...

-- 

Best regards,

Charles

Just an update for archives in case anyone else comes across it whilst
debugging, they can just shrug it off as a postfix anomaly, 
I only had two replies to this post, but both of them are also seeing
the same as I do, so nothing to worry about until postfix one decade
accepts this as a bug :)


On Fri, 2010-07-30 at 21:50 +1000, Noel Butler wrote:
> I know this unnecessary lookups question is really a postfix one, but
> I'm curious if anyone else sees the behaviour of
> postfix continuing looking up users after it clearly have got its answer
> that it is  "not a local domain" response.
> 
> 
> (this msg is an extract from what I sent to WV some time ago, with him
> showing absolutely no interest, I got bored tonight so thought I'd
throw
> it on this list since the question remains valid today)
> 
>      30 Query       SELECT 1 FROM virtual_domains WHERE
> name='example.net' AND active ='1'
>      31 Query       SELECT destination FROM view_aliases WHERE
> email='someuser at example.net'
> 
> 
> Should that not have ended its lookups at Q30 and not gone on to ask Q31
> which it now knows is not local?
> 
> 
> Secondly,  it seems to do "double lookups" of destination and
email
> before it gets to dovecots deliver, has anyone else ran a log on mysql
> and seen same? I'm trying to work out why, since it already has its
> answer by Q54 and Q55, it is doing Q56 and Q57, which seem pointless...
> 
>      54 Connect    
>      54 Query       SELECT destination FROM view_aliases WHERE
> email='laura at example.com'
>      55 Connect     
>      55 Query       SELECT email FROM view_users WHERE
> email='laura at example.com'
>      
>      56 Connect     
>      56 Query       SELECT destination FROM view_aliases WHERE
> email='laura at example.com'
>      57 Connect     
>      57 Query       SELECT email FROM view_users WHERE
> email='laura at example.com'
> 
> 
> So, it to me appears postifx does more work then it needs too since it
> already knows the answer, I consider this a flaw in postfix, yet perhaps
> I am the only one seeing it hence why WV couldnt give a shit.
> 
> just curious if anyone has noted same or not....
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stock_smiley-1.png
Type: image/png
Size: 873 bytes
Desc: not available
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20100804/5438745e/attachment-0002.png>

On Aug 3, 2010, at 6:53 PM, Noel Butler wrote:
> Just an update for archives in case anyone else comes across it whilst
> debugging, they can just shrug it off as a postfix anomaly, 
> I only had two replies to this post, but both of them are also seeing
> the same as I do, so nothing to worry about until postfix one decade
> accepts this as a bug :)
> 
> 
> On Fri, 2010-07-30 at 21:50 +1000, Noel Butler wrote:
> 
>> I know this unnecessary lookups question is really a postfix one, but
>> I'm curious if anyone else sees the behaviour of
>> postfix continuing looking up users after it clearly have got its
answer
>> that it is  "not a local domain" response.
>> 
>> 
>> (this msg is an extract from what I sent to WV some time ago, with him
>> showing absolutely no interest, I got bored tonight so thought I'd
throw
>> it on this list since the question remains valid today)
>> 
>>     30 Query       SELECT 1 FROM virtual_domains WHERE
>> name='example.net' AND active ='1'
>>     31 Query       SELECT destination FROM view_aliases WHERE
>> email='someuser at example.net'
>> 
>> 
>> Should that not have ended its lookups at Q30 and not gone on to ask
Q31
>> which it now knows is not local?
>> 
>> 
>> Secondly,  it seems to do "double lookups" of destination and
email
>> before it gets to dovecots deliver, has anyone else ran a log on mysql
>> and seen same? I'm trying to work out why, since it already has its
>> answer by Q54 and Q55, it is doing Q56 and Q57, which seem pointless...
>> 
>>     54 Connect    
>>     54 Query       SELECT destination FROM view_aliases WHERE
>> email='laura at example.com'
>>     55 Connect     
>>     55 Query       SELECT email FROM view_users WHERE
>> email='laura at example.com'
>> 
>>     56 Connect     
>>     56 Query       SELECT destination FROM view_aliases WHERE
>> email='laura at example.com'
>>     57 Connect     
>>     57 Query       SELECT email FROM view_users WHERE
>> email='laura at example.com'
>> 
>> 
>> So, it to me appears postifx does more work then it needs too since it
>> already knows the answer, I consider this a flaw in postfix, yet
perhaps
>> I am the only one seeing it hence why WV couldnt give a shit.
>> 
>> just curious if anyone has noted same or not....
>> 

how are you viewing the connections from tcpdump or netstat ?

On 2010-08-03 6:53 PM, Noel Butler <noel.butler at ausics.net>
wrote:
> Just an update for archives in case anyone else comes across it whilst
> debugging, they can just shrug it off as a postfix anomaly, 
> I only had two replies to this post, but both of them are also seeing
> the same as I do, so nothing to worry about until postfix one decade
> accepts this as a bug :)
Wietse takes bugs very seriously. He does however require actual proof,
in the form of hard evidence, before he will take a bug report seriously.

I'll wager it is not a bug, but more likely a misunderstanding on your
part as to how postfix works, and postfix is doing precisely what you
are telling it to do.

Since postfix does not do SQL lookups directly, you need to execute the
commands that postfix will use to access your maps, provide *full*
config details, and finally full log examples of 'the anomalous
behavior' - otherwise it is just noise.

-- 

Best regards,

Charles