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

[Postfixadmin-devel] postfixadmin-devel@lists.sourceforge.net

[MailingLists <mai...@st...>]

Hey guys,

I am having a serious problem with amavis and postfixadmin.  My
mailserver setup is as follows:

Postfix -> Dovecot -> Amavisd-new (clamav/spamassasin) -> MySQL ->
Roundcube -> Postfixadmin.

I sometimes get errors in my mail.log as follows:

Jul 20 16:36:12 stoned-hacker amavis[14077]: (14077-07)
lookup_sql_field(id) (WARN: no such field in the SQL table),
"mai...@st..." result=undef
Jul 20 16:36:32 stoned-hacker amavis[13326]: (13326-11)
lookup_sql_field(id) (WARN: no such field in the SQL table),
"mai...@st..." result=undef
Jul 20 16:38:28 stoned-hacker amavis[14077]: (14077-08)
lookup_sql_field(id) (WARN: no such field in the SQL table),
"mai...@st..." result=undef


root@stoned-hacker:/var/log# cat /etc/amavis/conf.d/50-user
use strict;

#
# Place your configuration directives here.  They will override those in
# earlier files.
#
# See /usr/share/doc/amavisd-new/ for documentation and examples of
# the directives you can use in this file
#

@lookup_sql_dsn = (
    ['DBI:mysql:database=postfixadmin;host=127.0.0.1;port=3306',
     'postfixadm',
     'aaaaaaaa']);

$sql_select_policy = 'SELECT domain FROM domain WHERE CONCAT("@",domain)
IN (%k)';



#------------ Do not modify anything below this line -------------
1;  # ensure a defined return
root@stoned-hacker:/var/log#



Is this a known problem as I can't find anything about it on google.

I am not the best with SQL so can't re-arrange the tables.

I would be really grateful if anyone can help me with this.

Thanks in advance,

Dusty.

P.S: Not sure what else you may need to see, just ask and i'll show ya.

[Postfixadmin-devel] create_mailbox_subdirs not working solved

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

Hi, solved it
as stated here
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1970684&group_id=191583
it a bug and its fixed in cvs

but it isnt fixed in total

with some dovecot setup there is no INBOX

change in in functions.inc.php

foreach($CONF['create_mailbox_subdirs'] as $f)
    {
       $f='{'.$s_host.'}INBOX.'.$f;


to

foreach($CONF['create_mailbox_subdirs'] as $f)
    {
       $f='{'.$s_host.'}'.$f;

fixed my problem

perhaps it would be good to have it somewhere in the faqs
and or include a parameter i.e Namespace in config.inc.php

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

[Postfixadmin-devel] create_mailbox_subdirs not working

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

Hi @ll,
using dovecot with virtual users
i cant get create_mailbox_subdirs
work, i cant find any entry in any mail or apache log
which gets me further, has anybody a hint how to debug ?
-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

Re: [Postfixadmin-devel] postfixadmin-2.2.0 fetchmail ssl option

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

Stefan Breitegger wrote:
> Suggenstion to click enable ssl option without extra options enabled  
> for fetchmail:
> 


> Maybe you would put it into svn trunk?
> Thanks!


Yes - more than happy to; but could you send it as either :

a) An attached file

or

b) Create a ticket on sf.net and attach it as a file?


thanks
David.
-- 
David Goodwin

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

[Postfixadmin-devel] postfixadmin-2.2.0 fetchmail ssl option

[Stefan B. <tu...@tu...>]

Suggenstion to click enable ssl option without extra options enabled  
for fetchmail:


diff -r ./ADDITIONS/fetchmail.pl  
/usr/local/src/postfixadmin/tags/postfixadmin-2.2.0/ADDITIONS/fetchmail.pl
21c21
< SELECT  
id,mailbox,src_server,src_auth,src_user,src_password,src_folder,fetchall,keep,protocol,mda,extra_options,ssla
---
> SELECT  
> id,mailbox,src_server,src_auth,src_user,src_password,src_folder,fetchall,keep,protocol,mda,extra_options
28c28
<       my  
($id,$mailbox,$src_server,$src_auth,$src_user,$src_password,$src_folder,$fetchall,$keep,$protocol,$mda,$extra_options,$ssla)=@$_;
---
>       my  
> ($id,$mailbox,$src_server,$src_auth,$src_user,$src_password,$src_folder,$fetchall,$keep,$protocol,$mda,$extra_options)=@$_;
39d38
<       $cmd.=" ssl" if ($ssla);
48,50d46
< defaults
<    smtphost mail.test.tld
<
diff -r ./fetchmail.php  
/usr/local/src/postfixadmin/tags/postfixadmin-2.2.0/fetchmail.php
70d69
<    "ssla"             => array(1,                1,                 
'bool'      ),
diff -r ./languages/de.lang  
/usr/local/src/postfixadmin/tags/postfixadmin-2.2.0/languages/de.lang
388d387
< $PALANG['pFetchmail_field_ssla']            = 'SSL aktiv';
404d402
< $PALANG['pFetchmail_desc_ssla']             = 'Verschl&uuml;sselung  
mit SSL';
diff -r ./languages/en.lang  
/usr/local/src/postfixadmin/tags/postfixadmin-2.2.0/languages/en.lang
388d387
< $PALANG['pFetchmail_field_ssla']            = 'SSL active';
404d402
< $PALANG['pFetchmail_desc_ssla']             = 'SSL encryption';
diff -r ./upgrade.php  
/usr/local/src/postfixadmin/tags/postfixadmin-2.2.0/upgrade.php
826d825
<        ssla tinyint(1) unsigned not null default 0,

Maybe you would put it into svn trunk?
Thanks!

Stefan Breitegger


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: [Postfixadmin-devel] Do we need a 2.2.1 release?

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

> Proposal:
> - new bugs have prio 5 by default, which is something like a "needs 
>   review" flag for me
> - major and critical bugs get a higher prio - 6, 7 or 8
> - blocker bugs get priority 9
> - not-so-important bugs get prio 4 or lower
> - prio 1 should be reserved for "do it on some rainy day" bugs ;-)
>   and maybe also for things we probably won't include, but that 
>   shouldn't be lost (like alternative vacation scripts)
> 
> Do you like this method? Or should we find another way?
 
 I don't mind this - but I'm not going to remember the above.

> While we are at it - should we force people to login before submitting 
> something to the tracker? Anonymous items are often problematic if we 
> need more information from the reporter...

Well, I'd rather keep bug reporting as easy as possible; and requiring
a sf login is one extra hurdle which might deter someone from
reporting it.

> I don't see a real problem with this - the forum also enforces login and 
> nobody complained about this yet ;-)
 
 Well, you can hardly complain if you can't post...


> > 'a' probably involves everything in trunk, except the merge of the
> > domain alias patch.
> 
> I would not exclude it - it's a feature that is requested quite often.

I think it should be slated for 2.3, and keep 2.2.1 as a maintenance
release were only bugs are fixed etc.

> However, we should think about adding an option to disable it via a 
> $CONF switch - and maybe it should be disabled by default in 2.2.*.
 
Yes.

> I have to admit that I didn't test domain aliases on a real server, but 
> at least the code in postfixadmin seems to work ;-)
 
 I've not tested it at all.

> collation specified in the MySQL dump. This means that the collation 
> 2.1 users have in their database depends on the local MySQL settings. 
> >From our point of view, we can just call it "random"...
> (also added this note to bug 1990191)
> 

I thought this might be the case.

> If you have some time, could you please update the changelog?
> If I get debian/changelog right, 2.2.0 was SVN r356. This means you'll 
> have to pick the most important changes since then:
>     svn log -r 356:379
 
 The changelog is only a normal text file... but yes I can/will.

> Please also add the SVN revision to CHANGELOG.txt in all (future) 
> releases and a $Id$ header (needs "svn propset svn:keywords 
> CHANGELOG.txt") so that we can always see when the changelog was last 
> updated.

OK
David.

-- 
David Goodwin 

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

Re: [Postfixadmin-devel] Do we need a 2.2.1 release?

[Michiel v. B. <mi...@va...>]

On 18:23, Sun 15 Jun 08, Christian Boltz wrote:
> Hello,
> 
> Am Sonntag, 15. Juni 2008 schrieb David Goodwin:
> > I'm getting the feeling that we need a 2.2.1 release, which would be
> > effectively :
> >
> > a) All the fixes we've made to trunk since 2.2.0 was released
> > b) A Fix for the MySQL table creation problem (collation stuff)
> 
> Sounds like a good idea.

+1 from me

> 
> I'd like to add
> c) go through all open bugs and check if they are release critical.
> 
> Unfortunately SF doesn't have a "severity" field, so we'll have to abuse 
> the priority ;-)
> Proposal:
> - new bugs have prio 5 by default, which is something like a "needs 
>   review" flag for me
> - major and critical bugs get a higher prio - 6, 7 or 8
> - blocker bugs get priority 9
> - not-so-important bugs get prio 4 or lower
> - prio 1 should be reserved for "do it on some rainy day" bugs ;-)
>   and maybe also for things we probably won't include, but that 
>   shouldn't be lost (like alternative vacation scripts)
> 
> Do you like this method? Or should we find another way?

This is the way we handle bugs on sf.net.
I think it's the only way to do it without severity field.

> 
> While we are at it - should we force people to login before submitting 
> something to the tracker? Anonymous items are often problematic if we 
> need more information from the reporter...
> I don't see a real problem with this - the forum also enforces login and 
> nobody complained about this yet ;-)

Like you said: this is the only way to make sure the OP gets the
requests for more information.
You can use sfbot's stuff to close bugs that did not get the required
feedback after X ammount of time. This makes life a bit easier for the
bug marshalls.

> 
> > 'a' probably involves everything in trunk, except the merge of the
> > domain alias patch.
> 
> I would not exclude it - it's a feature that is requested quite often.

I would. It's the only reason I'm not running current trunk.
> 
> However, we should think about adding an option to disable it via a 
> $CONF switch - and maybe it should be disabled by default in 2.2.*.

If it's like that I will upgrade.

> 
> I have to admit that I didn't test domain aliases on a real server, but 
> at least the code in postfixadmin seems to work ;-)
> 
> > What's the issue with the MySQL vacation table stuff - do we need to
> > find out what collation type the table is before creating it, so it
> > matches with existing ones, or not manually specify it? I don't fully
> > understand what's wrong.....
> 
> I checked the 2.1 release again and found out that there was no 
> collation specified in the MySQL dump. This means that the collation 
> 2.1 users have in their database depends on the local MySQL settings. 
> >From our point of view, we can just call it "random"...
> (also added this note to bug 1990191)
> 
> This means I should really change it within upgrade.php. (For users who 
> already have the correct charset there won't be a change of course, 
> even if the ALTER TABLE statements are executed.)
> 
> I'll probably have to setup a 2.1 database and manually alter the 
> collation to make sure the upgrade works (and additionally don't have 
> much time currently), so this "small" change might take some days.
> 
> 
> If you have some time, could you please update the changelog?
> If I get debian/changelog right, 2.2.0 was SVN r356. This means you'll 
> have to pick the most important changes since then:
>     svn log -r 356:379
> 
> Please also add the SVN revision to CHANGELOG.txt in all (future) 
> releases and a $Id$ header (needs "svn propset svn:keywords 
> CHANGELOG.txt") so that we can always see when the changelog was last 
> updated.

Great plan.

> 
> 
> Regards,
> 
> Christian Boltz
> -- 
> XSLT ist eine Art awk auf Bäumen und hat alle Nachteile von awk.
> Wenn man vorher nur Shell konnte, ist es allerdings die Erleuchtung.
> [Kristian Köhntopp in suse-linux-faq]
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Postfixadmin-devel mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel

-- 

Michiel van Baak
mi...@va...
http://michiel.vanbaak.eu
GnuPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x71C946BD

"Why is it drug addicts and computer aficionados are both called users?"

Re: [Postfixadmin-devel] Do we need a 2.2.1 release?

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

Hello,

Am Sonntag, 15. Juni 2008 schrieb David Goodwin:
> I'm getting the feeling that we need a 2.2.1 release, which would be
> effectively :
>
> a) All the fixes we've made to trunk since 2.2.0 was released
> b) A Fix for the MySQL table creation problem (collation stuff)

Sounds like a good idea.

I'd like to add
c) go through all open bugs and check if they are release critical.

Unfortunately SF doesn't have a "severity" field, so we'll have to abuse 
the priority ;-)
Proposal:
- new bugs have prio 5 by default, which is something like a "needs 
  review" flag for me
- major and critical bugs get a higher prio - 6, 7 or 8
- blocker bugs get priority 9
- not-so-important bugs get prio 4 or lower
- prio 1 should be reserved for "do it on some rainy day" bugs ;-)
  and maybe also for things we probably won't include, but that 
  shouldn't be lost (like alternative vacation scripts)

Do you like this method? Or should we find another way?

While we are at it - should we force people to login before submitting 
something to the tracker? Anonymous items are often problematic if we 
need more information from the reporter...
I don't see a real problem with this - the forum also enforces login and 
nobody complained about this yet ;-)

> 'a' probably involves everything in trunk, except the merge of the
> domain alias patch.

I would not exclude it - it's a feature that is requested quite often.

However, we should think about adding an option to disable it via a 
$CONF switch - and maybe it should be disabled by default in 2.2.*.

I have to admit that I didn't test domain aliases on a real server, but 
at least the code in postfixadmin seems to work ;-)

> What's the issue with the MySQL vacation table stuff - do we need to
> find out what collation type the table is before creating it, so it
> matches with existing ones, or not manually specify it? I don't fully
> understand what's wrong.....

I checked the 2.1 release again and found out that there was no 
collation specified in the MySQL dump. This means that the collation 
2.1 users have in their database depends on the local MySQL settings. 
From our point of view, we can just call it "random"...
(also added this note to bug 1990191)

This means I should really change it within upgrade.php. (For users who 
already have the correct charset there won't be a change of course, 
even if the ALTER TABLE statements are executed.)

I'll probably have to setup a 2.1 database and manually alter the 
collation to make sure the upgrade works (and additionally don't have 
much time currently), so this "small" change might take some days.


If you have some time, could you please update the changelog?
If I get debian/changelog right, 2.2.0 was SVN r356. This means you'll 
have to pick the most important changes since then:
    svn log -r 356:379

Please also add the SVN revision to CHANGELOG.txt in all (future) 
releases and a $Id$ header (needs "svn propset svn:keywords 
CHANGELOG.txt") so that we can always see when the changelog was last 
updated.


Regards,

Christian Boltz
-- 
XSLT ist eine Art awk auf Bäumen und hat alle Nachteile von awk.
Wenn man vorher nur Shell konnte, ist es allerdings die Erleuchtung.
[Kristian Köhntopp in suse-linux-faq]

[Postfixadmin-devel] Do we need a 2.2.1 release?

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

Hi,
I'm getting the feeling that we need a 2.2.1 release, which would be
effectively :

a) All the fixes we've made to trunk since 2.2.0 was released 
b) A Fix for the MySQL table creation problem (collation stuff)



'a' probably involves everything in trunk, except the merge of the
domain alias patch.

What's the issue with the MySQL vacation table stuff - do we need to
find out what collation type the table is before creating it, so it
matches with existing ones, or not manually specify it? I don't fully
understand what's wrong..... 

Ideas/Feedback welcome,

Thanks
David.

-- 
David Goodwin 

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

Re: [Postfixadmin-devel] courier-mta and aliases dir

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

Hello,

(posting to postfixadmin-devel again - this might be interesting for
more people. Please send your replies to the mailinglist also.)

Am Mittwoch, 11. Juni 2008 schrieb Stefan Breitegger:
> Zitat von Christian Boltz <pos...@cb...>:
...
> > So: What exactly do you want to do? What's the problem?
>
> Please send me a working authmysqlrc with a custom sql query working
> with postfix-admin! I don't know how to set the correct queries for
> the 2 tables (alias and mailbox). I was glad setting up the correct
> MYSQL query for the mailbox table....

You don't need the aliases for courier-authlib. The mailbox table contains
everything you need ;-)

Here's the config I'm using on a server with courier-authlib-0.58.
It still uses the old-style syntax with lots of MYSQL_* variables, but
works perfectly - so why should I change it?

# grep '^[^#]' authdaemonrc
authmodulelist="authmysql"
authmodulelistorig="authuserdb authpam authldap authmysql authcustom authpipe"
daemons=5
authdaemonvar=/var/run/authdaemon.courier-imap
DEBUG_LOGIN=0
DEFAULTOPTIONS=""
LOGGEROPTS=""

# grep '^[^#]' authmysqlrc
MYSQL_SERVER            localhost
MYSQL_USERNAME          mail-courier
MYSQL_PASSWORD          your_password_here
MYSQL_SOCKET            /var/lib/mysql/mysql.sock
MYSQL_OPT               0
MYSQL_DATABASE          mail
MYSQL_USER_TABLE        mailbox
MYSQL_CLEAR_PWFIELD     password
MYSQL_UID_FIELD         '20000'
MYSQL_GID_FIELD         '10002'
MYSQL_LOGIN_FIELD       username
MYSQL_HOME_FIELD        '/home/mailbox/'
MYSQL_NAME_FIELD        name
MYSQL_MAILDIR_FIELD     maildir
MYSQL_QUOTA_FIELD       concat(quota,'S')
MYSQL_WHERE_CLAUSE      active=1

Yes, I'm storing cleartext passwords in my database. Not nice, but it 
works quite good ;-)  You might want to use
MYSQL_CRYPT_PWFIELD   password
instead if you store your passwords encrypted.

You will also need to change MYSQL_UID_FIELD and MYSQL_GID_FIELD. They 
are set to a static UID and GID. This has to match the user that owns 
your mailboxes directory.

BTW: The only permissions the MySQL user needs are SELECT permissions on
the mailbox table.


Regards,

Christian Boltz
-- 
Das terrorsicherste Verkehrsmittel ist ganz klar das Automobil. Einzeln
verpackte Verkehrsteilnehmer in Stahlhülle mit großen Abständen. :)
[Kristian Köhntopp auf
http://blog.koehntopp.de/archives/1376-Mach-mir-den-Rail-Marshall.html]

Re: [Postfixadmin-devel] courier-mta and aliases dir

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

Hello,

Am Montag, 2. Juni 2008 schrieb Stefan Breitegger:
> How to implement aliases in "Courier-MTA" style with postfix admin?
>
> I think something like postfixadmin-alias-postcreation.sh and
> postfixadmin-alias-deletion.sh

Unfortunately I don't understand your problem and also don't know what 
you mean with Courier style aliases.

In my setup, postfix handles all the aliases and courier only knows 
about mailboxes (via courier-authdaemon, directly from MySQL). Maildrop 
does the delivery to the mailboxes.

So: What exactly do you want to do? What's the problem?


Regards,

Christian Boltz
-- 
Ich bin doch nicht bloed! Nur wegen util-linux ein neues Linux
zu installieren? Awatt.           [David Haller in suse-linux]

[Postfixadmin-devel] courier-mta and aliases dir

[Stefan B. <tu...@tu...>]

Hi!

How to implement aliases in "Courier-MTA" style with postfix admin?

I think something like postfixadmin-alias-postcreation.sh and  
postfixadmin-alias-deletion.sh


Please help!



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: [Postfixadmin-devel] 2.2?

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

Hello,

(I assume your mail should have gone to the mailinglist? ;-)

Am Samstag, 26. April 2008 schrieb David Goodwin:
> > BTW: Don't forget to change the "check for updates" URL when
> > creating the 2.2 tarball ;-)
>
> So, I can release 2.2 once that's done then?

If it istn't too much work, please add the "CREATE TABLE fetchmail" for 
PgSQL to upgrade.php.

Other minor things (more or less optional):
- update /CHANGELOG.TXT  (if you remember which SVN revision each rc 
  was, please note it there)
- update contributors in /LICENSE.TXT (at least the main contributors)
- DOCUMENTS/POSTFIXADMIN.txt is outdated (still refers to /admin)

Otherwise: yes, I think we can finally release 2.2 :-)


Regards,

Christian Boltz
-- 
[ Yes ] [ No ]
... used for harmless errors or simple questions: "It's high time you
had your cup of coffee! Would you like your KDE to prepare one for you?"
[Lukas Ocilka in opensuse-factory - YaST2 button styleguide]

Re: [Postfixadmin-devel] 2.2?

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

Hello,

Am Freitag, 25. April 2008 schrieb David Goodwin:
> Matt Rude wrote :
> > Was the fetchmail table added to the install?
>
> Historically the tables etc for this were always in fetchmail.php; it
> probably makes sense for it to move into upgrade.php

Right. Done for MySQL.

Please add the CREATE TABLE statements for PgSQL - I have already 
included an empty function at the end of upgrade.php.

> Does the fetchmail stuff work with PostgreSQL?

I have never tested it with PostgreSQL, but the fetchmail.php code looks 
good. IMHO it should work or only need very small fixes.

I have no idea if ADDITIONS/fetchmail.pl is prepared for PostgreSQL.


Regards,

Christian Boltz
-- 
Die SuSE 9.2 ist ein gutes Argument 20 Euro in die Hand zu nehmen
und ein DVD-Laufwerk zu kaufen.   [Manfred Tremmel in suse-linux]

Re: [Postfixadmin-devel] 2.2?

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

Hello,

Am Mittwoch, 23. April 2008 schrieb David Goodwin:
> 2.2.0rc5 packages/downloads are available on sf.net
>
> I'd like to think we'll soon have a 2.2.0 release! Does anyone know
> of any blockers? Can some of you try testing it please?

I installed it on a production server (which was using an early svn 
version before) and instantly found a blocker bug: common.php redirects 
to setup.php if config.inc.php doesn't exist or $CONF['configured'] is 
FALSE.
There's nothing wrong with that - unless you include() upgrade.php, 
which include()s common.php in setup.php ;-)  The result was a nice 
redirect loop from and to setup.php.

Good news: I already fixed this in SVN some hours ago (r343).


I also entered some possible enhancements for the colored markers to the 
tracker - for post-2.2.


> (rc4 didn't include mysql table creation for new installs, which was
> a slight flaw!)

Are you sure? I doubt ;-)

The tables are created in upgrade_5_mysql, which is basically a copy of 
SVN r1 DATABASE_MYSQL.TXT. (Yes, it is intentional that there are some 
ALTER statements before - they cover pre-sourceforge SVN r1 changes.)

And yes, I just tested this with a completely fresh install on a fresh 
database without any existing tables, while having upgrade_1_mysql 
completely commented out.


To be exact, upgrade_2_pgsql should be renamed to upgrade_5_pgsql (I 
assume you used SVN r1 as base?)


I just found out that create mailbox and create admin don't enforce the 
min_password_length - but this isn't a blocker for 2.2. We should 
probably fix this by merging create and edit (see fetchmail for an 
example) after 2.2 is out.


BTW: Don't forget to change the "check for updates" URL when creating 
the 2.2 tarball ;-)

Apropos... - http://postfixadmin.sourceforge.net/update-check.php 
results in a 404 :-(  I have created one that at least redirects to the 
home page - please run SVN up on the webspace (and implement 
update-check.php if you have some time).


Regards,

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

Re: [Postfixadmin-devel] 2.2?

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

Matt Rude wrote :
> 
> Was the fetchmail table added to the install?

Historically the tables etc for this were always in fetchmail.php; it
probably makes sense for it to move into upgrade.php

Does the fetchmail stuff work with PostgreSQL?

Thanks for the feedback,

David.

-- 
David Goodwin 

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

Re: [Postfixadmin-devel] 2.2?

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

On Wed, April 23, 2008 2:52 pm, David Goodwin wrote:
> Hi,
>
> 2.2.0rc5 packages/downloads are available on sf.net
>
> I'd like to think we'll soon have a 2.2.0 release! Does anyone know of
> any blockers? Can some of you try testing it please?
>
> (rc4 didn't include mysql table creation for new installs, which was a
> slight flaw!)
>
>
> thanks
> David.
>
> --
> David Goodwin
>
> [ david at codepoets dot co dot uk ]
> [ http://www.codepoets.co.uk       ]
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Postfixadmin-devel mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel
>

Was the fetchmail table added to the install?
I just tried to build a new install to see if the fetchmail table would
now be build but it wasn't.  This was a fresh install of postfixadmin
from the svn
(https://postfixadmin.svn.sourceforge.net/svnroot/postfixadmin/trunk)

The setup.php ran without any errors.

The error I received in my web browser was:

DEBUG INFORMATION:
Invalid query: Table 'postfix.fetchmail' doesn't exist

Please check the documentation and website for more information.

Postfix Admin
Forums

Thanks
-Matt
-- 
Matt Rude
www.mattrude.com

[Postfixadmin-devel] 2.2?

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

Hi,

2.2.0rc5 packages/downloads are available on sf.net

I'd like to think we'll soon have a 2.2.0 release! Does anyone know of 
any blockers? Can some of you try testing it please?

(rc4 didn't include mysql table creation for new installs, which was a 
slight flaw!)


thanks
David.

-- 
David Goodwin

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

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin: [331] trunk/languages/ja.lang

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

chr...@us... wrote:
> Revision: 331
>           http://postfixadmin.svn.sourceforge.net/postfixadmin/?rev=331&view=rev
> Author:   christian_boltz
> Date:     2008-04-11 15:58:55 -0700 (Fri, 11 Apr 2008)
> 
> Log Message:
> -----------
> ja.lang:
> - added some missing translation markers
> 


So, are we there [2.2] yet?
Anyone mind the effective dropping of setting up different users (by 
default) for e.g. vacation, postfixadmin and postfix (within the 
database)? (See also DOCUMENTS/SECURITY.TXT)


I've put a crap FAQ.TXT in as well, although I think perhaps it might be 
better if it was either duplicated, or also on the website.

I've tested the PostgreSQL setup.php, and so has one other person that I 
know of... so is MySQL sorted then?

David.

-- 
David Goodwin

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

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

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

Hello,

(answering in the public, this might be interesting for everybody)

Am Sonntag, 6. April 2008 schrieb David Goodwin:
> chr...@us... wrote:
> > Revision: 317
...
> <are we nearly there [2.2] yet?>

I have waited for this question ;-)

Yes, from the MySQL side I think so - however, I'd like to wait some 
days for feedback in the bugs and to do some tests with updating old 
databases (2.1, SVN r1) - I have mostly tested the changes with a new, 
empty database.

I have also entered a new (small) blocker bug some minutes ago:
setup.php should check if database is up to date, details on
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1936331&group_id=191583
(for 2.2, we can simply hardcode the required revision in setup.php - 
but we should find a better solution for the future.)

Another small item on the ToDo list: create the fetchmail table via 
upgrade.php. How does the statement for pgsql look like for it?
(see fetchmail.php for MySQL version)

BTW: What about integrating pgsql table creation (as of SVN r1) in 
upgrade.php (would be upgrade_5_pgsql) also? It would make the handling 
in the new blocker easier ;-)


Regards,

Christian Boltz
-- 
general rule: if Olaf reports a bug, it is a valid bug.
[Olaf Hering while reopening 
 https://bugzilla.novell.com/show_bug.cgi?id=168595]

Re: [Postfixadmin-devel] Create folder when adding new domain

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

Hello,

Am Freitag, 14. März 2008 schrieb li...@ma...:
> > Matt Rude wrote :
> >> ... when I tried to add the first mailbox 
> >> Postfixadmin told me that the email address was invalided. 

This might also happen if the nameserver can't resolve the domain. 
Unfortunately we miss a better error message in this case.

You can disable this lookup by setting
    $CONF['emailcheck_resolve_domain']='NO';
in config.inc.php

> >> ... PostfixAdmin did not create a folder for the new domain during
> >> the "Add Domain" process or when I tried to add the mailbox.  Once
> >> i created the folder PostfixAdmin was happy and added all the
> >> mailboxes with no problems and they are now receiving email.

If you use postfix (without maildrop etc.) to deliver the mail to the 
mailbox, postfix should create all needed directories. If it doesn't, 
check if it has write permissions and/or complains in the logfile.

If you use maildrop, you'll need some lines in maildroprc to create the 
directories. (Available on request.)

> I was hoping that I could use something like the
> "postfix-domain-postdelete" script but I can't figure out how to add
> that to PA.
>
> Is there someplace to put a script that would add the folders for me
> as Im creating the domain?

You can use $CONF['mailbox_postcreation_script']. Yes, it runs too often 
(on every mailbox creation instead of domain creation), but this 
shouldn't be a problem. ADDITIONS/postfixadmin-mailbox-postcreation.sh 
is an example script.


Regards,

Christian Boltz
-- 
> David, bitte wegschauen... Nein David, das hast Du nicht gesehen. Es
> ist alles OK, David... Ganz ruhig... :-)
*augen wieder aufmach* *haende von den ohren nehm*
Haeh? Was? Hab ich was verpasst?
[> Thomas Hertweck und David Haller in suse-linux]

Re: [Postfixadmin-devel] Create folder when adding new domain

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

> Matt Rude wrote :
>> Hello,
>> I am using PostfixAdmin (SVN#311 trunk), and today I added my first new
>> domain to my setup using PostfixAdmin.  The adding of the domain went
>> fine but when I tried to add the first mailbox Postfixadmin told me that
>> the email address was invalided. knowing that the address was fine I
>> started looking around.  My folder structure is such that each domain is
>> located in it's own folder, ie.
>>
>> /var/spool/mail/example1.com/
>> /var/spool/mail/example2.com/
>> /var/spool/mail/example3.com/
>>
>> But PostfixAdmin did not create a folder for the new domain during the
>> "Add Domain" process or when I tried to add the mailbox.  Once i created
>> the folder PostfixAdmin was happy and added all the mailboxes with no
>> problems and they are now receiving email.
>>
>> Is there a flag I need to flip somewhere or should I be looking at
>> postfix?
>>
>
> I suspect the problem would be that Postfixadmin wouldn't/couldn't have
> permission on it's own to create the domain folder (just like it
> can't/doesn't create mailboxes)
>
> Is there a script to run via sudo or anything to accomplish creation of
> the domain folder?
>
> David.
>

I was hoping that I could use something like the
"postfix-domain-postdelete" script but I can't figure out how to add that
to PA.

Is there someplace to put a script that would add the folders for me as Im
creating the domain?

-Matt

Re: [Postfixadmin-devel] Create folder when adding new domain

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

Matt Rude wrote :
> Hello,
> I am using PostfixAdmin (SVN#311 trunk), and today I added my first new 
> domain to my setup using PostfixAdmin.  The adding of the domain went 
> fine but when I tried to add the first mailbox Postfixadmin told me that 
> the email address was invalided. knowing that the address was fine I 
> started looking around.  My folder structure is such that each domain is 
> located in it's own folder, ie.
> 
> /var/spool/mail/example1.com/
> /var/spool/mail/example2.com/
> /var/spool/mail/example3.com/
> 
> But PostfixAdmin did not create a folder for the new domain during the 
> "Add Domain" process or when I tried to add the mailbox.  Once i created 
> the folder PostfixAdmin was happy and added all the mailboxes with no 
> problems and they are now receiving email.
> 
> Is there a flag I need to flip somewhere or should I be looking at postfix?
> 

I suspect the problem would be that Postfixadmin wouldn't/couldn't have
permission on it's own to create the domain folder (just like it
can't/doesn't create mailboxes)

Is there a script to run via sudo or anything to accomplish creation of
the domain folder?

David.

-- 
David Goodwin 

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

[Postfixadmin-devel] Create folder when adding new domain

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

Hello,
I am using PostfixAdmin (SVN#311 trunk), and today I added my first new 
domain to my setup using PostfixAdmin.  The adding of the domain went 
fine but when I tried to add the first mailbox Postfixadmin told me that 
the email address was invalided. knowing that the address was fine I 
started looking around.  My folder structure is such that each domain is 
located in it's own folder, ie.

/var/spool/mail/example1.com/
/var/spool/mail/example2.com/
/var/spool/mail/example3.com/

But PostfixAdmin did not create a folder for the new domain during the 
"Add Domain" process or when I tried to add the mailbox.  Once i created 
the folder PostfixAdmin was happy and added all the mailboxes with no 
problems and they are now receiving email.

Is there a flag I need to flip somewhere or should I be looking at postfix?

Thanks
-Matt

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

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

Hello,

Am Dienstag, 4. März 2008 schrieb agr...@us...:
> Revision: 308

> fixed an error that would not identify POP/IMAP accounts when a
> mailbox forwards to other destinations as well.

> +++ trunk/functions.inc.php	2008-03-04 22:02:20 UTC (rev 308)
> @@ -1985,7 +1985,7 @@

I'm afraid that this code section is still buggy :-(

Let me use "ta...@do...d" as mailbox name in the examples below.

We now have:
      if (preg_match ('/^' . $show_alias . '$/', $stat_goto) ||

Matches aliases that only forward to the mailbox.
Example: "ta...@do...d"
OK.

         preg_match ('/' . $show_alias . ',/', $stat_goto) ||

Matches if goto contains the target and another address.
Example: "target@domain,tld, fo...@do...d"

BUT: it also matches "oth...@do...d,fo...@do...d" :-(

Be warned that there will be nothing that matches 
"fo...@do...d,ta...@do...d,ba...@do...d" if you change the 
regex to   '/^' . $show_alias . ',/'


         preg_match ('/,' . $show_alias . '$/', $stat_goto) )

Matches if goto contains the mailbox as last entry.
Example: "fo...@do...d,ta...@do...d"
OK.


Proposal: Simplify the code by adding commas to $stat_goto ;-)

 preg_match(   '/,' . $show_alias . ',/'   ,   ',' . $stat_goto . ','  )
               ^^^^^^^^^^^^^^^^^^^^^^^^^       ^^^^^^^^^^^^^^^^^^^^^^
                       regex                      string to check

should catch everything ;-)


Regards,

Christian Boltz
-- 
BUGS My programs  never  have  bugs.  They  just  develop  random
     features.  If you discover such a feature and you want it to
     be removed: please send me an email.