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

Re: [Postfixadmin-devel] vacation sends message double

[Marko W. | Salondigital.d. <mar...@sa...>]

Hi David,
your posted link dont fixed anything. Vacation Messages still come twice.
The people in the posting talk about dspam sendings and such or ?
My Problem is, when a user activates vacation, the vacation message is 
sent twice.
I tried some tips from the post but it dont worked.

Let me know if you can help a bit and if you need anything maybe 
master.cf or main.cf

marko



David Goodwin schrieb:
> Marko Weber | Salondigital.de wrote :
>   
>> Hello,
>> when vacation is enabled , the vacation message is sent twice.
>> i dont get it why.
>> any ideas ?
>>
>> marko
>>
>> 
>>     
>
> See e.g.
> https://sourceforge.net/forum/forum.php?thread_id=3026548&forum_id=676076
>
> David.
>   
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
>
> !DSPAM:23,49a6ce9468521273275483!
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Postfixadmin-devel mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel
>
>
> !DSPAM:23,49a6ce9468521273275483!
>   

!DSPAM:171,49a6f77f68524591543903!

Re: [Postfixadmin-devel] vacation sends message double

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

Marko Weber | Salondigital.de wrote :
> Hello,
> when vacation is enabled , the vacation message is sent twice.
> i dont get it why.
> any ideas ?
> 
> marko
> 
> !DSPAM:171,49a6c5e668521101713239!

See e.g.
https://sourceforge.net/forum/forum.php?thread_id=3026548&forum_id=676076

David.
-- 
David Goodwin 

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

[Postfixadmin-devel] vacation sends message double

[Marko W. | Salondigital.d. <mar...@sa...>]

Hello,
when vacation is enabled , the vacation message is sent twice.
i dont get it why.
any ideas ?

marko

!DSPAM:171,49a6c5e668521101713239!

Re: [Postfixadmin-devel] Use extjs?

[Pető Z. <pe...@pe...>]

Sry, mispelled...
*
*http://pezo.net/extjs/postfixadmin/

PeZo
*
*Christian Boltz írta:
> Hello,
>
> Am Samstag, 21. Februar 2009 schrieb Peto Zoltn:
>   
>> Hello, I'm an Extjs developer. I like postfixadmin and also
>> use it. Do you interesting for postfixadmin to turn user
>> intervface to extjs? Small examples can be found here:
>> http://www.pezo.net/extjs/ and
>> http://extjs.com/deploy/dev/examples/
>>
>> Best Regards, Zoltan Peto from Hungary (pe...@pe...)
>>     
>
> I have to admit that I never heard of extjs before ;-) and also don't 
> really use AJAX frameworks so far except for some lightbox effect.
>
> I just looked at the extjs examples - they look impressing.
>
> My "usual" considerations are that this might come with too much 
> overhead for the small part of functionality we would need for 
> postfixadmin and what will happen to users that still use older or even 
> text mode browsers.
>
> I'm forwarding your mail to the postfixadmin-devel mailinglist to see 
> what the other developers think.
>
> Please CC the postfixadmin-devel mailinglist if you reply to this mail. 
> If needed, I will moderate your mails - but you can also subscribe to 
> postfixadmin-devel ;-)
>
> BTW: I also have a small bugreport for you: I use Konqueror as browser 
> and was unable to enter anything in the rich text fields (those that 
> show icons for bold, italic etc.). Please fix this ;-) or at least add 
> a fallback for browsers you can't/don't want to support.
>
>
> Regards,
>
> Christian Boltz
>   

Re: [Postfixadmin-devel] Use extjs?

[Pető Z. <pe...@pe...>]

Hey, there is one plan for new UI with two types of possible menus.

http://www.pezo.net/postfixadmin/

PeZo

Christian Boltz írta:
> Hello,
>
> Am Samstag, 21. Februar 2009 schrieb Peto Zoltn:
>   
>> Hello, I'm an Extjs developer. I like postfixadmin and also
>> use it. Do you interesting for postfixadmin to turn user
>> intervface to extjs? Small examples can be found here:
>> http://www.pezo.net/extjs/ and
>> http://extjs.com/deploy/dev/examples/
>>
>> Best Regards, Zoltan Peto from Hungary (pe...@pe...)
>>     
>
> I have to admit that I never heard of extjs before ;-) and also don't 
> really use AJAX frameworks so far except for some lightbox effect.
>
> I just looked at the extjs examples - they look impressing.
>
> My "usual" considerations are that this might come with too much 
> overhead for the small part of functionality we would need for 
> postfixadmin and what will happen to users that still use older or even 
> text mode browsers.
>
> I'm forwarding your mail to the postfixadmin-devel mailinglist to see 
> what the other developers think.
>
> Please CC the postfixadmin-devel mailinglist if you reply to this mail. 
> If needed, I will moderate your mails - but you can also subscribe to 
> postfixadmin-devel ;-)
>
> BTW: I also have a small bugreport for you: I use Konqueror as browser 
> and was unable to enter anything in the rich text fields (those that 
> show icons for bold, italic etc.). Please fix this ;-) or at least add 
> a fallback for browsers you can't/don't want to support.
>
>
> Regards,
>
> Christian Boltz
>   

Re: [Postfixadmin-devel] Use extjs?

[Pető Z. <pe...@pe...>]

Thank you for your fast answer!

I think there is two way for postfixadmin, first is the html based admin 
area and second is the rich GUI.
Rich GUI may be developed by ExtJs. I can do it for you but it needs 
some changes in postfixadmin code.
For example: form submit handling may be the same but after submitting 
the form response may be a JSON array.

Best regards: PeZo

Christian Boltz írta:
> Hello,
>
> Am Samstag, 21. Februar 2009 schrieb Peto Zoltn:
>   
>> Hello, I'm an Extjs developer. I like postfixadmin and also
>> use it. Do you interesting for postfixadmin to turn user
>> intervface to extjs? Small examples can be found here:
>> http://www.pezo.net/extjs/ and
>> http://extjs.com/deploy/dev/examples/
>>
>> Best Regards, Zoltan Peto from Hungary (pe...@pe...)
>>     
>
> I have to admit that I never heard of extjs before ;-) and also don't 
> really use AJAX frameworks so far except for some lightbox effect.
>
> I just looked at the extjs examples - they look impressing.
>
> My "usual" considerations are that this might come with too much 
> overhead for the small part of functionality we would need for 
> postfixadmin and what will happen to users that still use older or even 
> text mode browsers.
>
> I'm forwarding your mail to the postfixadmin-devel mailinglist to see 
> what the other developers think.
>
> Please CC the postfixadmin-devel mailinglist if you reply to this mail. 
> If needed, I will moderate your mails - but you can also subscribe to 
> postfixadmin-devel ;-)
>
>   

> BTW: I also have a small bugreport for you: I use Konqueror as browser 
> and was unable to enter anything in the rich text fields (those that 
> show icons for bold, italic etc.). Please fix this ;-) or at least add 
> a fallback for browsers you can't/don't want to support.
>   
Please send me an URL where you were found that bug.
>   
>
> Regards,
>
> Christian Boltz
>   

[Postfixadmin-devel] Use extjs? (was: question about postfixadmin)

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

Hello,

Am Samstag, 21. Februar 2009 schrieb Peto Zoltn:
> Hello, I'm an Extjs developer. I like postfixadmin and also
> use it. Do you interesting for postfixadmin to turn user
> intervface to extjs? Small examples can be found here:
> http://www.pezo.net/extjs/ and
> http://extjs.com/deploy/dev/examples/
>
> Best Regards, Zoltan Peto from Hungary (pe...@pe...)

I have to admit that I never heard of extjs before ;-) and also don't 
really use AJAX frameworks so far except for some lightbox effect.

I just looked at the extjs examples - they look impressing.

My "usual" considerations are that this might come with too much 
overhead for the small part of functionality we would need for 
postfixadmin and what will happen to users that still use older or even 
text mode browsers.

I'm forwarding your mail to the postfixadmin-devel mailinglist to see 
what the other developers think.

Please CC the postfixadmin-devel mailinglist if you reply to this mail. 
If needed, I will moderate your mails - but you can also subscribe to 
postfixadmin-devel ;-)

BTW: I also have a small bugreport for you: I use Konqueror as browser 
and was unable to enter anything in the rich text fields (those that 
show icons for bold, italic etc.). Please fix this ;-) or at least add 
a fallback for browsers you can't/don't want to support.


Regards,

Christian Boltz
-- 
Microsoft is a cross between The Borg and the Ferengi. Unfortunately
they use Borg to do their marketing and Ferengi to do their programming.
                                               [Simon Slavin in the SDM]

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

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

Hello,

Am Mittwoch, 4. Februar 2009 schrieb Jan Röhrich:
> > Minor issue first: Postfixadmin uses 3 space characters per
> > indention level for historical reasons. No tabs please.
> > (I did the whitespace fixes of your commit in SVN r561.)
> > If you use vim as editor, the vim: line in each file should setup
> > this automatically (except if you have disabled modelines - which
> > is the case on most newer installations because modelines can be
> > security relevant somehow [don't ask for the details]).
>
> I'm using eclipse. Ok, now I configured to use 3 spaces instead of
> tabs. Hope that works :-)
> But as David mentioned recently. The whole file functions.inc.php
> uses 4 spaces and so I continued using 4 spaces for now.

Indeed, functions.inc.php uses 4 spaces. I just fixed the vim: comment - 
one file less to migrate from the historical 3 spaces ;-)
(If you find other files that use 4 spaces and have a vim: comment 
saying 3, feel free to fix the vim: comment.)

BTW: Your last commit added some tabs again - I replaced them with 
spaces.

> > Is there a special reason to always use the same static salt?
> > Otherwise, I'd prefer a random salt for security reasons.
>
> Good point. I didn't thought that much about the crypt-flavor because
> I'm using unsalted md5s in my environment. I changed that to use a
> random salt in SVN r562.

Thanks!

> > Also the PHP documentation about crypt() says that in some cases
> > (depending on the encryption method) the salt should be longer than
> > two characters.
>
> Yes, but courier-authlib only supports two-character salts.

Ah, OK. I added a comment about this to avoid similar questions in the 
future ;-)

> >> +      	if(stripos($flavor, 'md5raw') === 0) {
> >> +         	$password = '{' . $flavor . '}' . md5($pw);
> >> +      	} else if(stripos($flavor, 'md5') === 0) {
> >
> > Why "else if" instead of "elseif"?

> Shouldn't else if and elseif be the same when you use curly braces?
> -> http://de.php.net/manual/en/control-structures.elseif.php

Yes, they are the same. It's more a style question.

Since the two listed lines are the only ones in postfixadmin using "else 
if" instead of "elseif", I took the liberty to remove the space.

All these things are in SVN r564.

> > Oh, and what happens if someone sets something like
> >     $CONF['authlib_default_flavour'] = 'this-is-not-supported';
> > (or just a typo like 'md6')?
> >
> > I'd expect an "else" with a clear error message for this case...
> > (Feel free to use die() since this is a configuration error.)
>
> Another good point :-) I fixed this in SVN r562 too.

Thanks!

Another thing I just noticed:

        if(stripos($flavor, 'md5raw') === 0) {
            ...
        } elseif(stripos($flavor, 'md5') === 0) {
            ...
        } elseif(stripos($flavor, 'crypt') === 0) {
            ...

This code depends on the correct order (md5raw must be checked before 
md5) which of course works. However, it will also match something 
like "md52" as "md5".

I don't know how the field looks in courier-authlib style (can you post 
some examples?), but if there is a separator between the encryption 
method and the encrypted password, you should include the separator in 
the stripos() check.


Regards,

Christian Boltz
-- 
Graphisch??? Wie meinen? Hast du zuviel Fleisch von zu "gluecklichen"
Rindern gefuttert? *scnr*  Wozu zum Henker sollte man sowas brauchen?
Logo ginge auch per ASCII :)  (Logo?  welches Logo? Wozu ueberhaupt?)
[David Haller in suse-linux]

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

[Jan R. <ja...@ro...>]

> Minor issue first: Postfixadmin uses 3 space characters per indention 
> level for historical reasons. No tabs please.
> (I did the whitespace fixes of your commit in SVN r561.)
> If you use vim as editor, the vim: line in each file should setup this 
> automatically (except if you have disabled modelines - which is the 
> case on most newer installations because modelines can be security 
> relevant somehow [don't ask for the details]).

I'm using eclipse. Ok, now I configured to use 3 spaces instead of tabs. 
Hope that works :-)
But as David mentioned recently. The whole file functions.inc.php uses 4 
spaces and so I continued using 4 spaces for now.

> Is there a special reason to always use the same static salt? Otherwise, 
> I'd prefer a random salt for security reasons.

Good point. I didn't thought that much about the crypt-flavor because 
I'm using unsalted md5s in my environment. I changed that to use a 
random salt in SVN r562.

> Also the PHP documentation about crypt() says that in some cases 
> (depending on the encryption method) the salt should be longer than two 
> characters.

Yes, but courier-authlib only supports two-character salts.

>> +      	if(stripos($flavor, 'md5raw') === 0) {
>> +         	$password = '{' . $flavor . '}' . md5($pw);
>> +      	} else if(stripos($flavor, 'md5') === 0) {
> 
> Why "else if" instead of "elseif"?
> 
>> +      		$password = '{' . $flavor . '}' . base64_encode(md5($pw,
>>                                                         TRUE)); 
>> +      	} else if(stripos($flavor, 'crypt') === 0) { 
> 
> Same question about "else if" again ;-)

Shouldn't else if and elseif be the same when you use curly braces? -> 
http://de.php.net/manual/en/control-structures.elseif.php

> Oh, and what happens if someone sets something like
>     $CONF['authlib_default_flavour'] = 'this-is-not-supported';
> (or just a typo like 'md6')?
> 
> I'd expect an "else" with a clear error message for this case...
> (Feel free to use die() since this is a configuration error.)

Another good point :-) I fixed this in SVN r562 too.

Greetings Jan

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

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

Hello,

Am Dienstag, 3. Februar 2009 schrieb David Goodwin:
> Christian Boltz wrote :
...
> Oh really? I thought we used 4 spaces... at least I'm pretty sure I'm
> reindenting code to this etc.

At least the vim: lines say ts=3 in most files ;-)
I grepped around a bit - only 9 of 72 files have ts=4.

In the future (read: when doing the long-planned rewrite etc.) we should 
really use ts=4 (and maybe use real tabs instead of spaces), but the 
historically grown files come with ts=3.

> > If you use vim as editor, the vim: line in each file should setup
> > this automatically (except if you have disabled modelines - which
> > is the case on most newer installations because modelines can be
> > security relevant somehow [don't ask for the details]).
>
> Ah.. so that explains why the magic lines aren't working any longer..
> *grr*

Hint: Add something like this to your ~/.vimrc to re-enable it:
    set modelines=15
(see also ":help modelines")


Regards,

Christian Boltz
-- 
         .:  Schneewittchen & die Pfälzer Waldconnection  :.
        Ein polit-kabarettistisches Märchenstück mit viel Musik
  gesungen & gespielt von Mitgliedern der Landjugend RheinhessenPfalz
18.1.2009 Berlin - 6.2.2009 Neustadt - Infos: www.LJ-RheinhessenPfalz.de

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

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

Christian Boltz wrote :
> Hello,
> 
> I have some questions and remarks about your commit.
> 
> Minor issue first: Postfixadmin uses 3 space characters per indention 
> level for historical reasons. No tabs please.
> (I did the whitespace fixes of your commit in SVN r561.)
> \

Oh really? I thought we used 4 spaces... at least I'm pretty sure I'm
reindenting code to this etc.

> If you use vim as editor, the vim: line in each file should setup this 
> automatically (except if you have disabled modelines - which is the 
> case on most newer installations because modelines can be security 
> relevant somehow [don't ask for the details]).

Ah.. so that explains why the magic lines aren't working any longer..
*grr*

David.
-- 
David Goodwin 

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

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

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

Hello,

I have some questions and remarks about your commit.

Minor issue first: Postfixadmin uses 3 space characters per indention 
level for historical reasons. No tabs please.
(I did the whitespace fixes of your commit in SVN r561.)

If you use vim as editor, the vim: line in each file should setup this 
automatically (except if you have disabled modelines - which is the 
case on most newer installations because modelines can be security 
relevant somehow [don't ask for the details]).

Am Dienstag, 3. Februar 2009 schrieb roe...@us...:
> Revision: 560
> Author:   roehrijn

> function.inc.php:
> - changed pa_crypt to make it handle courier authlib authentication
> flavors

> --- trunk/functions.inc.php	2009-02-02 22:14:23 UTC (rev 559)
> +++ trunk/functions.inc.php	2009-02-03 17:50:13 UTC (rev 560)
> @@ -1160,6 +1160,27 @@

> +    if ($CONF['encrypt'] == 'authlib') {
> +    	$flavor = $CONF['authlib_default_flavor'];
> +    	$salt = '  ';

Is there a special reason to always use the same static salt? Otherwise, 
I'd prefer a random salt for security reasons.

Also the PHP documentation about crypt() says that in some cases 
(depending on the encryption method) the salt should be longer than two 
characters.

> +    	if(ereg('^{.*}', $pw_db)) {

preg_match() might be faster - at least that's what the documentation 
says ;-)

> +      	if(stripos($flavor, 'md5raw') === 0) {
> +         	$password = '{' . $flavor . '}' . md5($pw);
> +      	} else if(stripos($flavor, 'md5') === 0) {

Why "else if" instead of "elseif"?

> +      		$password = '{' . $flavor . '}' . base64_encode(md5($pw,
>                                                         TRUE)); 
> +      	} else if(stripos($flavor, 'crypt') === 0) { 

Same question about "else if" again ;-)

Oh, and what happens if someone sets something like
    $CONF['authlib_default_flavour'] = 'this-is-not-supported';
(or just a typo like 'md6')?

I'd expect an "else" with a clear error message for this case...
(Feel free to use die() since this is a configuration error.)


Regards,

Christian Boltz
-- 
         .:  Schneewittchen & die Pfälzer Waldconnection  :.
        Ein polit-kabarettistisches Märchenstück mit viel Musik
  gesungen & gespielt von Mitgliedern der Landjugend RheinhessenPfalz
18.1.2009 Berlin - 6.2.2009 Neustadt - Infos: www.LJ-RheinhessenPfalz.de

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[506] trunk/upgrade.php

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

Hello,

Am Samstag, 31. Januar 2009 schrieb David Goodwin:
> > I promise one thing: If we ever get any bugs regarding the
> > vacation_notification constraint again, I will find a way to drop
> > the constraint (even if it means to parse "show create table"
> > output) - and never create a constraint again.
>
> Hah. I suspect I would have introduced that constraint.

Probably - since you did several database changes when making the PgSQL 
vacation script MySQL compatible...

> Does your changes to CHANGELOG imply that you think we're ready for
> 2.3 to be released?

The only showstopper I currently see is that only superadmins can delete 
domain aliases. This should be quite easy to fix (see my mail from 
friday for details).


Regards,

Christian Boltz
-- 
         .:  Schneewittchen & die Pfälzer Waldconnection  :.
        Ein polit-kabarettistisches Märchenstück mit viel Musik
  gesungen & gespielt von Mitgliedern der Landjugend RheinhessenPfalz
18.1.2009 Berlin - 6.2.2009 Neustadt - Infos: www.LJ-RheinhessenPfalz.de

[Postfixadmin-devel] feature request pop3 imap field

[Robert S. <ro...@sc...>]

Hi,
i am not really up2date with current
postfixadmin , so excuse if my request was done before and/or was
already done

dovecot gives the chance to limit users
either pop3 and/or imap login
out of sql

see

http://wiki.dovecot.org/Authentication/RestrictAccess

------------
SQL

You can use the %Ls variable which expands to imap or pop3 in
password_query, eg:

password_query = SELECT password FROM users WHERE userid = '%u' and
(imap_allowed = true or '%Ls' = 'pop3')

--------

so it would be nice to have that fields in the
sql layout, and able to configure in the postfixadmin gui
there should be a choosable default ( only pop3 on, only imap on, or
both on )
in the master postfixadnin conf too

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[506] trunk/upgrade.php

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

> 
> > I think I'd rather upgrade.php stay as it is - as I have some small
> > amount of belief that it now works for everyone. At least no one else
> > has reported bugs with it!
> 
> I hope this means there are no bugs left ;-)
> 

Me too :)

> I promise one thing: If we ever get any bugs regarding the 
> vacation_notification constraint again, I will find a way to drop the 
> constraint (even if it means to parse "show create table" output) - and 
> never create a constraint again.

Hah. I suspect I would have introduced that constraint.

Does your changes to CHANGELOG imply that you think we're ready for
2.3 to be released?

thanks
David.

-- 
David Goodwin 

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

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[506] trunk/upgrade.php

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

Hello,

Am Montag, 26. Januar 2009 schrieb David Goodwin:
> > > @@ -156,8 +156,8 @@
> > > -                '{UTF-8}'           => '/*!40100 CHARACTER SET
> > > utf8   COLLATE utf8_unicode_ci */', -                '{LATIN1}'  
> > >        => '/*!40100 CHARACTER SET latin1 COLLATE
> > > latin1_swedish_ci */', +                '{UTF-8}'           =>
> > > '/*!40100 CHARACTER SET utf8 */', +                '{LATIN1}'    
> > >      => '/*!40100 CHARACTER SET latin1 */',
> >
> > Do you really think COLLATE can cause problems?
>
> Well... people who had their default collation/character set, set to
> uft8 had problems.

If it works this way - OK. But I still think the problem is that there 
are _different_ settings - maybe we forgot to set COLLATE somewhere 
before or something like that.

> > IMHO it causes more problems if we do not explicitely set it
> > because we then get a "random" (as in "MySQL default on this
> > system") collation. I doubt that this is positive ;-)
>
> Is it a problem if it's set to e.g utf-8? I get the impression that
> the distros are moving towards this as a default.

MySQL and utf-8 is an "interesting" story, and things aren't that easy 
as they might seem.

Best example: utf-8 varchar fields use 3 times the disk space a latin1 
field uses. Not nice, but not really problematic in our use case. (If 
you don't have disk space for the database, you don't even need to 
think about hosting mailboxes ;-)

The real problem is when you want to have an index over multiple varchar 
columns. A utf-8 varchar(255) is counted as 3*255 = 765, and the total 
index length is limited to 1024. This means you can't have an index 
across two utf-8 varchar(255) columns.
(We have an unique index across two varchar(255) columns in 
vacation_notification - for obvious reasons those columns are in 
latin1.)

This is the main reason why I try to stick to latin1 fields whereever 
possible.

> > > @@ -306,7 +306,7 @@
> > > -    ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci
> > > TYPE=InnoDB ... +    ) ENGINE=InnoDB DEFAULT CHARSET=utf8
> > > TYPE=InnoDB ...
> >
> > Sidenote: CHARSET=utf8 (and COLLATE) should be replaced with
> > {UTF-8}
>
> I don't think I fully understand the difference between the two! It's
> so much easier with PostgreSQL!

CHARSET ist just another word for CHARACTER SET. No difference involved.

> > > @@ -772,7 +772,6 @@
> > > -        ALTER TABLE `$table_vacation_notification` DROP FOREIGN
> > > KEY `vacation_notification_pkey`
> >
> > This ALTER TABLE was there for a reason (probably because some
> > version of the vacation_notification table had such a primary key).
> >
> > I'd like to reintroduce it with the ignore_errors flag set, so that
> > the key is deleted if it exists. Any objections?
>
> Not really. I had one user who was seeing problems when it was trying
> to remove the key (and it didn't already exist). I presumed it was
> not necessary, and could be removed.

That is the fun part with the ignore_errors flag - if something fails 
for whatever reason, it just silently ignores it and continues with the 
next query ;-)

You could even do a query like "ASDFAWE ASDF QWE SDFQ WEDSS FA;" - as 
long as you pass the ignore_errors flag, nothing bad will happen (from 
the user's POV) ;-)

> I think I'd rather upgrade.php stay as it is - as I have some small
> amount of belief that it now works for everyone. At least no one else
> has reported bugs with it!

I hope this means there are no bugs left ;-)

I promise one thing: If we ever get any bugs regarding the 
vacation_notification constraint again, I will find a way to drop the 
constraint (even if it means to parse "show create table" output) - and 
never create a constraint again.


Regards,

Christian Boltz
-- 
         .:  Schneewittchen & die Pfälzer Waldconnection  :.
        Ein polit-kabarettistisches Märchenstück mit viel Musik
  gesungen & gespielt von Mitgliedern der Landjugend RheinhessenPfalz
18.1.2009 Berlin - 6.2.2009 Neustadt - Infos: www.LJ-RheinhessenPfalz.de

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[512] trunk/delete.php

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

Hello,

Am Montag, 26. Januar 2009 schrieb David Goodwin:
> Christian Boltz wrote :
> > Am Montag, 12. Januar 2009 schrieb Gin...@us...:
> > > Revision: 512
> > >
> > > delete.php: this probably allows you to delete domains
> > >
> > > Modified: trunk/delete.php
> > >
> > > +elseif ($fTable == "alias_domain")
> > > +{
> > > +   authentication_require_role('global-admin');
> >
> > Is there a special reason why you limited deletion of alias domains
> > to superadmins?
> >
> > Every domain admin is allowed to create alias domains (given he has
> > at least 2 domains ;-) - so he should also be allowed to delete
> > domain aliases again. (A check if both involved domains are owned
> > by the admin is of course necessary.)
>
> I wasn't sure how to tell if a non-global admin owned a domain.. so I
> just went with the easy option.

What about   
    list_domains_for_admin ($fUsername)
or   
    check_owner ($username, $domain)
? ;-)

Your easy option has the disadvantage that a domain admin can't delete 
the alias domains he created before...


Regards,

Christian Boltz
-- 
         .:  Schneewittchen & die Pfälzer Waldconnection  :.
        Ein polit-kabarettistisches Märchenstück mit viel Musik
  gesungen & gespielt von Mitgliedern der Landjugend RheinhessenPfalz
18.1.2009 Berlin - 6.2.2009 Neustadt - Infos: www.LJ-RheinhessenPfalz.de

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[512] trunk/delete.php

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

Christian Boltz wrote :
> Hello,
> 
> Am Montag, 12. Januar 2009 schrieb Gin...@us...:
> > Revision: 512
> 
> > delete.php: this probably allows you to delete domains
> 
> > Modified: trunk/delete.php
> 
> > +elseif ($fTable == "alias_domain")
> > +{
> > +   authentication_require_role('global-admin');
> 
> Is there a special reason why you limited deletion of alias domains to 
> superadmins?
> 
> Every domain admin is allowed to create alias domains (given he has at 
> least 2 domains ;-) - so he should also be allowed to delete domain 
> aliases again. (A check if both involved domains are owned by the admin 
> is of course necessary.)
> 

I wasn't sure how to tell if a non-global admin owned a domain.. so I
just went with the easy option.

David.

-- 
David Goodwin 

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

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[506] trunk/upgrade.php

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

> 
> > @@ -156,8 +156,8 @@
> > -                '{UTF-8}'           => '/*!40100 CHARACTER SET utf8   COLLATE utf8_unicode_ci */', 
> > -                '{LATIN1}'          => '/*!40100 CHARACTER SET latin1 COLLATE latin1_swedish_ci */', 
> > +                '{UTF-8}'           => '/*!40100 CHARACTER SET utf8 */', 
> > +                '{LATIN1}'          => '/*!40100 CHARACTER SET latin1 */',
> 
> Do you really think COLLATE can cause problems?

Well... people who had their default collation/character set, set to
uft8 had problems. 

> 
> IMHO it causes more problems if we do not explicitely set it because we 
> then get a "random" (as in "MySQL default on this system") collation. 
> I doubt that this is positive ;-)

Is it a problem if it's set to e.g utf-8? I get the impression that
the distros are moving towards this as a default.

> 
> > @@ -306,7 +306,7 @@
> > -    ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci TYPE=InnoDB ...
> > +    ) ENGINE=InnoDB DEFAULT CHARSET=utf8 TYPE=InnoDB ...
> 
> Sidenote: CHARSET=utf8 (and COLLATE) should be replaced with {UTF-8}
> 

I don't think I fully understand the difference between the two! It's
so much easier with PostgreSQL!

> > @@ -772,7 +772,6 @@
> > -        ALTER TABLE `$table_vacation_notification` DROP FOREIGN KEY `vacation_notification_pkey` 
> 
> This ALTER TABLE was there for a reason (probably because some version
> of the vacation_notification table had such a primary key).
> 
> I'd like to reintroduce it with the ignore_errors flag set, so that
> the key is deleted if it exists. Any objections?

Not really. I had one user who was seeing problems when it was trying
to remove the key (and it didn't already exist). I presumed it was not
necessary, and could be removed.

I think I'd rather upgrade.php stay as it is - as I have some small
amount of belief that it now works for everyone. At least no one else
has reported bugs with it!

David.
-- 
David Goodwin 

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

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[512] trunk/delete.php

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

Hello,

Am Montag, 12. Januar 2009 schrieb Gin...@us...:
> Revision: 512

> delete.php: this probably allows you to delete domains

> Modified: trunk/delete.php

> +elseif ($fTable == "alias_domain")
> +{
> +   authentication_require_role('global-admin');

Is there a special reason why you limited deletion of alias domains to 
superadmins?

Every domain admin is allowed to create alias domains (given he has at 
least 2 domains ;-) - so he should also be allowed to delete domain 
aliases again. (A check if both involved domains are owned by the admin 
is of course necessary.)


Regards,

Christian Boltz
-- 
         .:  Schneewittchen & die Pfälzer Waldconnection  :.
        Ein polit-kabarettistisches Märchenstück mit viel Musik
  gesungen & gespielt von Mitgliedern der Landjugend RheinhessenPfalz
18.1.2009 Berlin - 6.2.2009 Neustadt - Infos: www.LJ-RheinhessenPfalz.de

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[506] trunk/upgrade.php

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

Hello,

(just going through some commits and updating the changelog)

Am Sonntag, 4. Januar 2009 schrieb Gin...@us...:
> Revision: 506

> 1) remove explicit collation settings; 
> 2) remove vacation_notification_pkey drop thing 

> Modified: trunk/upgrade.php

> @@ -156,8 +156,8 @@
> -                '{UTF-8}'           => '/*!40100 CHARACTER SET utf8   COLLATE utf8_unicode_ci */', 
> -                '{LATIN1}'          => '/*!40100 CHARACTER SET latin1 COLLATE latin1_swedish_ci */', 
> +                '{UTF-8}'           => '/*!40100 CHARACTER SET utf8 */', 
> +                '{LATIN1}'          => '/*!40100 CHARACTER SET latin1 */',

Do you really think COLLATE can cause problems?

IMHO it causes more problems if we do not explicitely set it because we 
then get a "random" (as in "MySQL default on this system") collation. 
I doubt that this is positive ;-)

> @@ -306,7 +306,7 @@
> -    ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci TYPE=InnoDB ...
> +    ) ENGINE=InnoDB DEFAULT CHARSET=utf8 TYPE=InnoDB ...

Sidenote: CHARSET=utf8 (and COLLATE) should be replaced with {UTF-8}

> @@ -772,7 +772,6 @@
> -        ALTER TABLE `$table_vacation_notification` DROP FOREIGN KEY `vacation_notification_pkey` 

This ALTER TABLE was there for a reason (probably because some version
of the vacation_notification table had such a primary key).

I'd like to reintroduce it with the ignore_errors flag set, so that
the key is deleted if it exists. Any objections?


Regards,

Christian Boltz
-- 
         .:  Schneewittchen & die Pfälzer Waldconnection  :.
        Ein polit-kabarettistisches Märchenstück mit viel Musik
  gesungen & gespielt von Mitgliedern der Landjugend RheinhessenPfalz
18.1.2009 Berlin - 6.2.2009 Neustadt - Infos: www.LJ-RheinhessenPfalz.de

Re: [Postfixadmin-devel] Supporting courier-authlib authentication flavors

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

Jan Röhrich wrote :
> Hello List,
> 
> I'm using courier-authlib together with postfix with user metadata 
> stored in a mysql database.
> 

Hello,

I use courierauthlib with PostgreSQL and don't need any of the below.
Am I missing something obvious?

(I'm happy for the patch to be submitted)

David.

> courier-authlib uses authentication flavors. Some examples:
> 
> {md5}MDbtZsfdyqbY0o7eDlJjKrQ==
> {md5raw}be623121af8f94d0ddc1e052d17831d6
> {crypt}AhlkDUpVER6dQ
> 
> I added support for such authetication flavors to postfixadmin and it 
> works in my setup. I attached a first patch which should clarify how I 
> would like to support this.
> 
> May I add this to trunk?

Re: [Postfixadmin-devel] Using SQL prepared statements -> getting rid of mysql extension

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

Jan Röhrich wrote :
> Hello List,
> 
> I mentioned in my participation request a few days ago that I think
> there are some theoretical SQL injection vulnerabilities in postfixadmin.
> 
> Have a look at the login process:
> 
> 
> $result = db_query ("SELECT password FROM $table_admin WHERE
> username='$fUsername' AND active='1'");
>      if ($result['rows'] == 1)
>      {
>          $row = db_array ($result['result']);
>          $password = pacrypt ($fPassword, $row['password']);
>          $result = db_query ("SELECT * FROM $table_admin WHERE
> username='$fUsername' AND password='$password' AND active='1'");
>          if ($result['rows'] != 1)
>          {
>              $error = 1;
>              $tMessage = $PALANG['pLogin_failed'];
>              $tUsername = $fUsername;
>          }
>      }
> 
> I think the main problem is the usage of "unprepared" sql statements.
> Somebody may form a username like "' OR true" ore something like that
> and the sql statement ends up in a completely different meaning. This is
> a very theoretical vulnerability as there is a second query after the
> password is hashed.
> 
> But can't we get rid of the mysql extension compatibility and force
> usage of mysqli (ore pgsql) to make use of prepared statements? With
> prepared statements we can render sql selects like "SELECT * FROM
> $table_admin WHERE username=? AND password=? AND active='1'", which is
> much more secure than the method mentioned above. Postgres supports
> prepared statements this since version 7.4 which was released in 2004 I
> think.
> 
> I would like to do this - maybe in a svn branch. I'm looking forward to
> your comments.

Hi!

We've kind of had this debate in the past......

a) Someone will complain about using $library (which will be needed to
emulate prepared statements for MySQL)

b) All fields should have 'escape_string' run on them before being
used... so 'should' be safe. Obviously this requires $developer
remembers to do whatever.

c) It's quite likely that we'll migrate to using Zend_Db_Table/Zend_Db
(which implies PDO) soon ... so although it's a good idea for you to
patch any bugs in the current codebase, it's not worth porting all the
code to use a library which provides agnostic prepared statements as
your work will be in vain if we do move to Zend_Db....

thanks
David.

-- 
David Goodwin 

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

[Postfixadmin-devel] Supporting courier-authlib authentication flavors

[Jan R. <ja...@ro...>]

Hello List,

I'm using courier-authlib together with postfix with user metadata 
stored in a mysql database.

courier-authlib uses authentication flavors. Some examples:

{md5}MDbtZsfdyqbY0o7eDlJjKrQ==
{md5raw}be623121af8f94d0ddc1e052d17831d6
{crypt}AhlkDUpVER6dQ

I added support for such authetication flavors to postfixadmin and it 
works in my setup. I attached a first patch which should clarify how I 
would like to support this.

May I add this to trunk?

Best regards Jan

Index: config.inc.php
===================================================================
--- config.inc.php	(revision 530)
+++ config.inc.php	(working copy)
@@ -89,8 +89,15 @@
  // system = whatever you have set as your PHP system default
  // cleartext = clear text passwords (ouch!)
  // mysql_encrypt = useful for PAM integration
+// authlib = support for courier-authlib style passwords
  $CONF['encrypt'] = 'md5crypt';

+// In what flavor should courier-authlib style passwords be enrypted?
+// md5 = {md5} + base64 encoded md5 hash
+// md5raw = {md5raw} + plain encoded md5 hash
+// crypt = {crypt} + Standard UNIX DES-enrypted with 2-character salt
+$CONF['authlib_default_flavor'] = 'md5raw';
+
  // Minimum length required for passwords. Postfixadmin will not
  // allow users to set passwords which are shorter than this value.
  $CONF['min_password_length'] = 5;
Index: functions.inc.php
===================================================================
--- functions.inc.php	(revision 548)
+++ functions.inc.php	(working copy)
@@ -256,7 +256,7 @@
              flash_error("emailcheck_resolve_domain is enabled, but 
function (checkdnsrr) missing!");
          }
      }
-
+
      return true;
  }

@@ -1160,6 +1160,27 @@
          $l = db_row($res["result"]);
          $password = $l[0];
      }
+
+    if ($CONF['encrypt'] == 'authlib') {
+    	$flavor = $CONF['authlib_default_flavor'];
+    	$salt = '  ';
+    	if(ereg('^{.*}', $pw_db)) {
+    		// we have a flavor in the db -> use it instead of default flavor
+    		$result = split('{|}', $pw_db, 3);
+    		$flavor = $result[1];
+    		$salt = substr($result[2], 0, 2);  		
+    	}
+    	    	
+      	if(stripos($flavor, 'md5raw') === 0) {
+         	$password = '{' . $flavor . '}' . md5($pw);
+      	} else if(stripos($flavor, 'md5') === 0) {
+      		$password = '{' . $flavor . '}' . base64_encode(md5($pw, TRUE));
+      	} else if(stripos($flavor, 'crypt') === 0) {
+      		$password = '{' . $flavor . '}' . crypt($pw, $salt);
+      	}
+   	}
+
+
      $password = escape_string ($password);
      return $password;
  }


-- 
Jan Röhrich
Kleinglattbacher Str. 12
D-75428 Illingen
Tel.: +49 7042 120351
Mobil: +49 1638463295
eMail: ja...@ro...

[Postfixadmin-devel] Using SQL prepared statements -> getting rid of mysql extension

[Jan R. <ja...@ro...>]

Hello List,

I mentioned in my participation request a few days ago that I think
there are some theoretical SQL injection vulnerabilities in postfixadmin.

Have a look at the login process:


$result = db_query ("SELECT password FROM $table_admin WHERE
username='$fUsername' AND active='1'");
     if ($result['rows'] == 1)
     {
         $row = db_array ($result['result']);
         $password = pacrypt ($fPassword, $row['password']);
         $result = db_query ("SELECT * FROM $table_admin WHERE
username='$fUsername' AND password='$password' AND active='1'");
         if ($result['rows'] != 1)
         {
             $error = 1;
             $tMessage = $PALANG['pLogin_failed'];
             $tUsername = $fUsername;
         }
     }

I think the main problem is the usage of "unprepared" sql statements.
Somebody may form a username like "' OR true" ore something like that
and the sql statement ends up in a completely different meaning. This is
a very theoretical vulnerability as there is a second query after the
password is hashed.

But can't we get rid of the mysql extension compatibility and force
usage of mysqli (ore pgsql) to make use of prepared statements? With
prepared statements we can render sql selects like "SELECT * FROM
$table_admin WHERE username=? AND password=? AND active='1'", which is
much more secure than the method mentioned above. Postgres supports
prepared statements this since version 7.4 which was released in 2004 I
think.

I would like to do this - maybe in a svn branch. I'm looking forward to
your comments.

Best regards

Jan

-- 
Jan Röhrich
Kleinglattbacher Str. 12
D-75428 Illingen
Tel.: 07042 120351
Mobil: 01638463295
eMail: ja...@ro...