postfixadmin-tracker Mailing List for PostfixAdmin (Page 3)
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...> - 2013-01-22 19:24:26
|
Bugs item #3601798, was opened at 2013-01-22 11:24 Message generated for change (Tracker Item Submitted) made by z0l0ft You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3601798&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: Z0l0ft (z0l0ft) Assigned to: Nobody/Anonymous (nobody) Summary: index.php and login.php should check for active session Initial Comment: When entering: https://postfixurl/ https://postfixurl/index.php https://postfixurl/login.php one should be redirected to https://postfixurl/main.php if there is a valid administrator session. As it is now one can easily be tricked into believing one is logged out when entering root page or login page. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3601798&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2013-01-21 16:17:29
|
Bugs item #3601648, was opened at 2013-01-21 08:17 Message generated for change (Tracker Item Submitted) made by vdenaropapa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3601648&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Vincenzo De Naro Papa (vdenaropapa) Assigned to: Nobody/Anonymous (nobody) Summary: Display quota for users don't use Dovecot Initial Comment: Hi, i've setup Postfixadmin correctly but i would like to know if there is some trick to show "used_quota" for users like me that don't use Dovecot. I'm using Courier. Can you help me? Thanks in advance. Vincenzo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3601648&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2013-01-16 04:00:16
|
Bugs item #3266874, was opened at 2011-04-01 02:09 Message generated for change (Comment added) made by i18ner You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3266874&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: v2.3.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gabriele Vivinetto (gabrielev) Assigned to: Nobody/Anonymous (nobody) Summary: Translation is not applied in squirrelmail plugin options Initial Comment: Althoug the mo files are generated via build.sh, and the main options menu items are translated, in wvry plugin options page, language is resetted to English ---------------------------------------------------------------------- Comment By: I18N (i18ner) Date: 2013-01-15 20:00 Message: I of course meant to say "In common.php, comment out the line that calls include_if_exists()". ---------------------------------------------------------------------- Comment By: I18N (i18ner) Date: 2013-01-15 19:56 Message: I can reproduce this bug in FreeBSD 9.1-RELEASE using the latest ports; squirrelmail 1.4.22 and squirrelmail-postfixadmin-plugin (2.3.0). The steps to reproduce are: 1. Set your browser's preffered language to en_US. 2. Set the default squirrelmail language to something other than en_US and make sure it's supported by both squirrelmail and the postfix squirrelmail-plugin. 3. Open squirrelmail and look at the main options menu, try to set up forwarding/vacation/password. Compare with the screenshots. Technical conclusions (I'm a php noob, please bear with me): This is a problem with dependencies and scope in the function include_if_exists() in functions.inc.php that is being called around line 13 in common.php with the parameter "SM_PATH . 'include/validate.php'". Validate.php depends on "SM_PATH . 'functions/i18n.php'", which has an undocumented dependency on the global variable $squirrelmail_default_language (declared in "SM_PATH . 'config/config.php' ) inside the set_up_language() function. This variable is not in the scope of include_if_exists(), which will cause it to appear as empty when set_up_language() is called. When set_up_language() doesn't see the default language, it will try to get the preferred language from the HTTP_ACCEPT_LANGUAGE header instead. That is fine and explained in the squirrelmail documentation. However, our browser is set to en_US and squirrelmail is set to something different, hence we get this bug. NOTE: In the plugin's common.php, there's a conditional statement after the call to include_if_exists(), which will make no difference, due to the static variable $Setup_Already, declared in set_up_language(). How to fix: In common.php, uncomment the line that calls include_if_exists(). The conditional statement which follows it will make sure that validate.php is included in the global scope. To make things as clear as possible, here's some diff output. Common.php.old is identical to the latest common.php. --- common.php.old 2013-01-14 03:02:33.000000000 +0100 +++ common.php.new 2013-01-14 03:01:52.000000000 +0100 @@ -10,7 +10,7 @@ } include_once(SM_PATH . 'plugins/postfixadmin/config.php'); include_once(SM_PATH . 'plugins/postfixadmin/functions.inc.php'); -include_if_exists(SM_PATH . 'include/validate.php'); +//include_if_exists(SM_PATH . 'include/validate.php'); if (file_exists(SM_PATH . 'include/validate.php')) { include_once(SM_PATH . 'include/validate.php'); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3266874&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2013-01-16 03:56:53
|
Bugs item #3266874, was opened at 2011-04-01 02:09 Message generated for change (Comment added) made by i18ner You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3266874&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: v2.3.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gabriele Vivinetto (gabrielev) Assigned to: Nobody/Anonymous (nobody) Summary: Translation is not applied in squirrelmail plugin options Initial Comment: Althoug the mo files are generated via build.sh, and the main options menu items are translated, in wvry plugin options page, language is resetted to English ---------------------------------------------------------------------- Comment By: I18N (i18ner) Date: 2013-01-15 19:56 Message: I can reproduce this bug in FreeBSD 9.1-RELEASE using the latest ports; squirrelmail 1.4.22 and squirrelmail-postfixadmin-plugin (2.3.0). The steps to reproduce are: 1. Set your browser's preffered language to en_US. 2. Set the default squirrelmail language to something other than en_US and make sure it's supported by both squirrelmail and the postfix squirrelmail-plugin. 3. Open squirrelmail and look at the main options menu, try to set up forwarding/vacation/password. Compare with the screenshots. Technical conclusions (I'm a php noob, please bear with me): This is a problem with dependencies and scope in the function include_if_exists() in functions.inc.php that is being called around line 13 in common.php with the parameter "SM_PATH . 'include/validate.php'". Validate.php depends on "SM_PATH . 'functions/i18n.php'", which has an undocumented dependency on the global variable $squirrelmail_default_language (declared in "SM_PATH . 'config/config.php' ) inside the set_up_language() function. This variable is not in the scope of include_if_exists(), which will cause it to appear as empty when set_up_language() is called. When set_up_language() doesn't see the default language, it will try to get the preferred language from the HTTP_ACCEPT_LANGUAGE header instead. That is fine and explained in the squirrelmail documentation. However, our browser is set to en_US and squirrelmail is set to something different, hence we get this bug. NOTE: In the plugin's common.php, there's a conditional statement after the call to include_if_exists(), which will make no difference, due to the static variable $Setup_Already, declared in set_up_language(). How to fix: In common.php, uncomment the line that calls include_if_exists(). The conditional statement which follows it will make sure that validate.php is included in the global scope. To make things as clear as possible, here's some diff output. Common.php.old is identical to the latest common.php. --- common.php.old 2013-01-14 03:02:33.000000000 +0100 +++ common.php.new 2013-01-14 03:01:52.000000000 +0100 @@ -10,7 +10,7 @@ } include_once(SM_PATH . 'plugins/postfixadmin/config.php'); include_once(SM_PATH . 'plugins/postfixadmin/functions.inc.php'); -include_if_exists(SM_PATH . 'include/validate.php'); +//include_if_exists(SM_PATH . 'include/validate.php'); if (file_exists(SM_PATH . 'include/validate.php')) { include_once(SM_PATH . 'include/validate.php'); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3266874&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2012-12-07 13:04:11
|
Bugs item #3591094, was opened at 2012-11-29 08:34 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3591094&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Oliver Salzburg () Assigned to: Nobody/Anonymous (nobody) Summary: Invalid Parameter Initial Comment: When I click "Virtual List" I get a message: Invalid parameter! If you see this message, please open a bugreport This is the bugreport ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2012-12-07 05:04 Message: Thanks for the report! The message indicates that I check I considered obsolete is still needed ;-) Some questions: - which version of PostfixAdmin do you use? - what exactly did you do when the message appeared? - were you logged in as superadmin or as domain admin? - how many domains do you have in PostfixAdmin? If you were logged in as domain admin, how many domains does this admin have? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3591094&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2012-11-29 16:34:20
|
Bugs item #3591094, was opened at 2012-11-29 08:34 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3591094&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Oliver Salzburg () Assigned to: Nobody/Anonymous (nobody) Summary: Invalid Parameter Initial Comment: When I click "Virtual List" I get a message: Invalid parameter! If you see this message, please open a bugreport This is the bugreport ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3591094&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2012-10-29 16:38:07
|
Bugs item #3581342, was opened at 2012-10-28 07:06 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3581342&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: v2.3.5 >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Patrik Karisch () Assigned to: Nobody/Anonymous (nobody) Summary: Domain admins can't modify self created aliases Initial Comment: My domain admins can't modify self created aliases. Postfixadmin quits with following message: Check config.inc.php - domain administrators do not have the ability to edit user's aliases (alias_control_admin) ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2012-10-29 09:38 Message: The error message already gives you a hint - set $CONF[alias_control_admin] to YES if you want to edit mailbox aliases as domain admin. Does it work with this config change? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3581342&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2012-10-28 14:06:17
|
Bugs item #3581342, was opened at 2012-10-28 07:06 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3581342&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: v2.3.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Patrik Karisch () Assigned to: Nobody/Anonymous (nobody) Summary: Domain admins can't modify self created aliases Initial Comment: My domain admins can't modify self created aliases. Postfixadmin quits with following message: Check config.inc.php - domain administrators do not have the ability to edit user's aliases (alias_control_admin) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3581342&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2012-10-25 08:36:47
|
Feature Requests item #3580061, was opened at 2012-10-25 01:36 Message generated for change (Tracker Item Submitted) made by deisler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3580061&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: Interface Improvements (example) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: deisler (deisler) Assigned to: Nobody/Anonymous (nobody) Summary: add default size quota option for domain settings Initial Comment: Hello. Add default size quota as options for domain settings, please. This option should be given an opportunity to establish default size quota for the domain when creating the mailbox. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3580061&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2012-10-23 02:39:37
|
Bugs item #3575816, was opened at 2012-10-09 12:07 Message generated for change (Comment added) made by sabitov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3575816&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: Interface (example) Group: v2.3.5 Status: Open Resolution: Invalid Priority: 4 Private: No Submitted By: Mariano Absatz (el_baby) Assigned to: Nobody/Anonymous (nobody) Summary: UTF-8 displayed as ISO-8859 Initial Comment: Hi, I installed ubuntu's package (http://archive.ubuntu.com/ubuntu/pool/universe/p/postfixadmin/postfixadmin_2.3.5-2_all.deb) and configured it to use apache2 and postgresql. The database was created OK using UTF-8. I enter accented characters and they're properly handled (I can check this using phppgadmin). However, when I browse domains or users whose names or descriptions have accented characters, they show up as 2 weird characters (this is what normally happens when UTF-8 chars are interpreted as ISO-8859-X). If I try to edit the name in postfixadmin, the field to be edited displays OK. The problem is when it is being "shown". Using stock ubuntu server 12.04 ---------------------------------------------------------------------- Comment By: sabitov (sabitov) Date: 2012-10-22 19:39 Message: Sorry for that, but what exactly should be changed? ---------------------------------------------------------------------- Comment By: Mariano Absatz (el_baby) Date: 2012-10-13 14:51 Message: I see... the problem is that I'm using quantal's .deb in precise (which has php 5.3.1). I edited a couple of source files and fixed it. Thanx for your help. ---------------------------------------------------------------------- Comment By: ColdSmile (coldsmile) Date: 2012-10-13 14:29 Message: htmlentities() The default value for the encoding parameter was changed to UTF-8 since 5.4.0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3575816&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2012-10-16 10:45:26
|
Bugs item #3489740, was opened at 2012-02-20 12:29 Message generated for change (Comment added) made by nervoso You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3489740&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: v2.3.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: AJ (koga73) Assigned to: Nobody/Anonymous (nobody) Summary: dovecot SHA256 problem Initial Comment: I tried using dovecot:SHA256 to hash my passwords. I finally got it working after some code modifications. For one dovecotpw is now doveadm pw. I generated my hash using doveadm pw -s SHA256 and updated the database. PostfixAdmin would not log in and threw no errors. After echoing the hash that PFA was generating I realized two things: The PFA generated hash trims the encryption scheme (whats the purpose?). This creates problems for dovecot when using a SHA hash. The PFA generated hash has a new line character "\n" at the end. To fix the hashing issues I made the following change: MODIFIED THIS LINE: $password = trim(str_replace('{' . $method . '}', '', $password)); TO THIS: $password = rtrim($password); Now I am able to keep the encryption scheme in the database and the modified code trims the newline character off the end of the hash. ---------------------------------------------------------------------- Comment By: Luca Gibelli (nervoso) Date: 2012-10-16 03:45 Message: # dovecot --version 1.2.9 ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2012-10-16 03:29 Message: Hi, 1. config.inc.php does contain comments to suggest using either dovecotpw or doveadm pw - depending on the version of dovecot - see around the setting for : // If you use the dovecot encryption method: where is the dovecotpw binary located? // for dovecot 1.x // $CONF['dovecotpw'] = "/usr/sbin/dovecotpw"; // for dovecot 2.x (dovecot 2.0.0 - 2.0.7 is not supported!) $CONF['dovecotpw'] = "/usr/sbin/doveadm pw"; Presumably the str_replace stuff is/was the behaviour necessary from Dovecot 1.x perhaps? (I know I've had dovecot working with PFA in the past). ---------------------------------------------------------------------- Comment By: Luca Gibelli (nervoso) Date: 2012-10-16 03:23 Message: +1 for this I faced the same problem and solved it the same way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3489740&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2012-10-16 10:29:02
|
Bugs item #3489740, was opened at 2012-02-20 12:29 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3489740&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: v2.3.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: AJ (koga73) Assigned to: Nobody/Anonymous (nobody) Summary: dovecot SHA256 problem Initial Comment: I tried using dovecot:SHA256 to hash my passwords. I finally got it working after some code modifications. For one dovecotpw is now doveadm pw. I generated my hash using doveadm pw -s SHA256 and updated the database. PostfixAdmin would not log in and threw no errors. After echoing the hash that PFA was generating I realized two things: The PFA generated hash trims the encryption scheme (whats the purpose?). This creates problems for dovecot when using a SHA hash. The PFA generated hash has a new line character "\n" at the end. To fix the hashing issues I made the following change: MODIFIED THIS LINE: $password = trim(str_replace('{' . $method . '}', '', $password)); TO THIS: $password = rtrim($password); Now I am able to keep the encryption scheme in the database and the modified code trims the newline character off the end of the hash. ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2012-10-16 03:29 Message: Hi, 1. config.inc.php does contain comments to suggest using either dovecotpw or doveadm pw - depending on the version of dovecot - see around the setting for : // If you use the dovecot encryption method: where is the dovecotpw binary located? // for dovecot 1.x // $CONF['dovecotpw'] = "/usr/sbin/dovecotpw"; // for dovecot 2.x (dovecot 2.0.0 - 2.0.7 is not supported!) $CONF['dovecotpw'] = "/usr/sbin/doveadm pw"; Presumably the str_replace stuff is/was the behaviour necessary from Dovecot 1.x perhaps? (I know I've had dovecot working with PFA in the past). ---------------------------------------------------------------------- Comment By: Luca Gibelli (nervoso) Date: 2012-10-16 03:23 Message: +1 for this I faced the same problem and solved it the same way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3489740&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2012-10-16 10:23:10
|
Bugs item #3489740, was opened at 2012-02-20 12:29 Message generated for change (Comment added) made by nervoso You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3489740&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: v2.3.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: AJ (koga73) Assigned to: Nobody/Anonymous (nobody) Summary: dovecot SHA256 problem Initial Comment: I tried using dovecot:SHA256 to hash my passwords. I finally got it working after some code modifications. For one dovecotpw is now doveadm pw. I generated my hash using doveadm pw -s SHA256 and updated the database. PostfixAdmin would not log in and threw no errors. After echoing the hash that PFA was generating I realized two things: The PFA generated hash trims the encryption scheme (whats the purpose?). This creates problems for dovecot when using a SHA hash. The PFA generated hash has a new line character "\n" at the end. To fix the hashing issues I made the following change: MODIFIED THIS LINE: $password = trim(str_replace('{' . $method . '}', '', $password)); TO THIS: $password = rtrim($password); Now I am able to keep the encryption scheme in the database and the modified code trims the newline character off the end of the hash. ---------------------------------------------------------------------- Comment By: Luca Gibelli (nervoso) Date: 2012-10-16 03:23 Message: +1 for this I faced the same problem and solved it the same way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3489740&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2012-10-13 21:51:57
|
Bugs item #3575816, was opened at 2012-10-09 12:07 Message generated for change (Comment added) made by el_baby You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3575816&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: Interface (example) Group: v2.3.5 Status: Open >Resolution: Invalid Priority: 4 Private: No Submitted By: Mariano Absatz (el_baby) Assigned to: Nobody/Anonymous (nobody) Summary: UTF-8 displayed as ISO-8859 Initial Comment: Hi, I installed ubuntu's package (http://archive.ubuntu.com/ubuntu/pool/universe/p/postfixadmin/postfixadmin_2.3.5-2_all.deb) and configured it to use apache2 and postgresql. The database was created OK using UTF-8. I enter accented characters and they're properly handled (I can check this using phppgadmin). However, when I browse domains or users whose names or descriptions have accented characters, they show up as 2 weird characters (this is what normally happens when UTF-8 chars are interpreted as ISO-8859-X). If I try to edit the name in postfixadmin, the field to be edited displays OK. The problem is when it is being "shown". Using stock ubuntu server 12.04 ---------------------------------------------------------------------- >Comment By: Mariano Absatz (el_baby) Date: 2012-10-13 14:51 Message: I see... the problem is that I'm using quantal's .deb in precise (which has php 5.3.1). I edited a couple of source files and fixed it. Thanx for your help. ---------------------------------------------------------------------- Comment By: ColdSmile (coldsmile) Date: 2012-10-13 14:29 Message: htmlentities() The default value for the encoding parameter was changed to UTF-8 since 5.4.0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3575816&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2012-10-13 21:29:39
|
Bugs item #3575816, was opened at 2012-10-09 12:07 Message generated for change (Comment added) made by coldsmile You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3575816&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: Interface (example) Group: v2.3.5 Status: Open Resolution: None Priority: 4 Private: No Submitted By: Mariano Absatz (el_baby) Assigned to: Nobody/Anonymous (nobody) Summary: UTF-8 displayed as ISO-8859 Initial Comment: Hi, I installed ubuntu's package (http://archive.ubuntu.com/ubuntu/pool/universe/p/postfixadmin/postfixadmin_2.3.5-2_all.deb) and configured it to use apache2 and postgresql. The database was created OK using UTF-8. I enter accented characters and they're properly handled (I can check this using phppgadmin). However, when I browse domains or users whose names or descriptions have accented characters, they show up as 2 weird characters (this is what normally happens when UTF-8 chars are interpreted as ISO-8859-X). If I try to edit the name in postfixadmin, the field to be edited displays OK. The problem is when it is being "shown". Using stock ubuntu server 12.04 ---------------------------------------------------------------------- Comment By: ColdSmile (coldsmile) Date: 2012-10-13 14:29 Message: htmlentities() The default value for the encoding parameter was changed to UTF-8 since 5.4.0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3575816&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2012-10-10 11:20:18
|
Bugs item #3576009, was opened at 2012-10-10 04:20 Message generated for change (Tracker Item Submitted) made by mindcontrolled You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3576009&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: v2.3.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martijn (mindcontrolled) Assigned to: Nobody/Anonymous (nobody) Summary: Several issues with pacrypt() Initial Comment: I would like to bring to your attention what I think are several (related) issues with pacrypt(). Simply skip to "Issues" if you're in a hurry ;-) Situation: currently I'm working on a virtual mail system based on - Postfix (2.7.x) as SMTP only, no LDA - Dovecot (1.x) as LDA / POP3 / IMAP - Postfixadmin for simple mailbox management The data on this system will be coming from an older platform, which uses crypt-md5 ($1$...) salted hashed passwords. For newly made accounts we intent to use the superiour SHA-512 ($6$...) instead. Together with the $version$-strings in crypt()'s hashes, this provides for an excellent way to gradually upgrade everyone to the stronger hash: - Accounts with older passwords are still able to log in. - New accounts or account that have their password changed will be given the stronger SHA-512 hash and profit from better hashing. Now, let's see about the availability of SHA-512 in the surrounding systems: - Dovecot 1.x password scheme 'CRYPT' will support all the hashing methods available to crypt() from glibc on the system, according to http://wiki.dovecot.org/Authentication/PasswordSchemes - For a system with glibc v2.7+, this usually means SHA-256 ($5$...) and (our choice) SHA-512 are available. - For upgraders, Dovecot 2.x will support 'SHA512-CRYPT' - http://wiki2.dovecot.org/Authentication/PasswordSchemes - For PHP it's pretty much the same thing: http://php.net/manual/en/function.crypt.php - for PHP < 5.3.0 it can use what's available in glibc, and for > 5.3.0 it uses it's own implementation if glibc lacks support. - Postfix is a bit of a question mark for me. I've seen examples that used MySQL's encrypt() to match the password, which makes for a 30+ year old Standard DES hash... I figured the same could work with a non-crypt non-salted MD5() in MySQL. I've also seen hashmaps built from plaintext. None of those options are very encouraging imho. In our case however, it won't matter since SMTP-AUTH on Postfix can use "smtpd_sasl_type = dovecot". In other words: Postfix will ask Dovecot if the SMTP-AUTH password is correct and not even try to figure it out by itself ;-) Summing it up, this looks like we're pretty much safe to use SHA-512 hashes on the main software, now what about Postfixadmin? I've set up my 2.3.5 installation and configured my $CONF['crypt'] to be 'system' as that seemed like the closest option to crypt() for me. Issues: 1. The config mentions that 'system' is 'whatever you have set as your PHP system default'. But PHP doesn't really have a system default for that, or at least not one that can be set by the user. What PHP's crypt() will be using automatically seems to be defined by what's likely to be compatible, instead of what's safe. And before actually generating a hash, I don't believe it's possible to see which of the hashing methods crypt() is going to choose. In my tests on a modern Ubuntu system with PHP 5.3.x, calling crypt() without pre-setup (like '$6$rounds=5000$[...salt...]$) salt provides me with a Standard DES hash, just the least it can do. To force PHP crypt() to generate a (new) SHA-512 password we must provide it with a pre-setup version string and salt. This has to be configurable in Postfixadmin. The configured hashing method should only be forced on hashes we're newly creating, and not on password checking: crypt() will already take care of that (see my second point below). This way, 'system' is compatible with checking all versions of crypt() hashes in the database, and chooses the preferred hashing method for new accounts. 2. After putting some SHA-512 hashes into the database, I noticed Postfixadmin has trouble reading the passwords although it is using crypt() to check. I had a look at the loop that's used for 'system' but I can't figure out what it's supposed to do exactly. For what I can tell, it can only do crypt-md5, which would make it equal to the seperately configurable 'crypt-md5' in config.inc.php. If you want to check a password with PHP crypt(), just feed it the entire password from the database. crypt() will extract the salt automatically and then use it to hash the provided password from the first function argument. This would make all the code needed just for checking a password for 'system' like this: if (strlen($pw_db) !== 0) { $password = crypt($pw, $pw_db); } [...] return $password; For generating a new password with a specific hash method, a setting should be used. Summing up 1 and 2, a start for a backwards compatible patch is included. It could use some more refining. I haven't tested it thoroughly, but it does work well on my data. It currently misses support for extended DES (old) and blowfish (recommended), and also I don't check on the variables indicating whether or not a hashing method is available in PHP since I didn't see an easy way to bring that error to the user. But it's a start. 3. Please do not escape passwords before hashing them ;-) I noticed this was reported and also reported fixed so no need to get into that. Unrelated: 4. The minimum password length seems to be enforced when changing the password only, not when creating an admin or mailbox. Is this intended behaviour? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3576009&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2012-10-09 19:22:07
|
Patches item #3508083, was opened at 2012-03-18 14:16 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=3508083&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: J.Kruis (jan-kruis) Assigned to: Nobody/Anonymous (nobody) Summary: vacation with choice of reply Initial Comment: This patch provides users and administrators the ability to choose between three types of reply. one reply autoreply reply with delay ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2012-10-09 12:22 Message: (sorry for the delay - I'd need days with at least 30 hours ;-) > // as well to add a entry pReplychoice_xxxxxx to the the > [postfixhomedir]/languages/en.lang and your onw contry file using $CONF['language_hook'] might be the better solution for custom texts/translations. > Question 1 > Can i work with a array of 3 items like > $CONF['choice_of_reply'] = array ( > 'one reply', '0', 'pReplychoice_ones', No, but you can do it in a much easier way - just drop the first "column" ;-) AFAIK texts like "one reply" aren't used anywhere, which means they are superfluous ;-) If you really need an array with 3 "columns", you can use nested arrays - but this shouldn't be needed here. $CONF['choice_of_reply'] = array( // seconds => text 0 => 'pReplychoice_ones', 1 => 'pReplychoice_autoreply', 60*60 => 'pReplychoice_hourly', 24*60*60 => 'pReplychoice_daily', ); > Questing 2 > how can display a list using the above array foreach ( $CONF['choice_of_reply'] as $interval => $text ) { echo "$interval - $text"; } > type of reply and interval should by stored in the database and the > translation string referred by pReplychoice… should be displayed as a > list. As I said above - storing the integer value (0 for "reply once", 1 for "autoreply", > 1 for seconds between autoreplies) is enough ;-) ---------------------------------------------------------------------- Comment By: J.Kruis (jan-kruis) Date: 2012-08-04 13:16 Message: Hi Christian, You are right $ CONF ['usercontol'] and $ CONFIG ['users_domain_controle'] which are not used yet also $ CONF ['vacation_replytype_control'] and $ CONFIG ['vacation_allow_user_reply'] are not used yet These items should not have been included in this patch but I was already working on Patch 352593 [UserControl] I have With concern to $ CONF ['choice_of_reply'] i also agree with you. I would like to change in the form of an array and applying with the language files, but my knowledge of programming in PHP is somewhat limited so help is welcome I am thinking of adding this into config.inc.php [Code] // Get the user or Admin a choice of reply // If you want to add a extra type of reply you MUST add this choice to the interval_time arry below // as well to add a entry pReplychoice_xxxxxx to the the [postfixhomedir]/languages/en.lang and your onw contry file $CONF['choice_of_reply'] = array ( 'One Reply' => 'pReplychoice_ones', // Only Reply ones on a email 'Auto Reply' => 'pReplychoice_auto_reply', // Send no email if last email was send within 10 sec. see interval_time [Auto Reply] 'One Hour' => 'PReplychoice_one_hour', // Send only a reply to a email if the last 1 hour ago. see interval_time [One Hour] 'One Day' => 'pReplychoice_one_day', // Send only a reply to a email if the last 1 day ago. see interval_time [One Day] 'One Week' => 'pReplychoice_one_week' // Send only a reply to a email if the last 1 week ago. see interval_time [One Week] ); // Get the time according to choice of reply (see above entry) // If your have add a extra choice add that choice also below in this array $CONF['interval_time'] = array ( 'One Reply' => '0', // 0 means only one reply this value MUST be Zero en may not be change 'Auto Reply' => '10', // This is your autoreplydelay time adjust this value to your needs 'One Hour' => '3600', // one hour = 60 * 60 seconds 'One Day' => '86400', // One day = 60 * 60 * 24 seconds 'One Week' => '604800' // One week = 60 * 60 * 24 * 7 seconds ); [/CODE] or is it better to place this array I vacation.php Question 1 Can i work with a array of 3 items like $CONF['choice_of_reply'] = array ( //type of reply interval time translation string 'one reply', '0', 'pReplychoice_ones', 'auto reply', '10', 'pReplychoice_autoreply', … ); Questing 2 how can display a list using the above array type of reply and interval should by stored in the database and the translation string referred by pReplychoice… should be displayed as a list. I have make change to upgrade.php and now used _db_add_field() Regards Jan Kruis ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2012-08-01 15:02 Message: I know I'm late ;-) but unfortunately your patch contains several issues :-( (and you are lucky that David already commited it - I would have rejected it in the current state ;-) The patch introduces two unrelated (and unused?) config options: $CONF['usercontol'] and $CONF['users_domain_controle'] which aren't used. $CONF['vacation_replytype_control'] and $CONF['vacation_allow_user_reply'] aren't used/checked (the fields are always displayed) the texts for $CONF['choice_of_reply'] are hardcoded in several places - does it really make sense to make them configurable? (Besides that, I'd prefer to have them translateable.) if I get the comment in vacation.pl right, only the reply interval is checked ( 0 = onereply, 1 = autoreply, >1 = Delay reply ) - what's the reason for storing the "reply_type" as text in the database? It looks superfluous to me. (BTW: Does it really make sense to let the user enter the interval? IMHO providing the dropdown with some options would be enough, but I don't know your usecase.) upgrade_1345_mysql should use the _db_add_field() function of upgrade.php the upgrade for postgresql users is missing (hint: _db_add_field() can cover both) in vacation.pl, the interval stored in the database silently overrides the config option $interval - this might make sense, but it should at least be documented (and/or the config option removed) Can you please provide an additional patch to solve those issues? ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2012-04-19 14:56 Message: Thank you for the patch; I've not tested it yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=3508083&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2012-10-09 19:07:58
|
Bugs item #3575816, was opened at 2012-10-09 12:07 Message generated for change (Settings changed) made by el_baby You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3575816&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: Interface (example) Group: v2.3.5 Status: Open Resolution: None >Priority: 4 Private: No Submitted By: Mariano Absatz (el_baby) Assigned to: Nobody/Anonymous (nobody) Summary: UTF-8 displayed as ISO-8859 Initial Comment: Hi, I installed ubuntu's package (http://archive.ubuntu.com/ubuntu/pool/universe/p/postfixadmin/postfixadmin_2.3.5-2_all.deb) and configured it to use apache2 and postgresql. The database was created OK using UTF-8. I enter accented characters and they're properly handled (I can check this using phppgadmin). However, when I browse domains or users whose names or descriptions have accented characters, they show up as 2 weird characters (this is what normally happens when UTF-8 chars are interpreted as ISO-8859-X). If I try to edit the name in postfixadmin, the field to be edited displays OK. The problem is when it is being "shown". Using stock ubuntu server 12.04 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3575816&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2012-10-09 19:07:18
|
Bugs item #3575816, was opened at 2012-10-09 12:07 Message generated for change (Tracker Item Submitted) made by el_baby You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3575816&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: Interface (example) Group: v2.3.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mariano Absatz (el_baby) Assigned to: Nobody/Anonymous (nobody) Summary: UTF-8 displayed as ISO-8859 Initial Comment: Hi, I installed ubuntu's package (http://archive.ubuntu.com/ubuntu/pool/universe/p/postfixadmin/postfixadmin_2.3.5-2_all.deb) and configured it to use apache2 and postgresql. The database was created OK using UTF-8. I enter accented characters and they're properly handled (I can check this using phppgadmin). However, when I browse domains or users whose names or descriptions have accented characters, they show up as 2 weird characters (this is what normally happens when UTF-8 chars are interpreted as ISO-8859-X). If I try to edit the name in postfixadmin, the field to be edited displays OK. The problem is when it is being "shown". Using stock ubuntu server 12.04 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3575816&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2012-08-20 20:59:31
|
Feature Requests item #3559985, was opened at 2012-08-20 13:59 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3559985&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: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: desc field for alias Initial Comment: It would be nice if there would be description field for aliases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3559985&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2012-08-04 20:16:58
|
Patches item #3508083, was opened at 2012-03-18 14:16 Message generated for change (Comment added) made by jan-kruis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=3508083&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: J.Kruis (jan-kruis) Assigned to: Nobody/Anonymous (nobody) Summary: vacation with choice of reply Initial Comment: This patch provides users and administrators the ability to choose between three types of reply. one reply autoreply reply with delay ---------------------------------------------------------------------- Comment By: J.Kruis (jan-kruis) Date: 2012-08-04 13:16 Message: Hi Christian, You are right $ CONF ['usercontol'] and $ CONFIG ['users_domain_controle'] which are not used yet also $ CONF ['vacation_replytype_control'] and $ CONFIG ['vacation_allow_user_reply'] are not used yet These items should not have been included in this patch but I was already working on Patch 352593 [UserControl] I have With concern to $ CONF ['choice_of_reply'] i also agree with you. I would like to change in the form of an array and applying with the language files, but my knowledge of programming in PHP is somewhat limited so help is welcome I am thinking of adding this into config.inc.php [Code] // Get the user or Admin a choice of reply // If you want to add a extra type of reply you MUST add this choice to the interval_time arry below // as well to add a entry pReplychoice_xxxxxx to the the [postfixhomedir]/languages/en.lang and your onw contry file $CONF['choice_of_reply'] = array ( 'One Reply' => 'pReplychoice_ones', // Only Reply ones on a email 'Auto Reply' => 'pReplychoice_auto_reply', // Send no email if last email was send within 10 sec. see interval_time [Auto Reply] 'One Hour' => 'PReplychoice_one_hour', // Send only a reply to a email if the last 1 hour ago. see interval_time [One Hour] 'One Day' => 'pReplychoice_one_day', // Send only a reply to a email if the last 1 day ago. see interval_time [One Day] 'One Week' => 'pReplychoice_one_week' // Send only a reply to a email if the last 1 week ago. see interval_time [One Week] ); // Get the time according to choice of reply (see above entry) // If your have add a extra choice add that choice also below in this array $CONF['interval_time'] = array ( 'One Reply' => '0', // 0 means only one reply this value MUST be Zero en may not be change 'Auto Reply' => '10', // This is your autoreplydelay time adjust this value to your needs 'One Hour' => '3600', // one hour = 60 * 60 seconds 'One Day' => '86400', // One day = 60 * 60 * 24 seconds 'One Week' => '604800' // One week = 60 * 60 * 24 * 7 seconds ); [/CODE] or is it better to place this array I vacation.php Question 1 Can i work with a array of 3 items like $CONF['choice_of_reply'] = array ( //type of reply interval time translation string 'one reply', '0', 'pReplychoice_ones', 'auto reply', '10', 'pReplychoice_autoreply', … ); Questing 2 how can display a list using the above array type of reply and interval should by stored in the database and the translation string referred by pReplychoice… should be displayed as a list. I have make change to upgrade.php and now used _db_add_field() Regards Jan Kruis ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2012-08-01 15:02 Message: I know I'm late ;-) but unfortunately your patch contains several issues :-( (and you are lucky that David already commited it - I would have rejected it in the current state ;-) The patch introduces two unrelated (and unused?) config options: $CONF['usercontol'] and $CONF['users_domain_controle'] which aren't used. $CONF['vacation_replytype_control'] and $CONF['vacation_allow_user_reply'] aren't used/checked (the fields are always displayed) the texts for $CONF['choice_of_reply'] are hardcoded in several places - does it really make sense to make them configurable? (Besides that, I'd prefer to have them translateable.) if I get the comment in vacation.pl right, only the reply interval is checked ( 0 = onereply, 1 = autoreply, >1 = Delay reply ) - what's the reason for storing the "reply_type" as text in the database? It looks superfluous to me. (BTW: Does it really make sense to let the user enter the interval? IMHO providing the dropdown with some options would be enough, but I don't know your usecase.) upgrade_1345_mysql should use the _db_add_field() function of upgrade.php the upgrade for postgresql users is missing (hint: _db_add_field() can cover both) in vacation.pl, the interval stored in the database silently overrides the config option $interval - this might make sense, but it should at least be documented (and/or the config option removed) Can you please provide an additional patch to solve those issues? ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2012-04-19 14:56 Message: Thank you for the patch; I've not tested it yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=3508083&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2012-08-01 22:02:52
|
Patches item #3508083, was opened at 2012-03-18 14:16 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=3508083&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: J.Kruis (jan-kruis) Assigned to: Nobody/Anonymous (nobody) Summary: vacation with choice of reply Initial Comment: This patch provides users and administrators the ability to choose between three types of reply. one reply autoreply reply with delay ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2012-08-01 15:02 Message: I know I'm late ;-) but unfortunately your patch contains several issues :-( (and you are lucky that David already commited it - I would have rejected it in the current state ;-) The patch introduces two unrelated (and unused?) config options: $CONF['usercontol'] and $CONF['users_domain_controle'] which aren't used. $CONF['vacation_replytype_control'] and $CONF['vacation_allow_user_reply'] aren't used/checked (the fields are always displayed) the texts for $CONF['choice_of_reply'] are hardcoded in several places - does it really make sense to make them configurable? (Besides that, I'd prefer to have them translateable.) if I get the comment in vacation.pl right, only the reply interval is checked ( 0 = onereply, 1 = autoreply, >1 = Delay reply ) - what's the reason for storing the "reply_type" as text in the database? It looks superfluous to me. (BTW: Does it really make sense to let the user enter the interval? IMHO providing the dropdown with some options would be enough, but I don't know your usecase.) upgrade_1345_mysql should use the _db_add_field() function of upgrade.php the upgrade for postgresql users is missing (hint: _db_add_field() can cover both) in vacation.pl, the interval stored in the database silently overrides the config option $interval - this might make sense, but it should at least be documented (and/or the config option removed) Can you please provide an additional patch to solve those issues? ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2012-04-19 14:56 Message: Thank you for the patch; I've not tested it yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=3508083&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2012-07-18 11:40:42
|
Feature Requests item #3545169, was opened at 2012-07-17 13:13 Message generated for change (Comment added) made by libertytrek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3545169&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Seelenhirt (seelenhirt) Assigned to: Nobody/Anonymous (nobody) Summary: E-Mail validation according to RFC 2822 Initial Comment: When trying to add a new mail box, Postfix Admin rejects some valid email addresses claiming they are invalid (you can find some examples in [1]). If I correctly understand the code the function in question is check_email in functions.inc.php. The regex checking for validity is too simple to encompass the complex universe of email addresses. I suggest the adaption of said function so it conforms to RFC 2822. Some approaches for an implementation in PHP can be found in this article [2]. [1] https://en.wikipedia.org/wiki/Email_address#Valid_email_addresses [2] http://www.linuxjournal.com/article/9585?page=0,0 ---------------------------------------------------------------------- Comment By: Charles (libertytrek) Date: 2012-07-18 04:40 Message: Id disagree that all addresses that may be *technically* valid should be considered valid by postfixadmin. Most mail systems would not consider as valid email addresses with most of the special characters in them. Maybe have a 'fully compliant' option that is disabled by default, but I would never use it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3545169&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2012-07-17 20:13:35
|
Feature Requests item #3545169, was opened at 2012-07-17 13:13 Message generated for change (Tracker Item Submitted) made by seelenhirt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3545169&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Seelenhirt (seelenhirt) Assigned to: Nobody/Anonymous (nobody) Summary: E-Mail validation according to RFC 2822 Initial Comment: When trying to add a new mail box, Postfix Admin rejects some valid email addresses claiming they are invalid (you can find some examples in [1]). If I correctly understand the code the function in question is check_email in functions.inc.php. The regex checking for validity is too simple to encompass the complex universe of email addresses. I suggest the adaption of said function so it conforms to RFC 2822. Some approaches for an implementation in PHP can be found in this article [2]. [1] https://en.wikipedia.org/wiki/Email_address#Valid_email_addresses [2] http://www.linuxjournal.com/article/9585?page=0,0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3545169&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2012-06-30 11:10:57
|
Bugs item #3539027, was opened at 2012-06-29 10:08 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3539027&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: v2.3.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Martijn (mindcontrolled) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot redeclare maildir_name_hook() Initial Comment: This was reported earlier in #3305278 but closed because it could not be reproduced, but I just ran into this so here to see if we can get this solved forever ;-) When this occured, I just downloaded the 2.3.5 tar.gz. Unpacked. Then began editting the config first, going through all the options one by one. I didn't use my previous config file which was from 2.3.3, and I didn't copy any other files over from that version. This 2.3.5 was a clean install. Last thing I changed was maildir_name_hook. I uncommented the function, then attempted to run setup.php for generating a password hash. No error was displayed, but the page stopped rendering right after "Depends on: presence config.inc.php - OK". After the closing </li> there is an empty line in the source, it stops there. In the logs I found a "PHP Fatal error: Cannot redeclare maildir_name_hook() (previously declared in /home/websites/www/postfixadmin/config.inc.php:172) in /home/websites/www/postfixadmin/config.inc.php on line 179". Line 172: The line where function maildir_name_hook starts. Line 179: The line where the function ends by means of a closing curly bracket. If I uncomment the function completely, setup.php runs fine. Uncommenting it stops setup.php from running. Looking at setup.php, line 123 and 126: The first one has a require_once() of the config, but the latter has a require() of the config. So in short, it seems that setup.php is loading config.inc.php twice, once by require_once() plus once by using require(), and the second time PHP will complain and halt on redeclaration of maildir_name_hook(). I'm not sure what the intention of this code is; on line 124 it sets $config_loaded = 1 and then it loads the config again. My initial response would be to remove the require() on line 126. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2012-06-30 04:10 Message: Well, actually config.inc.php is already require_once()'d via common.php, so the inclusion via setup.php is basically superfluous - but I'll keep it nevertheless (but only once) ;-) Thanks for finding the cause of this issue. I fixed it in SVN r 1405 (2.3 branch). SVN trunk seems to be fixed already. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3539027&group_id=191583 |
700 messages has been excluded from this view by a project administrator.
