postfixadmin-devel — Postfix Admin development talk - users are also welcome

[Postfixadmin-devel] upgrade problem

[<me...@td...>]

Hi,

I am attempting to upgrade from pfa 2.1.1 to svn509. The 509 install is being
installed on a new machine that I took the old db and installed it on the new
machine. I configured config.inc.php and ran setup.php. Below is the output
of setup.php.

Postfix Admin Setup Checker

Running software:

     * PHP version 5.1.6
     * Apache/2.2.3 (CentOS)

Checking for dependencies:

     * Warning: Magic Quotes: ON (internal workaround used)
     * Depends on: presence config.inc.php - OK
     * Checking $CONF['configured'] - OK
     * Depends on: MySQL 3.23, 4.0 - OK
     * Depends on: MySQL 4.1 - OK
     * Depends on: PostgreSQL - OK (change the database_type to 'pgsql' in config.inc.php!!)
     * Testing database connection - OK - mysqli://postfix:xxxxx@localhost/postfix
     * Depends on: session - OK
     * Depends on: pcre - OK
     * Depends on: multibyte string - OK
     * Depends on: IMAP functions - OK

Everything seems fine... attempting to create/update database structure

Updating database:

- old version: 0; target version: 509

updating to version 1 (MySQL)...   done

updating to version 2 (MySQL)...   done

updating to version 3 (MySQL)...   done

updating to version 4 (MySQL)...   done

updating to version 5 (MySQL)...   done

updating to version 79 (MySQL)...   done

updating to version 81 (MySQL)...   done

updating to version 90 (all databases)...   done

updating to version 169 (MySQL)...   done

updating to version 318 (MySQL)...

DEBUG INFORMATION:
Invalid query: Can't create table './postfix/vacation_notification.frm' (errno: 150)

As you can see the db is not being updated properly. Can someone help me get
this upgraded?

regards,

-- 
Tom			me...@td...		Spamtrap address	 		me...@td...

Re: [Postfixadmin-devel] Hello, Projects Postfixadmin (vacation.pl ) ADD config.ini

[Christian B. <pos...@cb...>]

Hello,

(keeping the CC list from GingerDog, but please reply to the 
mailinglist!)

Am Sonntag, 21. Dezember 2008 schrieb David Goodwin:
> Thanks for the below; if you intend to send any more stuff 'our' way,
> please send to the postfixadmin-devel mailing list.
>
> I'm personally happy to merge the vacation.pl stuff (at least .ini
> file support) but I'm not sure I like the config directory (i'd
> rather config stuff was in /etc/postfixadmin or something .... )

The latest vacation.pl already has support for reading the configuration 
from /etc/mail/postfixadmin/vacation.conf. This file has to be in perl 
syntax (instead of .ini format), for example

    $db_username = 'vacation';
    $db_password = 'topsecret';

I'm not sure if switching to INI format is really useful. Yes, it is a 
widely known file format, but people who setup a mail server should be 
able to write valid perl files ;-)

In the future, I plan to have config files for every script we ship. 
This includes also some bash scripts which will have a bash-style 
key=value config file since parsing INI files in bash isn't that 
easy ;-)

If we really want to have a common config file format for everything, 
then I'd vote for using
    key=value
    key2=another value
files. These are quite easy to parse in perl and can just be source'd in 
bash. INI files have the disadvantage that the "header" will cause 
problems in bash.


Regards,

Christian Boltz
-- 
Und allen, die keinen Internetzugang haben bleibt nur übrig, bis zur
nächsten Ausgabe einer PC-Zeitung mit aktuellem Virenscanner zu warten.
                        [Hitradio AS gibt Tips zur ILOVEYOU-Bekämpfung]

Re: [Postfixadmin-devel] spam?

[Christian B. <pos...@cb...>]

Hello,

Am Montag, 22. Dezember 2008 schrieb David Goodwin:
> Can anonymous commenting on tickets be removed somehow; I don't like
> spam.

As already written in #postfixadmin, I changed the tracker settings to 
disallow anonymous comments.

Now you have to login to comment on a ticket or to create a new one.

I also cleaned the mailinglist archive for postfixadmin-tracker (you'll 
see "52 messages hidden by admin") and marked the spam comments in the 
tracker itsself as hidden (that's a new feature of tracker2).


Oh, and let's hope that the spammers don't start to login ;-)


Regards,

Christian Boltz
-- 
The mission statement is simply 'world domination', 
but we don't tell anybody. :-)
[Juergen Weigert in opensuse-project]

[Postfixadmin-devel] spam?

[David G. <da...@co...>]

Hi,
Can anonymous commenting on tickets be removed somehow; I don't like
spam.

David.

-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]

Re: [Postfixadmin-devel] Hello, Projects Postfixadmin (vacation.pl ) ADD config.ini

[David G. <da...@co...>]

Hi Jose,

Thanks for the below; if you intend to send any more stuff 'our' way,
please send to the postfixadmin-devel mailing list.

I'm personally happy to merge the vacation.pl stuff (at least .ini
file support) but I'm not sure I like the config directory (i'd rather
config stuff was in /etc/postfixadmin or something .... )

thanks,
David.

Jose Nilton wrote :
> I'm making some changes in vacation.pl
> added Config:: INI:: Simple;
> I created a configuration file
> 
> This is simply be done by setting a postfixadmin
> 
> 
> 
> 
> This config is Debian
> *I use OpenSuSe 11.1*
> 
> 
> ADD modulo Config::INI in perl
> perl -MCPAN -e shell
> install Config::INI::Simple
> 
> 
> 
> mkdir /var/www/postfixadmin/config/
> touch /var/www/postfixadmin/config/.htaccess
> 
> ADD
> echo 'Order allow,deny
> Deny from all' > /var/www/postfixadmin/config/.htaccess
> 
> 
> touch /var/www/postfixadmin/config/config.ini
> *[vacation]
> domain = site.com
> reply = autoreply.site.com
> db_type = mysql
> db_host = localhost
> db_username = postfixadmin
> db_password = postfixadmin
> db_name = postfix
> *
> 
> use Config::INI::Simple;
> my $conf = new Config::INI::Simple;
> $conf->read ("/var/www/postfixadmin/config/config.ini");
> 
> my $db_type = $conf->{postfixadmin}->{db_type};
> 
> # leave empty for connection via UNIX socket
> my $db_host = $conf->{postfixadmin}->{db_host};
> 
> # connection details
> my $db_username = $conf->{postfixadmin}->{db_username};
> my $db_password = $conf->{postfixadmin}->{db_password};
> my $db_name     = $conf->{postfixadmin}->{db_name};
> 
> my $vacation_domain = $conf->{postfixadmin}->{vacation};
> 
> 
> Thanks !!!
> 
> 
> -- 
> _________________________
> Web Site: http://zaitan.net
> Wiki: http://zaitan.net/wiki

-- 
 David Goodwin                          Pale Purple Limited
 Office: 0845 0046746                   Mobile: 07792380669 
 http://www.palepurple.co.uk            Company No: 5580814 
 'Business Web Application Development and Training in PHP'

[Postfixadmin-devel] users/vacation.php should not delete records from alias table

[Dyks, A. <Axe...@co...>]

Hi,

I've just noticed that "users/vacation.php" would delete a user's entry from the alias table,
if there were no alias(es) defined for the user.

See line 107++ in
http://postfixadmin.svn.sourceforge.net/viewvc/postfixadmin/trunk/users/vacation.php?revision=303&view=markup

Although this actually shouldn't happen, because users/edit-alias.php will never create a
record with an empty goto field, it would still produce a situation which users/edit-alias.php
wouldn't be able to handle, because it NEVER inserts a record, it always UPDATE(s).

See line 119++ in
http://postfixadmin.svn.sourceforge.net/viewvc/postfixadmin/trunk/users/edit-alias.php?revision=250&view=markup

Furthermore I think that users/edit-alias.php shouldn't blindly insert a ',' into $goto
at line 83. It actually APPENDS it, in case $goto is empty (no aliases specified in textbox).

Cheers,
Axel

Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Günter W. Engerer Vorstand/Managing Board: Andreas Bublak, Manfred Steinberger, Robert Zellner COC AG Sitz/Registered Office Burghausen Amtsgericht/District Court Traunstein, HRB 17218

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[499] trunk/edit-domain.php

[David G. <da...@co...>]

> 
> >     trunk/edit-domain.php
> (reduced to non-whitespace changes)

:-)

> > @@ -69,1 +69,4 @@
> > -       if (isset ($_POST['fTransport'])) $fTransport = escape_string
> >                                   ($_POST['fTransport']);
> > +    $fTransport = $CONF['transport_default'];
> > +    if($CONF['transport'] != 'NO' && isset ($_POST['fTransport'])) {
> > +        $fTransport = escape_string ($_POST['fTransport']);
> > +    }
> 
> IMHO this is buggy. Even if $CONF['transport'] is set to NO, there could 
> be some domains with a transport different from 
> $CONF['default_transport'] - for example, $CONF['transport'] could have 
> been YES for some time.

True.

> 
> The correct solution is to use the old transport value in the database 
> also as new value. Or to simply omit changing the transport field in 
> the UPDATE query if $CONF['transport'] is NO.
> 
> Besides that: transport is not a freetext field, but a dropdown with a 
> list of defined values ($CONF['transport_options']). So we should also 
> check the input against this list of allowed values instead of simply 
> escape_string'ing it.

OK. I agree. Will fix soon (unless someone beats me to it)

thanks
David.

-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[499] trunk/edit-domain.php

[Christian B. <pos...@cb...>]

Hello,

Am Freitag, 12. Dezember 2008 schrieb Gin...@us...:
> Revision: 499

> edit-domain.php: fix bug where editing a domain nukes the transport
> field (we actually were not checking the config field properly to see
> whether transport control was turned on or not; this fixes
> https://sourceforge.net/tracker/index.php?func=detail&aid=2378038&gro
>up_id=191583&atid=937964

>     trunk/edit-domain.php
(reduced to non-whitespace changes)
> @@ -69,1 +69,4 @@
> -       if (isset ($_POST['fTransport'])) $fTransport = escape_string
>                                   ($_POST['fTransport']);
> +    $fTransport = $CONF['transport_default'];
> +    if($CONF['transport'] != 'NO' && isset ($_POST['fTransport'])) {
> +        $fTransport = escape_string ($_POST['fTransport']);
> +    }

IMHO this is buggy. Even if $CONF['transport'] is set to NO, there could 
be some domains with a transport different from 
$CONF['default_transport'] - for example, $CONF['transport'] could have 
been YES for some time.

The correct solution is to use the old transport value in the database 
also as new value. Or to simply omit changing the transport field in 
the UPDATE query if $CONF['transport'] is NO.

Besides that: transport is not a freetext field, but a dropdown with a 
list of defined values ($CONF['transport_options']). So we should also 
check the input against this list of allowed values instead of simply 
escape_string'ing it.


Regards,

Christian Boltz
-- 
If you need to ask stupid questions, there may be two reasons:
a) the documentation (in this case mostly the wiki) is incomplete
b) you're stupid :-)
[Dirk Stoecker inopensuse-buildservice]

[Postfixadmin-devel] SQL Upgrade 495 has SQL error

[Matt R. <li...@ma...>]

I was having a problem upgrading my PA to the last's SVN version.  When
I would run the upgrade.php script page it would error out on the
upgrade_495_mysql function.  Attached is the patch.

Thanks
-Matt

-- 
http://wiki.mattrude.com

Re: [Postfixadmin-devel] mysql table structure for vacation and vacation_notication (version 2.2.1.1)

[David G. <da...@co...>]

Dyks, Axel wrote :
> Hi,
> 
> could someone with a running 2.2.1.1 installation of postfixadmin be so
> nice and post the mysql table structure (including indexes and such)
> for the tables "vacation" and "vacation_notification".
> 
> I'm in the "lucky" position to implement "vacation" (o-o-o) on top
> of an existing postfix virtual mailbox installation and I want to
> use as much of postfixadmin's "vacation" feature as possible.
> 
> Thank you very much
> 
> Axel

CREATE TABLE `vacation_notification` (
`on_vacation` varchar(255) NOT NULL,
`notified` varchar(255) NOT NULL,
`notified_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`on_vacation`,`notified`),
CONSTRAINT `vacation_notification_pkey` FOREIGN KEY (`on_vacation`) REFERENCES `vacation` (`email`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='Postfix Admin - Virtual Vacation Notifications'

CREATE TABLE `vacation` (
`email` varchar(255) NOT NULL,
`subject` varchar(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
`body` text CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
`cache` text NOT NULL,
`domain` varchar(255) NOT NULL,
`created` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
`active` tinyint(1) NOT NULL DEFAULT '1',
PRIMARY KEY (`email`),
KEY `email` (`email`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
COMMENT='Postfix Admin - Virtual Vacation'


Hope that helps,
thanks
David.

-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]

[Postfixadmin-devel] mysql table structure for vacation and vacation_notication (version 2.2.1.1)

[Dyks, A. <Axe...@co...>]

Hi,

could someone with a running 2.2.1.1 installation of postfixadmin be so
nice and post the mysql table structure (including indexes and such)
for the tables "vacation" and "vacation_notification".

I'm in the "lucky" position to implement "vacation" (o-o-o) on top
of an existing postfix virtual mailbox installation and I want to
use as much of postfixadmin's "vacation" feature as possible.

Thank you very much

Axel


Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Günter W. Engerer Vorstand/Managing Board: Andreas Bublak, Manfred Steinberger, Robert Zellner COC AG Sitz/Registered Office Burghausen Amtsgericht/District Court Traunstein, HRB 17218

Re: [Postfixadmin-devel] Postfix Admin brazilian portuguese translation: updated/revised

[David G. <da...@co...>]

Luis wrote :
> Hi,
> 
> I just finished updating and revising the brazilian portuguese
> translation of Postfix Admin (pt-br.lang attached). I believe it's much
> better than the one currently being used. It has translations for all
> tags present in the last en.lang from SVN trunk.
> 
> Can someone upload it for me? Thought it would be easier to just send
> the lang file here.
> 
> Of course I'm open to any suggestions/criticism. I will keep my email
> subscribed to this list for the next weeks or so.
> 


Hi,
Merged/uploaded into subversion.

thanks
David.



-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]

Re: [Postfixadmin-devel] Postfix Admin brazilian portuguese translation: updated/revised

[David G. <da...@co...>]

Luis wrote :
> Hi,
> 
> I just finished updating and revising the brazilian portuguese
> translation of Postfix Admin (pt-br.lang attached). I believe it's much
> better than the one currently being used. It has translations for all
> tags present in the last en.lang from SVN trunk.
> 
> Can someone upload it for me? Thought it would be easier to just send
> the lang file here.
> 

Hi; unless someone beats me to it - I'll have it uploaded by/on Monday.

thanks
David.

-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]

[Postfixadmin-devel] Postfix Admin brazilian portuguese translation: updated/revised

[Luis <lu...@ri...>]

Hi,

I just finished updating and revising the brazilian portuguese
translation of Postfix Admin (pt-br.lang attached). I believe it's much
better than the one currently being used. It has translations for all
tags present in the last en.lang from SVN trunk.

Can someone upload it for me? Thought it would be easier to just send
the lang file here.

Of course I'm open to any suggestions/criticism. I will keep my email
subscribed to this list for the next weeks or so.

Thanks.

-- 
Luis

OpenPGP key:
0xA53D8214 | keyserver.noreply.org

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[482] trunk

[David G. <da...@co...>]

Christian Boltz wrote :
> Hello,
> 
> Am Samstag, 22. November 2008 schrieb David Goodwin:
> > Christian Boltz wrote :
> > > c) add a "show password" link (with a $CONF setting to enable it,
> > >    default should be disabled) which displays the password
> > > somewhere (using flash_info or a alert() feeded with a AJAX
> > > request) This would have some advantages:
> > >    - it works in every browser, not only if you have some extension
> > >    - it only transfers the password on request - which reduces the
> > > risk (and number) of passwords in browser cache etc. a lot - it
> > > fixes all the problems in edit-mailbox I described above - it would
> > > easily allow to mail a notification to the user, which might be
> > > required by some people/companies for privacy or policy reasons
> 
> > c) sounds good, but I've no motivation to write it; so either we
> > ditch the change, or someone writes a patch...
> 
> I reverted the patch for now (r485) - and opened a feature request so 
> that we don't forget about it:
> https://sourceforge.net/tracker/index.php?func=detail&aid=2332595&group_id=191583&atid=937967
> 
> > (So far, Postfixadmin is AJAX free, perhaps it should stay this way?)
> 
> I don't want to do "big" things with AJAX. But I don't see a problem in 
> using something like
>     alert($password_fetched_by_AJAX_request)
> The fallback could be that the "show password" link uses flash_info for 
> this - with the disadvantage of causing a page reload (and possibly 
> loose changes).
> 
> BTW: I don't see a real problem with AJAX - nearly every browser I know 
> supports it. OK, you could argue with lynx or even netscape 4 ;-) - but 
> people using lynx are probably the same that do a quick query in MySQL 
> if they want to find out the password. And people using netscape 4, 
> well, that's their own fault *g*
> 


Hi,

I don't have anything against JS; aside from to use it properly should
really pick and standardise on an appropriate JS library!

David.
-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[482] trunk

[Christian B. <pos...@cb...>]

Hello,

Am Samstag, 22. November 2008 schrieb David Goodwin:
> Christian Boltz wrote :
> > c) add a "show password" link (with a $CONF setting to enable it,
> >    default should be disabled) which displays the password
> > somewhere (using flash_info or a alert() feeded with a AJAX
> > request) This would have some advantages:
> >    - it works in every browser, not only if you have some extension
> >    - it only transfers the password on request - which reduces the
> > risk (and number) of passwords in browser cache etc. a lot - it
> > fixes all the problems in edit-mailbox I described above - it would
> > easily allow to mail a notification to the user, which might be
> > required by some people/companies for privacy or policy reasons

> c) sounds good, but I've no motivation to write it; so either we
> ditch the change, or someone writes a patch...

I reverted the patch for now (r485) - and opened a feature request so 
that we don't forget about it:
https://sourceforge.net/tracker/index.php?func=detail&aid=2332595&group_id=191583&atid=937967

> (So far, Postfixadmin is AJAX free, perhaps it should stay this way?)

I don't want to do "big" things with AJAX. But I don't see a problem in 
using something like
    alert($password_fetched_by_AJAX_request)
The fallback could be that the "show password" link uses flash_info for 
this - with the disadvantage of causing a page reload (and possibly 
loose changes).

BTW: I don't see a real problem with AJAX - nearly every browser I know 
supports it. OK, you could argue with lynx or even netscape 4 ;-) - but 
people using lynx are probably the same that do a quick query in MySQL 
if they want to find out the password. And people using netscape 4, 
well, that's their own fault *g*


Regards,

Christian Boltz
-- 
My Trash Can is also a shortcut for Amarok... I guess the Amarok team
must have had some wild thoughts about the features of their program =)
[Benjamin Bach in opensuse]

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[482] trunk

[David G. <da...@co...>]

Christian Boltz wrote :
> Hello,
> 
> Am Samstag, 22. November 2008 schrieb David Goodwin:
> ...
> > > - edit-mailbox might think the user wants to change the password
> > >   (because the password field isn't empty). This might result in
> > >   semi-random passwords if passwords are stored encrypted in the
> > >   database - the password hash will become the new password.
> > > (untested, but that's how I remember the code.)
> 
> > Well, int said there was a firefox extension which doesn't show stars
> > in a password field. The upshot being, that if you are a network
> > admin, and need to tell someone what their password is (or login as
> > them) then it's quite useful.
> 
> The usual solution for this problem is to simply change the password ;-)
> (doesn't solve the "login as them" part - but admins shouldn't do that 
> in general, and if the user wants them to do so, he can also tell his 
> password ;-)
> 
> And I still think displaying the password might cause problems as soon 
> as someone uses encrypted passwords and hits the "save" button...
> 
> Let me test it...
> 
> Test 1: encrypted passwords
> - go to edit-mailbox
> - click the save button
> Result: error message "the two passwords differ"
> 
> Test 2: plain text passwords
> - go to edit-mailbox
> - click the save button
> Result: password not changed, because edit-mailbox checks if it differs 
> from the old one
> 
> Test 3: plain text passwords again
> - go to edit-mailbox
> - "forget" to change "new password" field
> - enter a new password in "new password (again)" field
> Result: No password change and also no error message :-( because 
> edit-mailbox checks only the "new password" field for changes, not 
> the "(again)" field.
> 
> Testcase 3 is fixed now, but it will cause "the two passwords differ" 
> message in testcase 2 also.
> 
> Additionally, I get a "undefined variable" notice inside the password 
> field because the password is (intentionally) not read from $_POST. (Not 
> fixed yet, because I still think we'll need another solution, see c) 
> below.)
> 
> > Perhaps the config setting should be renamed, or have a comment
> > attached to make it obvious that it's only of any use if you store
> > plain text passwords.
> 
> If we really want to keep this feature (I'm still against it), then I 
> see three options:
> a) make it a separate setting ($CONF['SHOW_MAILBOX_PASSWORD_ON_EDIT'] or
> b) auto-disable it when password encryption is active  or
> c) add a "show password" link (with a $CONF setting to enable it, 
>    default should be disabled) which displays the password somewhere
>    (using flash_info or a alert() feeded with a AJAX request)
>    This would have some advantages:
>    - it works in every browser, not only if you have some extension
>    - it only transfers the password on request - which reduces the risk
>      (and number) of passwords in browser cache etc. a lot
>    - it fixes all the problems in edit-mailbox I described above
>    - it would easily allow to mail a notification to the user, which 
>      might be required by some people/companies for privacy or policy 
>      reasons
> 
> I think option c) is the best (or let's say "least bad") solution.

Hi,

c) sounds good, but I've no motivation to write it; so either we ditch
the change, or someone writes a patch...

(So far, Postfixadmin is AJAX free, perhaps it should stay this way?)

David.

-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[482] trunk

[Christian B. <pos...@cb...>]

Hello,

Am Samstag, 22. November 2008 schrieb David Goodwin:
...
> > - edit-mailbox might think the user wants to change the password
> >   (because the password field isn't empty). This might result in
> >   semi-random passwords if passwords are stored encrypted in the
> >   database - the password hash will become the new password.
> > (untested, but that's how I remember the code.)

> Well, int said there was a firefox extension which doesn't show stars
> in a password field. The upshot being, that if you are a network
> admin, and need to tell someone what their password is (or login as
> them) then it's quite useful.

The usual solution for this problem is to simply change the password ;-)
(doesn't solve the "login as them" part - but admins shouldn't do that 
in general, and if the user wants them to do so, he can also tell his 
password ;-)

And I still think displaying the password might cause problems as soon 
as someone uses encrypted passwords and hits the "save" button...

Let me test it...

Test 1: encrypted passwords
- go to edit-mailbox
- click the save button
Result: error message "the two passwords differ"

Test 2: plain text passwords
- go to edit-mailbox
- click the save button
Result: password not changed, because edit-mailbox checks if it differs 
from the old one

Test 3: plain text passwords again
- go to edit-mailbox
- "forget" to change "new password" field
- enter a new password in "new password (again)" field
Result: No password change and also no error message :-( because 
edit-mailbox checks only the "new password" field for changes, not 
the "(again)" field.

Testcase 3 is fixed now, but it will cause "the two passwords differ" 
message in testcase 2 also.

Additionally, I get a "undefined variable" notice inside the password 
field because the password is (intentionally) not read from $_POST. (Not 
fixed yet, because I still think we'll need another solution, see c) 
below.)

> Perhaps the config setting should be renamed, or have a comment
> attached to make it obvious that it's only of any use if you store
> plain text passwords.

If we really want to keep this feature (I'm still against it), then I 
see three options:
a) make it a separate setting ($CONF['SHOW_MAILBOX_PASSWORD_ON_EDIT'] or
b) auto-disable it when password encryption is active  or
c) add a "show password" link (with a $CONF setting to enable it, 
   default should be disabled) which displays the password somewhere
   (using flash_info or a alert() feeded with a AJAX request)
   This would have some advantages:
   - it works in every browser, not only if you have some extension
   - it only transfers the password on request - which reduces the risk
     (and number) of passwords in browser cache etc. a lot
   - it fixes all the problems in edit-mailbox I described above
   - it would easily allow to mail a notification to the user, which 
     might be required by some people/companies for privacy or policy 
     reasons

I think option c) is the best (or let's say "least bad") solution.


Regards,

Christian Boltz
-- 
Ei, wie lustig sie aufeinander losgehen. Flugs das Listenarchiv auf CD
gebrannt und das ganze als "SimRatti" verkauft. Steuern sie den kleinen
Helden durch Angriffswellen von Neidern, die die Erde mit Personal-
ausweisen bedrohen. Nu ist aber gut. ;-)     [Ratti in suse-linux]

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[482] trunk

[David G. <da...@co...>]

> > patch from int on irc - if $CONF[show_passwords] then do so
> > Modified: trunk/templates/edit-mailbox.php
> > Modified: trunk/edit-mailbox.php
> 
> I'd like to revert this change.
> 
> Reasons:
> 
> IMHO, showing the password is (only) useful at _mailbox creation_ to 
> check the password (or to note it down if you used an autogenerated 
> one).
> 
> But it isn't useful when editing mailboxes for several reasons:
> - the password field will just display stars, the "real" password will 
>   only be visible in the HTML source. That's useless.
> - the HTML source (including the password) might be stored in the 
>   browser cache - which implies some security risk
> - if the password is stored encrypted in the database, it will be 
>   displayed encrypted - which is more than useless ;-)
> - edit-mailbox might think the user wants to change the password 
>   (because the password field isn't empty). This might result in 
>   semi-random passwords if passwords are stored encrypted in the 
>   database - the password hash will become the new password. (untested,
>   but that's how I remember the code.)
> 
> Summary: There's no advantage for the user, but some possible problems.
> 
> GingerDog, do you agree on reverting this change?

Hi,

Well, int said there was a firefox extension which doesn't show stars
in a password field. The upshot being, that if you are a network
admin, and need to tell someone what their password is (or login as
them) then it's quite useful.

Perhaps the config setting should be renamed, or have a comment
attached to make it obvious that it's only of any use if you store
plain text passwords.


David.

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[482] trunk

[Christian B. <pos...@cb...>]

Hello,

Am Donnerstag, 13. November 2008 schrieb 
Gin...@us...:
> Revision: 482

> patch from int on irc - if $CONF[show_passwords] then do so
> Modified: trunk/templates/edit-mailbox.php
> Modified: trunk/edit-mailbox.php

I'd like to revert this change.

Reasons:

IMHO, showing the password is (only) useful at _mailbox creation_ to 
check the password (or to note it down if you used an autogenerated 
one).

But it isn't useful when editing mailboxes for several reasons:
- the password field will just display stars, the "real" password will 
  only be visible in the HTML source. That's useless.
- the HTML source (including the password) might be stored in the 
  browser cache - which implies some security risk
- if the password is stored encrypted in the database, it will be 
  displayed encrypted - which is more than useless ;-)
- edit-mailbox might think the user wants to change the password 
  (because the password field isn't empty). This might result in 
  semi-random passwords if passwords are stored encrypted in the 
  database - the password hash will become the new password. (untested,
  but that's how I remember the code.)

Summary: There's no advantage for the user, but some possible problems.

GingerDog, do you agree on reverting this change?


Regards,

Christian Boltz
-- 
I understand German well. But replying in German would make
me look like Trapatonni...    [Jaime Santos in suse-laptop]

Re: [Postfixadmin-devel] Quota not working ?

[albinootje <alb...@gm...>]

Marko Weber wrote:

Hi,

> Is this Sieve easy to do ?

I'm using this :

http://wiki.dovecot.org/LDA/Sieve#head-f083c4265adca5ce0fecf17d7684bd2dedbd5812-2

Very easy to set up,  (just use the file .dovecot.sieve in the users dir)
but the users have to ask me to set up the vacation-message,
and to remove it when they come back.

I've also tried AvelSieve as a plugin for Squirrelmail, which looks cool,

http://email.uoa.gr/avelsieve/wiki/Screenshots

took me quite some time to set it up, and then i decided that it was too
tricky for my
users to make mistakes with filtering.
I also had some strange permission-problems with it, which i couldn't
fix eventually,
I gave up for now.

Regards,
A.

Re: [Postfixadmin-devel] Quota not working ?

[Marko W. <mar...@sa...>]

when i delete a mailbox in postfixadmin i get a message =
"konnte nicht gelöscht werden  ex...@ma... (physical mail!)"

it deletes the mail from the "virtual list", but the folder are still 
there on the server after deletion ...

any ideas ?

marko

Re: [Postfixadmin-devel] Quota not working ?

[Marko W. <mar...@sa...>]

At first thank you for your effort to list all links,
i will go thru them.
Very interesting sounds the way to manage vacation over Sieve.

For me,. i got the vacation in postfixadmin working in some steps.
you gotta install some perl packets. with cpan an easy job.
then i edited some lines in the vacation.pl and it worked out of box.
but the postfix admin - vacation dont remember who got an vacation 
message before.
so if same person mails u again,. he gets everytime the vacation massage.

Is this Sieve easy to do ?

marko


albinootje schrieb:
> Marko Weber wrote:
>
>   
>> sorry, in your howto is quota config  <some text> , seems its planned
>>  for later. ill try man maildrop, if problems i come back , ok ?
>>     
>
> Okay, If i may shamelessly plug my favourite imap/pop3 server here :-)
>
> http://wiki.dovecot.org/HowTo/DovecotLDAPostfixAdminMySQL?highlight=(postfixadmin)
>
> I'm happily using this on a few mailservers at least for 1 year,
> following this howto (one change in the howto for running it on debian was
> the gid 8 for mail)
>
> One advantage of dovecot is that dovecot can do also the LDA,
> no need for extra software like maildrop. (I've tried maildrop before,
> but that
> was pretty hard to debug when it didn't work right away :( )
>
> I'm not using quota, but here's a wiki-page about dovecot + quota
> http://wiki.dovecot.org/Quota
>
> Dovecot is actively maintained, the author is pretty responsive on the
> mailinglists, it's fast and it focuses (amongst others) on security.
> It's also flexible and has several plugin options.
>
> I like dovecot, and i like postfixadmin too, but after spending *days*
> (months ago) on getting the postfixadmin autoreply functioning kind of
> properly (eventually using a mix of debian stable and debian testing), i've
> finally switched to the sieve plugin of dovecot for autoreplies.
>
> http://wiki.dovecot.org/LDA/Sieve
>
> see also :
> http://wiki.dovecot.org/Migration
>
> just FYI
>
>
>
>   

-- 

-- 
*Marko Weber* | Administration

*SALON DIGITAL* Media GmbH
Rothenbaumchaussee 19a
20148 Hamburg

T. (040) 429 48 68 - 23
F. (040) 429 48 68 - 20

mar...@sa... <mailto:mar...@sa...>
www.salondigital.de <http://www.salondigital.de>

--
Geschäftsführung: Stephan Michalik, Ekkehart Opitz
Registergericht: Amtsgericht Hamburg, NR: HRB 78111

NOTE: This communication is confidential and is intended for the use of 
the individual or entity to which it is directed. It may contain 
information that is privileged and exempt from disclosure under 
applicable law. If you are not the intended recipient please notify us 
immediately. You should not copy it or disclose its contents to any 
other person.

Re: [Postfixadmin-devel] Quota not working ?

[Guido 'l. B. <g....@le...>]

albinootje wrote:
> Marko Weber wrote:
> 
>> sorry, in your howto is quota config  <some text> , seems its planned
>>  for later. ill try man maildrop, if problems i come back , ok ?
> 
> Okay, If i may shamelessly plug my favourite imap/pop3 server here :-)
> .....
> http://wiki.dovecot.org/HowTo/DovecotLDAPostfixAdminMySQL?highlight=(postfixadmin)

Exactly the same over here, i'm running my own Dovecot/PFA setup
on a few FreeBSD boxes and i'm happy ever since i switched from
Courier/Maildrop.

I use Dovecot for POP3/IMAP/LDA together with the sieveplugin and
let my users modify their filtersettings and autoreplies via my
Squirrel-/Nutsmail installation featuring the "avelsieve" extension.

// lenix
-- 
Guido Boehm |    _/  | website: http://lenix.de/
Voigtstr. 8 |   _/   | contact: http://lenix.de/contact/
20257 DE/HH |  _/    | my card: http://lenix.de/contact/vcard.vcf
01738099196 | _/_/_/ | sweet<3: http://xichen.de/ :]

Re: [Postfixadmin-devel] Quota not working ?

[albinootje <alb...@gm...>]

Marko Weber wrote:

> sorry, in your howto is quota config  <some text> , seems its planned
>  for later. ill try man maildrop, if problems i come back , ok ?

Okay, If i may shamelessly plug my favourite imap/pop3 server here :-)

http://wiki.dovecot.org/HowTo/DovecotLDAPostfixAdminMySQL?highlight=(postfixadmin)

I'm happily using this on a few mailservers at least for 1 year,
following this howto (one change in the howto for running it on debian was
the gid 8 for mail)

One advantage of dovecot is that dovecot can do also the LDA,
no need for extra software like maildrop. (I've tried maildrop before,
but that
was pretty hard to debug when it didn't work right away :( )

I'm not using quota, but here's a wiki-page about dovecot + quota
http://wiki.dovecot.org/Quota

Dovecot is actively maintained, the author is pretty responsive on the
mailinglists, it's fast and it focuses (amongst others) on security.
It's also flexible and has several plugin options.

I like dovecot, and i like postfixadmin too, but after spending *days*
(months ago) on getting the postfixadmin autoreply functioning kind of
properly (eventually using a mix of debian stable and debian testing), i've
finally switched to the sieve plugin of dovecot for autoreplies.

http://wiki.dovecot.org/LDA/Sieve

see also :
http://wiki.dovecot.org/Migration

just FYI