postfixadmin-tracker Mailing List for PostfixAdmin (Page 9)
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...> - 2011-10-07 21:06:19
|
Bugs item #3420440, was opened at 2011-10-07 23:06 Message generated for change (Tracker Item Submitted) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3420440&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: SVN (please specify revision!) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: gen_show_status POP/IMAP check broken - recipient_delimiter Initial Comment: from #postfixadmin [22:14] <stderr1> cboltz: I think I found a bug in functions.php:gen_show_status() [22:15] <cboltz> details please ;-) [22:15] <stderr1> cboltz: haven't traced it but from reading the code I'm quite sure the POP/IMAP check incorrectly cuts the part after the recipient delimiter [22:15] <cboltz> 2.3.x or trunk? [22:16] <stderr1> In the deliverable check it's correct because it works on one address at a time, but in the pop/imap one the preg_replace works on the whole comma separated list [22:16] <stderr1> 2.3.5 if I'm not mistaken, wait... [22:16] <stderr1> no, 2.3.3 [22:17] <stderr1> so fo...@ba...,blurb@some.where would be cut to foo@some.where [22:19] <cboltz> indeed, this gives me "forward only" [22:19] <cboltz> same in trunk ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3420440&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-03 15:12:49
|
Bugs item #3417951, was opened at 2011-10-03 17:12 Message generated for change (Tracker Item Submitted) made by darkweaver87 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3417951&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.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rémi BUISSON (darkweaver87) Assigned to: Nobody/Anonymous (nobody) Summary: Alias listing in fetchmail -- Feature request Initial Comment: Hi all, It would be interesting to have also aliases listed in fetchmail rules. That way, we could fetch email from one account and dispatch to mutliple mailboxes. Thanks. Regards, Rémi ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3417951&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-09-29 22:50:18
|
Bugs item #2958684, was opened at 2010-02-25 13:49 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2958684&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: Fixed Priority: 1 Private: No Submitted By: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: $CONF['admin_email'] ignored in most cases Initial Comment: [13:42] <mrfrenzy> in the configfile it says // This will be used to send emails from to create mailboxes. [13:42] <mrfrenzy> $CONF['admin_email'] [13:42] <mrfrenzy> however, when I create mailboxes the welcome mail is sent with my username as sender [13:44] <cboltz> indeed. a quick grep shows that it is only used by broadcast-message.php [13:44] <cboltz> the question is which behaviour is better [13:44] <cboltz> a) always use the admin_email sender [13:44] <cboltz> b) drop admin_email and use the admin username [13:44] <cboltz> what would you prefer? ;-) [13:45] <mrfrenzy> it really isn't that important, aslong as the instructions in the config filer are correct [13:46] <mrfrenzy> however. I do think there might be reasons you don't want to tell the users what username your adminuser has [13:46] <cboltz> good argument ;-) [13:47] <cboltz> I'll paste the above lines in the bugtracker... [13:47] <mrfrenzy> I really love this irc based bugtracker submission engine :P ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-09-30 00:50 Message: @tabmowtez: having an extra field per domain sounds over-engineered to me compared to the additional functionality it would bring. If you really want to avoid that people @domaina don't get welcome mails from admin@domainb, simply login as admin@domaina ;-) @lnxus: I'd guess the typical setup only has one superadmin, therefore your idea wouldn't change too much ;-) Besides that, I'd like to avoid additional complexity whenever possible. We already have enough config options and enough differences in behaviour between domain admin and superadmin. I decided to implement it as described long time ago (2010-03-02): $CONF['admin_email'] = '' -> use the mail address of the logged in admin $CONF['admin_email'] = "fo...@ex..." -> always use fo...@ex... I implemented this for sendmail.php and broadcast-message.php some time ago, and I just implemented it in create-mailbox.php (SVN trunk r1197) which means it is done everywhere. Well, all these files now call smtp_get_admin_email() in functions.inc.php. (I won't backport this change to 2.3.x because it would change the behaviour.) If you really need more options to set the mail sender, please speak up. You'll have better chances to get your wish fulfilled if you include a proposal how to do it without additional config options, database fields or confusion for people editing config.inc.php ;-) ---------------------------------------------------------------------- Comment By: Dale Blount (lnxus) Date: 2011-06-01 19:37 Message: I feel that super admin's loginname/email address should not be sent via email at all. Is it feasable to use $CONF['admin_email'] if logged in as a superadmin or use the domain admin's email if logged in as a domain admin? If not, $CONF['admin_email'] all the time for all purposes is fine by me. ---------------------------------------------------------------------- Comment By: Tabmow (tabmowtez) Date: 2010-03-02 23:06 Message: Well, it is a solution. I guess it depends on what sort of hosting situation we are trying to cater for. If people use postfixadmin to setup client domains, then it is feasible that people that create mailboxes in domain b don't want the welcome message to come from ad...@do.... One way is to have an extra field in the domain table called admin_email possibly? Obviously the $fFrom in create-mailbox.php would change but I see this as a full solution to cater for everyone. If that field is blank then it can resort back to $CONF['admin_email']. Alternatively you can make it a required field moving forward? Thoughts? ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2010-03-02 16:09 Message: Idea: $CONF['admin_email'] = '' -> use the mail address of the logged in admin $CONF['admin_email'] = "fo...@ex..." -> always use fo...@ex... What do you think about this solution? ---------------------------------------------------------------------- Comment By: Tabmow (tabmowtez) Date: 2010-03-02 05:52 Message: Quick change in create-mailbox.php should fix this. --- create-mailbox.php 2009-04-07 05:54:11.000000000 +1000 +++ /usr/local/www/postfixadmin/create-mailbox.php 2010-03-02 15:48:26.000000000 +1100 @@ -230,7 +230,7 @@ if ($fMail == "on") { $fTo = $fUsername; - $f>From = $SESSID_USERNAME; + $fFrom = $CONF['admin_email']; $fHeaders = "To: " . $fTo . "\n"; $fHeaders .= "From: " . $fFrom . "\n"; Might be possible to add another config option and being able to define an address as well? Possible a per domain address? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2958684&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-09-29 22:19:29
|
Bugs item #3385499, was opened at 2011-08-03 12: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=3385499&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: SVN (please specify revision!) >Status: Closed >Resolution: Fixed Priority: 7 Private: No Submitted By: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: update-check fails - 2.3rc7 is "newer" than 2.3.3 Initial Comment: reported by simonhobson in http://sourceforge.net/projects/postfixadmin/forums/forum/676076/topic/4635474 However, it looks like the version check is broken. http://postfixadmin.sourceforge.net/update-check.php?version=2.3%2520rc7 says "Congratulations - you're running the latest version of PostfixAdmin". It seems that to the checker, "2.3rc7" and "2.3 rc7" are both >= 2.3.3 ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-09-30 00:19 Message: Fixed in SVN r1196 and deployed to postfixadmin.sourceforge.net ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3385499&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-09-25 21:58:03
|
Feature Requests item #3413280, was opened at 2011-09-23 13:47 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3413280&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: Wont Fix Priority: 5 Private: No Submitted By: Charles (libertytrek) Assigned to: Nobody/Anonymous (nobody) Summary: Limit Failed AUTH attempts? Initial Comment: I searched and didn't see an existing Feature Request for this, but may have missed something... Is it feasible/possible to add a function in postfixadmin that would temporarily lock out a user account after a configured number of AUTH attempt failures within a specifid time period? For example, consider a hack attempt on a specific users account - I'd like to be able to lock out a users account for, say, 5 minutes, after 3 failed AUTH attempts. So, after 3 failed attempts (bad password, any attempt to log in to that users account gets a TEMPFAIL for 5 minutes, then it will allow up to 3 more tries. Even better would be a way to lock it out permanently after 3 failed cycles on the same day. Anyway, not sure this is doable in postfixadmin, but it sure would add a large extra layer of security. Or... does anyone know if this is possible with fail2ban already? ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-09-25 23:58 Message: This is nothing that can be implemented in PostfixAdmin AFAIK, but it should be possible with fail2ban. Basically you need to scan the mail log for authentification failures, filter out the username (or IP) and configure fail2ban to act based on this. The easiest way is probably to block the IP, but AFAIK fail2ban can run any script - for example, you could write a small script that disables the login for the user under attack by setting a flag in the database. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3413280&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-09-25 19:14:14
|
Bugs item #1951979, was opened at 2008-04-26 00:55 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1951979&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: SVN (please specify revision!) >Status: Closed >Resolution: Fixed Priority: 4 Private: No Submitted By: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: create mailbox/admin ignore $CONF['min_password_length'] Initial Comment: create mailbox and create admin don't honor $CONF['min_password_length'] (edit mailbox / admin is OK) Not sure if we should fix it or if we should invest the time to merge edit and create (see fetchmail.php for an example)... (NOT a blocker for 2.2) ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-09-25 21:14 Message: Fixed in SVN trunk r1193 (create-admin) and r1194 (create-mailbox). ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2008-04-26 00:57 Message: Logged In: YES user_id=593261 Originator: YES (found in SVN r343) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1951979&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-09-25 18:41:47
|
Feature Requests item #1785513, was opened at 2007-08-31 13:15 Message generated for change (Comment added) made by christian_boltz 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: Closed >Resolution: Fixed 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: Christian Boltz (christian_boltz) Date: 2011-09-25 20:41 Message: Implemented in SVN trunk r1192 - see $CONF['password_validation']. Please test it ;-) ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-08-27 01:27 Message: > Cool... but how would you specify 'must contain at least n special > characters', where n is greater than one? I'll give you an example for numbers to avoid escaping issues ;-) /([0-9].*){3}/ would enforce at least 3 digits - with or without any other characters between them (as usual: untested) /[0-9].*[0-9].*[0-9]/ would do the same, but it starts to hurt if you want to enforce 10 digits ;-) > Also, could the last regex be modified to provide a list of allowable > characters like this: The regex array will be a $CONF option - you can change it like you want. Feel free to add proposals that we can ship in config.inc.php as examples or preconfiguration. ---------------------------------------------------------------------- Comment By: Charles (libertytrek) Date: 2011-08-24 14:14 Message: Cool... but how would you specify 'must contain at least n special characters', where n is greater than one? Also, could the last regex be modified to provide a list of allowable characters like this: /^[a-zA-Z0-9!@#$%^&*();':",.<>[]{}|\-=_+]$/ - may only contain letters and numbers ? ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-08-24 00:17 Message: Short update after thinking about this for a loooooong ;-) time: I'll add a config option with an array of RegExes. This should be flexible enough to fulfil all wishes, for example: /......../ - at last 8 chars (could even replace $CONF[min_password_length], except specifying the required length in the error message) /[a-zA-Z]/ - must contain at least one letter /[0-9]/ - must contain at least one digit /^[^¿¡]*$/ - must not contain ¿ or ¡ /^[a-zA-Z0-9]$/ - may only contain letters and numbers I also have thought about a method how to give useful (= user-understandable) error messages for each rule. More on this when it's implemented ;-) ---------------------------------------------------------------------- Comment By: amsys (amsys) Date: 2007-12-17 01:40 Message: Logged In: YES user_id=1299438 Originator: NO Maybe it will be nice to fix that nice red-to-green js password strength checker ;-) ---------------------------------------------------------------------- Comment By: suprune (suprune) Date: 2007-10-08 13: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 20: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 |
|
From: SourceForge.net <no...@so...> - 2011-09-23 11:47:52
|
Feature Requests item #3413280, was opened at 2011-09-23 07:47 Message generated for change (Tracker Item Submitted) made by libertytrek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3413280&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: Charles (libertytrek) Assigned to: Nobody/Anonymous (nobody) Summary: Limit Failed AUTH attempts? Initial Comment: I searched and didn't see an existing Feature Request for this, but may have missed something... Is it feasible/possible to add a function in postfixadmin that would temporarily lock out a user account after a configured number of AUTH attempt failures within a specifid time period? For example, consider a hack attempt on a specific users account - I'd like to be able to lock out a users account for, say, 5 minutes, after 3 failed AUTH attempts. So, after 3 failed attempts (bad password, any attempt to log in to that users account gets a TEMPFAIL for 5 minutes, then it will allow up to 3 more tries. Even better would be a way to lock it out permanently after 3 failed cycles on the same day. Anyway, not sure this is doable in postfixadmin, but it sure would add a large extra layer of security. Or... does anyone know if this is possible with fail2ban already? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3413280&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-09-22 23:09:02
|
Bugs item #3412484, was opened at 2011-09-21 20:31 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3412484&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.3 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Matthias Bethke (msbethke) Assigned to: Nobody/Anonymous (nobody) Summary: Possible SQL injection in create_admin Initial Comment: The fDomains parameter to create_admin() is taken from POST data and interpolated in SQL without santitizing it, posing the risk of an SQL injection attack. The risk is probably low as the function is only available to global admins but even then they shouldn't be able to screw up the database or exploit further vulnerabilities in the DBMS. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-09-23 01:09 Message: Could you report such issues a day before a release instead of a day after the (2.3.4) release next time, please? (Just kidding ;-) Seriously: Good catch, thanks for reporting it! Fixed in - 2.3 branch in SVN r1185, the fix will be in 2.3.5 (which we'll probably release soon, thanks to your bugreport ;-) - SVN trunk r1186 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3412484&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-09-22 22:06:24
|
Bugs item #3412476, was opened at 2011-09-21 20: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=3412476&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: v2.3.3 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Matthias Bethke (msbethke) Assigned to: Nobody/Anonymous (nobody) Summary: Missing language string pAdminDelete_admin_error Initial Comment: If admin deletion fails in delete.php, 'pAdminDelete_admin_error' is supposed to be diaplayed but this isn't defined in the language files. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-09-23 00:06 Message: Good catch! The text existed in trunk, but not in 2.3.x. Fixed in SVN 1184 (2.3 branch), the fix will be in 2.3.5. Thanks for your report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3412476&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-09-21 18:31:32
|
Bugs item #3412484, was opened at 2011-09-21 13:31 Message generated for change (Tracker Item Submitted) made by msbethke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3412484&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.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Bethke (msbethke) Assigned to: Nobody/Anonymous (nobody) Summary: Possible SQL injection in create_admin Initial Comment: The fDomains parameter to create_admin() is taken from POST data and interpolated in SQL without santitizing it, posing the risk of an SQL injection attack. The risk is probably low as the function is only available to global admins but even then they shouldn't be able to screw up the database or exploit further vulnerabilities in the DBMS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3412484&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-09-21 18:26:03
|
Bugs item #3412476, was opened at 2011-09-21 13:26 Message generated for change (Tracker Item Submitted) made by msbethke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3412476&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: v2.3.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Bethke (msbethke) Assigned to: Nobody/Anonymous (nobody) Summary: Missing language string pAdminDelete_admin_error Initial Comment: If admin deletion fails in delete.php, 'pAdminDelete_admin_error' is supposed to be diaplayed but this isn't defined in the language files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3412476&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-09-02 09:25:09
|
Bugs item #3403116, was opened at 2011-09-02 09:25 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3403116&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: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: mysqli_connect with ports Initial Comment: sry, this is the first bug I report, so apologies for bad form and language problems mysqli_connect needs the port as an extra parameter therefor writing 127.0.0.1:3307 doesn't work. The port either needs to be extracted from $CONF['database_host'] (where it is supposed to be following the setup.inc.php) or you use $CONF['database_port'] like you do for pgsql and change the description in setup.inc.php I took the first way, probably a bad choise, but I didn't know, if you had maybe any religous reasons to preserve $CONF['database_port'] for pgsql :) so essentialy I changed in functions.inc.php $link = @mysqli_connect ($CONF['database_host'], $CONF['database_user'], $CONF['database_password']) or $error_text .= ("<p />DEBUG INFORMATION:<br />Connect: " . mysqli_connect_error () . "$DEBUG_TEXT"); _to_ list($host, $givenPort) = explode(":", $CONF['database_host']); $port = (int) ($givenPort ? $givenPort : (ini_get("mysqli.default_port"))); $link = @mysqli_connect ($host, $CONF['database_user'], $CONF['database_password'], '', $port) or $error_text .= ("<p />DEBUG INFORMATION:<br />Connect: " . mysqli_connect_error () . "$DEBUG_TEXT"); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3403116&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-08-26 23:27:33
|
Feature Requests item #1785513, was opened at 2007-08-31 13:15 Message generated for change (Comment added) made by christian_boltz 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: Christian Boltz (christian_boltz) Date: 2011-08-27 01:27 Message: > Cool... but how would you specify 'must contain at least n special > characters', where n is greater than one? I'll give you an example for numbers to avoid escaping issues ;-) /([0-9].*){3}/ would enforce at least 3 digits - with or without any other characters between them (as usual: untested) /[0-9].*[0-9].*[0-9]/ would do the same, but it starts to hurt if you want to enforce 10 digits ;-) > Also, could the last regex be modified to provide a list of allowable > characters like this: The regex array will be a $CONF option - you can change it like you want. Feel free to add proposals that we can ship in config.inc.php as examples or preconfiguration. ---------------------------------------------------------------------- Comment By: Charles (libertytrek) Date: 2011-08-24 14:14 Message: Cool... but how would you specify 'must contain at least n special characters', where n is greater than one? Also, could the last regex be modified to provide a list of allowable characters like this: /^[a-zA-Z0-9!@#$%^&*();':",.<>[]{}|\-=_+]$/ - may only contain letters and numbers ? ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-08-24 00:17 Message: Short update after thinking about this for a loooooong ;-) time: I'll add a config option with an array of RegExes. This should be flexible enough to fulfil all wishes, for example: /......../ - at last 8 chars (could even replace $CONF[min_password_length], except specifying the required length in the error message) /[a-zA-Z]/ - must contain at least one letter /[0-9]/ - must contain at least one digit /^[^¿¡]*$/ - must not contain ¿ or ¡ /^[a-zA-Z0-9]$/ - may only contain letters and numbers I also have thought about a method how to give useful (= user-understandable) error messages for each rule. More on this when it's implemented ;-) ---------------------------------------------------------------------- Comment By: amsys (amsys) Date: 2007-12-17 01:40 Message: Logged In: YES user_id=1299438 Originator: NO Maybe it will be nice to fix that nice red-to-green js password strength checker ;-) ---------------------------------------------------------------------- Comment By: suprune (suprune) Date: 2007-10-08 13: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 20: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 |
|
From: SourceForge.net <no...@so...> - 2011-08-26 22:12:38
|
Bugs item #3393643, was opened at 2011-08-18 09:47 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3393643&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: v2.3.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Juri Gurjanov (mralone) Assigned to: Nobody/Anonymous (nobody) Summary: squirrelmail plugin login error Initial Comment: Hello. Found a problem with squirrelmail plugin and postfixadmin - if I made changes in "Forwarding", "Auto Response" or "Change Password", then click "Sigh Out" and login again, I can't access "Forwarding", "Auto Response" or "Change Password" anymore due to "ERROR You must be logged in to access this page." I can reproduce this problem on Squrrelmail 1.4.21 and 1.4.22 with Postfixadmin 2.3.3 but can't reproduce on Squirrelmail 1.4.15 ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-08-27 00:12 Message: Giving only a linenumber as context is not really useful because it heavily depends on the version ;-) Please provide a "diff -u" (unified diff) patch. That said: This issue might be a bug in squirrelmail itsself. Can you report it to the squirrelmail developers, please (with the patch included)? Then add a link to the squirrelmail bugreport here. BTW: The path "plugins" and "plugins/" should be enough. "plugins/postfixadmin" is in theory more secure (because other plugins can't access the session cookie), but that's more a theoretical issue IMHO. ---------------------------------------------------------------------- Comment By: Juri Gurjanov (mralone) Date: 2011-08-25 18:58 Message: Actually, adding next code to line 389 in squirrelmail/functions/global.php fix the problem. sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . 'plugins/'); sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . 'plugins'); sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . 'plugins/postfixadmin'); sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . 'plugins/postfixadmin/'); Not sure, what folder you use to store session cookies. ---------------------------------------------------------------------- Comment By: Juri Gurjanov (mralone) Date: 2011-08-25 18:14 Message: According to my test, latest version w/o problem - 1.4.17. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-08-22 01:01 Message: That sounds like a problem with the PHP session and/or session cookies. It would be helpful if you can find out the exact squirrelmail version that introduced the problem. The squirrelmail changelog [1] mentions various session-related changes for the 1.4.19 release, which sound like the best "candidate" for introducing the problem you describe. Can you please tes/verifyt if - 1.4.19 contains the bug you mentioned - 1.4.18 works bug-free Knowing this will hopefully help to find the bug. (It might as well be a bug/regression in squirrelmail.) [1] http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4-STABLE/squirrelmail/doc/ChangeLog?revision=14139&view=markup ---------------------------------------------------------------------- Comment By: Juri Gurjanov (mralone) Date: 2011-08-18 09:49 Message: Forgot to say, that if I close browser window, and login again, I can access plugin parts, until some changes were made. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3393643&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-08-25 16:58:26
|
Bugs item #3393643, was opened at 2011-08-18 10:47 Message generated for change (Comment added) made by mralone You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3393643&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: v2.3.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Juri Gurjanov (mralone) Assigned to: Nobody/Anonymous (nobody) Summary: squirrelmail plugin login error Initial Comment: Hello. Found a problem with squirrelmail plugin and postfixadmin - if I made changes in "Forwarding", "Auto Response" or "Change Password", then click "Sigh Out" and login again, I can't access "Forwarding", "Auto Response" or "Change Password" anymore due to "ERROR You must be logged in to access this page." I can reproduce this problem on Squrrelmail 1.4.21 and 1.4.22 with Postfixadmin 2.3.3 but can't reproduce on Squirrelmail 1.4.15 ---------------------------------------------------------------------- >Comment By: Juri Gurjanov (mralone) Date: 2011-08-25 19:58 Message: Actually, adding next code to line 389 in squirrelmail/functions/global.php fix the problem. sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . 'plugins/'); sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . 'plugins'); sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . 'plugins/postfixadmin'); sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . 'plugins/postfixadmin/'); Not sure, what folder you use to store session cookies. ---------------------------------------------------------------------- Comment By: Juri Gurjanov (mralone) Date: 2011-08-25 19:14 Message: According to my test, latest version w/o problem - 1.4.17. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-08-22 02:01 Message: That sounds like a problem with the PHP session and/or session cookies. It would be helpful if you can find out the exact squirrelmail version that introduced the problem. The squirrelmail changelog [1] mentions various session-related changes for the 1.4.19 release, which sound like the best "candidate" for introducing the problem you describe. Can you please tes/verifyt if - 1.4.19 contains the bug you mentioned - 1.4.18 works bug-free Knowing this will hopefully help to find the bug. (It might as well be a bug/regression in squirrelmail.) [1] http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4-STABLE/squirrelmail/doc/ChangeLog?revision=14139&view=markup ---------------------------------------------------------------------- Comment By: Juri Gurjanov (mralone) Date: 2011-08-18 10:49 Message: Forgot to say, that if I close browser window, and login again, I can access plugin parts, until some changes were made. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3393643&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-08-25 16:14:35
|
Bugs item #3393643, was opened at 2011-08-18 10:47 Message generated for change (Comment added) made by mralone You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3393643&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: v2.3.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Juri Gurjanov (mralone) Assigned to: Nobody/Anonymous (nobody) Summary: squirrelmail plugin login error Initial Comment: Hello. Found a problem with squirrelmail plugin and postfixadmin - if I made changes in "Forwarding", "Auto Response" or "Change Password", then click "Sigh Out" and login again, I can't access "Forwarding", "Auto Response" or "Change Password" anymore due to "ERROR You must be logged in to access this page." I can reproduce this problem on Squrrelmail 1.4.21 and 1.4.22 with Postfixadmin 2.3.3 but can't reproduce on Squirrelmail 1.4.15 ---------------------------------------------------------------------- >Comment By: Juri Gurjanov (mralone) Date: 2011-08-25 19:14 Message: According to my test, latest version w/o problem - 1.4.17. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-08-22 02:01 Message: That sounds like a problem with the PHP session and/or session cookies. It would be helpful if you can find out the exact squirrelmail version that introduced the problem. The squirrelmail changelog [1] mentions various session-related changes for the 1.4.19 release, which sound like the best "candidate" for introducing the problem you describe. Can you please tes/verifyt if - 1.4.19 contains the bug you mentioned - 1.4.18 works bug-free Knowing this will hopefully help to find the bug. (It might as well be a bug/regression in squirrelmail.) [1] http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4-STABLE/squirrelmail/doc/ChangeLog?revision=14139&view=markup ---------------------------------------------------------------------- Comment By: Juri Gurjanov (mralone) Date: 2011-08-18 10:49 Message: Forgot to say, that if I close browser window, and login again, I can access plugin parts, until some changes were made. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3393643&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-08-24 19:56:00
|
Bugs item #3397453, was opened at 2011-08-24 16:30 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3397453&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: Pending Resolution: None Priority: 5 Private: No Submitted By: rcbandit (rcbandit) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot install Postfix Admin on Centos 6 Initial Comment: Hi, I cannot install Postfix Admin on Centos 6. Would you make a test to install Posffix Admin on Centos? Regards Peter ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-08-24 21:55 Message: A more detailed problem description would be very helpful ;-) Which file did you download? Which error messages do you see? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3397453&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-08-24 14:30:54
|
Bugs item #3397453, was opened at 2011-08-24 17:30 Message generated for change (Tracker Item Submitted) made by rcbandit You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3397453&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: rcbandit (rcbandit) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot install Postfix Admin on Centos 6 Initial Comment: Hi, I cannot install Postfix Admin on Centos 6. Would you make a test to install Posffix Admin on Centos? Regards Peter ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3397453&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-08-24 12:18:13
|
Feature Requests item #2752992, was opened at 2009-04-11 09:24 Message generated for change (Comment added) made by libertytrek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=2752992&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: Duplicate Priority: 5 Private: No Submitted By: Charles (libertytrek) Assigned to: Nobody/Anonymous (nobody) Summary: Cracklib support for strong passwords Initial Comment: I'd love to see support for the use of cracklib, where the Admin can define the password criteria on a per-domain basis, in a simple screen... Min Length: Duration: # of Upper Case characters: # of Lower Case characters: # of Number characters: # of Non-AlphaNumeric characters: Illegal characters: Hmmm... duration would also require Cron support I guess... and also the ability to send email notifications (similar to Quota notifications) so the user knows when they need to change it - maybe even with a link to a secure change password page so if they let it expire, they can still go change it without having to call support... ---------------------------------------------------------------------- Comment By: Charles (libertytrek) Date: 2011-08-24 08:18 Message: Well, a couple of thoughts... Using just the regexes doesn't provide the protection of testing the password for crackability like using cracklib. You could specify the regexes like you suggest, but the user could still create a fairly simple password that would be easy for a dictionary cracker to crack. I still think cracklib support would be good, as a final way to 'test' the password for complexity. But yes, the regexes get us part way there... ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-08-23 19:28 Message: Your requirements should be able to fulfill with a set of RegExes, for example "at least 2 uppercase characters" would be "/[A-Z].*[A-Z]/". Therefore I'm closing this as duplicate of http://sourceforge.net/tracker/?func=detail&aid=1785513&group_id=191583&atid=937967 The only exception is the duration / expiration date of passwords - but that's something I'm not planning to implement because it would be the only thing requiring a cron job. BTW, how would you enforce this? Disabling SMTP and POP3 logins is insane (and would even be possible without a cronjob - do it in SQL), and users won't care much if they only get a warning in PostfixAdmin. Besides activating vacation, most users never login in PostfixAdmin. If you only want to send a "please change your password" mail, this can easily be done with an additional field for the expiration date and an external cron script. (I'd accept a patch and a script for ADDITIONS/, but won't do it myself.) Therefore closing as 90% duplicate and 10% wontfix ;-) If you don't agree, feel free to reopen. ---------------------------------------------------------------------- Comment By: Charles (libertytrek) Date: 2011-01-02 17:23 Message: I'd still like to see this happen, although I no longer have any interest in setting a duration, so no cron support would be required... ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-04-18 02:59 Message: Is there anything else you'd like adding ? :-) It seems a good idea - and there is http://pecl.php.net/package/crack which would help somewhat. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=2752992&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-08-24 12:14:42
|
Feature Requests item #1785513, was opened at 2007-08-31 07:15 Message generated for change (Comment added) made by libertytrek 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: Charles (libertytrek) Date: 2011-08-24 08:14 Message: Cool... but how would you specify 'must contain at least n special characters', where n is greater than one? Also, could the last regex be modified to provide a list of allowable characters like this: /^[a-zA-Z0-9!@#$%^&*();':",.<>[]{}|\-=_+]$/ - may only contain letters and numbers ? ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-08-23 18:17 Message: Short update after thinking about this for a loooooong ;-) time: I'll add a config option with an array of RegExes. This should be flexible enough to fulfil all wishes, for example: /......../ - at last 8 chars (could even replace $CONF[min_password_length], except specifying the required length in the error message) /[a-zA-Z]/ - must contain at least one letter /[0-9]/ - must contain at least one digit /^[^¿¡]*$/ - must not contain ¿ or ¡ /^[a-zA-Z0-9]$/ - may only contain letters and numbers I also have thought about a method how to give useful (= user-understandable) error messages for each rule. More on this when it's implemented ;-) ---------------------------------------------------------------------- Comment By: amsys (amsys) Date: 2007-12-16 19:40 Message: Logged In: YES user_id=1299438 Originator: NO Maybe it will be nice to fix that nice red-to-green js password strength checker ;-) ---------------------------------------------------------------------- Comment By: suprune (suprune) Date: 2007-10-08 07: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 14: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 |
|
From: SourceForge.net <no...@so...> - 2011-08-23 23:28:41
|
Feature Requests item #2752992, was opened at 2009-04-11 15:24 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=2752992&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: Duplicate Priority: 5 Private: No Submitted By: Charles (libertytrek) Assigned to: Nobody/Anonymous (nobody) Summary: Cracklib support for strong passwords Initial Comment: I'd love to see support for the use of cracklib, where the Admin can define the password criteria on a per-domain basis, in a simple screen... Min Length: Duration: # of Upper Case characters: # of Lower Case characters: # of Number characters: # of Non-AlphaNumeric characters: Illegal characters: Hmmm... duration would also require Cron support I guess... and also the ability to send email notifications (similar to Quota notifications) so the user knows when they need to change it - maybe even with a link to a secure change password page so if they let it expire, they can still go change it without having to call support... ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-08-24 01:28 Message: Your requirements should be able to fulfill with a set of RegExes, for example "at least 2 uppercase characters" would be "/[A-Z].*[A-Z]/". Therefore I'm closing this as duplicate of http://sourceforge.net/tracker/?func=detail&aid=1785513&group_id=191583&atid=937967 The only exception is the duration / expiration date of passwords - but that's something I'm not planning to implement because it would be the only thing requiring a cron job. BTW, how would you enforce this? Disabling SMTP and POP3 logins is insane (and would even be possible without a cronjob - do it in SQL), and users won't care much if they only get a warning in PostfixAdmin. Besides activating vacation, most users never login in PostfixAdmin. If you only want to send a "please change your password" mail, this can easily be done with an additional field for the expiration date and an external cron script. (I'd accept a patch and a script for ADDITIONS/, but won't do it myself.) Therefore closing as 90% duplicate and 10% wontfix ;-) If you don't agree, feel free to reopen. ---------------------------------------------------------------------- Comment By: Charles (libertytrek) Date: 2011-01-02 23:23 Message: I'd still like to see this happen, although I no longer have any interest in setting a duration, so no cron support would be required... ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-04-18 08:59 Message: Is there anything else you'd like adding ? :-) It seems a good idea - and there is http://pecl.php.net/package/crack which would help somewhat. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=2752992&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-08-23 22:17:12
|
Feature Requests item #1785513, was opened at 2007-08-31 13:15 Message generated for change (Comment added) made by christian_boltz 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: Christian Boltz (christian_boltz) Date: 2011-08-24 00:17 Message: Short update after thinking about this for a loooooong ;-) time: I'll add a config option with an array of RegExes. This should be flexible enough to fulfil all wishes, for example: /......../ - at last 8 chars (could even replace $CONF[min_password_length], except specifying the required length in the error message) /[a-zA-Z]/ - must contain at least one letter /[0-9]/ - must contain at least one digit /^[^¿¡]*$/ - must not contain ¿ or ¡ /^[a-zA-Z0-9]$/ - may only contain letters and numbers I also have thought about a method how to give useful (= user-understandable) error messages for each rule. More on this when it's implemented ;-) ---------------------------------------------------------------------- Comment By: amsys (amsys) Date: 2007-12-17 01:40 Message: Logged In: YES user_id=1299438 Originator: NO Maybe it will be nice to fix that nice red-to-green js password strength checker ;-) ---------------------------------------------------------------------- Comment By: suprune (suprune) Date: 2007-10-08 13: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 20: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 |
|
From: SourceForge.net <no...@so...> - 2011-08-23 21:24:13
|
Feature Requests item #3292408, was opened at 2011-04-24 13:14 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3292408&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: Fixed Priority: 5 Private: No Submitted By: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: Provide a hook to override or add translations Initial Comment: Sometimes people need to override (or add) translations. Currently this is only possible by editing languages/*, which is a maintenance hell on upgrades. We should offer a $CONF option to call a PHP function after languages/* to allow overriding translations. The selected language should be provided as parameter. Skeleton for the hook function: function lang_override($LANG, $language) { if ($language == "de") { $LANG['whatever'] = 'foo'; } return $LANG; } I chose to hand over $LANG as parameter instead of using "global $LANG" because it avoids global variables, which might be a good idea on our way to move everything in classes ;-) ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-08-23 23:24 Message: Commited to SVN trunk r1176. See $CONF['language_hook'] and the example hook function in config.inc.php. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3292408&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-08-21 23:01:09
|
Bugs item #3393643, was opened at 2011-08-18 09:47 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3393643&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: v2.3.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Juri Gurjanov (mralone) Assigned to: Nobody/Anonymous (nobody) Summary: squirrelmail plugin login error Initial Comment: Hello. Found a problem with squirrelmail plugin and postfixadmin - if I made changes in "Forwarding", "Auto Response" or "Change Password", then click "Sigh Out" and login again, I can't access "Forwarding", "Auto Response" or "Change Password" anymore due to "ERROR You must be logged in to access this page." I can reproduce this problem on Squrrelmail 1.4.21 and 1.4.22 with Postfixadmin 2.3.3 but can't reproduce on Squirrelmail 1.4.15 ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-08-22 01:01 Message: That sounds like a problem with the PHP session and/or session cookies. It would be helpful if you can find out the exact squirrelmail version that introduced the problem. The squirrelmail changelog [1] mentions various session-related changes for the 1.4.19 release, which sound like the best "candidate" for introducing the problem you describe. Can you please tes/verifyt if - 1.4.19 contains the bug you mentioned - 1.4.18 works bug-free Knowing this will hopefully help to find the bug. (It might as well be a bug/regression in squirrelmail.) [1] http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4-STABLE/squirrelmail/doc/ChangeLog?revision=14139&view=markup ---------------------------------------------------------------------- Comment By: Juri Gurjanov (mralone) Date: 2011-08-18 09:49 Message: Forgot to say, that if I close browser window, and login again, I can access plugin parts, until some changes were made. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3393643&group_id=191583 |
700 messages has been excluded from this view by a project administrator.
