postfixadmin-tracker Mailing List for PostfixAdmin (Page 50)
Brought to you by:
christian_boltz,
gingerdog
Menu
▾
▴
postfixadmin-tracker — Postfix Admin tracker notification - READ ONLY!
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(67) |
Nov
(83) |
Dec
(47) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(57) |
Feb
(15) |
Mar
(21) |
Apr
(38) |
May
(27) |
Jun
(38) |
Jul
(35) |
Aug
(50) |
Sep
(8) |
Oct
(9) |
Nov
(59) |
Dec
(59) |
| 2009 |
Jan
(27) |
Feb
(42) |
Mar
(63) |
Apr
(46) |
May
(26) |
Jun
(25) |
Jul
(40) |
Aug
(19) |
Sep
(17) |
Oct
(35) |
Nov
(26) |
Dec
(21) |
| 2010 |
Jan
(11) |
Feb
(19) |
Mar
(40) |
Apr
(25) |
May
(23) |
Jun
(17) |
Jul
(10) |
Aug
(18) |
Sep
(21) |
Oct
(12) |
Nov
(10) |
Dec
(22) |
| 2011 |
Jan
(30) |
Feb
(23) |
Mar
(23) |
Apr
(38) |
May
(32) |
Jun
(19) |
Jul
(20) |
Aug
(36) |
Sep
(11) |
Oct
(28) |
Nov
(4) |
Dec
(4) |
| 2012 |
Jan
(6) |
Feb
(3) |
Mar
(16) |
Apr
(28) |
May
(29) |
Jun
(10) |
Jul
(2) |
Aug
(3) |
Sep
|
Oct
(13) |
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
(11) |
Feb
(7) |
Mar
(29) |
Apr
(2) |
May
(3) |
Jun
(15) |
Jul
(8) |
Aug
(5) |
Sep
(5) |
Oct
(4) |
Nov
(27) |
Dec
(81) |
| 2014 |
Jan
(12) |
Feb
(13) |
Mar
(5) |
Apr
|
May
(41) |
Jun
(16) |
Jul
(7) |
Aug
(10) |
Sep
(24) |
Oct
(50) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(5) |
Feb
(2) |
Mar
(7) |
Apr
(20) |
May
(1) |
Jun
(3) |
Jul
(12) |
Aug
(1) |
Sep
(17) |
Oct
(5) |
Nov
(20) |
Dec
(10) |
| 2016 |
Jan
(10) |
Feb
(11) |
Mar
(22) |
Apr
(30) |
May
(33) |
Jun
(3) |
Jul
|
Aug
(12) |
Sep
(20) |
Oct
(11) |
Nov
(15) |
Dec
(8) |
| 2017 |
Jan
(1) |
Feb
(11) |
Mar
(10) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
(3) |
| 2018 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
(4) |
Jun
(2) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2008-06-26 11:52:38
|
Patches item #2003105, was opened at 2008-06-26 15:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2003105&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Languages Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pavel Usischev (pusischev) Assigned to: Nobody/Anonymous (nobody) Summary: Updated ru.lang Initial Comment: Updated ru.lang attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2003105&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-25 14:30:39
|
Bugs item #2002490, was opened at 2008-06-25 18:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2002490&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: rutkov aleksander (rutkov) Assigned to: Nobody/Anonymous (nobody) Summary: errno: 152 Initial Comment: Hi, Encontrei o sequinte problema pelo caminho: Everything seems fine… attempting to create/update database structure Updating database: old version: 317; target version: 352 updating to version 318 (MySQL)… DEBUG INFORMATION: Invalid query: Error on rename of ‘./postfix/vacation_notification’ to ‘./postfix/#sql2-135a-97′ (errno: 152) You can help me ????? Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2002490&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-17 21:34:43
|
Patches item #1986622, was opened at 2008-06-06 16:20 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=1986622&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Languages Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: tw.lang (modified) Initial Comment: Modified Tranditional Chinese language file ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2008-06-17 21:34 Message: Logged In: YES user_id=1761957 Originator: NO I almost merged this, and then gave up. I lack the chinese unicode fonts, so I can't tell if I'm screwing up the unicode stuff or not when I download/edit/merge ---------------------------------------------------------------------- Comment By: John Chen (johnpupu) Date: 2008-06-13 09:56 Message: Logged In: YES user_id=2109445 Originator: NO OK , I translate this file from cn.lang file so , It's for tw.lang. ^^ ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2008-06-06 23:27 Message: Logged In: YES user_id=593261 Originator: NO I'm slightly confused - according to the comments in the file, it is based on cn.lang (simplified chinese). However, you have uploaded it as tw.lang (traditional chinese). Which is the correct language of your file? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=1986622&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-17 21:27:47
|
Patches item #1995478, was opened at 2008-06-16 20:21 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=1995478&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Breitegger (tuxstef) Assigned to: Nobody/Anonymous (nobody) Summary: postfixadmin-2.2.0 fetchmail ssl option Initial Comment: Suggenstion to click enable ssl option without extra options enabled for fetchmail. ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2008-06-17 21:27 Message: Logged In: YES user_id=1761957 Originator: NO Hi, Thanks for the patch; I think the change to upgrade.php really needs to occur in it's own distinct upgrade function (and there probably needs to be one for postgresql and mysql). Hopefully i'll fix this and merge it shortly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=1995478&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-17 21:25:37
|
Patches item #1995119, was opened at 2008-06-16 13:00 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=1995119&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Vacation Group: SVN (please specify revision!) >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Sylvain BEUCLER (beuc) Assigned to: Nobody/Anonymous (nobody) Summary: Unquote ' before display Initial Comment: If the vacation text contains a single quote (') or a backslash (\), it gets escaped (\' \\) in the textarea. This patch fixes this by stripping slashes before inserting the text back in the textarea. ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2008-06-17 21:25 Message: Logged In: YES user_id=1761957 Originator: NO see r387 in trunk. I presumed the vacation subject needs the same treatment. thanks David. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=1995119&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-17 21:19:53
|
Patches item #1996052, was opened at 2008-06-17 12:42 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=1996052&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: SVN (please specify revision!) >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Sylvain BEUCLER (beuc) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot change password: missing $maildir parameter Initial Comment: (rev 380) In edit-mailbox.php $maildir is unspecified and triggers "empty username, domain and/or maildir parameter" error message in mailbox_postedit. Here's a fix. ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2008-06-17 21:20 Message: Logged In: YES user_id=1761957 Originator: NO fixed in revision 386; thank you! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=1996052&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-17 21:17:00
|
Patches item #1996054, was opened at 2008-06-17 12:44 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=1996054&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Vacation Group: SVN (please specify revision!) >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Sylvain BEUCLER (beuc) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in INSTALL.txt Initial Comment: (rev 380) Just s/Virual/Virtual/ :) ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2008-06-17 21:17 Message: Logged In: YES user_id=1761957 Originator: NO Thanks; fixed in r385 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=1996054&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-17 12:44:21
|
Patches item #1996054, was opened at 2008-06-17 14:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=1996054&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Vacation Group: SVN (please specify revision!) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sylvain BEUCLER (beuc) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in INSTALL.txt Initial Comment: (rev 380) Just s/Virual/Virtual/ :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=1996054&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-17 12:42:37
|
Patches item #1996052, was opened at 2008-06-17 14:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=1996052&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: SVN (please specify revision!) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sylvain BEUCLER (beuc) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot change password: missing $maildir parameter Initial Comment: (rev 380) In edit-mailbox.php $maildir is unspecified and triggers "empty username, domain and/or maildir parameter" error message in mailbox_postedit. Here's a fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=1996052&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-16 20:21:40
|
Patches item #1995478, was opened at 2008-06-16 22:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=1995478&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Breitegger (tuxstef) Assigned to: Nobody/Anonymous (nobody) Summary: postfixadmin-2.2.0 fetchmail ssl option Initial Comment: Suggenstion to click enable ssl option without extra options enabled for fetchmail. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=1995478&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-16 13:00:00
|
Patches item #1995119, was opened at 2008-06-16 15:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=1995119&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Vacation Group: SVN (please specify revision!) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sylvain BEUCLER (beuc) Assigned to: Nobody/Anonymous (nobody) Summary: Unquote ' before display Initial Comment: If the vacation text contains a single quote (') or a backslash (\), it gets escaped (\' \\) in the textarea. This patch fixes this by stripping slashes before inserting the text back in the textarea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=1995119&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-15 16:18:20
|
Bugs item #1990191, was opened at 2008-06-10 23:12 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1990191&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Database >Group: v 2.2 Status: Open Resolution: None >Priority: 8 Private: No Submitted By: Jon Kristian Nilsen (jonkristian) Assigned to: Nobody/Anonymous (nobody) Summary: Illegal mix of collations Initial Comment: DEBUG INFORMATION: Invalid query: Illegal mix of collations (latin1_general_ci,IMPLICIT) and (latin1_swedish_ci,IMPLICIT) for operation '=' In virtual-list.php , it's a bug in upgrade.php see attached patch. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2008-06-15 18:18 Message: Logged In: YES user_id=593261 Originator: NO I checked the 2.1 release again and found out that there was no collation specified in the MySQL dump. This means that the collation 2.1 users have in their database depends on the local MySQL settings. >From the postfixadmin point of view, we can just call it "random"... I'll add a fix to upgrade.php in the next days. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-06-11 09:06 Message: Logged In: NO Why is latin1_swedish_ci used instead of latin1_general_ci anyway? ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2008-06-11 01:52 Message: Logged In: YES user_id=593261 Originator: NO It isn't that easy (because your patch would break upgrades) and changing from latin1_swedish_ci to latin1_general_ci doesn't make a real difference, so I tend to reject your patch. However, let's wait what we find out in the forum thread where this bug report came from: https://sourceforge.net/forum/forum.php?thread_id=2039397&forum_id=676076 (The question is where the latin1_general_ci field is hidden / comes from ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1990191&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-15 09:58:28
|
Bugs item #1694669, was opened at 2007-04-04 17:14 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1694669&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: SVN (please specify revision!) Status: Open Resolution: None Priority: 2 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Improper Use of crypt() Initial Comment: Inside the pacrypt() function in functions.inc.php, crypt() is used for the 'system' encryption type. Salt is first calculated, with the below code: if (ereg ("\$1\$", $pw_db)) { $split_salt = preg_split ('/\$/', $pw_db); $salt = $split_salt[2]; } else { $salt = substr ($pw_db, 0, 2); } ... however, that is improper according to the php.net documentation (http://www.php.net/crypt) for the crypt() call: ... You should pass the entire results of crypt() as the salt for comparing a password, to avoid problems when different hashing algorithms are used. (As it says above, standard DES-based password hashing uses a 2-character salt, but MD5-based hashing uses 12.) ... Simply modifying the code to read: if ($pw_db) { $password = crypt ($pw, $pw_db); } else { $password = crypt ($pw); } ... fixed the problem in my case. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-06-15 02:58 Message: Logged In: NO Same here. I had to patch this manually (for every PFA version so far) to make it work under FreeBSD with "long" (MD5 instead of DES) crypt passwords. Currently in 2.2.0 version this code is used: if ($CONF['encrypt'] == 'system') { if (ereg ("\$1\$", $pw_db)) { $split_salt = preg_split ('/\$/', $pw_db); $salt = $split_salt[2]; } else { if (strlen($pw_db) == 0) { $salt = substr (md5 (mt_rand ()), 0, 2); } else { $salt = substr ($pw_db, 0, 2); } } $password = crypt ($pw, $salt); } which creates "short" (DES) passwords when creating new users. Using the code above (proposed in the description of this bug) elegantly fixes all the issues. Will this fix be included in the following PostfixAdmin release? I think it's about time. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-01-31 03:05 Message: Logged In: NO I can certify this does not break anything on GNU/Linux or FreeBSD systems; passing the entire hash as salt is the proper way. Splitting, like you currently do in pacrypt(), does not work -- If you create a new user, he cannot log in. Copying /etc/passwd entries breaks also. -- Morten Hustveit ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-01-27 09:56 Message: Logged In: NO i changed it in following way: .... if (ereg ('\$1\$', $pw_db)) { $split_salt = preg_split ('/\$/', $pw_db); $salt = "$1$".$split_salt[2]; } .... i think that is without any side effects. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2007-10-09 10:05 Message: Logged In: YES user_id=1761957 Originator: NO I'd be tempted to think not - after all people must (!?) be using crypt'ed passwords with other 3rd party applications (e.g. imap/pop3 clients).... doesn't this imply we can fix this without any side effects? ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2007-10-07 13:03 Message: Logged In: YES user_id=593261 Originator: NO Your arguments are valid, but the question is: Will this break existing passwords? (If yes, it will be problematic to do this change.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1694669&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-14 08:32:35
|
Patches item #1752327, was opened at 2007-07-11 17:19 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=1752327&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Vacation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Seifarth (waw) Assigned to: Nobody/Anonymous (nobody) Summary: simple PHP vacation script Initial Comment: This is a simplistic vacation script for postfixadmin, written in PHP. Since postfix has already figured out who the sender is, and who the recipient is, we can use these values passed via the command line from the postfix pipe daemon process when our script is called. This avoids having to parse the email message itself, and vastly simplifies the program logic. It does impose some limitations, described below. This version only supports the postgres backend database. It should be easy to adapt to mysql, by someone familiar with that database. Ideally, it should be database-independent. The main design goal is extreme simplicity, with decent error checking, to avoid sending inappropriate vacation notifications. It is much simpler than the vacation.pl script included with postfixadmin, since it does not have to parse the email headers to extract the sender and recipient. However, it should be easily modifiable by anyone reasonably familiar with PHP. Features: - Written entirely in simple, linear PHP. - Error checking: at each step, if an error is encountered, the error is logged and the program exits - Relies on postfix for the sender and recipient address - Allows a time-based repeat policy for re-sending notifications. For example, it can be set to notify every 10 days, every day, or even every 1 second if you want a notification sent for each incoming mail from each sender. Limits: * Postgres only, because I do not have a Mysql test DB. I previously had the vacation-psql.pl script running when I was using postfix 2.2, but it stopped working when I upgraded to postfix 2.3 (which I needed for working with dovecot SASL auth). This vacation-psql.pl uses the vacation_notification table to keep track of which senders have already received a vacation notification. I did not see this table used in the mysql vacation.pl script. * Does not attempt to find the actual address to which the mail was sent, it just uses the ${recipient} macro from the postfix pipe interface to find the recipient mailbox. Therefore, the return address of the vacation notification is that of the user's mailbox, not necessarily the address to which the sender originaly sent the email, which may well be an alias to that mailbox. My workaround for this limitation for users who have ab...@wh...d type addresses is to suggest that they put their usual address or their name in the subject line. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-06-14 01:32 Message: Logged In: NO saasax ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=1752327&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-13 09:56:05
|
Patches item #1986622, was opened at 2008-06-07 00:20 Message generated for change (Comment added) made by johnpupu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=1986622&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Languages Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: tw.lang (modified) Initial Comment: Modified Tranditional Chinese language file ---------------------------------------------------------------------- Comment By: John Chen (johnpupu) Date: 2008-06-13 17:56 Message: Logged In: YES user_id=2109445 Originator: NO OK , I translate this file from cn.lang file so , It's for tw.lang. ^^ ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2008-06-07 07:27 Message: Logged In: YES user_id=593261 Originator: NO I'm slightly confused - according to the comments in the file, it is based on cn.lang (simplified chinese). However, you have uploaded it as tw.lang (traditional chinese). Which is the correct language of your file? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=1986622&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-11 20:42:03
|
Feature Requests item #1987990, was opened at 2008-06-08 07:39 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1987990&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: SVN (please specify revision!) Status: Open Resolution: None Priority: 5 Private: No Submitted By: GingerDog (gingerdog) Assigned to: Nobody/Anonymous (nobody) Summary: Installer - check perms to create tables etc Initial Comment: Quite a few users seem to run into problems on installation regarding the ability to create tables within their db. The installer (setup.php) should check to see whether the db user can create tables within the database, and if not, it should write out the SQL to screen for the user to run. (Presumably this is just a case of doing "echo $sql" rather than "db_query($sql)") The user can then be responsible for copy & pasting the SQL in as appropriate. ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2008-06-11 20:42 Message: Logged In: YES user_id=1761957 Originator: YES Perhaps "Show Grants" can help? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1987990&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-11 07:06:46
|
Bugs item #1990191, was opened at 2008-06-10 14:12 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1990191&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Database Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jon Kristian Nilsen (jonkristian) Assigned to: Nobody/Anonymous (nobody) Summary: Illegal mix of collations Initial Comment: DEBUG INFORMATION: Invalid query: Illegal mix of collations (latin1_general_ci,IMPLICIT) and (latin1_swedish_ci,IMPLICIT) for operation '=' In virtual-list.php , it's a bug in upgrade.php see attached patch. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-06-11 00:06 Message: Logged In: NO Why is latin1_swedish_ci used instead of latin1_general_ci anyway? ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2008-06-10 16:52 Message: Logged In: YES user_id=593261 Originator: NO It isn't that easy (because your patch would break upgrades) and changing from latin1_swedish_ci to latin1_general_ci doesn't make a real difference, so I tend to reject your patch. However, let's wait what we find out in the forum thread where this bug report came from: https://sourceforge.net/forum/forum.php?thread_id=2039397&forum_id=676076 (The question is where the latin1_general_ci field is hidden / comes from ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1990191&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-10 23:52:32
|
Bugs item #1990191, was opened at 2008-06-10 23:12 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1990191&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Database Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jon Kristian Nilsen (jonkristian) Assigned to: Nobody/Anonymous (nobody) Summary: Illegal mix of collations Initial Comment: DEBUG INFORMATION: Invalid query: Illegal mix of collations (latin1_general_ci,IMPLICIT) and (latin1_swedish_ci,IMPLICIT) for operation '=' In virtual-list.php , it's a bug in upgrade.php see attached patch. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2008-06-11 01:52 Message: Logged In: YES user_id=593261 Originator: NO It isn't that easy (because your patch would break upgrades) and changing from latin1_swedish_ci to latin1_general_ci doesn't make a real difference, so I tend to reject your patch. However, let's wait what we find out in the forum thread where this bug report came from: https://sourceforge.net/forum/forum.php?thread_id=2039397&forum_id=676076 (The question is where the latin1_general_ci field is hidden / comes from ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1990191&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-10 21:12:29
|
Bugs item #1990191, was opened at 2008-06-10 23:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1990191&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Database Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jon Kristian Nilsen (jonkristian) Assigned to: Nobody/Anonymous (nobody) Summary: Illegal mix of collations Initial Comment: DEBUG INFORMATION: Invalid query: Illegal mix of collations (latin1_general_ci,IMPLICIT) and (latin1_swedish_ci,IMPLICIT) for operation '=' In virtual-list.php , it's a bug in upgrade.php see attached patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1990191&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-10 11:20:36
|
Feature Requests item #1973673, was opened at 2008-05-27 01:04 Message generated for change (Comment added) made by lenix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1973673&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: SVN (please specify revision!) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: merge SQL queries for alias domains Initial Comment: >From POSTFIX_CONF.txt: virtual_alias_maps = proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_maps.cf, proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_maps.cf, proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_catchall_maps.cf virtual_mailbox_maps = proxy:mysql:/etc/postfix/sql/mysql_virtual_mailbox_maps.cf, proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_mailbox_maps.cf This means MySQL is called twice for mailboxes and three times for aliases (except if the first try returns a result, of course). If possible, we should merge the queries so that alias and mailbox queries always only need one map. SELECT ... UNION SELECT ... UNION SELECT ... doesn't look very nice, but it has a better performance than doing two or three separate queries. Or is there a special reason why we should do separate queries? ---------------------------------------------------------------------- Comment By: Guido Boehm (lenix) Date: 2008-06-10 13:20 Message: Logged In: YES user_id=142401 Originator: NO hi christian, i did some testing with the new query inside postfix and had to do some further modifications. http://www.postfix.org/mysql_table.5.html states that %u When the input key is an address of the form user@domain, %u is replaced by the SQL quoted local part of the address. Other- wise, %u is replaced by the entire search string. If the localpart is empty, the query is suppressed and returns no results. that's why i had to get "%u" and "%d' manually using SUBSTR_INDEX(), else postfix would suppress the catchall-lookup (with the empty %u part) next to this there's a note that This parameter is available with Postfix 2.2. In prior releases the SQL query was built from the separate parameters: select_field, table, where_field and additional_conditions. The mapping from the old parameters to the equivalent query is: so our current setup is >= postfix 2.2 compatible. the final query installed on my system now looks like this: SELECT alias.goto FROM alias LEFT JOIN alias_domain ON alias_domain.alias_domain = SUBSTRING_INDEX( '%s', '@', -1 ) AND alias.domain = alias_domain.target_domain WHERE alias.active =1 AND ( alias.address = '%s' OR ( alias_domain.alias_domain = SUBSTRING_INDEX( '%s', '@', -1 ) AND alias.address = CONCAT( SUBSTRING_INDEX( '%s', '@', 1 ), '@', alias_domain.target_domain ) ) ) ORDER BY alias_domain.alias_domain ASC LIMIT 1 // lenix ---------------------------------------------------------------------- Comment By: Guido Boehm (lenix) Date: 2008-06-10 02:24 Message: Logged In: YES user_id=142401 Originator: NO hi christian, the following modified query would ensure that we always get the desired row: SELECT alias.goto FROM alias LEFT JOIN alias_domain ON alias_domain.alias_domain = '%d' AND alias.domain = alias_domain.target_domain WHERE alias.active = 1 AND ( alias.address='%s' OR (alias_domain.alias_domain='%d' AND alias.address=CONCAT('%u','@',alias_domain.target_domain)) ) ORDER BY alias_domain.alias_domain ASC LIMIT 1 extending the join-condition with "AND alias.domain = alias_domain.target_domain" will return a NULL-value for the "alias_domain.alias_domain" column in a row matched by the condition "alias.address='%s'". to explain this with your example (us...@fo... -> use...@ex...): there would be one row with alias.address='us...@fo...', alias.domain='foo.de' alias_domain.alias_domain=NULL alias_domain.target_domain=NULL for this row alias_domain.alias_domain='foo.de' would be matched by the first ON-condition, but alias_domain.target_domain='bar.de' is != alias.domain, so no join and therefor NULL-values in alias_domain.* next to this there would be another row with alias.address='us...@ba...' alias.domain='bar.de' alias_domain.alias_domain='foo.de' alias_domain.target_domain='bar.de' since the NULL-value orders in front of 'foo.de', "LIMIT 1" will return only the first row, which is the one we're looking for. i already studied the feature-request you mentioned, but as long as wietse/ the postfix-docs don't recommend to return multiple rows for alias-lookups i would personally advice against doing so. of course you're right that this query wouldn't work with such a configuration. i'll have a look at "virtual_mailbox_maps" and do some testing inside postfix the next days :-) sorry for posting the last message twice btw. // lenix ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2008-06-10 00:40 Message: Logged In: YES user_id=593261 Originator: YES I'd say I know MySQL quite good, but don't consider myself to be an expert ;-) I would not rely on the sort order and do a LIMIT 1. Unless we specify an ORDER BY, the results are probably sorted by creation time, which is as acceptable as ORDER BY random()... In theory we could use something like SELECT goto, 1 as rank FROM alias UNION SELECT ... AS goto, 2 as rank ORDER BY rank LIMIT 1 but it has some disadvantage: * It will return an additional column to postfix, and I have no idea how postfix behaves in this case. (Additionally the query above is untested, but I hope it should work this way.) * We have a feature request to split the goto field to one address per row, which means there could be multiple results (I hope the requester tested the postfix behaviour, I didn't ;-) - LIMIT 1 would be deadly after this change. I'm afraid the only clean solution is doing this inside MySQL. This reduces the traffic between Postfix and MySQL to a single query. For some example SQL code, see https://listi.jpberlin.de/pipermail/postfixbuch-users/2007-November/039627.html People who use older MySQL versions (MySQL 4 and older) could still use separate queries. ---------------------------------------------------------------------- Comment By: Guido Boehm (lenix) Date: 2008-06-09 01:05 Message: Logged In: YES user_id=142401 Originator: NO with the query i mentioned your testcase would result in 2 rows being returned. at least for me the first result was always the one where alias.address='%s' matched, so one could just append "LIMIT 1", but i'm not sure how consistent this is, maybe there's some mysql-professional who could tell? // lenix ---------------------------------------------------------------------- Comment By: Guido Boehm (lenix) Date: 2008-06-09 00:59 Message: Logged In: YES user_id=142401 Originator: NO with the query i mentioned your testcase would result in 2 rows being returned. at least for me the first result was always the one where alias.address='%s' matched, so one could just append "LIMIT 1", but i'm not sure how consistent this is, maybe there's some mysql-professional who could tell? // lenix ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2008-06-09 00:35 Message: Logged In: YES user_id=593261 Originator: YES To make things more interesting: We still allow to have separate aliases on a domain that is defined as alias domain. This is not really bad (and might even be useful in some cases), but it might lead to interesting ;-) setups. For example, there could be the following setup: alias domain: foo.de -> bar.de alias: us...@ba... -> use...@ex... alias: us...@fo... -> use...@ex... In this case, I would expect that mails sent to us...@fo... are forwarded to user-foo@, not user-bar@. With the separate queries, it should work - but I'm not sure about the merged one. Please add such a setup to your testcase ;-) If it turns out that merging the queries is too complicated, creating a function inside MySQL could be an option for those who want better performance. Users who don't want to do this (or can't because they still use MySQL 4) could still use the separated queries. ---------------------------------------------------------------------- Comment By: Guido Boehm (lenix) Date: 2008-06-08 20:02 Message: Logged In: YES user_id=142401 Originator: NO hi christian, after re-thinking the way postfix does lookups it appears to me it already does run 2 queries per item in 'virtual_alias_maps': - a first try for exact matches (looking up the key 'bo...@ex...') - if the first try didn't give any results a second try for catchall (looking up the key '@example.com') based on this assumption i created the following query which should be able to replace the 3 virtual_alias_maps-queries in the current setup: SELECT alias.goto FROM alias LEFT JOIN alias_domain ON alias_domain.alias_domain = '%d' WHERE alias.active = 1 AND ( alias.address='%s' OR (alias_domain.alias_domain='%d' AND alias.address=CONCAT('%u','@',alias_domain.target_domain)) ) although i did run a set of test-queries against my own database which looked promising i don't have the time to extensivly test it inside my postfix-setup right now. i'll try to do this next week and keep you updated. thanks for your patience, lenix ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1973673&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-10 00:24:22
|
Feature Requests item #1973673, was opened at 2008-05-27 01:04 Message generated for change (Comment added) made by lenix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1973673&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: SVN (please specify revision!) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: merge SQL queries for alias domains Initial Comment: >From POSTFIX_CONF.txt: virtual_alias_maps = proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_maps.cf, proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_maps.cf, proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_catchall_maps.cf virtual_mailbox_maps = proxy:mysql:/etc/postfix/sql/mysql_virtual_mailbox_maps.cf, proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_mailbox_maps.cf This means MySQL is called twice for mailboxes and three times for aliases (except if the first try returns a result, of course). If possible, we should merge the queries so that alias and mailbox queries always only need one map. SELECT ... UNION SELECT ... UNION SELECT ... doesn't look very nice, but it has a better performance than doing two or three separate queries. Or is there a special reason why we should do separate queries? ---------------------------------------------------------------------- Comment By: Guido Boehm (lenix) Date: 2008-06-10 02:24 Message: Logged In: YES user_id=142401 Originator: NO hi christian, the following modified query would ensure that we always get the desired row: SELECT alias.goto FROM alias LEFT JOIN alias_domain ON alias_domain.alias_domain = '%d' AND alias.domain = alias_domain.target_domain WHERE alias.active = 1 AND ( alias.address='%s' OR (alias_domain.alias_domain='%d' AND alias.address=CONCAT('%u','@',alias_domain.target_domain)) ) ORDER BY alias_domain.alias_domain ASC LIMIT 1 extending the join-condition with "AND alias.domain = alias_domain.target_domain" will return a NULL-value for the "alias_domain.alias_domain" column in a row matched by the condition "alias.address='%s'". to explain this with your example (us...@fo... -> use...@ex...): there would be one row with alias.address='us...@fo...', alias.domain='foo.de' alias_domain.alias_domain=NULL alias_domain.target_domain=NULL for this row alias_domain.alias_domain='foo.de' would be matched by the first ON-condition, but alias_domain.target_domain='bar.de' is != alias.domain, so no join and therefor NULL-values in alias_domain.* next to this there would be another row with alias.address='us...@ba...' alias.domain='bar.de' alias_domain.alias_domain='foo.de' alias_domain.target_domain='bar.de' since the NULL-value orders in front of 'foo.de', "LIMIT 1" will return only the first row, which is the one we're looking for. i already studied the feature-request you mentioned, but as long as wietse/ the postfix-docs don't recommend to return multiple rows for alias-lookups i would personally advice against doing so. of course you're right that this query wouldn't work with such a configuration. i'll have a look at "virtual_mailbox_maps" and do some testing inside postfix the next days :-) sorry for posting the last message twice btw. // lenix ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2008-06-10 00:40 Message: Logged In: YES user_id=593261 Originator: YES I'd say I know MySQL quite good, but don't consider myself to be an expert ;-) I would not rely on the sort order and do a LIMIT 1. Unless we specify an ORDER BY, the results are probably sorted by creation time, which is as acceptable as ORDER BY random()... In theory we could use something like SELECT goto, 1 as rank FROM alias UNION SELECT ... AS goto, 2 as rank ORDER BY rank LIMIT 1 but it has some disadvantage: * It will return an additional column to postfix, and I have no idea how postfix behaves in this case. (Additionally the query above is untested, but I hope it should work this way.) * We have a feature request to split the goto field to one address per row, which means there could be multiple results (I hope the requester tested the postfix behaviour, I didn't ;-) - LIMIT 1 would be deadly after this change. I'm afraid the only clean solution is doing this inside MySQL. This reduces the traffic between Postfix and MySQL to a single query. For some example SQL code, see https://listi.jpberlin.de/pipermail/postfixbuch-users/2007-November/039627.html People who use older MySQL versions (MySQL 4 and older) could still use separate queries. ---------------------------------------------------------------------- Comment By: Guido Boehm (lenix) Date: 2008-06-09 01:05 Message: Logged In: YES user_id=142401 Originator: NO with the query i mentioned your testcase would result in 2 rows being returned. at least for me the first result was always the one where alias.address='%s' matched, so one could just append "LIMIT 1", but i'm not sure how consistent this is, maybe there's some mysql-professional who could tell? // lenix ---------------------------------------------------------------------- Comment By: Guido Boehm (lenix) Date: 2008-06-09 00:59 Message: Logged In: YES user_id=142401 Originator: NO with the query i mentioned your testcase would result in 2 rows being returned. at least for me the first result was always the one where alias.address='%s' matched, so one could just append "LIMIT 1", but i'm not sure how consistent this is, maybe there's some mysql-professional who could tell? // lenix ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2008-06-09 00:35 Message: Logged In: YES user_id=593261 Originator: YES To make things more interesting: We still allow to have separate aliases on a domain that is defined as alias domain. This is not really bad (and might even be useful in some cases), but it might lead to interesting ;-) setups. For example, there could be the following setup: alias domain: foo.de -> bar.de alias: us...@ba... -> use...@ex... alias: us...@fo... -> use...@ex... In this case, I would expect that mails sent to us...@fo... are forwarded to user-foo@, not user-bar@. With the separate queries, it should work - but I'm not sure about the merged one. Please add such a setup to your testcase ;-) If it turns out that merging the queries is too complicated, creating a function inside MySQL could be an option for those who want better performance. Users who don't want to do this (or can't because they still use MySQL 4) could still use the separated queries. ---------------------------------------------------------------------- Comment By: Guido Boehm (lenix) Date: 2008-06-08 20:02 Message: Logged In: YES user_id=142401 Originator: NO hi christian, after re-thinking the way postfix does lookups it appears to me it already does run 2 queries per item in 'virtual_alias_maps': - a first try for exact matches (looking up the key 'bo...@ex...') - if the first try didn't give any results a second try for catchall (looking up the key '@example.com') based on this assumption i created the following query which should be able to replace the 3 virtual_alias_maps-queries in the current setup: SELECT alias.goto FROM alias LEFT JOIN alias_domain ON alias_domain.alias_domain = '%d' WHERE alias.active = 1 AND ( alias.address='%s' OR (alias_domain.alias_domain='%d' AND alias.address=CONCAT('%u','@',alias_domain.target_domain)) ) although i did run a set of test-queries against my own database which looked promising i don't have the time to extensivly test it inside my postfix-setup right now. i'll try to do this next week and keep you updated. thanks for your patience, lenix ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1973673&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-09 22:40:40
|
Feature Requests item #1973673, was opened at 2008-05-27 01:04 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1973673&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: SVN (please specify revision!) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: merge SQL queries for alias domains Initial Comment: >From POSTFIX_CONF.txt: virtual_alias_maps = proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_maps.cf, proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_maps.cf, proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_catchall_maps.cf virtual_mailbox_maps = proxy:mysql:/etc/postfix/sql/mysql_virtual_mailbox_maps.cf, proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_mailbox_maps.cf This means MySQL is called twice for mailboxes and three times for aliases (except if the first try returns a result, of course). If possible, we should merge the queries so that alias and mailbox queries always only need one map. SELECT ... UNION SELECT ... UNION SELECT ... doesn't look very nice, but it has a better performance than doing two or three separate queries. Or is there a special reason why we should do separate queries? ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2008-06-10 00:40 Message: Logged In: YES user_id=593261 Originator: YES I'd say I know MySQL quite good, but don't consider myself to be an expert ;-) I would not rely on the sort order and do a LIMIT 1. Unless we specify an ORDER BY, the results are probably sorted by creation time, which is as acceptable as ORDER BY random()... In theory we could use something like SELECT goto, 1 as rank FROM alias UNION SELECT ... AS goto, 2 as rank ORDER BY rank LIMIT 1 but it has some disadvantage: * It will return an additional column to postfix, and I have no idea how postfix behaves in this case. (Additionally the query above is untested, but I hope it should work this way.) * We have a feature request to split the goto field to one address per row, which means there could be multiple results (I hope the requester tested the postfix behaviour, I didn't ;-) - LIMIT 1 would be deadly after this change. I'm afraid the only clean solution is doing this inside MySQL. This reduces the traffic between Postfix and MySQL to a single query. For some example SQL code, see https://listi.jpberlin.de/pipermail/postfixbuch-users/2007-November/039627.html People who use older MySQL versions (MySQL 4 and older) could still use separate queries. ---------------------------------------------------------------------- Comment By: Guido Boehm (lenix) Date: 2008-06-09 01:05 Message: Logged In: YES user_id=142401 Originator: NO with the query i mentioned your testcase would result in 2 rows being returned. at least for me the first result was always the one where alias.address='%s' matched, so one could just append "LIMIT 1", but i'm not sure how consistent this is, maybe there's some mysql-professional who could tell? // lenix ---------------------------------------------------------------------- Comment By: Guido Boehm (lenix) Date: 2008-06-09 00:59 Message: Logged In: YES user_id=142401 Originator: NO with the query i mentioned your testcase would result in 2 rows being returned. at least for me the first result was always the one where alias.address='%s' matched, so one could just append "LIMIT 1", but i'm not sure how consistent this is, maybe there's some mysql-professional who could tell? // lenix ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2008-06-09 00:35 Message: Logged In: YES user_id=593261 Originator: YES To make things more interesting: We still allow to have separate aliases on a domain that is defined as alias domain. This is not really bad (and might even be useful in some cases), but it might lead to interesting ;-) setups. For example, there could be the following setup: alias domain: foo.de -> bar.de alias: us...@ba... -> use...@ex... alias: us...@fo... -> use...@ex... In this case, I would expect that mails sent to us...@fo... are forwarded to user-foo@, not user-bar@. With the separate queries, it should work - but I'm not sure about the merged one. Please add such a setup to your testcase ;-) If it turns out that merging the queries is too complicated, creating a function inside MySQL could be an option for those who want better performance. Users who don't want to do this (or can't because they still use MySQL 4) could still use the separated queries. ---------------------------------------------------------------------- Comment By: Guido Boehm (lenix) Date: 2008-06-08 20:02 Message: Logged In: YES user_id=142401 Originator: NO hi christian, after re-thinking the way postfix does lookups it appears to me it already does run 2 queries per item in 'virtual_alias_maps': - a first try for exact matches (looking up the key 'bo...@ex...') - if the first try didn't give any results a second try for catchall (looking up the key '@example.com') based on this assumption i created the following query which should be able to replace the 3 virtual_alias_maps-queries in the current setup: SELECT alias.goto FROM alias LEFT JOIN alias_domain ON alias_domain.alias_domain = '%d' WHERE alias.active = 1 AND ( alias.address='%s' OR (alias_domain.alias_domain='%d' AND alias.address=CONCAT('%u','@',alias_domain.target_domain)) ) although i did run a set of test-queries against my own database which looked promising i don't have the time to extensivly test it inside my postfix-setup right now. i'll try to do this next week and keep you updated. thanks for your patience, lenix ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1973673&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-08 23:05:31
|
Feature Requests item #1973673, was opened at 2008-05-27 01:04 Message generated for change (Comment added) made by lenix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1973673&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: SVN (please specify revision!) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: merge SQL queries for alias domains Initial Comment: >From POSTFIX_CONF.txt: virtual_alias_maps = proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_maps.cf, proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_maps.cf, proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_catchall_maps.cf virtual_mailbox_maps = proxy:mysql:/etc/postfix/sql/mysql_virtual_mailbox_maps.cf, proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_mailbox_maps.cf This means MySQL is called twice for mailboxes and three times for aliases (except if the first try returns a result, of course). If possible, we should merge the queries so that alias and mailbox queries always only need one map. SELECT ... UNION SELECT ... UNION SELECT ... doesn't look very nice, but it has a better performance than doing two or three separate queries. Or is there a special reason why we should do separate queries? ---------------------------------------------------------------------- Comment By: Guido Boehm (lenix) Date: 2008-06-09 01:05 Message: Logged In: YES user_id=142401 Originator: NO with the query i mentioned your testcase would result in 2 rows being returned. at least for me the first result was always the one where alias.address='%s' matched, so one could just append "LIMIT 1", but i'm not sure how consistent this is, maybe there's some mysql-professional who could tell? // lenix ---------------------------------------------------------------------- Comment By: Guido Boehm (lenix) Date: 2008-06-09 00:59 Message: Logged In: YES user_id=142401 Originator: NO with the query i mentioned your testcase would result in 2 rows being returned. at least for me the first result was always the one where alias.address='%s' matched, so one could just append "LIMIT 1", but i'm not sure how consistent this is, maybe there's some mysql-professional who could tell? // lenix ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2008-06-09 00:35 Message: Logged In: YES user_id=593261 Originator: YES To make things more interesting: We still allow to have separate aliases on a domain that is defined as alias domain. This is not really bad (and might even be useful in some cases), but it might lead to interesting ;-) setups. For example, there could be the following setup: alias domain: foo.de -> bar.de alias: us...@ba... -> use...@ex... alias: us...@fo... -> use...@ex... In this case, I would expect that mails sent to us...@fo... are forwarded to user-foo@, not user-bar@. With the separate queries, it should work - but I'm not sure about the merged one. Please add such a setup to your testcase ;-) If it turns out that merging the queries is too complicated, creating a function inside MySQL could be an option for those who want better performance. Users who don't want to do this (or can't because they still use MySQL 4) could still use the separated queries. ---------------------------------------------------------------------- Comment By: Guido Boehm (lenix) Date: 2008-06-08 20:02 Message: Logged In: YES user_id=142401 Originator: NO hi christian, after re-thinking the way postfix does lookups it appears to me it already does run 2 queries per item in 'virtual_alias_maps': - a first try for exact matches (looking up the key 'bo...@ex...') - if the first try didn't give any results a second try for catchall (looking up the key '@example.com') based on this assumption i created the following query which should be able to replace the 3 virtual_alias_maps-queries in the current setup: SELECT alias.goto FROM alias LEFT JOIN alias_domain ON alias_domain.alias_domain = '%d' WHERE alias.active = 1 AND ( alias.address='%s' OR (alias_domain.alias_domain='%d' AND alias.address=CONCAT('%u','@',alias_domain.target_domain)) ) although i did run a set of test-queries against my own database which looked promising i don't have the time to extensivly test it inside my postfix-setup right now. i'll try to do this next week and keep you updated. thanks for your patience, lenix ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1973673&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-08 22:59:16
|
Feature Requests item #1973673, was opened at 2008-05-27 01:04 Message generated for change (Comment added) made by lenix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1973673&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: SVN (please specify revision!) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: merge SQL queries for alias domains Initial Comment: >From POSTFIX_CONF.txt: virtual_alias_maps = proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_maps.cf, proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_maps.cf, proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_catchall_maps.cf virtual_mailbox_maps = proxy:mysql:/etc/postfix/sql/mysql_virtual_mailbox_maps.cf, proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_mailbox_maps.cf This means MySQL is called twice for mailboxes and three times for aliases (except if the first try returns a result, of course). If possible, we should merge the queries so that alias and mailbox queries always only need one map. SELECT ... UNION SELECT ... UNION SELECT ... doesn't look very nice, but it has a better performance than doing two or three separate queries. Or is there a special reason why we should do separate queries? ---------------------------------------------------------------------- Comment By: Guido Boehm (lenix) Date: 2008-06-09 00:59 Message: Logged In: YES user_id=142401 Originator: NO with the query i mentioned your testcase would result in 2 rows being returned. at least for me the first result was always the one where alias.address='%s' matched, so one could just append "LIMIT 1", but i'm not sure how consistent this is, maybe there's some mysql-professional who could tell? // lenix ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2008-06-09 00:35 Message: Logged In: YES user_id=593261 Originator: YES To make things more interesting: We still allow to have separate aliases on a domain that is defined as alias domain. This is not really bad (and might even be useful in some cases), but it might lead to interesting ;-) setups. For example, there could be the following setup: alias domain: foo.de -> bar.de alias: us...@ba... -> use...@ex... alias: us...@fo... -> use...@ex... In this case, I would expect that mails sent to us...@fo... are forwarded to user-foo@, not user-bar@. With the separate queries, it should work - but I'm not sure about the merged one. Please add such a setup to your testcase ;-) If it turns out that merging the queries is too complicated, creating a function inside MySQL could be an option for those who want better performance. Users who don't want to do this (or can't because they still use MySQL 4) could still use the separated queries. ---------------------------------------------------------------------- Comment By: Guido Boehm (lenix) Date: 2008-06-08 20:02 Message: Logged In: YES user_id=142401 Originator: NO hi christian, after re-thinking the way postfix does lookups it appears to me it already does run 2 queries per item in 'virtual_alias_maps': - a first try for exact matches (looking up the key 'bo...@ex...') - if the first try didn't give any results a second try for catchall (looking up the key '@example.com') based on this assumption i created the following query which should be able to replace the 3 virtual_alias_maps-queries in the current setup: SELECT alias.goto FROM alias LEFT JOIN alias_domain ON alias_domain.alias_domain = '%d' WHERE alias.active = 1 AND ( alias.address='%s' OR (alias_domain.alias_domain='%d' AND alias.address=CONCAT('%u','@',alias_domain.target_domain)) ) although i did run a set of test-queries against my own database which looked promising i don't have the time to extensivly test it inside my postfix-setup right now. i'll try to do this next week and keep you updated. thanks for your patience, lenix ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1973673&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2008-06-08 22:35:28
|
Feature Requests item #1973673, was opened at 2008-05-27 01:04 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1973673&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None >Group: SVN (please specify revision!) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: merge SQL queries for alias domains Initial Comment: >From POSTFIX_CONF.txt: virtual_alias_maps = proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_maps.cf, proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_maps.cf, proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_catchall_maps.cf virtual_mailbox_maps = proxy:mysql:/etc/postfix/sql/mysql_virtual_mailbox_maps.cf, proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_mailbox_maps.cf This means MySQL is called twice for mailboxes and three times for aliases (except if the first try returns a result, of course). If possible, we should merge the queries so that alias and mailbox queries always only need one map. SELECT ... UNION SELECT ... UNION SELECT ... doesn't look very nice, but it has a better performance than doing two or three separate queries. Or is there a special reason why we should do separate queries? ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2008-06-09 00:35 Message: Logged In: YES user_id=593261 Originator: YES To make things more interesting: We still allow to have separate aliases on a domain that is defined as alias domain. This is not really bad (and might even be useful in some cases), but it might lead to interesting ;-) setups. For example, there could be the following setup: alias domain: foo.de -> bar.de alias: us...@ba... -> use...@ex... alias: us...@fo... -> use...@ex... In this case, I would expect that mails sent to us...@fo... are forwarded to user-foo@, not user-bar@. With the separate queries, it should work - but I'm not sure about the merged one. Please add such a setup to your testcase ;-) If it turns out that merging the queries is too complicated, creating a function inside MySQL could be an option for those who want better performance. Users who don't want to do this (or can't because they still use MySQL 4) could still use the separated queries. ---------------------------------------------------------------------- Comment By: Guido Boehm (lenix) Date: 2008-06-08 20:02 Message: Logged In: YES user_id=142401 Originator: NO hi christian, after re-thinking the way postfix does lookups it appears to me it already does run 2 queries per item in 'virtual_alias_maps': - a first try for exact matches (looking up the key 'bo...@ex...') - if the first try didn't give any results a second try for catchall (looking up the key '@example.com') based on this assumption i created the following query which should be able to replace the 3 virtual_alias_maps-queries in the current setup: SELECT alias.goto FROM alias LEFT JOIN alias_domain ON alias_domain.alias_domain = '%d' WHERE alias.active = 1 AND ( alias.address='%s' OR (alias_domain.alias_domain='%d' AND alias.address=CONCAT('%u','@',alias_domain.target_domain)) ) although i did run a set of test-queries against my own database which looked promising i don't have the time to extensivly test it inside my postfix-setup right now. i'll try to do this next week and keep you updated. thanks for your patience, lenix ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1973673&group_id=191583 |
700 messages has been excluded from this view by a project administrator.
