postfixadmin-tracker Mailing List for PostfixAdmin (Page 63)
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...> - 2007-10-11 09:05:30
|
Bugs item #1811005, was opened at 2007-10-10 18:26 Message generated for change (Comment added) made by rumbaya You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1811005&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: Francois Grange (rumbaya) Assigned to: Nobody/Anonymous (nobody) Summary: Full french language file updated Initial Comment: i post this one because the previous fr.lang file was encoded in ISO8859-8. This file is UTF-8 and updated ---------------------------------------------------------------------- >Comment By: Francois Grange (rumbaya) Date: 2007-10-11 11:05 Message: Logged In: YES user_id=1673988 Originator: YES Yes i have translated an old version, sorry for this mistake. So please forget all my changes i will check with the right file as soon as possible. Christian, many thanks for your help with this ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2007-10-11 00:28 Message: Logged In: YES user_id=593261 Originator: NO File Added: diff_SVN_rumbaya ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2007-10-11 00:27 Message: Logged In: YES user_id=593261 Originator: NO Hmm, I'm confused about your updated file because - several translations are changed (maybe they contained errors - I don't know because I don't understand french) - some translations were removed - a "updated by" comment was removed (Note: If you want some credits, feel free to add yourself. But please don't remove other people.) - require('default.lang') was removed - the new strings listed in www.cboltz.de/tmp/postfixadmin-languages.txt are not included I'll attach a diff showing your changes. Please check if every change was intentional. It looks like you translated an outdated SVN version - at least I have a dejavu on some errors included in it ;-) Please use the current SVN version. You can get it via "svn up" (with some luck, it will even preserve your changes) or download it from the web interface as described in the forum. BTW: 1) You can attach more than one file to a tracker item. No need to open another one. However, you'll have to scroll around to find a "Submit Changes" button (yes, the Sourceforge interface can be confusing) 2) If possible, attach a patch instead of the complete file. 3) If you use a SVN checkout, you can create a patch by running "svn diff". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1811005&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2007-10-10 23:49:58
|
Bugs item #1811214, was opened at 2007-10-11 01:50 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=1811214&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: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: charset problems and missing encoding in welcome mail Initial Comment: from the forum post https://sourceforge.net/forum/message.php?msg_id=4560954 by lfarkas: (+ some additions from me) in welcome mail there are encoding bugs. a) the problem starts with the subject. the subject filed is comes from the language file (at least i assume), but the language file is utf-8 encoded (which is imho the right decision), but the subject line in this case should have to transform to 7bit ready! eg like this (but this is iso-8859-2 not utf-8): Subject: =?iso-8859-2?Q?ATPL_felv=E9teli?= which is not happend with the welcome mails. -> Note to myself: http://php.net/mb_encode_mimeheader can be used to properly encode the header b) the same problem occurred with the message body. even if i edit the config.inc.php in utf-8 the welcome mail's header do not contain a Content-type so mailer use latin1 which is not the always the case. so my suggestion that ... the config.inc.php should have to save as utf-8, but also add the Content-type utf-8 header to the welcome mail. -> the Content-Type header can be passed as additional header -> To be fixed in function smtp_mail() in functions.inc.php, all other files use this function :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1811214&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2007-10-10 22:28:52
|
Bugs item #1811005, was opened at 2007-10-10 18:26 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1811005&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: Francois Grange (rumbaya) Assigned to: Nobody/Anonymous (nobody) Summary: Full french language file updated Initial Comment: i post this one because the previous fr.lang file was encoded in ISO8859-8. This file is UTF-8 and updated ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2007-10-11 00:28 Message: Logged In: YES user_id=593261 Originator: NO File Added: diff_SVN_rumbaya ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2007-10-11 00:27 Message: Logged In: YES user_id=593261 Originator: NO Hmm, I'm confused about your updated file because - several translations are changed (maybe they contained errors - I don't know because I don't understand french) - some translations were removed - a "updated by" comment was removed (Note: If you want some credits, feel free to add yourself. But please don't remove other people.) - require('default.lang') was removed - the new strings listed in www.cboltz.de/tmp/postfixadmin-languages.txt are not included I'll attach a diff showing your changes. Please check if every change was intentional. It looks like you translated an outdated SVN version - at least I have a dejavu on some errors included in it ;-) Please use the current SVN version. You can get it via "svn up" (with some luck, it will even preserve your changes) or download it from the web interface as described in the forum. BTW: 1) You can attach more than one file to a tracker item. No need to open another one. However, you'll have to scroll around to find a "Submit Changes" button (yes, the Sourceforge interface can be confusing) 2) If possible, attach a patch instead of the complete file. 3) If you use a SVN checkout, you can create a patch by running "svn diff". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1811005&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2007-10-10 22:27:24
|
Bugs item #1811005, was opened at 2007-10-10 18:26 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1811005&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: Francois Grange (rumbaya) Assigned to: Nobody/Anonymous (nobody) Summary: Full french language file updated Initial Comment: i post this one because the previous fr.lang file was encoded in ISO8859-8. This file is UTF-8 and updated ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2007-10-11 00:27 Message: Logged In: YES user_id=593261 Originator: NO Hmm, I'm confused about your updated file because - several translations are changed (maybe they contained errors - I don't know because I don't understand french) - some translations were removed - a "updated by" comment was removed (Note: If you want some credits, feel free to add yourself. But please don't remove other people.) - require('default.lang') was removed - the new strings listed in www.cboltz.de/tmp/postfixadmin-languages.txt are not included I'll attach a diff showing your changes. Please check if every change was intentional. It looks like you translated an outdated SVN version - at least I have a dejavu on some errors included in it ;-) Please use the current SVN version. You can get it via "svn up" (with some luck, it will even preserve your changes) or download it from the web interface as described in the forum. BTW: 1) You can attach more than one file to a tracker item. No need to open another one. However, you'll have to scroll around to find a "Submit Changes" button (yes, the Sourceforge interface can be confusing) 2) If possible, attach a patch instead of the complete file. 3) If you use a SVN checkout, you can create a patch by running "svn diff". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1811005&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2007-10-10 22:14:05
|
Bugs item #1811002, was opened at 2007-10-10 18:24 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1811002&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: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Francois Grange (rumbaya) Assigned to: Nobody/Anonymous (nobody) Summary: diff file for french language update Initial Comment: diff file for french language update. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2007-10-11 00:14 Message: Logged In: YES user_id=593261 Originator: NO Let's handle this in https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1811005&group_id=191583 which contains a follow-up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1811002&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2007-10-10 16:26:39
|
Bugs item #1811005, was opened at 2007-10-10 18:26 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=1811005&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: Francois Grange (rumbaya) Assigned to: Nobody/Anonymous (nobody) Summary: Full french language file updated Initial Comment: i post this one because the previous fr.lang file was encoded in ISO8859-8. This file is UTF-8 and updated ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1811005&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2007-10-10 16:24:09
|
Bugs item #1811002, was opened at 2007-10-10 18:24 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=1811002&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: Francois Grange (rumbaya) Assigned to: Nobody/Anonymous (nobody) Summary: diff file for french language update Initial Comment: diff file for french language update. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1811002&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2007-10-10 10:34:25
|
Bugs item #1810646, was opened at 2007-10-10 10:24 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1810646&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: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Levente Farkas (lfarkas) Assigned to: Nobody/Anonymous (nobody) Summary: hungarian lang update Initial Comment: hungarian lang update ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2007-10-10 12:34 Message: Logged In: YES user_id=593261 Originator: NO Added to SVN. Thanks again! ---------------------------------------------------------------------- Comment By: Levente Farkas (lfarkas) Date: 2007-10-10 12:21 Message: Logged In: YES user_id=405207 Originator: YES would you add it then: $PALANG['pEdit_mailbox_name_text'] = 'Teljes név'; ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2007-10-10 12:16 Message: Logged In: YES user_id=593261 Originator: NO Thanks for the translations! I just commited your file to SVN. (Sidenote: you missed pEdit_mailbox_name_text ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1810646&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2007-10-10 10:21:52
|
Bugs item #1810646, was opened at 2007-10-10 10:24 Message generated for change (Comment added) made by lfarkas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1810646&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: Accepted Priority: 5 Private: No Submitted By: Levente Farkas (lfarkas) Assigned to: Nobody/Anonymous (nobody) Summary: hungarian lang update Initial Comment: hungarian lang update ---------------------------------------------------------------------- >Comment By: Levente Farkas (lfarkas) Date: 2007-10-10 12:21 Message: Logged In: YES user_id=405207 Originator: YES would you add it then: $PALANG['pEdit_mailbox_name_text'] = 'Teljes név'; ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2007-10-10 12:16 Message: Logged In: YES user_id=593261 Originator: NO Thanks for the translations! I just commited your file to SVN. (Sidenote: you missed pEdit_mailbox_name_text ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1810646&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2007-10-10 10:15:57
|
Bugs item #1810646, was opened at 2007-10-10 10:24 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1810646&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: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Levente Farkas (lfarkas) Assigned to: Nobody/Anonymous (nobody) Summary: hungarian lang update Initial Comment: hungarian lang update ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2007-10-10 12:16 Message: Logged In: YES user_id=593261 Originator: NO Thanks for the translations! I just commited your file to SVN. (Sidenote: you missed pEdit_mailbox_name_text ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1810646&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2007-10-10 08:24:16
|
Bugs item #1810646, was opened at 2007-10-10 10:24 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=1810646&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: Levente Farkas (lfarkas) Assigned to: Nobody/Anonymous (nobody) Summary: hungarian lang update Initial Comment: hungarian lang update ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1810646&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2007-10-09 19:18:16
|
Bugs item #1699218, was opened at 2007-04-12 15:24 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1699218&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: SVN (please specify revision!) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: not MySQL strict compliant Initial Comment: Trying to run the database script on a database with strict mode is an exercise in futility. Why dates are stored as 0000-00-00 instead of being proper nulls? ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2007-10-09 21:18 Message: Logged In: YES user_id=593261 Originator: NO Gingerdog, you can real all the details on http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html The reporter unfortunately didn't mention where he found problems. According to grep, I think the problem is located in DATABASE_MYSQL.TXT which has several datetime fields with default '0000-00-00'. (Database design (especially encoding) and upgrading has to be discussed anyway. I'll start a thread on the -devel mailinglist.) ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2007-10-09 19:03 Message: Logged In: YES user_id=1761957 Originator: NO Hmm... I had no idea MySQL had a 'strict' mode. Anyone know how to do this? Would making it compliant with 'strict' mode affect PostgreSQL compatibility? (I suspect not, but it's something to be careful about) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1699218&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2007-10-09 19:06:00
|
Bugs item #1728078, was opened at 2007-05-30 09: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=1728078&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: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: benjyamon (benjyamon) Assigned to: Nobody/Anonymous (nobody) Summary: deleting its alias deletes a mailbox Initial Comment: When someone deletes the alias that points to a mailbox, thinking it's extra, postfixadmin actually deletes the mailbox itself -- including calling the $CONF['mailbox_postdeletion_script'] I thought I'd simply edit the languages/en.lang since most all our domain admins are english speaking, but the $PALANG['confirm'] = 'Are you sure you want to delete this?\n'; is used all sorts of places so it doesn't work to add a (specifig) warning here. Really what I think should happen is that when attempting to delete an alias, it is checked to see weather this is a mailbox alias, and if so, give the admin an error message. . . I know we could turn off $CONF['alias_control_admin'] but we do want admins to be able to edit mailbox aliases. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2007-10-09 21:06 Message: Logged In: YES user_id=593261 Originator: NO I guess I can clarify this. - In 2.1, every mailbox had an alias in the alias list. - In current SVN, the alias is listed in the mailbox table ("edit alias" link, next to the "edit mailbox" link) This means: The behaviour is the same, but thanks to the re-arrangement of the table, it is clearly understandable now that both alias and mailbox will be deleted. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2007-10-09 19:01 Message: Logged In: YES user_id=1761957 Originator: NO I can't replicate this in the current subversion version. I'm closing this ticket for now - but if it is actually still a problem (and I'm stupid/incapable of testing or whatever), please reopen it and we'll take another look thanks! David. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1728078&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2007-10-09 18:56:07
|
Bugs item #1752057, was opened at 2007-07-11 17:59 Message generated for change (Settings changed) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1752057&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Ric Flomag (ricflomag) Assigned to: Nobody/Anonymous (nobody) Summary: create domain: leaving fields blank leads to Mysql error Initial Comment: Using Postfix Admin 2.1.0: * go to the super admin page (/admin) * go to the "new domain" page * enter the name of the domain, but leave "alias" and "mailboxes" fields blank * click "add domain" --> a debug error is thrown because of a malformed mysql query. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2007-10-09 18:53 Message: Logged In: YES user_id=1761957 Originator: NO Hi, Bug found, and fixed. Thank you for reporting it :-) See changeset 144. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1752057&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2007-10-09 17:05:49
|
Bugs item #1694669, was opened at 2007-04-05 00:14 Message generated for change (Comment added) made by gingerdog 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: 5 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: GingerDog (gingerdog) Date: 2007-10-09 17: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 20: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...> - 2007-10-09 17:03:37
|
Bugs item #1699218, was opened at 2007-04-12 13:24 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1699218&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: not MySQL strict compliant Initial Comment: Trying to run the database script on a database with strict mode is an exercise in futility. Why dates are stored as 0000-00-00 instead of being proper nulls? ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2007-10-09 17:03 Message: Logged In: YES user_id=1761957 Originator: NO Hmm... I had no idea MySQL had a 'strict' mode. Anyone know how to do this? Would making it compliant with 'strict' mode affect PostgreSQL compatibility? (I suspect not, but it's something to be careful about) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1699218&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2007-10-09 17:01:37
|
Bugs item #1728078, was opened at 2007-05-30 07:12 Message generated for change (Settings changed) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1728078&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: Closed Resolution: None Priority: 5 Private: No Submitted By: benjyamon (benjyamon) Assigned to: Nobody/Anonymous (nobody) Summary: deleting its alias deletes a mailbox Initial Comment: When someone deletes the alias that points to a mailbox, thinking it's extra, postfixadmin actually deletes the mailbox itself -- including calling the $CONF['mailbox_postdeletion_script'] I thought I'd simply edit the languages/en.lang since most all our domain admins are english speaking, but the $PALANG['confirm'] = 'Are you sure you want to delete this?\n'; is used all sorts of places so it doesn't work to add a (specifig) warning here. Really what I think should happen is that when attempting to delete an alias, it is checked to see weather this is a mailbox alias, and if so, give the admin an error message. . . I know we could turn off $CONF['alias_control_admin'] but we do want admins to be able to edit mailbox aliases. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2007-10-09 17:01 Message: Logged In: YES user_id=1761957 Originator: NO I can't replicate this in the current subversion version. I'm closing this ticket for now - but if it is actually still a problem (and I'm stupid/incapable of testing or whatever), please reopen it and we'll take another look thanks! David. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1728078&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2007-10-09 17:01:13
|
Bugs item #1728078, was opened at 2007-05-30 07:12 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1728078&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: benjyamon (benjyamon) Assigned to: Nobody/Anonymous (nobody) Summary: deleting its alias deletes a mailbox Initial Comment: When someone deletes the alias that points to a mailbox, thinking it's extra, postfixadmin actually deletes the mailbox itself -- including calling the $CONF['mailbox_postdeletion_script'] I thought I'd simply edit the languages/en.lang since most all our domain admins are english speaking, but the $PALANG['confirm'] = 'Are you sure you want to delete this?\n'; is used all sorts of places so it doesn't work to add a (specifig) warning here. Really what I think should happen is that when attempting to delete an alias, it is checked to see weather this is a mailbox alias, and if so, give the admin an error message. . . I know we could turn off $CONF['alias_control_admin'] but we do want admins to be able to edit mailbox aliases. ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2007-10-09 17:01 Message: Logged In: YES user_id=1761957 Originator: NO I can't replicate this in the current subversion version. I'm closing this ticket for now - but if it is actually still a problem (and I'm stupid/incapable of testing or whatever), please reopen it and we'll take another look thanks! David. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1728078&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2007-10-09 16:58:18
|
Bugs item #1770514, was opened at 2007-08-08 23:11 Message generated for change (Settings changed) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1770514&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: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: edit-active.php vulnerable to URL injection Initial Comment: It's possible to inject an URL in edit-active.php where an user gets redirected to. Example: http://.../postfixadmin/admin/edit-active.php?alias=postmaster%40cboltz.de&domain=cboltz.de&return=http://www.google.de If the target page looks like Postfixadmin, the user might be tricked to enter privata data, mailbox passwords etc. The relevant code is quite new in SVN: diff -u -p -r1.1 edit-active.php --- admin/edit-active.php 16 Jan 2007 15:50:58 -0000 1.1 +++ admin/edit-active.php 8 Aug 2007 23:05:03 -0000 @@ -31,6 +31,7 @@ [...] + if (isset ($_GET['return'])) $fReturn = escape_string ($_GET['return']); [...] @@ -72,7 +73,14 @@ if ($error != 1) { - header ("Location: list-virtual.php?domain=$fDomain"); + if ( $fReturn != "" ) + { + header ("Location: $fReturn"); + } + else + { + header ("Location: list-virtual.php?domain=$fDomain"); + } exit; } Please validate $_GET['return'], using a list of allowed values. Sidenote: The "Location:" header requires a full URL to be specified. Giving only a filename can cause interesting[tm] effects in some browsers. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2007-10-08 20:39 Message: Logged In: YES user_id=1761957 Originator: NO It looks like it's fixed... if ($error != 1) { if ( preg_match( "/^list-virtual.php.*/", $fReturn ) || preg_match( "/^overview.php.*/", $fReturn ) || preg_match( "/^search.php.*/", $fReturn ) ) { //$fReturn appears OK, jump there header ("Location: $fReturn"); } else { if (authentication_has_role('global-admin')) { header ("Location: list-virtual.php?domain=$fDomain"); } else { header ("Location: overview.php?domain=$fDomain"); } } exit; ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2007-08-17 20:21 Message: Logged In: YES user_id=593261 Originator: YES No, I'm not aware of a browser that doesn't support relative redirects. But it is still off-spec and therefore might cause problems. But this is just a sidenote here - validating the return page is the important thing. Right now it looks like the ?return= parameter is only used from search.php. The best way to make it safe would be to use "?search=<search term>". ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2007-08-17 15:41 Message: Logged In: YES user_id=1761957 Originator: NO My understanding of Location: was that the spec says browsers should expect a full url, however all browsers support relative Location headers. Do you know of some browsers that don't support relative redirects? ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2007-08-08 23:23 Message: Logged In: YES user_id=593261 Originator: YES *ARGH* - this affects both postfixadmin/edit-active.php and postfixadmin/admin/edit-active.php. Duplicated code means duplicated bugs... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1770514&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2007-10-09 16:53:35
|
Bugs item #1752057, was opened at 2007-07-11 15:59 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1752057&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: Closed Resolution: None Priority: 5 Private: No Submitted By: Ric Flomag (ricflomag) Assigned to: Nobody/Anonymous (nobody) Summary: create domain: leaving fields blank leads to Mysql error Initial Comment: Using Postfix Admin 2.1.0: * go to the super admin page (/admin) * go to the "new domain" page * enter the name of the domain, but leave "alias" and "mailboxes" fields blank * click "add domain" --> a debug error is thrown because of a malformed mysql query. ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2007-10-09 16:53 Message: Logged In: YES user_id=1761957 Originator: NO Hi, Bug found, and fixed. Thank you for reporting it :-) See changeset 144. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1752057&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2007-10-08 20:38:58
|
Bugs item #1770514, was opened at 2007-08-08 23:11 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1770514&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: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: edit-active.php vulnerable to URL injection Initial Comment: It's possible to inject an URL in edit-active.php where an user gets redirected to. Example: http://.../postfixadmin/admin/edit-active.php?alias=postmaster%40cboltz.de&domain=cboltz.de&return=http://www.google.de If the target page looks like Postfixadmin, the user might be tricked to enter privata data, mailbox passwords etc. The relevant code is quite new in SVN: diff -u -p -r1.1 edit-active.php --- admin/edit-active.php 16 Jan 2007 15:50:58 -0000 1.1 +++ admin/edit-active.php 8 Aug 2007 23:05:03 -0000 @@ -31,6 +31,7 @@ [...] + if (isset ($_GET['return'])) $fReturn = escape_string ($_GET['return']); [...] @@ -72,7 +73,14 @@ if ($error != 1) { - header ("Location: list-virtual.php?domain=$fDomain"); + if ( $fReturn != "" ) + { + header ("Location: $fReturn"); + } + else + { + header ("Location: list-virtual.php?domain=$fDomain"); + } exit; } Please validate $_GET['return'], using a list of allowed values. Sidenote: The "Location:" header requires a full URL to be specified. Giving only a filename can cause interesting[tm] effects in some browsers. ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2007-10-08 20:39 Message: Logged In: YES user_id=1761957 Originator: NO It looks like it's fixed... if ($error != 1) { if ( preg_match( "/^list-virtual.php.*/", $fReturn ) || preg_match( "/^overview.php.*/", $fReturn ) || preg_match( "/^search.php.*/", $fReturn ) ) { //$fReturn appears OK, jump there header ("Location: $fReturn"); } else { if (authentication_has_role('global-admin')) { header ("Location: list-virtual.php?domain=$fDomain"); } else { header ("Location: overview.php?domain=$fDomain"); } } exit; ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2007-08-17 20:21 Message: Logged In: YES user_id=593261 Originator: YES No, I'm not aware of a browser that doesn't support relative redirects. But it is still off-spec and therefore might cause problems. But this is just a sidenote here - validating the return page is the important thing. Right now it looks like the ?return= parameter is only used from search.php. The best way to make it safe would be to use "?search=<search term>". ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2007-08-17 15:41 Message: Logged In: YES user_id=1761957 Originator: NO My understanding of Location: was that the spec says browsers should expect a full url, however all browsers support relative Location headers. Do you know of some browsers that don't support relative redirects? ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2007-08-08 23:23 Message: Logged In: YES user_id=593261 Originator: YES *ARGH* - this affects both postfixadmin/edit-active.php and postfixadmin/admin/edit-active.php. Duplicated code means duplicated bugs... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1770514&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2007-10-08 12:38:24
|
Bugs item #1783149, was opened at 2007-08-28 09:17 Message generated for change (Settings changed) made by michaelbeiter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1783149&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: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Michael Beiter (michaelbeiter) Assigned to: Nobody/Anonymous (nobody) Summary: Username in maildir path is not converted to lowercase Initial Comment: The entered username is not converted to lowercase in the maildir when adding a new mailbox. If the username is entered as i.e. Te...@do...valid, the resulting username (for login) will be te...@do...valid, what is correct. When the maildir is chosen to be made up of domain and username, it will result as domain.invalid/TeST - what is incorrect, as at least maildrop in my setup won't be able to deliver mails: it expects domain.invalid/test as maildir (what is only consequent). The fix is easy, it is sufficient to add a "strtolower" function call at the appropriate lines: admin/create-mailbox.php 143c143 < $maildir = $fDomain . "/" . escape_string ($_POST['fUsername']) . "/"; --- > $maildir = $fDomain . "/" . strtolower(escape_string ($_POST['fUsername'])) . "/"; create-mailbox.php 154c154 < $maildir = $fDomain . "/" . escape_string ($_POST['fUsername']) . "/"; --- > $maildir = $fDomain . "/" . strtolower(escape_string ($_POST['fUsername'])) . "/"; ---------------------------------------------------------------------- Comment By: Michael Beiter (michaelbeiter) Date: 2007-10-08 12:37 Message: Logged In: YES user_id=76720 Originator: YES >> Probably you didn't expect these difficulties because you use the >> alternative maildir structure (domain_in_mailbox==YES [...] > > I use the same setting as you do sorry, then I got that wrong. > [...] because maildrop reads the maildir from the database itsself > ("WHERE username=...") instead of using the value it got from postfix. ok, that's the point: We use the values from the database in maildrop only once for creating the maildir. For delivery, the path is created from the values provided by postfix (which are lowercase, as explained). Your tests surely work as you always use the database... In fact, delivery is the only place where we do not use the credentials from the db. Actually, courier worked fine for us with uppercase maildir names as you described. We decided once in a dark past that due to performance issues it would be better to build the maildir path using the provided credentials and not fire a db query. Anyway: The question of defaulting credentials to lowercase is not affected by this concern. Thanks, Michael ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2007-10-08 11:53 Message: Logged In: YES user_id=593261 Originator: NO > Probably you didn't expect these difficulties because you use the > alternative maildir structure (domain_in_mailbox==YES [...] I use the same setting as you do and even tested it: the maildir is created with uppercase letters. However this didn't matter on my system because maildrop reads the maildir from the database itsself ("WHERE username=...") instead of using the value it got from postfix. I tested: - delivery with postfix / maildrop - fetching mails with courier and everything worked with the uppercase maildir name. ---------------------------------------------------------------------- Comment By: Michael Beiter (michaelbeiter) Date: 2007-10-08 06:46 Message: Logged In: YES user_id=76720 Originator: YES Regarding my maildroprc: I used the username and domainname as provided by the database to create the maildirs. However, postfix always provides lowercase credentials when it delivers a mail to maildrop. Probably you didn't expect these difficulties because you use the alternative maildir structure (domain_in_mailbox==YES, what actually is the default IIRC). This results in using $fUsername on which a strtolower is applied in an earlier step somewhere around line 80. Unfortunately, at that place $fUsername ist tainted with the domain name, what requires using the POST-variable as described to restore $fUsername to its original value. In other words: I could use a strtolower when creating the maildir in my maildroprc. However, this could lead to inconsistencies in other applications. As imlemented by postfixadmin in the alternative maildir structure, user- and domainnames should be lowercase - and that's why I reported :-) HTH, Michael ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2007-10-07 19:52 Message: Logged In: YES user_id=593261 Originator: NO Just curious: How does your maildroprc look like? (I'm also using maildrop and using uppercase mailbox names works without problems.) Anyway: Your change won't do any harm or backwards compatibility issues (because it only affects creation of new mailboxes). I just applied your patch to create-mailbox.php in the SVN. Thanks for reporting this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1783149&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2007-10-08 12:38:02
|
Bugs item #1783149, was opened at 2007-08-28 09:17 Message generated for change (Comment added) made by michaelbeiter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1783149&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: Fixed Priority: 5 Private: No Submitted By: Michael Beiter (michaelbeiter) Assigned to: Nobody/Anonymous (nobody) Summary: Username in maildir path is not converted to lowercase Initial Comment: The entered username is not converted to lowercase in the maildir when adding a new mailbox. If the username is entered as i.e. Te...@do...valid, the resulting username (for login) will be te...@do...valid, what is correct. When the maildir is chosen to be made up of domain and username, it will result as domain.invalid/TeST - what is incorrect, as at least maildrop in my setup won't be able to deliver mails: it expects domain.invalid/test as maildir (what is only consequent). The fix is easy, it is sufficient to add a "strtolower" function call at the appropriate lines: admin/create-mailbox.php 143c143 < $maildir = $fDomain . "/" . escape_string ($_POST['fUsername']) . "/"; --- > $maildir = $fDomain . "/" . strtolower(escape_string ($_POST['fUsername'])) . "/"; create-mailbox.php 154c154 < $maildir = $fDomain . "/" . escape_string ($_POST['fUsername']) . "/"; --- > $maildir = $fDomain . "/" . strtolower(escape_string ($_POST['fUsername'])) . "/"; ---------------------------------------------------------------------- >Comment By: Michael Beiter (michaelbeiter) Date: 2007-10-08 12:37 Message: Logged In: YES user_id=76720 Originator: YES >> Probably you didn't expect these difficulties because you use the >> alternative maildir structure (domain_in_mailbox==YES [...] > > I use the same setting as you do sorry, then I got that wrong. > [...] because maildrop reads the maildir from the database itsself > ("WHERE username=...") instead of using the value it got from postfix. ok, that's the point: We use the values from the database in maildrop only once for creating the maildir. For delivery, the path is created from the values provided by postfix (which are lowercase, as explained). Your tests surely work as you always use the database... In fact, delivery is the only place where we do not use the credentials from the db. Actually, courier worked fine for us with uppercase maildir names as you described. We decided once in a dark past that due to performance issues it would be better to build the maildir path using the provided credentials and not fire a db query. Anyway: The question of defaulting credentials to lowercase is not affected by this concern. Thanks, Michael ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2007-10-08 11:53 Message: Logged In: YES user_id=593261 Originator: NO > Probably you didn't expect these difficulties because you use the > alternative maildir structure (domain_in_mailbox==YES [...] I use the same setting as you do and even tested it: the maildir is created with uppercase letters. However this didn't matter on my system because maildrop reads the maildir from the database itsself ("WHERE username=...") instead of using the value it got from postfix. I tested: - delivery with postfix / maildrop - fetching mails with courier and everything worked with the uppercase maildir name. ---------------------------------------------------------------------- Comment By: Michael Beiter (michaelbeiter) Date: 2007-10-08 06:46 Message: Logged In: YES user_id=76720 Originator: YES Regarding my maildroprc: I used the username and domainname as provided by the database to create the maildirs. However, postfix always provides lowercase credentials when it delivers a mail to maildrop. Probably you didn't expect these difficulties because you use the alternative maildir structure (domain_in_mailbox==YES, what actually is the default IIRC). This results in using $fUsername on which a strtolower is applied in an earlier step somewhere around line 80. Unfortunately, at that place $fUsername ist tainted with the domain name, what requires using the POST-variable as described to restore $fUsername to its original value. In other words: I could use a strtolower when creating the maildir in my maildroprc. However, this could lead to inconsistencies in other applications. As imlemented by postfixadmin in the alternative maildir structure, user- and domainnames should be lowercase - and that's why I reported :-) HTH, Michael ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2007-10-07 19:52 Message: Logged In: YES user_id=593261 Originator: NO Just curious: How does your maildroprc look like? (I'm also using maildrop and using uppercase mailbox names works without problems.) Anyway: Your change won't do any harm or backwards compatibility issues (because it only affects creation of new mailboxes). I just applied your patch to create-mailbox.php in the SVN. Thanks for reporting this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1783149&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2007-10-08 11:58:02
|
Bugs item #1694669, was opened at 2007-04-05 02:14 Message generated for change (Settings changed) made by christian_boltz 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 release!) Status: Open Resolution: None Priority: 5 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: Christian Boltz (christian_boltz) Date: 2007-10-07 22: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...> - 2007-10-08 11:53:38
|
Feature Requests item #1785513, was opened at 2007-08-31 14:15 Message generated for change (Comment added) made by suprune You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1785513&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: suprune (suprune) Assigned to: Nobody/Anonymous (nobody) Summary: Password and username restrictions Initial Comment: A user can change its password, and a domain administrator can set the password of a user. It would be nice if there were the following parameters in config.inc.php: password minimum length; and/or characters a password may contain, e.g. a regular expression for a password, like this: "!^[\\x21-\\x7E]{3,}$!" The same thing is desired for the users' names. Thanks. ---------------------------------------------------------------------- >Comment By: suprune (suprune) Date: 2007-10-08 14:53 Message: Logged In: YES user_id=1868725 Originator: YES > Minimum password length is implemented in the latest SVN version > as config option. Thanks. > Checking the password against a RegEx shouldn't be too hard to implement, > but I'm not sure if we really need it. I believe the non-ASCII administrators (like me, a Russian speaking man) would like to prevent their users to set passwords containing non-acsii characters. There are at least 3 different code pages for Russian characters, and one never knows how the password is encoded when it arrives to the postfixadmin scripts. Besides, a space (0x20) is not always convenient as a possible character of a password. A regEx seems to be the best way to check a password, including a check against minimum and maximum lengths. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2007-10-07 21:49 Message: Logged In: YES user_id=593261 Originator: NO Status: Minimum password length is implemented in the latest SVN version as config option. Checking the password against a RegEx shouldn't be too hard to implement, but I'm not sure if we really need it. Usernames always have to be (valid) mail addresses and are already checked. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1785513&group_id=191583 |
700 messages has been excluded from this view by a project administrator.
