Possible Bug ? postfix 3.1.0-3 fails on mysql table lookup

Hi guys, think I found a bug using Ubuntu 16.04, can you confirm this? what I get in the log: Jul 3 01:21:40 postfix/cleanup[10334]: warning: mysql query failed: Commands out of sync; you can't run this command now Jul 3 01:21:40 postfix/cleanup[10334]: warning: mysql:/etc/postfix/sql/aliases.cf

Re: Possible Bug ? postfix 3.1.0-3 fails on mysql table lookup

On 07/03/2016 05:35 PM, Joel Linn wrote: > > Hi guys, > > think I found a bug using Ubuntu 16.04, can you confirm this? > > ... Hi it's not actually a bug. Postfix does not support mysql stored procedures. This was discussed here back in 2008:

Re: Spamrl.com RBL problem

* Matthew McGehrin : > Hello. > > I would check your local system to see if you have any rogue perl > processes running. These are generally the cause of being blacklisted > for a dictionary attack, which implies that a script is running on your > local server. > >

Re: Spamrl.com RBL problem

> : host smx1.web-hosting.com[209.188.21.38] said: 550 > The >     sending IP (my dotted quad) is listed on https://spamrl.com as a source of >     dictionary attacks. (in reply to end of DATA command) That would mean that something tried logins against a POP/IMAP/SMTP

Re: Spamrl.com RBL problem

* li...@lazygranch.com : > This is probably more of a freebsd question, but it seems to me that Postfix > should be hogging (bound) to the mail ports, so if something is sending > email, it has to be using Postfix. No. Sending can be done by other processes as well, since

Re: Spamrl.com RBL problem

* Matthew McGehrin : > Hello. > > Your assuming that port 25 needs to be open on the local side to send > mail. this is not the case. There are two possibilities here. > > 1. A dirty IP was assigned to your server, and that the previous owner > had a spam issue.

Re: Spamrl.com RBL problem

Hello. Your assuming that port 25 needs to be open on the local side to send mail. this is not the case. There are two possibilities here. 1. A dirty IP was assigned to your server, and that the previous owner had a spam issue. 2. It's a php exploit, that spawns a perl script to send

AW: Possible Bug ? postfix 3.1.0-3 fails on mysql table lookup

Why is it chosen to "not support stored procedures" instead of adding two lines of code? Are there any security or performance implications? I don't see why the fix would not be applied. I'am now running a query that is several hundred characters long and doesn't scale linear, just to shoehorn

Re: Spamrl.com RBL problem

The only issue against the "dirty" IP address is for a little over a year, I had no problems with this RBL. My problem now is I keep clearing the block, and it gets reset.  This particular RBL has a few complaints about false positives. In fact, for dictionary searches. However the most recent

Re: AW: Possible Bug ? postfix 3.1.0-3 fails on mysql table lookup

Quoting wie...@porcupine.org: Wietse Venema: Joel Linn: > Why is it chosen to "not support stored procedures" instead of adding two > lines of code? The original mysql client may well have been written at a time that stored procedures did not exist, or no API documentation existed for how to

Re: Number of address in "To:"

Hi Bill. Thank you for your answer. This method via header_checks will work only in messages originated from my domain. I do not want to affect incoming messages. Thank you Marcelo -- View this message in context:

Re: AW: Possible Bug ? postfix 3.1.0-3 fails on mysql table lookup

Wietse Venema: > Joel Linn: > > Why is it chosen to "not support stored procedures" instead of adding two > > lines of code? > > The original mysql client may well have been written at a time that > stored procedures did not exist, or no API documentation existed > for how to do this correctly. >

Re: AW: Possible Bug ? postfix 3.1.0-3 fails on mysql table lookup

j...@conductive.de: > > Quoting wie...@porcupine.org: > > > Wietse Venema: > >> Joel Linn: > >> > Why is it chosen to "not support stored procedures" instead of adding two > >> > lines of code? > >> > >> The original mysql client may well have been written at a time that > >> stored procedures

Re: postfix 3.1.1 upgrade from 3.1.0

FreeBSD 10.2. Both 3.1.0 and 3.1.1 were built from ports. I was running Postfix 2 when I first set up the server. I suppose it is possible I missed this "change" when I did the installation of 3.1.0, but not likely. It seems to work. What do you think this would break?  Given this was an

Re: Number of address in "To:"

On 3 Jul 2016, at 18:21, mmgomess wrote: Hi Bill. Thank you for your answer. This method via header_checks will work only in messages originated from my domain. I do not want to affect incoming messages. Yes, but I failed to mention a detail of how you might do that in my prior message;

Re: postfix 3.1.1 upgrade from 3.1.0

li...@lazygranch.com: > During the upgrade from postfix 3.1.0 to 3.1.1, the installation script > issued the following: > > -- > ===> Creating users > Using existing user 'postfix'. That must be a distro-specific script (different OSes have different

Re: AW: Possible Bug ? postfix 3.1.0-3 fails on mysql table lookup

Joel Linn: > Why is it chosen to "not support stored procedures" instead of adding two > lines of code? The original mysql client may well have been written at a time that stored procedures did not exist, or no API documentation existed for how to do this correctly. If you feel strongly about

postfix 3.1.1 upgrade from 3.1.0

During the upgrade from postfix 3.1.0 to 3.1.1, the installation script issued the following: -- ===> Creating users Using existing user 'postfix'. Note: the following files or directories still exist but are no longer part of Postfix: