Re: [Postfixadmin-devel] Changing some defaults in trunk/3.0?

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

Hello,

thanks for all the feedback!

I'll take this mail as base for my reply because you were the first to 
respond ;-) and commented on all options. My response is summarized for 
all mails on this topic.

The summarized votes do _not_ include my personal vote.

BTW: Did I really catch every $CONF option that might need a better 
default value? ;-)

Am Freitag, 13. April 2012 schrieb Robert Schetterer:
> Am 13.04.2012 02:04, schrieb Christian Boltz:
> >     $CONF['database_type'] = 'mysqli'; # current value: "mysql"
> > 
> > should be changed to "mysqli". The reason is simple - I don't expect
> > we have too many users using MySQL < 4.1 nowadays ;-) so using the
> > (newer) mysqli interface by default would make sense.
> 
> ACK

That makes a total of +4, which means I'll change this.

>From David's mail:
| Just silently default to mysqli perhaps - i.e. if someone chooses 
| 'mysql' they're actually using 'mysqli' ?

I don't really like this idea - maybe there's someone who intentionally 
uses the "old" mysql functions for whatever reasons.
Besides that, mysqli doesn't bring noticeable advantages for 
postfixadmin besides the "it's newer" argument because we don't use the 
additional features it provides.

We should set mysqli as default, but if someone really want to use the 
old mysql functions, then I won't stop him ;-)

| We could wrap this in a if(function_exists('mysqli_connect')) or 
| something - just incase it's possible to have a php5-mysql installed 
| without a php5-mysqli package?

openSUSE 12.1 ships mysqli in the php5-mysql package, but older releases 
(please don't ask for a version number) had separate php5-mysql and 
php5-mysqli packages IIRC. So it's probably possible to have php5-mysql 
without php5-mysqli.

BTW: we already have function_exists() checks in db_connect().

> >     $CONF['dovecotpw'] = "/usr/sbin/doveadm pw";
> >     # current value: "/usr/sbin/dovecotpw";
> > 
> > reason: dovecot 2.x comes with doveadm instead of dovecotpw
> 
> ACK

That's +1 (and 3 neutral / no comment), so I'll change it to doveadm pw 
(with a comment about dovecotpw for dovecot 1.x)

> >     $CONF['domain_path'] = 'YES'; # was NO
> >     $CONF['domain_in_mailbox'] = 'NO'; # was YES
> > 
> > in other words: domain/username/ instead of username@domain/
> > reason: maybe personal taste ;-)
> 
> there might not be a default for all people satisfy
> reading doku stays mandatory

Indeed. Nevertheless we have a total +3 so I'll change it as proposed.

> >     $CONF['quota'] = 'YES'; # was NO
> > 
> > reason: I'm using quota everywhere - even if I make the mailbox
> > *very* big, just to avoid that a forgotten mailbox can fill up the
> > harddisk.
> NOTACK, using quota isnt so wide spreaded as you think, so stay simple
> default might be better choice

I'm quite surprised by the -4 result ;-) and will of course respect it.

> >     $CONF['vacation'] = 'YES'; # was NO
> > 
> > why should we hide this feature? ;-)
> 
> NOTACK,

That sums up to -1, one neutral and one "we should use sieve", so it 
will stay NO.

> vacation is done via sieve ?

No, it's done by the vacation.pl script we ship with postfixadmin.
There's a feature request to use sieve, but nobody implemented it yet.

> >     $CONF['alias_control'] = 'YES'; # was NO
> >     $CONF['alias_control_admin'] = 'YES'; # was NO
> > 
> > I stopped counting how often users asked to implement this feature
> > ;-) so we should enable it by default
> 
> OK

Total: +3

> >     $CONF['backup'] = 'NO'; # was YES
> > 
> > The backup module is basically unmaintained...
> 
> then it should stay NO

It is currently YES ;-) which makes a total of +4 for NO.

> >     $CONF['show_status']='YES'; # was NO
> > 
> > Why should we hide such a nice feature?
> > Note that some of the related options would also need better
> > defaults, but let's first discuss if enabling show_status by
> > default makes sense.
> just forgot what show status means *g

This got +2 and 2 questionmarks ;-)

It displays color markers for several things based on the alias target. 
I'll paste from config.inc.php because the explanation there is better 
than anything I could write to sum it up ;-)
(Proposals for better default values are welcome ;-)

//set to YES to enable this feature
$CONF['show_status']='NO';
//display a guide to what these colors mean
$CONF['show_status_key']='NO';
// 'show_status_text' will be displayed with the background colors
// associated with each status, you can customize it here
$CONF['show_status_text']='&nbsp;&nbsp;';
// show_undeliverable is useful if most accounts are delivered to this
// postfix system.  If many aliases and mailboxes are forwarded
// elsewhere, you will probably want to disable this.
$CONF['show_undeliverable']='NO';
$CONF['show_undeliverable_color']='tomato';
// mails to these domains will never be flagged as undeliverable
$CONF['show_undeliverable_exceptions']=array("unixmail.domain.ext","exchangeserver.domain.ext","gmail.com");
$CONF['show_popimap']='NO';                                                                                                                                                     
$CONF['show_popimap_color']='darkgrey';
// you can assign special colors to some domains. To do this,
// - add the domain to show_custom_domains
// - add the corresponding color to show_custom_colors
$CONF['show_custom_domains']=array("subdomain.domain.ext","domain2.ext");
$CONF['show_custom_colors']=array("lightgreen","lightblue");
// If you use a recipient_delimiter in your postfix config, you can also
// honor it when aliases are checked.
// Example: $CONF['recipient_delimiter'] = "+";
// Set to "" to disable this check.
$CONF['recipient_delimiter'] = "";

I'd propose the following changes:
$CONF['show_status']='YES'; # was NO
$CONF['show_status_key']='YES'; # was NO
$CONF['show_undeliverable']='YES'; # was NO
$CONF['show_undeliverable_exceptions']=array("unixmail.domain.ext","exchangeserver.domain.ext"); 
# removed "gmail.com"
$CONF['show_popimap']='YES'; # was NO

> >     $CONF['new_quota_table'] = 'YES'; # was NO
> > 
> > new quota table format in dovecot 2.x
> 
> ACK but depend on quota enable defaults

That makes +2, which also makes it compatible with the changed 
$CONF['dovecotpw'] ;-)

If quota support is disabled, it will be ignored regardless of its 
value.

>From Johan's mail:
| Dovecot 1 is not really supported any more.
| So if this could be merged into one quota setting that would be 
| better.

That would mean dropping support for Dovecot 1.x style quota tables, 
which is completely different from changing a default value. I will not 
do this as long as it doesn't cause noticeable maintenance work (at the 
moment it "just works", so there's no reason to drop it).

> is there a changelog preview by new feature sets ?

CHANGELOG.TXT in svn trunk already lists some changes (until 2011-08), 
and the second half is 
    svn log -r 1166:1367
The "svn log" part might sound funny, but it somehow scares me because 
I'll have to read and summarize it. Paperwork... (if someone volunteers 
to do it, I'll be more than happy ;-)


Regards,

Christian Boltz
-- 
Wenn du willst kannst du das so machen,  du kannst dir dann aber auch
genausogut mit ner Hilti ein schickes Schaedel-Piercing machen... Das
tut uebrigens auch nur ganz kurz weh...  [David Haller in suse-linux]