On 11/23/2016 10:54 PM, j...@conductive.de wrote: > On 2016-11-23 21:57, John Fawcett wrote: >> On 11/22/2016 01:35 AM, Joel Linn wrote: >>> Hey Guys, >>> >>> this issue has decayed a bit but I now finally found the time (and the >>> nerves) to integrate the fix in my system. >>> I'm running Ubuntu 16.04 and trying not change to many things and be >>> able to have clean comparison I applied the patch to the apt sources >>> and only replaced the postfix-mysql package (ubuntu is using 3.1.0 it >>> seems) with my own. >>> I introduced some stored procedures and from my tests I conclude it >>> works. I will see in the next couple of days if there are issues I >>> overlooked. >>> I ran into an issue where I was returning no result set using >>> "smtpd_recipient_restrictions = check_recipient_access mysql:/[...]". >>> I'm not sure if that's an dict_mysql issue or caused by design >>> upstream. I overcame that by doing "select 1 from dual where false" >>> when I don't have anything else to return, which basically is an empty >>> result set. >>> >>> Thanks very much for your work, >>> Joel >> Joel >> >> can you provide some more information to reproduce the issue you >> mentioned? >> >> John > Sure I can. Have a look at my log: > > Nov 23 22:42:49 leuchtkanone postfix/smtpd[5863]: connect from > divmail1.helmholtz-berlin.de[134.30.104.21] > Nov 23 22:42:49 leuchtkanone postfix/smtpd[5863]: warning: > mysql:/etc/postfix/sql/recipient-access.cf: table lookup problem > Nov 23 22:42:49 leuchtkanone postfix/smtpd[5863]: NOQUEUE: reject: > RCPT from divmail1.helmholtz-berlin.de[134.30.104.21]: 451 4.3.5 > <j...@conductive.de>: Recipient address rejected: Server configuration > error; from=<joel.l...@helmholtz-berlin.de> to=<j...@conductive.de> > proto=ESMTP helo=<divmail1.helmholtz-berlin.de> > > I used this empty test procedure (query = CALL ret_empty;): > > CREATE DEFINER=`vmail`@`localhost` PROCEDURE `ret_empty`() > BEGIN > END > > In my procedure I had some code paths return a result and some not. > Like I said i'm now using "SELECT 1 FROM dual WHERE false;" for those > dead paths, this simulates the behavior of the previous solution (one > line query) which always returns a result set, even if it's empty.
Joel with MySQL procedures every SELECT statement that is executed produces a result set. In my patch I explicitly check to make sure there are no multiple result sets, but I do not check for no result. That could be improved upon, to give a specific warning that no result sets were returned. However, that will always be a lookup failure. The stored procedure (based on the way the patch is written) must always return a result set even if that result set is empty. Your solution with returning an empty result set when there is no other result (SELECT 1 FROM DUAL WHERE FALSE) looks correct. John
