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

[Postfixadmin-devel] PFA v3

[Rudi F. <rud...@go...>]

[translation into german on request]
Hallo Christian,

ich denke die art wie wir unser svn nutzen stößt an seine grenzen. Für
die ganzen ideen wie wir einpflegen wollen, müssten wir nur in branches
entwickeln, bzw. bugfixes durchführen und mit tags releases festhalten.
Nicht nur in trunk entwickeln. Entweder wir strukturieren die arbeit in
svn um, oder wir wechseln zu Git wenn das auf sourceforge schon möglich ist.

Desweiteren würde ich fragen wie es mit der entwicklung für PFA3 aussieht?
Würde dafür gerne dann eine neue branch in svn oder in git einen neuen
context starten. Generell schon mal eine todo anfangen.
Mag zwar ein langer weg werden, aber einige Ziele sind ja schon da
(einige aus meinem privaten wunsch sammelsorium), wie
*trennung von Model und Controller
*trennung der db functionen aus der functions.php
*generell nur noch kleine hilfsfunktionen in der functions.php aufbewahren.
*neues pfad system, um das mvc konzept bestmöglich auszunutzen.
*von usern eingepflegte spalten. (stichwort CCK in drupal)
*besseres setup, mit automatischer setup.php creation.
*upgrade von 2.2 und 2.3 evntl. 2.4 wenn es raus ist.
*verbesserte unterstützung von PFA-CLI
*etc.

Was sagst du dazu?

Würd mich über eine antwort freuen.

[Postfixadmin-devel] phpdocumentor

[Rudi F. <rud...@go...>]

Hallo guys,

can you install phpdocumentor or something semilar? Would be nice for
developing, when we set the right tags.
example:
a list of all @todo tags.

Re: [Postfixadmin-devel] 2.3.3 release?

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

Hello,

Am Donnerstag, 3. März 2011 schrieb Tanstaafl:
> On 2011-03-03 4:38 PM, Christian Boltz wrote:
> > Besides that, the diff (see [1]) looks good and we don't have
> > critical open bugs in the bugtracker.
> 
> What about the broken logging bugs I reported? I'd really like to see
> them fixed...

I'd also prefer to have an empty bug list ;-) but if we wait with the 
release until we reach that status, you'll see PostfixAdmin 2.3.3 in two 
years - if nobody finds new bugs ;-)  (see sig *g*)

OTOH, what we have in the 2.3 branch now (see my changelog sniplet) 
includes one major and long-standing bugfix (multiple alias targets in 
create-alias) and several smaller fixes.

I really want to have those fixes released. This doesn't mean I/we won't 
fix the bugs you reported, it just means that they won't make it in the 
2.3.3 release.

I also would like to get SVN trunk in a state that we can release as 
stable version to make the new features (commandline interface, vacation 
start/end date etc.) available for more users.
You probably noticed that we are going to move most code into PHP 
classes. As a side effect, we get several bugfixes more or less "for 
free" which would cause quite some work in the old code. (This also 
means I won't backport every small bugfix if backporting would be too 
much work.)

That said: I won't have time to work on PostfixAdmin in the next days 
because the carnival season is in its end phase and I'm on tour with a 
big float in some carnival parades the next 4 days.

If you send patches for one or more of your bugreports until ash 
wednesday that are not too intrusive (and don't look dangerous to me), 
I'll include them for 2.3.3.


Regards,

Christian Boltz
-- 
[Re: Status of 2.2 release?]
Erm.. Christian tends to keep creating new 'blocker' tickets
(normally when he closes another!) ... :)
[GingerDog in https://sourceforge.net/forum/message.php?msg_id=4895826]

Re: [Postfixadmin-devel] 2.3.3 release?

[Tanstaafl <tan...@li...>]

On 2011-03-03 4:38 PM, Christian Boltz wrote:
> Besides that, the diff (see [1]) looks good and we don't have critical
> open bugs in the bugtracker.

What about the broken logging bugs I reported? I'd really like to see
them fixed...

I know they aren't exactly 'critical', but they are 'not good'...

3150296 - Vacation logging is broken
3148694 - Modifying a users vacation as user is DOUBLE logged
3148692 - Modifying a users vacation as admin is not logged

[Postfixadmin-devel] 2.3.3 release?

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

Hello,

I just checked the full diff between 2.3.2 and what we have in the 2.3 
branch currently. This lead to the revert of using table_by_key() in 
db_delete to avoid breaking (or having to change) delete.php - see my 
commit some minutes ago.

Besides that, the diff (see [1]) looks good and we don't have critical
open bugs in the bugtracker.

Therefore I propose to release PostfixAdmin 2.3.3 from the 2.3 branch.

IMHO we only need to do three things before doing the 2.3.3 release:
- change $version in functions.inc.php to 2.3.3
- enter date and SVN revision in CHANGELOG.TXT
- tag the release (svn cp to tags/)

Please give the 2.3 branch a test and report back if everything works.

@David: (If nobody objects or finds a regression in the 2.3 branch)
As always, please send me the the tarball and the .deb (and, 
if you want, a GPG signature for each of the files as *.asc).
I'll then create a RPM package and GPG signatures and upload everything 
to SourceForge.


Here's the changelog for 2.3.3:

Version 2.3.3 - 2011/**/** - SVN r*** (postfixadmin-2.3 branch)
---------------------------------------------------------------

  - create-alias: allow multiple alias targets
  - create-alias, edit-alias: prevent input data loss on validation errors
  - list-virtual: fix displaying of 'modified' column for aliases when using
    postgres
  - replaced deprecated split() with preg_split() or explode()
  - functions.inc.php: better error messages when database functions are missing
  - create domain: fixed typo in variable name that broke the default value for
    default aliases
  - postgres: changed mailbox.quota, domain.quota and domain.maxquota fields
    to bigint to allow mailboxes >4 GB (run setup.php to upgrade your database)
  - vacation.pl logged literal $variable instead of the variable content at two
    places
  - POSTFIX_CONF.txt: fixed filename for quota map
  - config.inc.php: removed double $CONF['database_prefix']
  - config.inc.php: fixed comments about domain_post* script parameters
  - updated INSTALL.TXT and UPGRADE.TXT
  - sk translation update
  - some more minor fixes


Regards,

Christian Boltz

[1] svn diff -r860:980 - see the attached file
-- 
Well, I guess, Stephan knows very well, what the fuzz is about: it's
about hundreds of patches, which will have to be regenerated, done as
an employment-creation measure for this lazy gang of packagers. 
[Hans-Peter Jansen in opensuse-packaging]

Re: [Postfixadmin-devel] About Trunk version

[Rudi F. <rud...@go...>]

Sorry I meant scripts/snippets
I've been working on a new Crypt Class and a model/controller setup.

It would be nice if you can submit some of your ideas to this folder. If
we have an amount of changes we can open a new trunk folder for PFA 3.0


As Cristian mentioned we try to change to OOP as far es we can and want.
The step to MVC is important for various backends like CLI and Web, but
we have not so much freetime to go to MVC in the next month.

Am 28.02.2011 11:25, schrieb Неворотин Вадим:
> Hm, I can't see extras/ folder in SVN repository:
> http://postfixadmin.svn.sourceforge.net/viewvc/postfixadmin/
>
> 28 февраля 2011 г. 12:59 пользователь Rudi Floren
> <rud...@go... <mailto:rud...@go...>> написал:
>
>     There is work on a New model system based on mvc. Watch
>     extras/snippets.
>
>     Am 28.02.2011 10:45 schrieb "Неворотин Вадим" <ma...@ub...
>     <mailto:ma...@ub...>>:
>
>     > Hello!
>     >
>     > As I can see in trunk you try to rewrite PostfixAdmin with
>     classes and
>     > objects (OOP). It's very good and can really make PA more clear.
>     But in fact
>     > a code, which is present now in model/ folder, doesn't seem to
>     be correct
>     > OOP. To be clear, it's not an OOP at all. You've simply renamed
>     >
>     > add_user($username, $quota, ....)
>     >
>     > to
>     >
>     > $user = new UserHandler($username);
>     > $user->add($quota, ...);
>     >
>     > There isn't any preferences in such renaming. The main goal in
>     OOP is that
>     > one class (object) represent a *one* entity. For example, class User
>     > represent one user and *no more*. But now, e.g.
>     UserHandler::add, try to
>     > represent whole PostfixAdmin, because it do (or will do, when
>     you move code
>     > from old create-user.php) auth and privilege checks, domain
>     checks and so
>     > on. But if it's a user, it shouldn't do anything, exept a work
>     with one
>     > user. AliasHandler has same problems.
>     >
>     > I understand, that you haven't got enough time to develop PA,
>     but, may be,
>     > it's not a good idea to do extra work and write a lot of useless
>     code.
>     >
>     > Below some concept of possible architecture for PA based on OOP:
>     >
>     > There is one main class (e.g. pa_main), which handle sessions,
>     > configuration, language options etc. It has static field -
>     $instance, which
>     > store an object of this class, and static method -
>     getInstance(), which
>     > return value of $instance. It can be used like:
>     >
>     > pa_main::getInstance()->getText($name);
>     > pa_main::getInstance()->getConf($param);
>     >
>     > There is only one class to handle all operations with users.
>     E.g. pa_user.
>     > pa_main has a filed $user, which store an pa_user object, which
>     represent
>     > current logged in user.
>     >
>     > pa_user can have methods like: changePasswd($newpass),
>     checkPasswd($pass),
>     > isAdmin(), isDomainAdmin($domain), save() [save new pa_user to
>     database],
>     > update() [update userinfo in database from current object].
>     Object of
>     > pa_user should store all data for this user from mailbox table
>     of database.
>     >
>     > pa_user shouldn't do any checks, which are not associated with
>     the db table
>     > mailbox. And other parts of PA shouldn't interact with mailbox table
>     > directly, only by creating pa_user objects.
>     >
>     > Similar scheme should be for aliases and domains. And you can
>     also add
>     > pa_userslist and pa_aliaseslist to work with groups of users and
>     aliases
>     > (e.g. for search).
>     >
>     > Next: there should be database handler class, e.g. pa_db.
>     pa_main should
>     > store one object, which is represent db. E.g.
>     >
>     > pa_main::getInstance()->getDbh()->query('...');
>     >
>     > The similar concept is using in RoundCube - you can look to it's
>     source
>     > code. And it's easy to work with RC, because each part of it do
>     their
>     > specific job.
>     >
>     > And you should merge two login pages (for admins and for users)
>     into one and
>     > delete two tables - admins and domain_admin, because they repeat
>     the table
>     > mailbox and are totally redundant. There shouldn't be also two
>     main pages
>     > etc. In fact, if you switch to
>     > architecture, based on object and classes, all duplicate pages
>     will be
>     > removed automatically.
>     >
>     > I hope, you'll get something usefull from my letter and will
>     develop PA to
>     > be more clear. And will not make classes like UserHandler :)
>     >
>     > Best regards, Vadim Nevorotin.
>
>

Re: [Postfixadmin-devel] About Trunk version

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

Hello,

(CC'ing you because you are not subscribed to postfixadmin-devel)

Am Montag, 28. Februar 2011 schrieb Неворотин Вадим:
> As I can see in trunk you try to rewrite PostfixAdmin with classes
> and objects (OOP). It's very good and can really make PA more clear.
> But in fact a code, which is present now in model/ folder, doesn't
> seem to be correct OOP. To be clear, it's not an OOP at all. You've
> simply renamed
> 
> add_user($username, $quota, ....)
> 
> to
> 
> $user = new UserHandler($username);
> $user->add($quota, ...);
[...]
> I understand, that you haven't got enough time to develop PA, but,
> may be, it's not a good idea to do extra work and write a lot of
> useless code.

I have to disagree slightly ;-)

You are correct that model/* are not 100% pure OOP.

I'd like to tell you our current targets regarding those files:

First and most important: 
have one instance of the code for doing a job - and not one in "create-
mailbox", one in "edit-mailbox" and another one in the commandline 
client.

Besides that, I want to have a common interface in all classes (where it 
makes sense - things like "create", "update", "delete"), so that 
- adding custom fields is very easy (see $fm_struct and $fm_defaults in 
  fetchmail.php - it will become something like this)
- creating a new module in PostfixAdmin is easy (I'm dreaming of 
  something like "define two arrays, add a menu entry and you'll get 
  list and edit mode including input validation. Yes, that is possible.)

Of course I also have the "usual" reasons for OOP in mind, but not 
always as primary goals.

> Below some concept of possible architecture for PA based on OOP:
[...]

That looks like 100% OOP.

Don't get me wrong - there's nothing wrong with OOP, but I don't insist 
on using OOP just because it is OOP. There has to be a clear advantage.

For example, I don't see the advantage of a DB class over the db_* 
functions we have, and therefore I'm not too keen to write 
    pa_main::getInstance()->getDbh()->query('...');
instead of
    db_query('...');

(I hate XSLT for similar reasons ;-)

OTOH, your mail also contains lots of useful ideas for the model/* 
files. I won't comment on each of them and just say "thanks!" instead.

> And you should merge two login pages (for admins and for users) into
> one 

That's not as easy as it sounds - what if there are an admin and a 
mailbox with the same name? Choose the one where the password matches? 
;-)

> and delete two tables - admins and domain_admin, because they
> repeat the table mailbox and are totally redundant. 

They are not - if you check the content of those tables, you'll notice 
that they contain very different stuff (especially domain_admin).

If your intention is to use mailbox passwords for admin logins: that's 
something we discussed some time ago, but I don't really like it.

> There shouldn't
> be also two main pages etc. In fact, if you switch to
> architecture, based on object and classes, all duplicate pages will
> be removed automatically.

You don't even want to know how much duplicate code I removed since I'm 
working on PostfixAdmin ;-) For example, edit-alias existed for domain 
admins, for superadmins and for users - and each of them had nearly the 
same code (except the UPDATE query) duplicated for GET and POST...
(If you are really interested, checkout SVN r1 from sourceforge and look 
at the code. But: you have been warned! *eg*)

There's no need to tell me that duplicate code is evil - the problem is 
that it needs some development time to remove/merge it (usually every 
copy comes with different bugs ;-) ), and unfortunately this doesn't 
happen "automatically".

So we have the choice between 
a) doing a "90% OOP" class quite fast to avoid that we have to maintain  
   3 copies of the same functionality - or -
b) do 100% OOP with at least double development time (you'll always find 
   something that is not OOP'ed yet) and have to maintain the old code 
   until that is done.

My choice for now is "90% OOP", and the reason is quite easy: with the 
same time spent, we'll only have 50% of the "100% OOP" done, and still 
have to manage half of the "old" code ;-)

The long term handling might be different and tend to 99% OOP ;-)

> I hope, you'll get something usefull from my letter and will develop
> PA to be more clear. And will not make classes like UserHandler :)

The layout and interface is not set in stone (and not perfect). But it 
is much better than what we had before, and I already have some things 
in mind that I want to change. Unfortunately, the same problem about 
"time" applies here.

Nevertheless: thanks for your comments!


Regards,

Christian Boltz

PS: hand-picked .sig today ;-)
-- 
In most cases, XSLT is good enough. But I agree, for some parts
you need Aspirin. ;-)        [Thomas Schraitle in opensuse-doc]

[Postfixadmin-devel] About Trunk version

[Неворотин В. <ma...@ub...>]

Hello!

As I can see in trunk you try to rewrite PostfixAdmin with classes and
objects (OOP). It's very good and can really make PA more clear. But in fact
a code, which is present now in model/ folder, doesn't seem to be correct
OOP. To be clear, it's not an OOP at all. You've simply renamed

add_user($username, $quota, ....)

to

$user = new UserHandler($username);
$user->add($quota, ...);

There isn't any preferences in such renaming. The main goal in OOP is that
one class (object) represent a *one* entity. For example, class User
represent one user and *no more*. But now, e.g. UserHandler::add, try to
represent whole PostfixAdmin, because it do (or will do, when you move code
from old create-user.php) auth and privilege checks, domain checks and so
on. But if it's a user, it shouldn't do anything, exept a work with one
user. AliasHandler has same problems.

I understand, that you haven't got enough time to develop PA, but, may be,
it's not a good idea to do extra work and write a lot of useless code.

Below some concept of possible architecture for PA based on OOP:

There is one main class (e.g. pa_main), which handle sessions,
configuration, language options etc. It has static field - $instance, which
store an object of this class, and static method - getInstance(), which
return value of $instance. It can be used like:

  pa_main::getInstance()->getText($name);
  pa_main::getInstance()->getConf($param);

There is only one class to handle all operations with users. E.g. pa_user.
pa_main has a filed $user, which store an pa_user object, which represent
current logged in user.

pa_user can have methods like: changePasswd($newpass), checkPasswd($pass),
isAdmin(), isDomainAdmin($domain), save() [save new pa_user to database],
update() [update userinfo in database from current object]. Object of
pa_user should store all data for this user from mailbox table of database.

pa_user shouldn't do any checks, which are not associated with the db table
mailbox. And other parts of PA shouldn't interact with mailbox table
directly, only by creating pa_user objects.

Similar scheme should be for aliases and domains. And you can also add
pa_userslist and pa_aliaseslist to work with groups of users and aliases
(e.g. for search).

Next: there should be database handler class, e.g. pa_db. pa_main should
store one object, which is represent db. E.g.

pa_main::getInstance()->getDbh()->query('...');

The similar concept is using in RoundCube - you can look to it's source
code. And it's easy to work with RC, because each part of it do their
specific job.

And you should merge two login pages (for admins and for users) into one and
delete two tables - admins and domain_admin, because they repeat the table
mailbox and are totally redundant. There shouldn't be also two main pages
etc. In fact, if you switch to
architecture, based on object and classes, all duplicate pages will be
removed automatically.

I hope, you'll get something usefull from my letter and will develop PA to
be more clear. And will not make classes like UserHandler :)

Best regards, Vadim Nevorotin.

[Postfixadmin-devel] About Trunk version

[Неворотин В. <nev...@gm...>]

Hello!

As I can see in trunk you try to rewrite PostfixAdmin with classes and
objects (OOP). It's very good and can really make PA more clear. But in fact
a code, which is present now in model/ folder, doesn't seem to be correct
OOP. To be clear, it's not an OOP at all. You've simply renamed

add_user($username, $quota, ....)

to

$user = new UserHandler($username);
$user->add($quota, ...);

There isn't any preferences in such renaming. The main goal in OOP is that
one class (object) represent a *one* entity. For example, class User
represent one user and *no more*. But now, e.g. UserHandler::add, try to
represent whole PostfixAdmin, because it do (or will do, when you move code
from old create-user.php) auth and privilege checks, domain checks and so
on. But if it's a user, it shouldn't do anything, exept a work with one
user. AliasHandler has same problems.

I understand, that you haven't got enough time to develop PA, but, may be,
it's not a good idea to do extra work and write a lot of useless code.

Below some concept of possible architecture for PA based on OOP:

There is one main class (e.g. pa_main), which handle sessions,
configuration, language options etc. It has static field - $instance, which
store an object of this class, and static method - getInstance(), which
return value of $instance. It can be used like:

  pa_main::getInstance()->getText($name);
  pa_main::getInstance()->getConf($param);

There is only one class to handle all operations with users. E.g. pa_user.
pa_main has a filed $user, which store an pa_user object, which represent
current logged in user.

pa_user can have methods like: changePasswd($newpass), checkPasswd($pass),
isAdmin(), isDomainAdmin($domain), save() [save new pa_user to database],
update() [update userinfo in database from current object]. Object of
pa_user should store all data for this user from mailbox table of database.

pa_user shouldn't do any checks, which are not associated with the db table
mailbox. And other parts of PA shouldn't interact with mailbox table
directly, only by creating pa_user objects.

Similar scheme should be for aliases and domains. And you can also add
pa_userslist and pa_aliaseslist to work with groups of users and aliases
(e.g. for search).

Next: there should be database handler class, e.g. pa_db. pa_main should
store one object, which is represent db. E.g.

pa_main::getInstance()->getDbh()->query('...');

The similar concept is using in RoundCube - you can look to it's source
code. And it's easy to work with RC, because each part of it do their
specific job.

And you should merge two login pages (for admins and for users) into one and
delete two tables - admins and domain_admin, because they repeat the table
mailbox and are totally redundant. There shouldn't be also two main pages
etc. In fact, if you switch to
architecture, based on object and classes, all duplicate pages will be
removed automatically.

I hope, you'll get something usefull from my letter and will develop PA to
be more clear. And will not make classes like UserHandler :)

Best regards, Vadim Nevorotin.

Re: [Postfixadmin-devel] A feature request.

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

On 14 Feb 2011, at 11:40, Simone Piccardi wrote:

> Hi,
> 
> I got this request from a client wanting to add some information about 
> his users. Would be possible to add an editable (by the web interface) a 
> "Notes" field associated to each account?
> 

Yes, it's possible. I suspect you'd need to hire a PHP programmer to get such functionality implemented. 

There have been a number of requests for random other fields to be attached to users in the past.

The changes required shouldn't be too difficult/time consuming.


David.



> Regards
> Simone
> -- 
> Simone Piccardi                                 Truelite Srl
> pic...@tr... (email/jabber)             Via Monferrato, 6
> Tel. +39-347-1032433                            50142 Firenze
> http://www.truelite.it  Tel. +39-055-7879597    Fax. +39-055-7333336
> 
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Postfixadmin-devel mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel

[Postfixadmin-devel] A feature request.

[Simone P. <pic...@tr...>]

Hi,

I got this request from a client wanting to add some information about 
his users. Would be possible to add an editable (by the web interface) a 
"Notes" field associated to each account?

Regards
Simone
-- 
Simone Piccardi                                 Truelite Srl
pic...@tr... (email/jabber)             Via Monferrato, 6
Tel. +39-347-1032433                            50142 Firenze
http://www.truelite.it  Tel. +39-055-7879597    Fax. +39-055-7333336

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[949] trunk/smarty.inc.php

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

> 
> 
>>> That said: Some time ago, I asked if it would be possible to have
>>> NO compile_dir at all (and recompile the templates every time).
>>> IIRC the answer was "yes, that's possible", however I have no idea
>>> how to do that.
>> 
>> There's a config parameter to do it. Can't remember which ones, but
>> It is possible to do with smarty.
> 
> I tried googling this, but didn't find an answer. Would be nice if you 
> can find it out ;-)
> 

I suspect it's :

http://www.smarty.net/docs/en/caching.tpl ?

David.

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[949] trunk/smarty.inc.php

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

Hello,

Am Sonntag, 13. Februar 2011 schrieb David Goodwin:
> On 13 Feb 2011, at 18:43, Christian Boltz <pos...@cb...> 
> wrote:

> > We could do this easily inside the PFASmarty class (in __construct)
> > - no need to make those settings public.
> > 
> > That would also mean we can remove __set, __get and __call.
> > 
> > Objections?
> 
> None. Motion carried :)

OK, I moved the smarty setup (template_dir etc.) into __construct() and 
removed __set, __get and __call. 

A quick test didn't show any breakage :-)

[smarty compile_dir in /tmp]
> Sorry. Didnt realise I'd committed or written that.

Then you must have a ghost in your keyboard - or your dog is better at 
typing than you thought ;-)

I'll remove the /tmp/ stuff.

Commit follows in some minutes.

> > That said: Some time ago, I asked if it would be possible to have
> > NO compile_dir at all (and recompile the templates every time).
> > IIRC the answer was "yes, that's possible", however I have no idea
> > how to do that.
> 
> There's a config parameter to do it. Can't remember which ones, but
> It is possible to do with smarty.

I tried googling this, but didn't find an answer. Would be nice if you 
can find it out ;-)


Regards,

Christian Boltz
-- 
wer Windows in irgendeiner Form verwendet (ausser
als abschreckendes Beispiel) ist selbst schuld.
[Carsten Becher in suse-linux]

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[949] trunk/smarty.inc.php

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

Not enough snipping. See below. In short - yes. 

On 13 Feb 2011, at 18:43, Christian Boltz <pos...@cb...> wrote:

> Hello,
> 
> Am Dienstag, 8. Februar 2011 schrieb Gin...@us...:
>> Revision: 949
>> Author:   GingerDog
> 
>> remove strict standards issue with redefinition of smarty::assign()
>> with different parameters than parent class; ideally I should not
>> put the __get/__set/__call methods in here as living without them
>> would reduce our dependency on smarty, 
> 
> I'd also welcome that - just in case that
> a) we decide to switch template engines again ;-)
> b) someone wants to create additional template engines
> 
> If we can make the interface less dependent on smarty without loosing 
> functionality, I'd really like that.
> 
> Even if we need some smarty properties, I'd prefer to have individual 
> functions for them so that we have a clear interface documentation.
> 
> We should also drop usage of $smarty.get.*** (aka $_GET) and 
> $smarty.session.*** ($_SESSION) and instead use $smarty->assign for 
> every variable.
> 
>> --- trunk/smarty.inc.php    2011-02-07 23:27:19 UTC (rev 948)
>> +++ trunk/smarty.inc.php    2011-02-07 23:29:13 UTC (rev 949)
> 
>> +    public function __set($key, $value) {
>> +        $this->template->$key = $value;
>> +    }
>> +    public function __get($key) {
>> +        return $this->template->$key;
>> +    }
>> +    public function __call($method, $params) {
>> +        return call_user_func_array($this->template->$method,
>> $params); 
>> +    }
> 
> According to my grep results, we only use $smarty->assign and 
> $smarty->display.
> 
> The only exception is in smarty.inc.php where we set 
> - $smarty->template_dir 
> - $smarty->compile_dir 
> - $smarty->config_dir
> 
> We could do this easily inside the PFASmarty class (in __construct) - no 
> need to make those settings public.
> 
> That would also mean we can remove __set, __get and __call.
> 
> Objections?


None. Motion carried :) 

> 
>> $smarty->template_dir    = $incpath.'/templates';
>> -$smarty->compile_dir    = $incpath.'/templates_c';
>> +if(is_writeable('/tmp')) {
>> +    if(!is_dir('/tmp/postfixadmin_templates_c')) {
>> +         mkdir('/tmp/postfixadmin_templates_c');
>> +    }
>> +}
>> +if(is_writeable('/tmp/postfixadmin_templates_c')) {
>> +    $smarty->compile_dir = '/tmp/postfixadmin_templates_c';
>> +}
> 
> That opens us up to security problems like symlink attacks.
> Never use a fixed path in /tmp! 
> (Obviously you can't use a random dir for smarty caching - that will 
> fill up /tmp with lots of smarty cache dirs.)
> 

Sorry. Didnt realise I'd committed or written that. 

> In short: drop the idea of using /tmp/something.
> 

Yes. Seconded. 

>> +else {
>> +    $smarty->compile_dir    = $incpath.'/templates_c';
>> +}
>> +
> 
> This should be default behaviour - and only be overrideable by a $CONF 
> setting.
> 
> That said: Some time ago, I asked if it would be possible to have NO 
> compile_dir at all (and recompile the templates every time). IIRC the 
> answer was "yes, that's possible", however I have no idea how to do 
> that.

There's a config parameter to do it. Can't remember which ones, but It is possible to do with smarty. 

David. 

> 
> 
> Regards,
> 
> Christian Boltz
> -- 
>> jeder mit etwas guten Willen und einem IQ knapp über einem Kühlschrank
>> sollte das doch irgendwann einmal verstehen!
> dann sei du mein Gemüsefach, weil für mehr reicht es ja nicht .... ;)
> [> Burkhard Schichtel und Detlef Reichelt in opensuse-de]
> 
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Postfixadmin-devel mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel

[Postfixadmin-devel] Add unique index on table domain_admins?

[Zhang H. <zhb...@gm...>]

Hi, developers.

I'm using PostfixAdmin-2.3.2, the default structure of table 'domain_admins'
in upgrade.php is:


    CREATE TABLE {IF_NOT_EXISTS} $domain_admins (
      `username` varchar(255) NOT NULL default '',
      `domain` varchar(255) NOT NULL default '',
      `created` datetime NOT NULL default '0000-00-00 00:00:00',
      `active` tinyint(1) NOT NULL default '1',
      KEY username (`username`)
    ) {MYISAM} COMMENT='Postfix Admin - Domain Admins';";

I was wondering why not add a unique key to avoid duplicate records? for
example:

    PRIMARY KEY (username, domain)

Otherwise we can insert duplicate records like below:

INSERT INTO domain_admins (username, domain) values ('ad...@do...d', 'domain.ltd');
INSERT INTO domain_admins (username, domain) values ('ad...@do...d', 'domain.ltd');
INSERT INTO domain_admins (username, domain) values ('ad...@do...d', 'domain.ltd');

P.S. i post this in forum on Jan 27, no response yet.
http://sourceforge.net/projects/postfixadmin/forums/forum/676076/topic/4072904

-- 
Zhang Huangbin

- Open Source Mail Server Solution for Red Hat(R) Enterprise Linux,
  CentOS, Debian, Ubuntu, OpenSuSE, FreeBSD: http://www.iredmail.org/

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[949] trunk/smarty.inc.php

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

Hello,

Am Dienstag, 8. Februar 2011 schrieb Gin...@us...:
> Revision: 949
> Author:   GingerDog

> remove strict standards issue with redefinition of smarty::assign()
> with different parameters than parent class; ideally I should not
> put the __get/__set/__call methods in here as living without them
> would reduce our dependency on smarty, 

I'd also welcome that - just in case that
a) we decide to switch template engines again ;-)
b) someone wants to create additional template engines

If we can make the interface less dependent on smarty without loosing 
functionality, I'd really like that.

Even if we need some smarty properties, I'd prefer to have individual 
functions for them so that we have a clear interface documentation.

We should also drop usage of $smarty.get.*** (aka $_GET) and 
$smarty.session.*** ($_SESSION) and instead use $smarty->assign for 
every variable.

> --- trunk/smarty.inc.php	2011-02-07 23:27:19 UTC (rev 948)
> +++ trunk/smarty.inc.php	2011-02-07 23:29:13 UTC (rev 949)

> +    public function __set($key, $value) {
> +        $this->template->$key = $value;
> +    }
> +    public function __get($key) {
> +        return $this->template->$key;
> +    }
> +    public function __call($method, $params) {
> +        return call_user_func_array($this->template->$method,
> $params); 
> +    }

According to my grep results, we only use $smarty->assign and 
$smarty->display.

The only exception is in smarty.inc.php where we set 
- $smarty->template_dir 
- $smarty->compile_dir 
- $smarty->config_dir

We could do this easily inside the PFASmarty class (in __construct) - no 
need to make those settings public.

That would also mean we can remove __set, __get and __call.

Objections?

>  $smarty->template_dir	= $incpath.'/templates';
> -$smarty->compile_dir	= $incpath.'/templates_c';
> +if(is_writeable('/tmp')) {
> +    if(!is_dir('/tmp/postfixadmin_templates_c')) {
> +         mkdir('/tmp/postfixadmin_templates_c');
> +    }
> +}
> +if(is_writeable('/tmp/postfixadmin_templates_c')) {
> +    $smarty->compile_dir = '/tmp/postfixadmin_templates_c';
> +}

That opens us up to security problems like symlink attacks.
Never use a fixed path in /tmp! 
(Obviously you can't use a random dir for smarty caching - that will 
fill up /tmp with lots of smarty cache dirs.)

In short: drop the idea of using /tmp/something.

> +else {
> +    $smarty->compile_dir	= $incpath.'/templates_c';
> +}
> +

This should be default behaviour - and only be overrideable by a $CONF 
setting.

That said: Some time ago, I asked if it would be possible to have NO 
compile_dir at all (and recompile the templates every time). IIRC the 
answer was "yes, that's possible", however I have no idea how to do 
that.


Regards,

Christian Boltz
-- 
> jeder mit etwas guten Willen und einem IQ knapp über einem Kühlschrank
> sollte das doch irgendwann einmal verstehen!
dann sei du mein Gemüsefach, weil für mehr reicht es ja nicht .... ;)
[> Burkhard Schichtel und Detlef Reichelt in opensuse-de]

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[952] trunk/templates/header.tpl

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

Hello,

I found a newly introduced bug when reviewing your changes ;-)

Am Dienstag, 8. Februar 2011 schrieb Gin...@us...:
> Revision: 952
> Author:   GingerDog

> move this to common.php; i dislike inline php in templates
> 
> Modified Paths:
> --------------
>     trunk/templates/header.tpl
> 
> Modified: trunk/templates/header.tpl
> ===================================================================
> --- trunk/templates/header.tpl	2011-02-07 23:30:17 UTC (rev 951)
> +++ trunk/templates/header.tpl	2011-02-07 23:30:46 UTC (rev 952)
> @@ -39,6 +39,5 @@
>  					{/foreach}
>  				</ul>
>  			{/if}
> -		{php}$_SESSION['flash'] = array();{/php}
>  		{/if}
>  {/strip}

(+ similar, but not equal code added to common.php in r953)

Unfortunately this change broak the flash messages. Or, to be exact, it 
broke the cleanup of them ;-)

At the moment we have no code that cleans up the flash messages after 
they have been printed out. The result is that the flash messages are 
kept until you log out (instead of being displayed only once).

What we need is (pseudocode):
- assign flash messages to a smarty variable/array
- cleanup $_SESSION['flash']


Regards,

Christian Boltz
-- 
MSCE
Führerschein für die Maus. (Thore Tams)

[Postfixadmin-devel] XMLRPC interfaces

[Juan C. G. D. <jua...@pe...>]

Hello guys, it's me Juan Carlos Gutiérrez.
I'm sorry for taking so long to contact you, my project was delayed.
If you don't remember, I'm the one whos trying to enable some new 
interfaces through xml-rpc for postfixadmin.
The last time we talk Christian told to enable the admin authetication 
interface and base the rest of them on this admin auth.
Well, I did that, I created an AdminHandler class and enabled the login 
interface, it is working very good.
My problems came when I was developing the "create_mailbox" interface.
Here is what I did:
First I took the code in the /create_mailbox.php file and tried to put 
it in two functions in the model/AdminHandler.php class, one function 
for all the intial validations and a second one for the mailbox creating 
functionality. Then I used the AdminHandler in the create_mailbox.php.
BTW, I did the same with the admin login code and it worked very nice.
The big difference between the login and the mailbox creation is that 
the mailbox creation code uses some variables that the AdminHandler 
cannot see, like $CONF.
I tried to pass it through the AdminHandler construtor but it didn't 
work either. Also I tried to use a require_once('common.php') in the 
model/AdminHandler.php file but I got nothing.
I don't know what else I can do and that's why I'm contacting you, maybe 
you can know how I can use these variables in my class.

Some code for you in case you need it:

*create_mailbox.php:*
require_once('common.php');

authentication_require_role('admin');
$SESSID_USERNAME = authentication_get_username();
if(authentication_has_role('global-admin')) {
    $list_domains = list_domains ();
}
else {
    $list_domains = list_domains_for_admin($SESSID_USERNAME);
}

$pCreate_mailbox_name_text = $PALANG['pCreate_mailbox_name_text'];
$pCreate_mailbox_password_text = $PALANG['pCreate_mailbox_password_text'];
$pCreate_mailbox_quota_text = $PALANG['pCreate_mailbox_quota_text'];

if ($_SERVER['REQUEST_METHOD'] == "GET")
{
    $fDomain = $list_domains[0];
    if (isset ($_GET['domain'])) $fDomain = escape_string ($_GET['domain']);

    if(!in_array($fDomain, $list_domains)) {
       die("Invalid domain name selected, or you tried to select a 
domain you are not an admin for");
    }
    $tDomain = $fDomain;
    $result = db_query ("SELECT * FROM $table_domain WHERE 
domain='$fDomain'");
    if ($result['rows'] == 1)
    {
       $row = db_array ($result['result']);
       $tQuota = $row['maxquota'];
    }
}

if ($_SERVER['REQUEST_METHOD'] == "POST")
{
    if (isset ($_POST['fUsername']) && isset ($_POST['fDomain'])) 
$fUsername = escape_string ($_POST['fUsername']) . "@" . escape_string 
($_POST['fDomain']);
    $fUsername = strtolower ($fUsername);
    if (isset ($_POST['fPassword'])) $fPassword = escape_string 
($_POST['fPassword']);
    if (isset ($_POST['fPassword2'])) $fPassword2 = escape_string 
($_POST['fPassword2']);
    isset ($_POST['fName']) ? $fName = escape_string ($_POST['fName']) : 
$fName = "";
    if (isset ($_POST['fDomain'])) $fDomain = escape_string 
($_POST['fDomain']);
    isset ($_POST['fQuota']) ? $fQuota = intval($_POST['fQuota']) : 
$fQuota = 0;
    isset ($_POST['fActive']) ? $fActive = escape_string 
($_POST['fActive']) : $fActive = "1";
    if (isset ($_POST['fMail'])) $fMail = escape_string ($_POST['fMail']);

    $ah = new AdminHandler($SESSID_USERNAME);
    $pCreate_mailbox_username_text = $ah->validate($fUsername, $fDomain, 
$fPassword, $fPassword2, $fName, $fQuota);

    $tPassGenerated = 0;
    if (empty ($fPassword) or empty ($fPassword2) or ($fPassword != 
$fPassword2))
    {
        if (empty ($fPassword) and empty ($fPassword2) and 
$CONF['generate_password'] == "YES")
        {
            $fPassword = generate_password ();
            $tPassGenerated = 1;
        }
    }

    if (!empty($pCreate_mailbox_username_text))
    {
           $tMessage = $ah->create_mailbox($fUsername, $fDomain, 
$fPassword, $fPassword2, $fName, $fQuota, $fActive, $fMail);
    }

*model/AdminHandler.php:*
class AdminHandler {

     protected $username = null;

     public function __construct($username) {
         $this->username = $username;
     }

     /**
      * Attempt to log an admin in.
      * @param string $username
      * @param string $password
      * @return boolean true on successful login (i.e. password matches etc)
      */
     public static function login($admin_username, $admin_password) {

         global $config;
         $admin_username = escape_string($admin_username);

         $table_admin = table_by_key('admin');
         $active = db_get_boolean(True);

         $to_return = true;
         $result = db_query ("SELECT password FROM $table_admin WHERE 
username='$admin_username' AND active='$active'");
         if ($result['rows'] == 1)
         {
             $row = db_array ($result['result']);
             $password = pacrypt ($admin_password, $row['password']);
             $result = db_query ("SELECT * FROM $table_admin WHERE 
username='$admin_username' AND password='$password' AND active='$active'");
             if ($result['rows'] != 1)
             {
                 $to_return = false;
             }
         }
         else
         {
             $to_return = false;
         }
         return $to_return;
     }

     /**
      * Check if they are domain admin.
      * @param string $username
      * @return boolean true on being domain admin
      */
     public function check_domain_admin($admin_username) {

         global $config;
         $admin_username = escape_string($admin_username);

         $table_domain_admins = table_by_key('domain_admins');
         $active = db_get_boolean(True);

         $to_return = false;
         $result = db_query ("SELECT * FROM $table_domain_admins WHERE 
username='$admin_username' AND domain='ALL' AND active='$active'");
         if ($result['rows'] == 1)
         {
             $to_return = true;
         }
         return $to_return;
     }

     /**
      * Test function
      * @param string message_second_part
      * @return string message
      */
     public function test($message_second_part) {
         $message_first_part = 'Hola ';
         $message = $message_first_part.$message_second_part;
         return $message;
     }

     /**
      * create_mailbox function
      * @param string $fUsername
      * @param string $fDomain
      * @param string $fPassword
      * @param string $fPassword2
      * @param string $fName
      * @param string $fQuota
      * @param boolean $fActive
      * @param boolean $fMail
      * @return string message
      */
     public function create_mailbox($fUsername, $fDomain, $fPassword, 
$fPassword2, $fName, $fQuota, $fActive, $fMail) {

             global $config;

             $password = pacrypt ($fPassword);

             if($CONF['maildir_name_hook'] != 'NO' && 
function_exists($CONF['maildir_name_hook'])) {
                 $hook_func = $CONF['maildir_name_hook'];
                 $maildir = $hook_func ($fDomain, $fUsername);
             }
             else if ($CONF['domain_path'] == "YES")
             {
                 if ($CONF['domain_in_mailbox'] == "YES")
                 {
                     $maildir = $fDomain . "/" . $fUsername . "/";
                 }
                 else
                 {
                     $maildir = $fDomain . "/" . escape_string 
(strtolower($_POST['fUsername'])) . "/";
                 }
             }
             else
             {
                 $maildir = $fUsername . "/";
             }

             if (!empty ($fQuota))
             {
                 $quota = multiply_quota ($fQuota);
             }
             else
             {
                 $quota = 0;
             }

             //if ($fActive == "on")
             if ($fActive)
             {
                 $sqlActive = db_get_boolean(True);
             }
             else
             {
                 $sqlActive = db_get_boolean(False);
             }
             if ('pgsql'==$CONF['database_type'])
             {
                 db_query('BEGIN');
             }

             $table_alias = table_by_key('alias');
             $result = db_query ("INSERT INTO $table_alias 
(address,goto,domain,created,modified,active) VALUES 
('$fUsername','$fUsername','$fDomain',NOW(),NOW(),'$sqlActive')");
             if ($result['rows'] != 1)
             {
                 $tDomain = $fDomain;
                 $tMessage = $PALANG['pAlias_result_error'] . "<br 
/>($fUsername -> $fUsername)</br />";
             }

             // apparently uppercase usernames really confuse some IMAP 
clients.
             $fUsername = strtolower($fUsername);
             $local_part = '';
             if(preg_match('/^(.*)@/', $fUsername, $matches)) {
                 $local_part = $matches[1];
             }

             $result = db_query ("INSERT INTO $table_mailbox 
(username,password,name,maildir,local_part,quota,domain,created,modified,active) 
VALUES 
('$fUsername','$password','$fName','$maildir','$local_part','$quota','$fDomain',NOW(),NOW(),'$sqlActive')");
             if ($result['rows'] != 1 || 
!mailbox_postcreation($fUsername,$fDomain,$maildir, $quota))
             {
                 $tDomain = $fDomain;
                 $tMessage .= $PALANG['pCreate_mailbox_result_error'] . 
"<br />($fUsername)<br />";
                 db_query('ROLLBACK');
             }
             else
             {
                 db_query('COMMIT');
                 db_log ($SESSID_USERNAME, $fDomain, 'create_mailbox', 
"$fUsername");
                 $tDomain = $fDomain;

                 $tQuota = $CONF['maxquota'];

                 if ($fMail == "on")
                 {
                     $fTo = $fUsername;
                     $fFrom = $SESSID_USERNAME;
                     $fHeaders = "To: " . $fTo . "\n";
                     $fHeaders .= "From: " . $fFrom . "\n";

                     $fHeaders .= "Subject: " . encode_header 
($PALANG['pSendmail_subject_text']) . "\n";
                     $fHeaders .= "MIME-Version: 1.0\n";
                     $fHeaders .= "Content-Type: text/plain; 
charset=utf-8\n";
                     $fHeaders .= "Content-Transfer-Encoding: 8bit\n";

                     $fHeaders .= $CONF['welcome_text'];

                     if (!smtp_mail ($fTo, $fFrom, $fHeaders))
                     {
                         $tMessage .= "<br />" . 
$PALANG['pSendmail_result_error'] . "<br />";
                     }
                     else
                     {
                         $tMessage .= "<br />" . 
$PALANG['pSendmail_result_success'] . "<br />";
                     }
                  }

                  $tShowpass = "";
                  if ( $tPassGenerated == 1 || $CONF['show_password'] == 
"YES") $tShowpass = " / $fPassword";

                  if (create_mailbox_subfolders($fUsername,$fPassword))
                  {
                      $tMessage .= 
$PALANG['pCreate_mailbox_result_success'] . "<br />($fUsername$tShowpass)";
                  } else {
                      $tMessage .= 
$PALANG['pCreate_mailbox_result_succes_nosubfolders'] . "<br 
/>($fUsername$tShowpass)";
                  }

              }

              return $tMessage;
     }

     /**
      * validate params
      * @param string $fUsername
      * @param string $fDomain
      * @param string $fPassword
      * @param string $fPassword2
      * @param string $fName
      * @param int $fQuota
      * @return string to_return: error message
      */
     public function validate($fUsername, $fDomain, $fPassword, 
$fPassword2, $fName, $fQuota) {

         $to_return = '';

         //not a valid domain
         if ( (!check_owner ($fUsername, $fDomain)) && 
(!authentication_has_role('global-admin')) )
         {
             $error = 1;
             $tUsername = escape_string ($fUsername);
             $tName = $fName;
             $tQuota = $fQuota;
             $tDomain = $fDomain;
             $to_return = $PALANG['pCreate_mailbox_username_text_error1'];
         }

         //mailbox limit reached
         if (!check_mailbox ($fDomain))
         {
             $error = 1;
             $tUsername = escape_string ($fUsername);
             $tName = $fName;
             $tQuota = $fQuota;
             $tDomain = $fDomain;
             $to_return = $PALANG['pCreate_mailbox_username_text_error3'];
         }

         //not valid email
         if (empty ($fUsername) or !check_email ($fUsername))
         {
             $error = 1;
             $tUsername = escape_string ($fUsername);
             $tName = $fName;
             $tQuota = $fQuota;
             $tDomain = $fDomain;
             $to_return = $PALANG['pCreate_mailbox_username_text_error1'];
         }

         if (empty ($fPassword) or empty ($fPassword2) or ($fPassword != 
$fPassword2))
         {
             //password does not match or is empty
             if (!(empty ($fPassword) and empty ($fPassword2) and 
$CONF['generate_password'] == "YES"))
             {
                 $error = 1;
                 $tUsername = escape_string ($fUsername);
                 $tName = $fName;
                 $tQuota = $fQuota;
                 $tDomain = $fDomain;
                 $to_return = 
$PALANG['pCreate_mailbox_password_text_error'];
             }
         }

         if ($CONF['quota'] == "YES")
         {
                //Quota too high
             if (!check_quota ($fQuota, $fDomain))
             {
                 $error = 1;
                 $tUsername = escape_string ($fUsername);
                 $tName = $fName;
                 $tQuota = $fQuota;
                 $tDomain = $fDomain;
                 $to_return = $PALANG['pCreate_mailbox_quota_text_error'];
             }
         }

         $table_alias = table_by_key('alias');
         $result = db_query ("SELECT * FROM $table_alias WHERE 
address='$fUsername'");
         //email already exists
         if ($result['rows'] == 1)
         {
             $error = 1;
             $tUsername = escape_string ($fUsername);
             $tName = $fName;
             $tQuota = $fQuota;
             $tDomain = $fDomain;
             $to_return = $PALANG['pCreate_mailbox_username_text_error2'];
         }

         return $to_return;
     }

*login.php:*
require_once('common.php');

/* force user to delete setup.php (allows creation of superadmins!)*/
if($CONF['configured'] !== true) {
     print "Installation not yet configured; please edit config.inc.php";
     exit;
}

if ($_SERVER['REQUEST_METHOD'] == "GET")
{
     /*
     $smarty->assign ('smarty_template', 'login');
     $smarty->display ('index.tpl');
     */
     include ("./templates/header.php");
     include ("./templates/login.php");
     include ("./templates/footer.php");
}

if ($_SERVER['REQUEST_METHOD'] == "POST")
{
     $fUsername = '';
     $fPassword = '';
     if (isset ($_POST['fUsername'])) $fUsername = escape_string 
($_POST['fUsername']);
     if (isset ($_POST['fPassword'])) $fPassword = escape_string 
($_POST['fPassword']);
     $lang = safepost('lang');

     if ( $lang != check_language(0) ) { # only set cookie if language 
selection was changed
         setcookie('lang', $lang, time() + 60*60*24*30); # language 
cookie, lifetime 30 days
         # (language preference cookie is processed even if username 
and/or password are invalid)
     }

     if(AdminHandler::login($_POST['fUsername'], $_POST['fPassword'])) {
       session_regenerate_id();
       $_SESSION['sessid'] = array();
       $_SESSION['sessid']['username'] = $fUsername;
       $_SESSION['sessid']['roles'] = array();
       $_SESSION['sessid']['roles'][] = 'admin';
       echo "check_domain_admin!!! <br>";
       // they've logged in, so see if they are a domain admin, as well.
       $ah = new AdminHandler($fUsername);
       if($ah->check_domain_admin($fUsername)) {
           $_SESSION['sessid']['roles'][] = 'global-admin';
       }
       /*
       $result = db_query ("SELECT * FROM $table_domain_admins WHERE 
username='$fUsername' AND domain='ALL' AND active='1'");
       if ($result['rows'] == 1)
       {
           $_SESSION['sessid']['roles'][] = 'global-admin';
       }
       */
       header("Location: main.php");
       exit(0);
     }
     else
     {
         $tMessage = '<span class="error_msg">' . 
$PALANG['pLogin_failed'] . '</span>';
     }

[Postfixadmin-devel] 404: The requested URL /create-alias-domain.php was not found on this server

[J4 <ju...@kl...>]

Dear everyone,

    I tried to create an alias domain with postfix 2.3.2, but had this
error:


http://admin.simonloewen.info/create-alias-domain.php
404: The requested URL /create-alias-domain.php was not found on this server

This is not surprising because, the server uses https, and this is the
port I originally connected to to use postfixadmin, yet when I click on
the linkto call create-alias-domain.php, it ends up going to an http
port.  However, there is nothing listening for this domain on the http
port, so it'll never be found.

Strange.

S.

Re: [Postfixadmin-devel] confirm e943a0a370ea38dbb7292e978d2a4be701141cc8

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

Hallo Leute,

Am Sonntag, 7. Februar 2106 schrieb postfixadmin-devel-
re...@li...:
> If you reply to this message, keeping the Subject: header intact,
> Mailman will discard the held message.  Do this if the message is
> spam.  If you reply to this message and include an Approved: header
> with the list password in it, the message will be approved for
> posting to the list.  The Approved: header can also appear in the
> first line of the body of the reply.


Regards,

Christian Boltz
-- 
> Again, apt is dead, there is no maintainership upstream -- let's
> leave this sinking ship NOW.
Don't forget we are on the sea and not at the harbour.
So leaving the ship will end in the water as long as the new ship is
not ready.   [> Christoph Thiel and Eberhard Moenkeberg in opensuse]

Re: [Postfixadmin-devel] missing layout for postfixadmin on web site

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

On 19 Jan 2011, at 16:04, J4 wrote:

>> 
> Hi David,
> 
> I have nuked it with version 2.3.2.  All is well.
> 

good

> On a related topic.  I have a habit of change permissions on files to
> being quite restictive (may have been the cause of the problem).  Would
> you tell me how restictive I can make the files?
> 

it has to be readable by the webserver.

Approaches to make that database password more secure include :

a. embedding it within an Apache variable ? (not sure if this will help a lot)
b. using something like suphp / suexec so each 'website' is associated with a different system user.


chmod -R a-w will break stuff - you'll need at least teh templates_c directory to be writeable for Smarty.

thanks
David.


> In particular, the config.php.ini file contains the entry for the database:
> $CONF['database_password'] = '121212____!!!!!';
> What are the safest permissions for this file?
> 
> Are there any other files that should not have any writable permissions?
> Would a simple chmod -R a-w postfixadmin/  work, or would something break?
> 
> 
> Simon.

Re: [Postfixadmin-devel] missing layout for postfixadmin on web site

[J4 <ju...@kl...>]

Slightly stranger output:-

# diff --exclude=.svn -ru
/root/build/email_setup/postfixadmin-2.3.2/templates/
/srv/postfixadmin/templates/

Only in /root/build/email_setup/postfixadmin-2.3.2/templates/:
admin_create-admin.php
Only in /srv/postfixadmin/templates/: admin_create-admin.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/:
admin_create-domain.php
Only in /srv/postfixadmin/templates/: admin_create-domain.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/:
admin_edit-admin.php
Only in /srv/postfixadmin/templates/: admin_edit-admin.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/:
admin_edit-domain.php
Only in /srv/postfixadmin/templates/: admin_edit-domain.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/:
admin_list-admin.php
Only in /srv/postfixadmin/templates/: adminlistadmin.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/:
admin_list-domain.php
Only in /srv/postfixadmin/templates/: adminlistdomain.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/:
broadcast-message.php
Only in /srv/postfixadmin/templates/: broadcast-message.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/:
create-alias-domain.php
Only in /srv/postfixadmin/templates/: create-alias-domain.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/:
create-alias.php
Only in /srv/postfixadmin/templates/: create-alias.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/:
create-mailbox.php
Only in /srv/postfixadmin/templates/: create-mailbox.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/:
edit-alias.php
Only in /srv/postfixadmin/templates/: edit-alias.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/:
edit-mailbox.php
Only in /srv/postfixadmin/templates/: edit-mailbox.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/:
edit-vacation.php
Only in /srv/postfixadmin/templates/: edit-vacation.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/: fetchmail.php
Only in /srv/postfixadmin/templates/: fetchmail.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/: footer.php
Only in /srv/postfixadmin/templates/: footer.tpl
Only in /srv/postfixadmin/templates/: header.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/: index.php
Only in /srv/postfixadmin/templates/: index.tpl
Only in /srv/postfixadmin/templates/: list-virtual_alias_domain.tpl
Only in /srv/postfixadmin/templates/: list-virtual_alias.tpl
Only in /srv/postfixadmin/templates/: list-virtual_mailbox.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/:
list-virtual.php
Only in /srv/postfixadmin/templates/: list-virtual.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/: login.php
Only in /srv/postfixadmin/templates/: login.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/: main.php
Only in /srv/postfixadmin/templates/: main.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/: menu.php
Only in /srv/postfixadmin/templates/: menu.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/: message.php
Only in /srv/postfixadmin/templates/: message.tpl
Only in /srv/postfixadmin/templates/: motd.txt
Only in /srv/postfixadmin/templates/: motd-users.txt
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/:
overview-get.php
Only in /srv/postfixadmin/templates/: overview-get.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/: password.php
Only in /srv/postfixadmin/templates/: password.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/: search.php
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/: sendmail.php
Only in /srv/postfixadmin/templates/: sendmail.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/:
users_edit-alias.php
Only in /srv/postfixadmin/templates/: users_edit-alias.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/:
users_login.php
Only in /srv/postfixadmin/templates/: users_login.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/:
users_main.php
Only in /srv/postfixadmin/templates/: users_main.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/:
users_menu.php
Only in /srv/postfixadmin/templates/: users_menu.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/:
users_password.php
Only in /srv/postfixadmin/templates/: users_password.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/:
users_vacation.php
Only in /srv/postfixadmin/templates/: users_vacation.tpl
Only in /root/build/email_setup/postfixadmin-2.3.2/templates/: viewlog.php
Only in /srv/postfixadmin/templates/: viewlog.tpl

On 01/18/2011 01:31 PM, David Goodwin wrote:
> Try re-doing the diff with :
> 
> templates/
> config.inc.php
> 
> 
> David.
> 
> 
> On 18 Jan 2011, at 12:25, J4 wrote:
> 
>> Hi David,
>>
>> Thanks for the idea.
>>
>> # diff --exclude=.svn -ru
>> /root/build/email_setup/postfixadmin-2.3.2/css/default.css
>> /srv/postfixadmin/css/default.css
>> no difference.
>>
>> A diff of :
>> # diff --exclude=.svn -ru /root/build/email_setup/postfixadmin-2.3.2s
>> /srv/postfixadmin
>> ... produced 6059 lines of output. I don't think humans have the time
>> nor inclination to read through all of that!
>>
>>
>> On 01/18/2011 01:17 PM, David Goodwin wrote:
>>> diff -ru /path/to/svn/checkout /path/to/htdocs ?
>>>
>>> It'll give you loads of crap about .svn stuff, but might pinpoint what you've changed?
>>>
>>> (I think diff has an exclude option, e.g. --exclude .svn , but i may be wrong)
>>>
>>>
>>> David.
>>>
>>>
>>> On 18 Jan 2011, at 11:39, J4 wrote:
>>>
>>>> Hi David,
>>>>
>>>> # ls -l css/default.css
>>>> -rw-r--r-- 1 root root 5637 Jan  3 12:38 css/default.css
>>>> 	
>>>> $CONF['theme_css'] = 'css/default.css';
>>>>
>>>> Just to be sure the default.css was not the problem, I copied the
>>>> default.css from the svn I had downloaded into the htdoc location for my
>>>> postfixadmin install, but it did not change anything.
>>>>
>>>> Is there anywhere else that could cause a problem with the style sheets?
>>>>
>>>>
>>>>
>>>> On 01/18/2011 11:00 AM, David Goodwin wrote:
>>>>> I suspect you've somehow broken the stylesheet(s).
>>>>>
>>>>> Look in config.inc.php for $CONF['theme_css'] - it should be set to something like 'css/default.css'.
>>>>>
>>>>>
>>>>>
>>>>> David.
>>>>>
>>>>>
>>>>> On 17 Jan 2011, at 10:39, J4 wrote:
>>>>>
>>>>>> Hi there,
>>>>>>
>>>>>>   I had postfixadmin working well, but sadly made a change last Friday and have forgotten what it was :(  The result is that postfixadmin works, but the (presumably) style sheets are not read. The web page is displayed only in ascii with URL links, but not the nice way it was afore.  
>>>>>>
>>>>>> I took a screen-shot and upload it here as it better explains what I mean:
>>>>>> http://tinypic.com/r/zn629w/7
>>>>>>
>>>>>> Does anyone know what might have caused this?
>>>>>>
>>>>>> Best regards, J.
>>>>>> ------------------------------------------------------------------------------
>>>>>> Protect Your Site and Customers from Malware Attacks
>>>>>> Learn about various malware tactics and how to avoid them. Understand 
>>>>>> malware threats, the impact they can have on your business, and how you 
>>>>>> can protect your company and customers by using code signing.
>>>>>> http://p.sf.net/sfu/oracle-sfdevnl_______________________________________________
>>>>>> Postfixadmin-devel mailing list
>>>>>> Pos...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Protect Your Site and Customers from Malware Attacks
>>>> Learn about various malware tactics and how to avoid them. Understand 
>>>> malware threats, the impact they can have on your business, and how you 
>>>> can protect your company and customers by using code signing.
>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>> _______________________________________________
>>>> Postfixadmin-devel mailing list
>>>> Pos...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Protect Your Site and Customers from Malware Attacks
>>> Learn about various malware tactics and how to avoid them. Understand 
>>> malware threats, the impact they can have on your business, and how you 
>>> can protect your company and customers by using code signing.
>>> http://p.sf.net/sfu/oracle-sfdevnl
>>> _______________________________________________
>>> Postfixadmin-devel mailing list
>>> Pos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel
>>
>> ------------------------------------------------------------------------------
>> Protect Your Site and Customers from Malware Attacks
>> Learn about various malware tactics and how to avoid them. Understand 
>> malware threats, the impact they can have on your business, and how you 
>> can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Postfixadmin-devel mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel
> 

Re: [Postfixadmin-devel] missing layout for postfixadmin on web site

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

Try re-doing the diff with :

templates/
config.inc.php


David.


On 18 Jan 2011, at 12:25, J4 wrote:

> Hi David,
> 
> Thanks for the idea.
> 
> # diff --exclude=.svn -ru
> /root/build/email_setup/postfixadmin-2.3.2/css/default.css
> /srv/postfixadmin/css/default.css
> no difference.
> 
> A diff of :
> # diff --exclude=.svn -ru /root/build/email_setup/postfixadmin-2.3.2s
> /srv/postfixadmin
> ... produced 6059 lines of output. I don't think humans have the time
> nor inclination to read through all of that!
> 
> 
> On 01/18/2011 01:17 PM, David Goodwin wrote:
>> diff -ru /path/to/svn/checkout /path/to/htdocs ?
>> 
>> It'll give you loads of crap about .svn stuff, but might pinpoint what you've changed?
>> 
>> (I think diff has an exclude option, e.g. --exclude .svn , but i may be wrong)
>> 
>> 
>> David.
>> 
>> 
>> On 18 Jan 2011, at 11:39, J4 wrote:
>> 
>>> Hi David,
>>> 
>>> # ls -l css/default.css
>>> -rw-r--r-- 1 root root 5637 Jan  3 12:38 css/default.css
>>> 	
>>> $CONF['theme_css'] = 'css/default.css';
>>> 
>>> Just to be sure the default.css was not the problem, I copied the
>>> default.css from the svn I had downloaded into the htdoc location for my
>>> postfixadmin install, but it did not change anything.
>>> 
>>> Is there anywhere else that could cause a problem with the style sheets?
>>> 
>>> 
>>> 
>>> On 01/18/2011 11:00 AM, David Goodwin wrote:
>>>> I suspect you've somehow broken the stylesheet(s).
>>>> 
>>>> Look in config.inc.php for $CONF['theme_css'] - it should be set to something like 'css/default.css'.
>>>> 
>>>> 
>>>> 
>>>> David.
>>>> 
>>>> 
>>>> On 17 Jan 2011, at 10:39, J4 wrote:
>>>> 
>>>>> Hi there,
>>>>> 
>>>>>   I had postfixadmin working well, but sadly made a change last Friday and have forgotten what it was :(  The result is that postfixadmin works, but the (presumably) style sheets are not read. The web page is displayed only in ascii with URL links, but not the nice way it was afore.  
>>>>> 
>>>>> I took a screen-shot and upload it here as it better explains what I mean:
>>>>> http://tinypic.com/r/zn629w/7
>>>>> 
>>>>> Does anyone know what might have caused this?
>>>>> 
>>>>> Best regards, J.
>>>>> ------------------------------------------------------------------------------
>>>>> Protect Your Site and Customers from Malware Attacks
>>>>> Learn about various malware tactics and how to avoid them. Understand 
>>>>> malware threats, the impact they can have on your business, and how you 
>>>>> can protect your company and customers by using code signing.
>>>>> http://p.sf.net/sfu/oracle-sfdevnl_______________________________________________
>>>>> Postfixadmin-devel mailing list
>>>>> Pos...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel
>>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Protect Your Site and Customers from Malware Attacks
>>> Learn about various malware tactics and how to avoid them. Understand 
>>> malware threats, the impact they can have on your business, and how you 
>>> can protect your company and customers by using code signing.
>>> http://p.sf.net/sfu/oracle-sfdevnl
>>> _______________________________________________
>>> Postfixadmin-devel mailing list
>>> Pos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel
>> 
>> 
>> ------------------------------------------------------------------------------
>> Protect Your Site and Customers from Malware Attacks
>> Learn about various malware tactics and how to avoid them. Understand 
>> malware threats, the impact they can have on your business, and how you 
>> can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Postfixadmin-devel mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel
> 
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand 
> malware threats, the impact they can have on your business, and how you 
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Postfixadmin-devel mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel

Re: [Postfixadmin-devel] missing layout for postfixadmin on web site

[J4 <ju...@kl...>]

Hi David,

Thanks for the idea.

# diff --exclude=.svn -ru
/root/build/email_setup/postfixadmin-2.3.2/css/default.css
/srv/postfixadmin/css/default.css
no difference.

A diff of :
# diff --exclude=.svn -ru /root/build/email_setup/postfixadmin-2.3.2s
/srv/postfixadmin
... produced 6059 lines of output. I don't think humans have the time
nor inclination to read through all of that!


On 01/18/2011 01:17 PM, David Goodwin wrote:
> diff -ru /path/to/svn/checkout /path/to/htdocs ?
> 
> It'll give you loads of crap about .svn stuff, but might pinpoint what you've changed?
> 
> (I think diff has an exclude option, e.g. --exclude .svn , but i may be wrong)
> 
> 
> David.
> 
> 
> On 18 Jan 2011, at 11:39, J4 wrote:
> 
>> Hi David,
>>
>> # ls -l css/default.css
>> -rw-r--r-- 1 root root 5637 Jan  3 12:38 css/default.css
>> 	
>> $CONF['theme_css'] = 'css/default.css';
>>
>> Just to be sure the default.css was not the problem, I copied the
>> default.css from the svn I had downloaded into the htdoc location for my
>> postfixadmin install, but it did not change anything.
>>
>> Is there anywhere else that could cause a problem with the style sheets?
>>
>>
>>
>> On 01/18/2011 11:00 AM, David Goodwin wrote:
>>> I suspect you've somehow broken the stylesheet(s).
>>>
>>> Look in config.inc.php for $CONF['theme_css'] - it should be set to something like 'css/default.css'.
>>>
>>>
>>>
>>> David.
>>>
>>>
>>> On 17 Jan 2011, at 10:39, J4 wrote:
>>>
>>>> Hi there,
>>>>
>>>>    I had postfixadmin working well, but sadly made a change last Friday and have forgotten what it was :(  The result is that postfixadmin works, but the (presumably) style sheets are not read. The web page is displayed only in ascii with URL links, but not the nice way it was afore.  
>>>>
>>>> I took a screen-shot and upload it here as it better explains what I mean:
>>>> http://tinypic.com/r/zn629w/7
>>>>
>>>> Does anyone know what might have caused this?
>>>>
>>>> Best regards, J.
>>>> ------------------------------------------------------------------------------
>>>> Protect Your Site and Customers from Malware Attacks
>>>> Learn about various malware tactics and how to avoid them. Understand 
>>>> malware threats, the impact they can have on your business, and how you 
>>>> can protect your company and customers by using code signing.
>>>> http://p.sf.net/sfu/oracle-sfdevnl_______________________________________________
>>>> Postfixadmin-devel mailing list
>>>> Pos...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Protect Your Site and Customers from Malware Attacks
>> Learn about various malware tactics and how to avoid them. Understand 
>> malware threats, the impact they can have on your business, and how you 
>> can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Postfixadmin-devel mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel
> 
> 
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand 
> malware threats, the impact they can have on your business, and how you 
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Postfixadmin-devel mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel

Re: [Postfixadmin-devel] missing layout for postfixadmin on web site

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

diff -ru /path/to/svn/checkout /path/to/htdocs ?

It'll give you loads of crap about .svn stuff, but might pinpoint what you've changed?

(I think diff has an exclude option, e.g. --exclude .svn , but i may be wrong)


David.


On 18 Jan 2011, at 11:39, J4 wrote:

> Hi David,
> 
> # ls -l css/default.css
> -rw-r--r-- 1 root root 5637 Jan  3 12:38 css/default.css
> 	
> $CONF['theme_css'] = 'css/default.css';
> 
> Just to be sure the default.css was not the problem, I copied the
> default.css from the svn I had downloaded into the htdoc location for my
> postfixadmin install, but it did not change anything.
> 
> Is there anywhere else that could cause a problem with the style sheets?
> 
> 
> 
> On 01/18/2011 11:00 AM, David Goodwin wrote:
>> I suspect you've somehow broken the stylesheet(s).
>> 
>> Look in config.inc.php for $CONF['theme_css'] - it should be set to something like 'css/default.css'.
>> 
>> 
>> 
>> David.
>> 
>> 
>> On 17 Jan 2011, at 10:39, J4 wrote:
>> 
>>> Hi there,
>>> 
>>>    I had postfixadmin working well, but sadly made a change last Friday and have forgotten what it was :(  The result is that postfixadmin works, but the (presumably) style sheets are not read. The web page is displayed only in ascii with URL links, but not the nice way it was afore.  
>>> 
>>> I took a screen-shot and upload it here as it better explains what I mean:
>>> http://tinypic.com/r/zn629w/7
>>> 
>>> Does anyone know what might have caused this?
>>> 
>>> Best regards, J.
>>> ------------------------------------------------------------------------------
>>> Protect Your Site and Customers from Malware Attacks
>>> Learn about various malware tactics and how to avoid them. Understand 
>>> malware threats, the impact they can have on your business, and how you 
>>> can protect your company and customers by using code signing.
>>> http://p.sf.net/sfu/oracle-sfdevnl_______________________________________________
>>> Postfixadmin-devel mailing list
>>> Pos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel
>> 
> 
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand 
> malware threats, the impact they can have on your business, and how you 
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Postfixadmin-devel mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel