Re: mysql query suppressed?
email builder: 2) it's not intuitive to me that the query I have given to postifx is conditionally executed. And THAT is precisely what the documentation says. Wietse
Re: mysql query suppressed?
2) it's not intuitive to me that the query I have given to postifx is conditionally executed. And THAT is precisely what the documentation says. And THAT is merely what I was asking to have confirmation of (not sure why that is so difficult)... because it's not intuitive, and also because this fact is IMO buried too deep in the documentation. If you can set up queries but they might get ignored based on a naive scan of the query text, I think it might be good to make a more prominent note of this. But thanks anyway
Re: mysql query suppressed?
On Wed, Aug 08, 2012 at 12:07:09PM -0700, email builder wrote: 2) it's not intuitive to me that the query I have given to postifx is conditionally executed. And THAT is precisely what the documentation says. And THAT is merely what I was asking to have confirmation of (not sure why that is so difficult)... It is difficult only because you prefer to believe fanciful interpretations a plainly stated behaviour. The query is suppressed, it never happens, insert Monty Python parrot skit. The documentation is concise, but not (at least in this case) ambiguous. because it's not intuitive, It is intuititive if you understand that Postfix makes multiple lookups for a single key, some of which contain only the user or the domain part. The low-level table driver (LDAP, MySQL, ...) does not know which part of the address it is handed, or even whether the lookup key is an address at all. Thus, when a lookup key does not resembe an full email address, it is not possible to determine whether the key has a domain part or not. Instead of making meaningless queries that may produce incorrect results, Postfix suppresses the query. and also because this fact is IMO buried too deep in the documentation. It is documented in the paragraph that describes the %d syntax. Don't use %d in queries without reading what it does. There is surely no better place to describe %d semantics than in the associated paragraph of the query syntax definitions. -- Viktor.
Re: mysql query suppressed?
2) it's not intuitive to me that the query I have given to postifx is conditionally executed. And THAT is precisely what the documentation says. And THAT is merely what I was asking to have confirmation of (not sure why that is so difficult)... It is difficult only because you prefer to believe fanciful interpretations a plainly stated behaviour. NO. If you read my inquiry, I did read the documentation and understand it correctly. I merely had some lingering doubts and was asking for simple confirmation. Everyone's steadfast refusal to confirm (nothing more than yes would have been necessary), instead responding with hostile responses like yours is alienating, especially to a polite inquiry. Is this how you treat people face to face as well? Everyone has their own interpretations of what they read, based on varying degrees of expertise. If you refuse to hear the impression others get from reading the documentation, then maybe it will never improve. It is intuititive if you understand that Postfix makes multiple lookups for a single key, some of which contain only the user or the domain part. The low-level table driver (LDAP, MySQL, ...) does not know which part of the address it is handed, or even whether the lookup key is an address at all. Thus, when a lookup key does not resembe an full email address, it is not possible to determine whether the key has a domain part or not. Instead of making meaningless queries that may produce incorrect results, Postfix suppresses the query. If Postfix knows what's going on, then it may be able to communicate the situation through to the backend. I don't follow you entirely, since my response to this would be that if the query needs to know what part of the address the key is, it should be able to learn this by examining %u or %d to be empty/NULL when the key doesn't have @ in it. Of course, the query would only need to do this if it had advanced requirements. But I don't have the level of intimate knowledge of the workings and only speak as a user, so I guess you can dismiss my input with a Monty Python wisecrack. and also because this fact is IMO buried too deep in the documentation. It is documented in the paragraph that describes the %d syntax. Don't use %d in queries without reading what it does. There is surely no better place to describe %d semantics than in the associated paragraph of the query syntax definitions. I am not suggesting that text be removed, only that it is surprising to learn that the query is ignored in some cases and this might be a good thing to note elsewhere in addition. But it doesn't really sound like you want feedback anyway. shrug
Re: mysql query suppressed?
email builder: I read in http://www.postfix.org/mysql_table.5.html for the %d substitution in the query if the lookup is not a full email address with domain, the entire query is not even executed? Is this right? If postfix does not work as documented, please post a bug report. Wietse
Re: mysql query suppressed?
- Original Message - From: Wietse Venema wie...@porcupine.org To: Postfix users postfix-users@postfix.org Cc: Sent: Tuesday, August 7, 2012 8:26 AM Subject: Re: mysql query suppressed? email builder: I read in http://www.postfix.org/mysql_table.5.html for the %d substitution in the query if the lookup is not a full email address with domain, the entire query is not even executed? Is this right? If postfix does not work as documented, please post a bug report. I'm really not sure - what I'm asking for is clarification of the documentation. To me, it says if you use %d in your query and the lookup key is not in the form of u...@domain.tld (ie local part only), then the query is suppressed. Does that mean I can't do a query that tests if %d is NULL and return a result accordingly? My initial tests seem to indicate that my suspicion is correct, but I'm not expert enough so I was asking for help in this matter.
Re: mysql query suppressed?
email builder: it says if you use %d in your query and the lookup key is not in the form of u...@domain.tld (ie local part only), then the query is suppressed.? What is not clear about that? Wietse
Re: mysql query suppressed?
email builder: it says if you use %d in your query and the lookup key is not in the form of u...@domain.tld (ie local part only), then the query is suppressed.? What is not clear about that? 1) the word suppressed is only slightly unclear. I just want to make sure I understand the usage of this language (not executed in my words) 2) it's not intuitive to me that the query I have given to postifx is conditionally executed. Generally, I would expect it to use the query in all cases, letting me have control over what gets selected under any circumstance. I guess what you're telling me is it's a known limitation of Postfix that I cannot have a query that tests if %d is NULL. Unless there's a good reason to do it that way, I'd encourage this to change in the next release I have nicely asked if this wording is the same as if you put %d in your query, the query will not get executed when the lookup key only has the local part. Is it that hard to confirm my question with YES??
Re: mysql query suppressed?
On Tue, Aug 07, 2012 at 09:17:48PM -0700, email builder wrote: email builder: it says if you use %d in your query and the lookup key is not in the form of u...@domain.tld (ie local part only), then the query is suppressed.? What is not clear about that? 1) the word suppressed is only slightly unclear. I just want to make sure I understand the usage of this language (not executed in my words) As documented the query is suppressed, in other-words there is no query. There is really no reasonable alternative interpretation. It would be rather strange to run the query and then just throw away any results. The point of the query suppression is to make domain constraints work, only keys that look like addresses have a meaningful domain part. Otherwise, we can't distinguish between a bare domain and a bare user name. This feature is not going to change. Over and out. -- Viktor.
Re: mysql query suppressed?
This feature is not going to change. Over and out. I merely asked (politely I think) for confirmation that I understood the documentation correctly. Why do you have to use such unfriendly language in your responses?
mysql query suppressed?
I read in http://www.postfix.org/mysql_table.5.html for the %d substitution in the query if the lookup is not a full email address with domain, the entire query is not even executed? Is this right? If that's the case, you can't do complex queries like: select IF('%d' = 'example.com', . Even though a query like that might account for the case where %d is null, postfix won't execute it?
Re: mysql query suppressed?
Am 06.08.2012 22:54, schrieb email builder: I read in http://www.postfix.org/mysql_table.5.html for the %d substitution in the query if the lookup is not a full email address with domain, the entire query is not even executed? Is this right? If that's the case, you can't do complex queries like: select IF('%d' = 'example.com', . Even though a query like that might account for the case where %d is null, postfix won't execute it? how do you come to that conclusion? below a grep of a since 2009 working config [root@srv-rhsoft:~]$ cat /etc/postfix/mysql* | grep '%d' query= select deliver_to from dbmail_aliases where alias='%u@%d' and (select count(*) from dbmail_aliases where alias='%u@%d' and (round(deliver_to)0))=0; query= select target from dbma_rewrite_domains where source='%d' and ((select count(*) from dbmail_aliases where alias=(select concat('%u', (select target from dbma_rewrite_domains where source='%d' limit 1)) from dbma_rewrite_domains limit 1))0 or (select count(*) from dbmail_aliases where alias='%u@' limit 1)0) limit 1; query= select userid from dbmail_users where ((select count(*) from dbma_mta where mydestination='%d') 0 or (select count(*) from dbma_sender_relay where email='%s') 0) and user_idnr3; query= select filter from dbma_spamfilter where domain='%d'; query= select transport from dbma_transports where mydestination='%s' or mydestination='%d' order by transport desc limit 1; signature.asc Description: OpenPGP digital signature
Re: mysql query suppressed?
Am 06.08.2012 22:54, schrieb email builder: I read in http://www.postfix.org/mysql_table.5.html for the %d substitution in the query if the lookup is not a full email address with domain, the entire query is not even executed? Is this right? If that's the case, you can't do complex queries like: select IF('%d' = 'example.com', . Even though a query like that might account for the case where %d is null, postfix won't execute it? how do you come to that conclusion? By reading. %d When the input key is an address of the form user@domain, %d is replaced by the SQL quoted domain part of the address. Otherwise, the query is suppressed and returns no results. And by testing a query using %d against an alias with only a local part. below a grep of a since 2009 working config Any local part only aliases? It looks to me like your queries all assume input key in format u...@example.com [root@srv-rhsoft:~]$ cat /etc/postfix/mysql* | grep '%d' query = select deliver_to from dbmail_aliases where alias='%u@%d' and (select count(*) from dbmail_aliases where alias='%u@%d' and (round(deliver_to)0))=0; query = select target from dbma_rewrite_domains where source='%d' and ((select count(*) from dbmail_aliases where alias=(select concat('%u', (select target from dbma_rewrite_domains where source='%d' limit 1)) from dbma_rewrite_domains limit 1))0 or (select count(*) from dbmail_aliases where alias='%u@' limit 1)0) limit 1; query = select userid from dbmail_users where ((select count(*) from dbma_mta where mydestination='%d') 0 or (select count(*) from dbma_sender_relay where email='%s') 0) and user_idnr3; query = select filter from dbma_spamfilter where domain='%d'; query = select transport from dbma_transports where mydestination='%s' or mydestination='%d' order by transport desc limit 1;