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

Re: [Postfixadmin-devel] Postfixadmin 2.4

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

Hello,

Am Montag, 2. November 2009 schrieb David Goodwin:
> reg9009 wrote :
> > As discussed, I'd like to propose the merge of the trunk and smarty
> > branch. I've tried to keep all changes in sync, and Postfixadmin
> > smarty is running well on different sites in production.
> >
> > There should be little adjustment if any, as we kept most of the
> > system. There was just a bit of layout work. As I'm not that design
> > guy, help in the layout work is greatly appreciated.
> 
> Assuming you want to / are able to - feel free in merging it into
>  trunk :)

Same from me - feel free to merge it into trunk.

If possible, do a separate commit for the smarty (upstream) code and one 
for the postfixadmin-related code. This should result in better readable 
commit mails ;-)


I didn't look too close at the smarty branch yet (will do when it's in 
trunk), but I found one issue already:

Your fetchmail template doesn't exactly match the current fetchmail 
template, even if the resulting HTML looks the same.
- the current (PHP) template loops over all fields and prints them using 
  helper functions (per field type, for example "text input" or 
  "dropdown list")
- your smarty template contains a more "traditonal" code where each 
  field is listed separately - at least for displaying the list view.
- for the edit form, you are using PHP-functions to handle the loops 
  which is already better, but - can this be changed to smarty code?

The advantage of looping over all fields is that it's very easy to add 
additional fields:
1. add the column to the database
2. add one line in the $fm_struct array in fetchmail.php
3. (optional:) add a line to the $fm_defaults array
4. be happy ;-)

It would be good if the smarty template could work the same way, because 
I want to change all parts of postfixadmin to use a similar way on the 
long term. (We could then even have common templates for _all_ lists and 
_all_ edit forms, independent of what to edit or list.)

I think the best solution to do this is to have a template named 
"common-edit.tpl" (and one named common-list.tpl). 
It should still be possible to handle some fields in a special way.

The common-edit.tpl could look like this (pseudocode, I still have to 
learn smarty):

if ($table == foo and $fieldname == bar) # special field handling
    echo "<td>special field handling</td><td><input type=..."/></td>"
[... more special handling if needed ...]
elseif ($fieldtype == text)
    echo "<td>$label</td><td><input type="text" name="$field"/></td>"
elseif ($fieldtype == dropdown)
...
else # default for unknown field types
    echo "<td>$label</td><td><input type="text" name="$field"/></td>"


This is nothing that blocks the merge to trunk, but please change the 
fetchmail template to behave this way. (When this is done, we can change 
more parts to use the common-* templates.)

> I know cboltz and I have made a few minor changes to trunk since the
> 2.3 release, so I guess your branch is slightly out of date in that
> respect.

My yesterday's commit probably doesn't qualify as "minor change" ;-)
(but it doesn't change too much in the template)

BTW: your mail address suggests you are living in germany. Where 
exactly? (I live in the "Pfalz", in Insheim to be exact.)


Regards,

Christian Boltz
-- 
>Ein wenig künstlerische Freiheit darf doch wohl noch sein, oder?
Nur, falls Du die Artistic Licence unterschrieben hast.
                 [Bernd Brodesser und Martin Leidig in suse-talk]

Re: [Postfixadmin-devel] Postfixadmin 2.4

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

reg9009 wrote :
> Hi,
> 
> first of all, congratulations of getting Postfixadmin 2.3 out :)
> 
> As discussed, I'd like to propose the merge of the trunk and smarty
> branch. I've tried to keep all changes in sync, and Postfixadmin smarty
> is running well on different sites in production.
> 
> There should be little adjustment if any, as we kept most of the system.
> There was just a bit of layout work. As I'm not that design guy, help in
> the layout work is greatly appreciated.
> 

Hi,

Assuming you want to / are able to - feel free in merging it into trunk :)

I know cboltz and I have made a few minor changes to trunk since the
2.3 release, so I guess your branch is slightly out of date in that
respect.


> I think the merge could be done in November, and I'm happy to help out
> with any problems that are encountered to get the merge done as soon as
> possible. Btw., tests have shown that PFA runs with smarty 3 out of the
> box...

Is Smarty3 out of beta?

David.

-- 
David Goodwin 

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

Re: [Postfixadmin-devel] short_open_tag

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

Wijatmoko U. Prayitno wrote :
> Hi there,
> 
> Many distributions are set the "short_open_tag" to "off"
> (for example openSUSE). The following attachment are diff
> for "templates/main.php" which is still using
> "short open tag".
> 

Hello,

Committed as revision 748; many thanks for taking the time to report
this.

David.

[Postfixadmin-devel] short_open_tag

[Wijatmoko U. P. <ko...@sa...>]

Hi there,

Many distributions are set the "short_open_tag" to "off"
(for example openSUSE). The following attachment are diff
for "templates/main.php" which is still using
"short open tag".

--- postfixadmin-2.3-orig/templates/main.php
+++ postfixadmin-2.3/templates/main.php
@@ -13,12 +13,12 @@
       <td nowrap><a target="_top" href="create-mailbox.php"><?php print $PALANG['pMenu_create_mailbox']; ?></a></td>
       <td><?php print $PALANG['pMain_create_mailbox']; ?></td>
    </tr>
-<? if ($CONF['sendmail'] == "YES") { ?>
+<?php if ($CONF['sendmail'] == "YES") { ?>
    <tr>
       <td nowrap><a target="_top" href="sendmail.php"><?php print $PALANG['pMenu_sendmail']; ?></a></td>
       <td><?php print $PALANG['pMain_sendmail']; ?></td>
    </tr>
-<? } ?>
+<?php } ?>
    <tr>
       <td nowrap><a target="_top" href="password.php"><?php print $PALANG['pMenu_password']; ?></a></td>
       <td><?php print $PALANG['pMain_password']; ?></td>

[Postfixadmin-devel] Postfixadmin 2.4

[reg9009 <re...@ya...>]

Hi,

first of all, congratulations of getting Postfixadmin 2.3 out :)

As discussed, I'd like to propose the merge of the trunk and smarty
branch. I've tried to keep all changes in sync, and Postfixadmin smarty
is running well on different sites in production.

There should be little adjustment if any, as we kept most of the system.
There was just a bit of layout work. As I'm not that design guy, help in
the layout work is greatly appreciated.

I think the merge could be done in November, and I'm happy to help out
with any problems that are encountered to get the merge done as soon as
possible. Btw., tests have shown that PFA runs with smarty 3 out of the
box...

Regards,
Sebastian

Re: [Postfixadmin-devel] Smarty branch + 2.3 state ? Re: SF.net SVN: postfixadmin:[725] branches/postfixadmin-smarty/upgrade.php

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

Hello,

Am Sonntag, 18. Oktober 2009 schrieb David Goodwin:
> This changeset/patch/whatever hasn't been merged to trunk yet; I'd
>  like the smarty branch to mirror trunk (aside from the obvious
>  smarty bit) until 2.3 is released - then I've every intention of
>  merging the branch in and moving forward from there. We could merge
>  the Smarty stuff in now, but I'd rather get 2.3 released first - as
>  there are bound to be a few bugs/issues to resolve first.

ACK - the smarty branch should be merged to trunk after 2.3 release.

> (Sorry for not doing all that much work on PFA lately; I've been kept
> busy doing PHP training, and am unlikely to get much free time until
> after Christmas; perhaps I need to just bite the bullet and release
>  2.3 based on the current state of trunk now?)

AFAIK there are no critical bugs left, and we'll never be free of non-
critical bugs ;-)

Please test if setup.php/upgrade.php works on postgresql (I added some 
pgsql-only code to create triggers for the quota and quota2 table.)

If everything works, you can finally release 2.3!

Release ToDo-List:
- add release date/version and SVN revision to changelog
- update version in functions.inc.php
- create a tag in SVN. Please do this in tags/, not in branches/


Regards,

Christian Boltz
-- 
Benutzerfreundlichkeit
Der Benutzer hat zum Admin freundlich zu sein. [Thorsten Fenk]

Re: [Postfixadmin-devel] Regarding Bug #2835877

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

Hello,

Am Dienstag, 20. Oktober 2009 schrieb Stevan Bajić:
> > (Are you not able to re-open the ticket?)
> 
> No. I have no admin right in the Postfix.Admin bug tracker. And you
>  closed the bug for future comments so I am even not able to post any
>  additional text into the bug.

That's a feature (IMHO: mis-feature) that sourceforge introduced some 
time ago. There's a checkbox "Close comment posting" that appears when 
marking a bug as closed, which is unfortunately checked by default.
I just unchecked it for this specific bugreport.

@David: Please _always_ uncheck the "Close comment posting" box when 
marking a bug as closed.

@Stevan: From now on, you have posting permissions on postfixadmin-
devel, but you won't receive replies (unless you are in CC [1]).


Regards,

Christian Boltz

[1] depends on who is sending the answer: David usually CCs the sender,
    I usually send the mail only to the mailinglist.
-- 
> (bezieht sich nicht unbedingt auf Laptops, die Liste ist 
> aber etwas ruhig)
Cool, das wäre eigentlich ein Fall für die .signature.
[> Kevin Pfeiffer und Stefan Seyfried in suse-laptop]

Re: [Postfixadmin-devel] Regarding Bug #2835877

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>
> Hallo David,
> 
> 
>> The code above lives in a function called find_recipient() (or
>> something similar). BEFORE this is called we convert the SMTP
>> recipient (e.g. foo#bar@autoreply.whatever) to it's real email addres
>> (e.g. foo@bar). Hence I'm confused as to why you still insist it's
>> wrong. Can you please read the code which calls that function and
>> confirm I'm right - perhaps I've totally misread it?
>>
> I have attached the patch I would use to patch Postfix.Admin trunk for fixing that issue regarding alias lookups.
> 
> I was so free to change the email addresses in the header to not be directly addressable.
> 


Hi Stevan

Thanks for the patch, it was against the Smarty branch which didn't
cleanly apply; but I think I've translated it properly. I've merged the
change into svn and also updated the ticket on sf.net; thanks for having
the patience to explain to me why you are/were right :)

thanks
David.
- --
David Goodwin

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrewAoACgkQ/ISo3RF5V6YCowCg9+9EykFyjUea7jhiIPyKtiPF
MRsAoNIXLIl7i+XO9ieHjdy3gZ3LbdN5
=ADQ7
-----END PGP SIGNATURE-----

Re: [Postfixadmin-devel] Regarding Bug #2835877

[Stevan B. <st...@ba...>]

On Tue, 20 Oct 2009 20:27:27 +0100
David Goodwin <da...@co...> wrote:

> > I checked out trunk and see this here:
> > -------------------
> > # Recipient has vacation
> >         if ($rv == 1) {
> >                 $realemail = $email;
> >                 $logger->debug("Found '\$email'\ has vacation active");
> >         } else {
> >                 my $vemail = $email;
> >                 $vemail =~ s/\@/#/g;
> >                 $logger->debug("Looking for alias records that \'$email\' resolves to with vacation turned on");
> >                 $query = qq{SELECT goto FROM alias WHERE address=? AND (goto LIKE ? OR goto LIKE ? OR goto LIKE ?)};
> >                 $stm = $dbh->prepare($query) or panic_prepare($query);
> >                 $stm->execute($email,"$email,%","%,$email","%,$email,%") or panic_execute($query,"address='$email'");
> >                 $rv = $stm->rows;
> > -------------------
> > 
> > This is not going to work. This part here:
> > -------------------
> > $stm->execute($email,"$email,%","%,$email","%,$email,%") or panic_execute($query,"address='$email'");
> > -------------------
> > 
> > Is going to be executed as:
> > -------------------
> > SELECT goto FROM alias WHERE address='da...@co...' AND (goto LIKE 'da...@co...,%' OR goto LIKE '%,da...@co...' OR goto LIKE '%,da...@co...,%')
> > -------------------
> > 
> 
> Hi,
> 
Hallo David,


> The code above lives in a function called find_recipient() (or
> something similar). BEFORE this is called we convert the SMTP
> recipient (e.g. foo#bar@autoreply.whatever) to it's real email addres
> (e.g. foo@bar). Hence I'm confused as to why you still insist it's
> wrong. Can you please read the code which calls that function and
> confirm I'm right - perhaps I've totally misread it?
> 
I have attached the patch I would use to patch Postfix.Admin trunk for fixing that issue regarding alias lookups.

I was so free to change the email addresses in the header to not be directly addressable.


> Thanks
>
Kind Regards from Switzerland


> David.
> 
Stevan Bajic

Re: [Postfixadmin-devel] Regarding Bug #2835877

[Stevan B. <st...@ba...>]

On Tue, 20 Oct 2009 20:27:27 +0100
David Goodwin <da...@co...> wrote:

> > I checked out trunk and see this here:
> > -------------------
> > # Recipient has vacation
> >         if ($rv == 1) {
> >                 $realemail = $email;
> >                 $logger->debug("Found '\$email'\ has vacation active");
> >         } else {
> >                 my $vemail = $email;
> >                 $vemail =~ s/\@/#/g;
> >                 $logger->debug("Looking for alias records that \'$email\' resolves to with vacation turned on");
> >                 $query = qq{SELECT goto FROM alias WHERE address=? AND (goto LIKE ? OR goto LIKE ? OR goto LIKE ?)};
> >                 $stm = $dbh->prepare($query) or panic_prepare($query);
> >                 $stm->execute($email,"$email,%","%,$email","%,$email,%") or panic_execute($query,"address='$email'");
> >                 $rv = $stm->rows;
> > -------------------
> > 
> > This is not going to work. This part here:
> > -------------------
> > $stm->execute($email,"$email,%","%,$email","%,$email,%") or panic_execute($query,"address='$email'");
> > -------------------
> > 
> > Is going to be executed as:
> > -------------------
> > SELECT goto FROM alias WHERE address='da...@co...' AND (goto LIKE 'da...@co...,%' OR goto LIKE '%,da...@co...' OR goto LIKE '%,da...@co...,%')
> > -------------------
> > 
> 
> Hi,
> 
Hallo David,


> The code above lives in a function called find_recipient() (or
> something similar).
>
Correct.


> BEFORE this is called we convert the SMTP
> recipient (e.g. foo#bar@autoreply.whatever) to it's real email addres
> (e.g. foo@bar).
>
Correct.


> Hence I'm confused as to why you still insist it's
> wrong. Can you please read the code which calls that function and
> confirm I'm right - perhaps I've totally misread it?
> 
You miss the point how the content of the alias table is. Lets look at a normal entry (I removed the created and modified column to make it easier for reading):
+------------------+------------------+-------------+
| address          | goto             | domain      |
+------------------+------------------+-------------+
| @example.com     | us...@ex... | example.com |
| us...@ex... | us...@ex... | example.com |
+------------------+------------------+-------------+


Okay. Now "us...@ex..." is going to use Postfix.Admin and add vacation for his account. Beside that the table "vacation" is going to be updated the table "alias" is as well updated and looks like this:
+------------------+--------------------------------------------------+-------------+
| address          | goto                                             | domain      |
+------------------+--------------------------------------------------+-------------+
| @example.com     | us...@ex...                                 | example.com |
| us...@ex... | us...@ex...,user#example.com@vacationdomain | example.com |
+------------------+--------------------------------------------------+-------------+


So lets take a look in the sub called "find_real_address". The purpose of that function is to find users having vacation active. Right? And the purpose of that function is to try hard to find if an alias that got a mail (and aliases do not have "@vacationdomain" in their goto field) in fact has a real address that has vacation active. Right?

So this SQL clause here:
SELECT goto FROM alias WHERE address='us...@ex...' AND (goto LIKE 'us...@ex...,%' OR goto LIKE '%,us...@ex...' OR goto LIKE '%,us...@ex...,%')

Is wrong. It does not honor the vacation goto format. All we want is that the SQL lookup for an alias pointing to an real address (or another alias wich get's then again looked up by the vacation Perl script till it reaches a real address) should only match if that address has in fact vacation active. If goto does not contain the vacation format the the SQL clause should NOT match. That's what I am telling.

Or let's take it the other way around. If you have right then the whole code doing that crazy alias resolving is useless since there is enough to just check for address=$email (wich would be wrong).


The right SQL clause is:
SELECT goto FROM alias WHERE address='us...@ex...' AND (goto LIKE 'user#example.com@%' OR goto LIKE '%,user#example.com@%')


The absolute best (catching all possible cases) SQL clause would be:
SELECT goto FROM alias WHERE address='us...@ex...' AND (goto LIKE 'user#example.com@vacationdomain,%' OR goto LIKE '%,user#example.com@vacationdomain' OR goto LIKE '%,user#example.com@vacationdomain,%' OR goto='user#example.com@vacationdomain')


In Perl code that would be (just the significant lines):
$query = qq{SELECT goto FROM alias WHERE address=? AND (goto LIKE ? OR goto LIKE ? OR goto LIKE ? OR goto=?)};
$stm->execute($email,"$vemail@$vacation_domain,%","%,$vemail@$vacation_domain","%,$vemail@$vacation_domain,%","$vemail@$vacation_domain") or panic_execute($query,"address='$email'");


Do you now understand what I mean?



> Thanks
>
Kind Regards from Switzerland


> David.
> 
Stevan Bajic

Re: [Postfixadmin-devel] Regarding Bug #2835877

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

> I checked out trunk and see this here:
> -------------------
> # Recipient has vacation
>         if ($rv == 1) {
>                 $realemail = $email;
>                 $logger->debug("Found '\$email'\ has vacation active");
>         } else {
>                 my $vemail = $email;
>                 $vemail =~ s/\@/#/g;
>                 $logger->debug("Looking for alias records that \'$email\' resolves to with vacation turned on");
>                 $query = qq{SELECT goto FROM alias WHERE address=? AND (goto LIKE ? OR goto LIKE ? OR goto LIKE ?)};
>                 $stm = $dbh->prepare($query) or panic_prepare($query);
>                 $stm->execute($email,"$email,%","%,$email","%,$email,%") or panic_execute($query,"address='$email'");
>                 $rv = $stm->rows;
> -------------------
> 
> This is not going to work. This part here:
> -------------------
> $stm->execute($email,"$email,%","%,$email","%,$email,%") or panic_execute($query,"address='$email'");
> -------------------
> 
> Is going to be executed as:
> -------------------
> SELECT goto FROM alias WHERE address='da...@co...' AND (goto LIKE 'da...@co...,%' OR goto LIKE '%,da...@co...' OR goto LIKE '%,da...@co...,%')
> -------------------
> 

Hi,

The code above lives in a function called find_recipient() (or
something similar). BEFORE this is called we convert the SMTP
recipient (e.g. foo#bar@autoreply.whatever) to it's real email addres
(e.g. foo@bar). Hence I'm confused as to why you still insist it's
wrong. Can you please read the code which calls that function and
confirm I'm right - perhaps I've totally misread it?

Thanks
David.

Re: [Postfixadmin-devel] Regarding Bug #2835877

[Stevan B. <st...@ba...>]

On Tue, 20 Oct 2009 13:55:41 +0100
David Goodwin <da...@co...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stevan Bajic wrote:
> > Message body follows:
> > 
> > Hallo Gingerdog
> > 
> 
> 
> Hello!
> 
Hallo David


> I think there are two bugs - one which is related to the SQL statement -
> which I think is fixed. Are you able to confirm this with what's in trunk??
> 
I checked out trunk and see this here:
-------------------
# Recipient has vacation
        if ($rv == 1) {
                $realemail = $email;
                $logger->debug("Found '\$email'\ has vacation active");
        } else {
                my $vemail = $email;
                $vemail =~ s/\@/#/g;
                $logger->debug("Looking for alias records that \'$email\' resolves to with vacation turned on");
                $query = qq{SELECT goto FROM alias WHERE address=? AND (goto LIKE ? OR goto LIKE ? OR goto LIKE ?)};
                $stm = $dbh->prepare($query) or panic_prepare($query);
                $stm->execute($email,"$email,%","%,$email","%,$email,%") or panic_execute($query,"address='$email'");
                $rv = $stm->rows;
-------------------

This is not going to work. This part here:
-------------------
$stm->execute($email,"$email,%","%,$email","%,$email,%") or panic_execute($query,"address='$email'");
-------------------

Is going to be executed as:
-------------------
SELECT goto FROM alias WHERE address='da...@co...' AND (goto LIKE 'da...@co...,%' OR goto LIKE '%,da...@co...' OR goto LIKE '%,da...@co...,%')
-------------------

And will return a record even if 'da...@co...' does NOT have vacation active. So the patch I posted in the SF Bug Tracker has from my viewpoint still the better SQL clause for finding users in the alias table having vacation active.

Should I go on and modify the vacation script from trunk and send you a patch that fixes the issue?


> The second bug is what I thought I Was replying to - namely there is no
> need to mangle the email address passed into check_recipient() as it's
> already been converted from the vacation goto format
> foo#bar.com@autoreply.whatever to fo...@ba...
> 
> Does that help?
> 
> 
> (Are you not able to re-open the ticket?)
> 
> 
> Thanks
>
Kind Regards from Switzerland


> David.
> 
Stevan Bajic

> 
> > You write that you THINK that the patch is not needed. But I
> > KNOW that the patch is needed because without the patch
> > vacation is not working on my setup.
> > 
> > Vacation it self is working but as soon it hit's that wrong
> > SQL clause which is already in 2.3_rc7 then I get errors.
> > Please go ahead and try it yourself. You will see that you
> > will get MySQL and PostgreSQL barking about wrongly formated
> > SQL clause.
> > 
> > I get errors like this here:
> > ug 11 11:24:47 nyx postfix/pipe[15542]: EEA07A3C162:
> > to=<viktor#laf...@au...net.local>,
> > orig_to=<vi...@la...>, relay=vacation, delay=0.52,
> > delays=0.13/0/0/0.38, dsn=5.3.0, status=bounced (Command
> > died with status 255: "/usr/bin/perl". Command output:
> > DBD::mysql::st execute failed: You have an error in your SQL
> > syntax; check the manual that corresponds to your MySQL
> > server version for the right syntax to use near '% OR goto
> > LIKE %,'vi...@la...' OR goto LIKE
> > %,'vi...@la...',%)' at line 1 at
> > /var/spool/vacation/vacation-postfixadmin-2.3_rc7.pl line
> > 332, <STDIN> line 45. DBD::mysql::st execute failed: You
> > have an error in your SQL syntax; check the manual that
> > corresponds to your MySQL server version for the right
> > syntax to use near '% OR goto LIKE %,'vi...@la...' OR
> > goto LIKE %,'vi...@la...',%)' at line 1 at
> > /var/spool/vacation/vacation-postfixadmin-2.3_rc7.pl line
> > 332, <STDIN> line 45. )
> > 
> > Jul 26 22:33:02 nyx postfix/pipe[12772]: DFE4BA3C160:
> > to=<rog...@me...@autoreply.vunet.local>,
> > relay=vacation, delay=0.57, delays=0.12/0.01/0/0.44,
> > dsn=5.3.0, status=bounced (Command died with status 255:
> > "/usr/bin/perl". Command output: DBD::mysql::st execute
> > failed: You have an error in your SQL syntax; check the
> > manual that corresponds to your MySQL server version for the
> > right syntax to use near '% OR goto LIKE
> > %,'rog...@me...' OR goto LIKE
> > %,'roger.eckerlin@med' at line 1 at
> > /var/spool/vacation/vacation-postfixadmin-2.3_rc7.pl line
> > 332, <STDIN> line 40. DBD::mysql::st execute failed: You
> > have an error in your SQL syntax; check the manual that
> > corresponds to your MySQL server version for the right
> > syntax to use near '% OR goto LIKE
> > %,'rog...@me...' OR goto LIKE
> > %,'roger.eckerlin@med' at line 1 at
> > /var/spool/vacation/vacation-postfixadmin-2.3_rc7.pl line
> > 332, <STDIN> line 40. )
> > 
> > So the SQL clause is definitely wrong.
> > 
> > Could you reopen #2835877 so that we can continue the
> > discussion there?
> > 
> > 
> > Kind Regards from Switzerland
> > 
> > Stevan Bajic
> > 
> > --
> > This message has been sent to you, a registered SourceForge.net user,
> > by another site user, through the SourceForge.net site.  This message
> > has been delivered to your SourceForge.net mail alias.  You may reply
> > to this message using the "Reply" feature of your email client, or
> > using the messaging facility of SourceForge.net at:
> > https://sourceforge.net/sendmessage.php?touser=2515232
> > 
> 
> 
> - --
> David Goodwin
> 
> [ david at codepoets dot co dot uk ]
> [ http://www.codepoets.co.uk       ]
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkrds00ACgkQ/ISo3RF5V6awZwCg1Q0dqfEWpgtVUJvmqnxHlpFz
> 7pgAmQFT7ScS+5ILeQw4dpa5rTrxEAEs
> =lm9J
> -----END PGP SIGNATURE-----
> 

Re: [Postfixadmin-devel] Regarding Bug #2835877

[Stevan B. <st...@ba...>]

On Tue, 20 Oct 2009 13:55:41 +0100
David Goodwin <da...@co...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stevan Bajic wrote:
> > Message body follows:
> > 
> > Hallo Gingerdog
> > 
> 
> 
> Hello!
> 
Hello David


> I think there are two bugs - one which is related to the SQL statement -
> which I think is fixed. Are you able to confirm this with what's in trunk??
> 
I have to check. Will inform you as soon as I find time to checkout trunk.


> The second bug is what I thought I Was replying to - namely there is no
> need to mangle the email address passed into check_recipient() as it's
> already been converted from the vacation goto format
> foo#bar.com@autoreply.whatever to fo...@ba...
> 
Yes. You are right about that. But the only way to find out by looking at the alias table if an user has vacation active or not is by looking if the goto field has the vacation format. Assuming your own personal vacation domain is "postfixadmin.local" then one needs to craft the SQL clause to be like this here:

SELECT goto FROM alias WHERE address='da...@co...' AND (goto LIKE 'david#codepoets.co.uk@%' OR goto LIKE '%,david#codepoets.co.uk@%')

The vacation domain "postfixadmin.local" is in fact not even needed but without replacing the "@" sign with "#" one is not able (by only looking at the alias table) to find out if the user "da...@co..." has vacation active or not.

And since multi values inside the goto field are separated by a simple "," checking for 'david#codepoets.co.uk@%' or '%,david#codepoets.co.uk@%' is enough to find even the wildest combinations in the goto field:
da...@co...,dav...@gm...,david#codepoets.co.uk@postfixadmin.local
da...@co...,david#codepoets.co.uk@postfixadmin.local,dav...@gm...
dav...@gm...,david#codepoets.co.uk@postfixadmin.local,da...@co...
etc.


> Does that help?
> 
I hope I could make clear why the "@" character needs to be replaced by "#" for the SQL clause.


> (Are you not able to re-open the ticket?)
> 
No. I have no admin right in the Postfix.Admin bug tracker. And you closed the bug for future comments so I am even not able to post any additional text into the bug.


> 
> Thanks
>
Kind Regards from Switzerland


> David.
> 
Stevan Bajić


> 
> > You write that you THINK that the patch is not needed. But I
> > KNOW that the patch is needed because without the patch
> > vacation is not working on my setup.
> > 
> > Vacation it self is working but as soon it hit's that wrong
> > SQL clause which is already in 2.3_rc7 then I get errors.
> > Please go ahead and try it yourself. You will see that you
> > will get MySQL and PostgreSQL barking about wrongly formated
> > SQL clause.
> > 
> > I get errors like this here:
> > ug 11 11:24:47 nyx postfix/pipe[15542]: EEA07A3C162:
> > to=<viktor#laf...@au...net.local>,
> > orig_to=<vi...@la...>, relay=vacation, delay=0.52,
> > delays=0.13/0/0/0.38, dsn=5.3.0, status=bounced (Command
> > died with status 255: "/usr/bin/perl". Command output:
> > DBD::mysql::st execute failed: You have an error in your SQL
> > syntax; check the manual that corresponds to your MySQL
> > server version for the right syntax to use near '% OR goto
> > LIKE %,'vi...@la...' OR goto LIKE
> > %,'vi...@la...',%)' at line 1 at
> > /var/spool/vacation/vacation-postfixadmin-2.3_rc7.pl line
> > 332, <STDIN> line 45. DBD::mysql::st execute failed: You
> > have an error in your SQL syntax; check the manual that
> > corresponds to your MySQL server version for the right
> > syntax to use near '% OR goto LIKE %,'vi...@la...' OR
> > goto LIKE %,'vi...@la...',%)' at line 1 at
> > /var/spool/vacation/vacation-postfixadmin-2.3_rc7.pl line
> > 332, <STDIN> line 45. )
> > 
> > Jul 26 22:33:02 nyx postfix/pipe[12772]: DFE4BA3C160:
> > to=<rog...@me...@autoreply.vunet.local>,
> > relay=vacation, delay=0.57, delays=0.12/0.01/0/0.44,
> > dsn=5.3.0, status=bounced (Command died with status 255:
> > "/usr/bin/perl". Command output: DBD::mysql::st execute
> > failed: You have an error in your SQL syntax; check the
> > manual that corresponds to your MySQL server version for the
> > right syntax to use near '% OR goto LIKE
> > %,'rog...@me...' OR goto LIKE
> > %,'roger.eckerlin@med' at line 1 at
> > /var/spool/vacation/vacation-postfixadmin-2.3_rc7.pl line
> > 332, <STDIN> line 40. DBD::mysql::st execute failed: You
> > have an error in your SQL syntax; check the manual that
> > corresponds to your MySQL server version for the right
> > syntax to use near '% OR goto LIKE
> > %,'rog...@me...' OR goto LIKE
> > %,'roger.eckerlin@med' at line 1 at
> > /var/spool/vacation/vacation-postfixadmin-2.3_rc7.pl line
> > 332, <STDIN> line 40. )
> > 
> > So the SQL clause is definitely wrong.
> > 
> > Could you reopen #2835877 so that we can continue the
> > discussion there?
> > 
> > 
> > Kind Regards from Switzerland
> > 
> > Stevan Bajic
> > 
> > --
> > This message has been sent to you, a registered SourceForge.net user,
> > by another site user, through the SourceForge.net site.  This message
> > has been delivered to your SourceForge.net mail alias.  You may reply
> > to this message using the "Reply" feature of your email client, or
> > using the messaging facility of SourceForge.net at:
> > https://sourceforge.net/sendmessage.php?touser=2515232
> > 
> 
> 
> - --
> David Goodwin
> 
> [ david at codepoets dot co dot uk ]
> [ http://www.codepoets.co.uk       ]
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkrds00ACgkQ/ISo3RF5V6awZwCg1Q0dqfEWpgtVUJvmqnxHlpFz
> 7pgAmQFT7ScS+5ILeQw4dpa5rTrxEAEs
> =lm9J
> -----END PGP SIGNATURE-----
> 

Re: [Postfixadmin-devel] Regarding Bug #2835877

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stevan Bajic wrote:
> Message body follows:
> 
> Hallo Gingerdog
> 


Hello!

I think there are two bugs - one which is related to the SQL statement -
which I think is fixed. Are you able to confirm this with what's in trunk??

The second bug is what I thought I Was replying to - namely there is no
need to mangle the email address passed into check_recipient() as it's
already been converted from the vacation goto format
foo#bar.com@autoreply.whatever to fo...@ba...

Does that help?


(Are you not able to re-open the ticket?)


Thanks
David.


> You write that you THINK that the patch is not needed. But I
> KNOW that the patch is needed because without the patch
> vacation is not working on my setup.
> 
> Vacation it self is working but as soon it hit's that wrong
> SQL clause which is already in 2.3_rc7 then I get errors.
> Please go ahead and try it yourself. You will see that you
> will get MySQL and PostgreSQL barking about wrongly formated
> SQL clause.
> 
> I get errors like this here:
> ug 11 11:24:47 nyx postfix/pipe[15542]: EEA07A3C162:
> to=<viktor#laf...@au...net.local>,
> orig_to=<vi...@la...>, relay=vacation, delay=0.52,
> delays=0.13/0/0/0.38, dsn=5.3.0, status=bounced (Command
> died with status 255: "/usr/bin/perl". Command output:
> DBD::mysql::st execute failed: You have an error in your SQL
> syntax; check the manual that corresponds to your MySQL
> server version for the right syntax to use near '% OR goto
> LIKE %,'vi...@la...' OR goto LIKE
> %,'vi...@la...',%)' at line 1 at
> /var/spool/vacation/vacation-postfixadmin-2.3_rc7.pl line
> 332, <STDIN> line 45. DBD::mysql::st execute failed: You
> have an error in your SQL syntax; check the manual that
> corresponds to your MySQL server version for the right
> syntax to use near '% OR goto LIKE %,'vi...@la...' OR
> goto LIKE %,'vi...@la...',%)' at line 1 at
> /var/spool/vacation/vacation-postfixadmin-2.3_rc7.pl line
> 332, <STDIN> line 45. )
> 
> Jul 26 22:33:02 nyx postfix/pipe[12772]: DFE4BA3C160:
> to=<rog...@me...@autoreply.vunet.local>,
> relay=vacation, delay=0.57, delays=0.12/0.01/0/0.44,
> dsn=5.3.0, status=bounced (Command died with status 255:
> "/usr/bin/perl". Command output: DBD::mysql::st execute
> failed: You have an error in your SQL syntax; check the
> manual that corresponds to your MySQL server version for the
> right syntax to use near '% OR goto LIKE
> %,'rog...@me...' OR goto LIKE
> %,'roger.eckerlin@med' at line 1 at
> /var/spool/vacation/vacation-postfixadmin-2.3_rc7.pl line
> 332, <STDIN> line 40. DBD::mysql::st execute failed: You
> have an error in your SQL syntax; check the manual that
> corresponds to your MySQL server version for the right
> syntax to use near '% OR goto LIKE
> %,'rog...@me...' OR goto LIKE
> %,'roger.eckerlin@med' at line 1 at
> /var/spool/vacation/vacation-postfixadmin-2.3_rc7.pl line
> 332, <STDIN> line 40. )
> 
> So the SQL clause is definitely wrong.
> 
> Could you reopen #2835877 so that we can continue the
> discussion there?
> 
> 
> Kind Regards from Switzerland
> 
> Stevan Bajic
> 
> --
> This message has been sent to you, a registered SourceForge.net user,
> by another site user, through the SourceForge.net site.  This message
> has been delivered to your SourceForge.net mail alias.  You may reply
> to this message using the "Reply" feature of your email client, or
> using the messaging facility of SourceForge.net at:
> https://sourceforge.net/sendmessage.php?touser=2515232
> 


- --
David Goodwin

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrds00ACgkQ/ISo3RF5V6awZwCg1Q0dqfEWpgtVUJvmqnxHlpFz
7pgAmQFT7ScS+5ILeQw4dpa5rTrxEAEs
=lm9J
-----END PGP SIGNATURE-----

Re: [Postfixadmin-devel] Patch posted for dovecot v1.2 quota viewing

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

Hello,

Am Sonntag, 4. Oktober 2009 schrieb Christian Boltz:
> Am Sonntag, 4. Oktober 2009 schrieb Warren Volz:
> > On Sep 27, 2009, at 4:25 PM, Christian Boltz wrote:
> > > Am Samstag, 26. September 2009 schrieb Warren Volz:

> I just tested with an empty quota table on mysql commandline - the
> result contains a NULL value for the 'current' column. So it should
>  work to use
> 
>     WHERE [...] AND  (  $table_quota.path='quota/storage' OR
>                         $table_quota.path IS NULL  )
> 
> (I didn't test this in postfixadmin, and I also don't know if it
>  works with postgresql...)

I commited your patch to SVN r730, including the modified query quoted 
above. I tested with empty quota table, but more testing won't hurt of 
course.

@David: Please test if upgrade.php works with PostgreSQL.
Also test list-virtual with $CONF['used_quotas'] = 'YES' (with both 
$CONF['new_quota_table'] = 'NO' and 'YES') - you should still see all 
mailboxes in list-virtual even if your quota table is empty.

> > > Another issue is how to handle the different table formats in
> > > dovecot 1.1 and 1.2. IMHO we need two(!) quota tables:
> > > - one in dovecot 1.1 format, named "quota" to stay compatible
> > > with the current instructions/documentation (note: the quota
> > > table is not auto-created yet)
> > > - another one (maybe "quota2" or "quota12") in dovecot 1.2 format

upgrade.php now creates those tables (quota and quota2)

> > > Regarding PostgreSQL: If I get http://wiki.dovecot.org/Quota/Dict
> > > right, dovecot needs a trigger for updating the quota.
> >
> > Yeah, Postgres doesn't support ON DUPLICATE KEY UPDATE (which has
> > never really been an issue) thus the need for the trigger. I'm the
> >  one that added the v1.1 trigger to the dovecot wiki. Of course, if
> >  you add support for v1.2 there will need to be two triggers in the
> >  setup file which goes back to the need to check the version of
> >  dovecot...
> 
> As with the tables - it shouldn't hurt to create both triggers ;-)

Also done in current upgrade.php


Regards,

Christian Boltz
-- 
> > dank meiner Versionitis verwende ich längst die 10.1 ;-)
> Das Spielchen habe ich auch mitgemacht - von 6.0 bis 9.3. Nu reichts,
> man soll schließlich arbeiten mit dem Ding.
Zum Arbeiten braucht es kein unsupportetes Supplementary!
[>>Christian Boltz, > Christian Lepper & Marcus Meissner in suse-laptop]

[Postfixadmin-devel] Fwd: Re: SF.net SVN: postfixadmin:[726] branches/postfixadmin-smarty/upgrade.php

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

Hello,

please never post to the postfixadmin-svn mailinglist (except by running 
"svn commit" of course ;-)

Discussion about svn commits should always go to the -devel list.

David, Sebastian - I'm forwarding the messages to postfixadmin-devel.



----------  Weitergeleitete Nachricht  ----------

Betreff: Re: SF.net SVN: postfixadmin:[726]	branches/postfixadmin-smarty/upgrade.php
Datum: Sonntag, 18. Oktober 2009 14:35
Von: David Goodwin <da...@co...>
An: Seb...@us...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Seb...@us... wrote:
> Revision: 726
>           http://postfixadmin.svn.sourceforge.net/postfixadmin/?rev=726&view=rev
> Author:   Sebastian2009
> Date:     2009-10-18 12:00:48 +0000 (Sun, 18 Oct 2009)
> 
> Log Message:
> -----------
> - forgot to raise database target version...
> 
> Modified Paths:
> --------------
>     branches/postfixadmin-smarty/upgrade.php
> 
> Modified: branches/postfixadmin-smarty/upgrade.php
> ===================================================================
> --- branches/postfixadmin-smarty/upgrade.php	2009-10-18 11:49:42 UTC (rev 725)
> +++ branches/postfixadmin-smarty/upgrade.php	2009-10-18 12:00:48 UTC (rev 726)
> @@ -1096,3 +1096,4 @@
>         db_query_parsed("ALTER TABLE $table_vacation add activeuntil datetime default NULL");
>      }
>  }
> +
> 


Your commit message does not match the patch...

David.

- --
David Goodwin

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrbC38ACgkQ/ISo3RF5V6YqDQCg4h/Ekr+u44u7vuV3D2S8YOlN
QPoAn1G2Sx2/OzA1/JHDZ2seJJSILamc
=5+DG
-----END PGP SIGNATURE-----


-------------------------------------------------------



----------  Weitergeleitete Nachricht  ----------

Betreff: Re: SF.net SVN: postfixadmin:[726]	branches/postfixadmin-smarty/upgrade.php
Datum: Sonntag, 18. Oktober 2009 14:44
Von: reg9009 <re...@ya...>
An: David Goodwin <da...@co...>

David Goodwin schrieb:
> Seb...@us... wrote:
> > Revision: 726
> >          
> http://postfixadmin.svn.sourceforge.net/postfixadmin/?rev=726&view=rev
> > Author:   Sebastian2009
> > Date:     2009-10-18 12:00:48 +0000 (Sun, 18 Oct 2009)
>
> > Log Message:
> > -----------
> > - forgot to raise database target version...
>
> > Modified Paths:
> > --------------
> >     branches/postfixadmin-smarty/upgrade.php
>
> > Modified: branches/postfixadmin-smarty/upgrade.php
> > ===================================================================
> > --- branches/postfixadmin-smarty/upgrade.php    2009-10-18 11:49:42
> UTC (rev 725)
> > +++ branches/postfixadmin-smarty/upgrade.php    2009-10-18 12:00:48
> UTC (rev 726)
> > @@ -1096,3 +1096,4 @@
> >         db_query_parsed("ALTER TABLE $table_vacation add activeuntil
> datetime default NULL");
> >      }
> >  }
> > +
>
>
>
> Your commit message does not match the patch...
>
> David.
>
Actually now I understood how upgrade.php works. It takes the revision
of subversion to determine if upgrade is needed. I will update my commit.

The vacation patch is already incorporated into the smarty branch.

The only line that changed is:

my $query = qq{SELECT email FROM vacation WHERE email=? and
active=$db_true and activefrom <= NOW() and activeuntil >= NOW()};

Regards,
Sebastian


-------------------------------------------------------


Regards,

Christian Boltz
-- 
   175: NT-Admin
          Turnschuhe, Schweissfüsse
          Weiß, wo der Computer angeht und daß man Probleme durch
          Neustart, Neuinstallation oder Neubelegung eines 4000-DM-
          Kurses in Unterschleißheim lösen kann. (Anders Henke)

[Postfixadmin-devel] Smarty branch + 2.3 state ? Re: SF.net SVN: postfixadmin:[725] branches/postfixadmin-smarty/upgrade.php

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

This changeset/patch/whatever hasn't been merged to trunk yet; I'd like
the smarty branch to mirror trunk (aside from the obvious smarty bit)
until 2.3 is released - then I've every intention of merging the branch
in and moving forward from there. We could merge the Smarty stuff in
now, but I'd rather get 2.3 released first - as there are bound to be a
few bugs/issues to resolve first.

Where is the patch to vacation.pl to enable it to use these new fields?

(*Wondering if I've missed an email or something*)


(Sorry for not doing all that much work on PFA lately; I've been kept
busy doing PHP training, and am unlikely to get much free time until
after Christmas; perhaps I need to just bite the bullet and release 2.3
based on the current state of trunk now?)


thanks
David


Seb...@us... wrote:
> Revision: 725
>           http://postfixadmin.svn.sourceforge.net/postfixadmin/?rev=725&view=rev
> Author:   Sebastian2009
> Date:     2009-10-18 11:49:42 +0000 (Sun, 18 Oct 2009)
> 
> Log Message:
> -----------
> - modified upgrade.php to add two fields needed for new vacation.pl
>   It is now possible to set vacation notification for a specific time frame.
>   Only works with MySQL. TODO: add fields for pgSQL as well!
> 
> Modified Paths:
> --------------
>     branches/postfixadmin-smarty/upgrade.php
> 
> Modified: branches/postfixadmin-smarty/upgrade.php
> ===================================================================
> --- branches/postfixadmin-smarty/upgrade.php	2009-10-08 08:01:54 UTC (rev 724)
> +++ branches/postfixadmin-smarty/upgrade.php	2009-10-18 11:49:42 UTC (rev 725)
> @@ -1086,3 +1086,13 @@
>      db_query_parsed(_add_index('mailbox', 'domain', 'domain'));
>      db_query_parsed(_add_index('alias',   'domain', 'domain'));
>  }
> +
> +function upgrade_730_mysql() {
> +    $table_vacation = table_by_key('vacation');
> +    if(!_mysql_field_exists($table_vacation, 'activefrom')) {
> +       db_query_parsed("ALTER TABLE $table_vacation add activefrom datetime default NULL");
> +    }
> +    if(!_mysql_field_exists($table_vacation, 'activeuntil')) {
> +       db_query_parsed("ALTER TABLE $table_vacation add activeuntil datetime default NULL");
> +    }
> +}
> 


- --
David Goodwin

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrbAwAACgkQ/ISo3RF5V6ahegCeJrOtfN7dU3tFq+1ew5W6+5zw
7AcAoI6E9fLxIau1XsH5jU9Tkz3irpyh
=ATJN
-----END PGP SIGNATURE-----

Re: [Postfixadmin-devel] Patch to make domain quota split between all users

[Warren V. <wa...@wa...>]

Alrighty, here is my first go round at a updated quota patch with the  
behavior we discussed. I've tested it, but not a whole lot yet. Let me  
know what you think. There are some areas that could use improvement  
in my mind, namely:

Is there really a difference between "unlimited" and "disabled"? Not  
that I can tell, and if that's the case should we just make it say  
"unlimited"?
get_domain_properties should really return a zero length list on  
failure. This would prevent an extra db query in edit-mailbox where  
I'm checking quotas.
A check is needed in edit-domain that looks for max mailbox size  
(maxquota) > domain quota.

-Warren

Re: [Postfixadmin-devel] adding columns to existing tables

[reg9009 <re...@ya...>]

Christian Boltz schrieb:
> Hello,
>
> Am Samstag, 10. Oktober 2009 schrieb reg9009:
>   
>> in order to provide the vacation replies depending on a time frame, I
>> need to add some fields to an existing table. Additionally, I need to
>> add some tables, as I want to add the possibility to control relaying
>> depending on IPs, etc. Unfortunately, I didn't get into upgrade.php
>>  that deep, especially to ensure PostgreSQL compatibility.
>>
>> Would it be ok to post the tables and changes and someone could help
>>  me adopt the upgrade.php script?
>>     
>
> Yes, of course. The best way is to post your ALTER TABLE statements 
> (hint: phpMyAdmin displays them after adding fields ;-)
>
> I can do the MySQL part of upgrade.php then, David can do the PostgreSQL 
> part.
>
> On the long(er) run, we should write a generic functions like 
> add_field($table, $fieldname, $type, $default, $null, $after_field) 
> (and/or a set of functions like add_bool_field, add_text_field etc.) 
> This way, we can just call the generic function and don't need to worry 
> about the MySQL vs. PostgreSQL details each time. (Having to add some 
> fields might be a good reason to write those function ;-)
>
>
> Regards,
>
> Christian Boltz
>   
Hi,

sorry for replying that late, a lot of stuff over here...

Ok, so here are the MySQL statements. The first two are needed to set a
timeframe for which vacation message should be activated. It can be used
safely in existing PFA trunk.
The other ones are to tell Postfix about some whitelist entries
depending on sender, helo, recipient, sender, IP, etc.


alter table vacation add column activefrom datetime default NULL;

alter table vacation add column activeuntil datetime default NULL;

CREATE TABLE `client_access` (
 `client` char(50) NOT NULL,
 `action` char(50) NOT NULL default 'REJECT',
 UNIQUE KEY `client` (`client`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `from_access` (
 `from_access` char(50) NOT NULL,
 `action` char(50) NOT NULL default 'REJECT',
 UNIQUE KEY `from_access` (`from_access`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `helo_access` (
 `helo` char(50) NOT NULL,
 `action` char(50) NOT NULL default 'REJECT',
 UNIQUE KEY `helo` (`helo`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `rcpt_access` (
 `rcpt` char(50) NOT NULL,
 `action` char(50) NOT NULL default 'REJECT',
 UNIQUE KEY `rcpt` (`rcpt`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `user_whitelist` (
 `recipient` char(50) NOT NULL,
 `action` char(2) NOT NULL default 'OK',
 UNIQUE KEY `recipient` (`recipient`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;



Regards,
Sebastian

Re: [Postfixadmin-devel] adding columns to existing tables

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

Hello,

Am Samstag, 10. Oktober 2009 schrieb reg9009:
> in order to provide the vacation replies depending on a time frame, I
> need to add some fields to an existing table. Additionally, I need to
> add some tables, as I want to add the possibility to control relaying
> depending on IPs, etc. Unfortunately, I didn't get into upgrade.php
>  that deep, especially to ensure PostgreSQL compatibility.
> 
> Would it be ok to post the tables and changes and someone could help
>  me adopt the upgrade.php script?

Yes, of course. The best way is to post your ALTER TABLE statements 
(hint: phpMyAdmin displays them after adding fields ;-)

I can do the MySQL part of upgrade.php then, David can do the PostgreSQL 
part.

On the long(er) run, we should write a generic functions like 
add_field($table, $fieldname, $type, $default, $null, $after_field) 
(and/or a set of functions like add_bool_field, add_text_field etc.) 
This way, we can just call the generic function and don't need to worry 
about the MySQL vs. PostgreSQL details each time. (Having to add some 
fields might be a good reason to write those function ;-)


Regards,

Christian Boltz
-- 
> CPU&-Register:  die Person (mit Kurzzeitgedaechnis)
Ich darf doch schwer bitten. Wenn ich morgens aufwache, brauche ich
nicht erst Aktenordner durchzulesen. Ich kann mich auch so erinnern.
[> David Haller und Bernd Brodesser in suse-linux]

[Postfixadmin-devel] adding columns to existing tables

[reg9009 <re...@ya...>]

Hi guys,

in order to provide the vacation replies depending on a time frame, I
need to add some fields to an existing table. Additionally, I need to
add some tables, as I want to add the possibility to control relaying
depending on IPs, etc. Unfortunately, I didn't get into upgrade.php that
deep, especially to ensure PostgreSQL compatibility.

Would it be ok to post the tables and changes and someone could help me
adopt the upgrade.php script?

Regards,
Sebastian

[Postfixadmin-devel] Feature Request of vacation.pl

[Claudio P. <cla...@at...>]

Hi to all,

I use Virtual vacation 4.0 with virtual domains on mysql. My problem is:
if i sent a mail to an alias (in example tes...@at...), i
recieve reply from the real address (te...@at...) and not from the
alias. This is a problem becouse who send the mail expect a reply from
the same address "to:".

A solution, personally can be the vacation.pl take the first alias from
the alias table of that user, with a command like this:

select address from alias where goto=$email limit 0,1;

But i don't know how to put that thing in the actual vacation.pl, my
perl know-how is not so good.

Anyone give me some help pls?

Can be a good thing to add a function wich permit to specify a from for
any mail user (fixed from), so the autoresponder always respond from that.

Cheers,

Claudio.

-- 
------------
Claudio Prono
Systems Development @ PSS Srl, Divisione Implementazione Sistemi
Via San Bernardino, 17 - 10137 Torino (TO) - IT
Tel +39-011.32.72.100  Fax +39-011.32.46.497
PGP Fingerprint: 75C2 4049 E23D 2FBF A65F  40DB EA5C 11AC C2B0 3647
Disclaimer: http://atpss.net/disclaimer
------------ 

Re: [Postfixadmin-devel] Patch posted for dovecot v1.2 quota viewing

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

Hello,

Am Sonntag, 4. Oktober 2009 schrieb Warren Volz:
> On Sep 27, 2009, at 4:25 PM, Christian Boltz wrote:
> > Am Samstag, 26. September 2009 schrieb Warren Volz:

> > I just wonder if we really need separate queries for
> > vacation_control_admin on/off or if we could just skip displaying
> > the vacation status (which the template already does anyway).
> > I think we should merge the queries and just skip displaying to
> > have easier readable code. (I did not do this now to avoid breaking
> > your patch.)
> 
> Yeah the if statements can get out of control really quick. I think
> your suggestion for not displaying the vacation status would be fine
> by me, but I wonder if there are users that want this. I don't see
> anything about it in the feature request list, but I might be missing
> something.

Maybe my text wasn't clear - I'll sum it up:
- the sql query should _always include_ the vacation status (this means
  to remove the queries and if statements not including the vacation 
  status)
- if vacation_control_admin is off, just don't display the vacation 
  status (the template already has this switch, no need for a change)

> > Dovecot quota in general seems to be a can of worms ;-) and the
> > table format change in dovecot 1.2 doesn't make things easier.
> 
> Yeah, it makes things a little more complicated for sure. I think the
> format change for v1.2 does make more sense though.

ACK

(I already wondered who invented the interesting[tm] 1.1 table layout, 
and what he had smoked ;-)

> > An idea how to fix the issue you described in your patch:
> >
> >    // WARNING: This query will fail if a user does not have a
> >    // 'quota/storage' row in the quota table. Not sure how to
> > handle // this now.
> >    [...] WHERE [...] AND $table_quota.path='quota/storage'
> >
> > If there's a list of fixed values dovecot uses, what about using
> >    [...] WHERE [...] AND $table_quota.path !='quota/OTHERVALUE'
> > (If dovecot has a big list of values it can store in the quota.path
> > field, this solution won't work.)
> > -> What other values are possible in the quota.path field?
> 
> The only other value (that I've seen) is 'quota/messages'. However, I
> don't think revising the query helps because if an admin using PFA
> decides not to send a "welcome" email to a new account, the user will
> have no entries in the quota table at all until a delivery occurs
>  (see
>  http://sourceforge.net/tracker/index.php?func=detail&aid=2794247&gro
> up_id=191583&atid=937964 ).

I just tested with an empty quota table on mysql commandline - the 
result contains a NULL value for the 'current' column. So it should work 
to use

    WHERE [...] AND  (  $table_quota.path='quota/storage' OR 
                        $table_quota.path IS NULL  )

(I didn't test this in postfixadmin, and I also don't know if it works 
with postgresql...)

> The v1.2 quota table doesn't have this
>  problem with the query because there is no need to have the quota
>  table in the WHERE part of the query.

ACK

> > Another issue is how to handle the different table formats in
> > dovecot 1.1 and 1.2. IMHO we need two(!) quota tables:
> > - one in dovecot 1.1 format, named "quota" to stay compatible with
> > the current instructions/documentation (note: the quota table is
> > not auto-created yet)
> > - another one (maybe "quota2" or "quota12") in dovecot 1.2 format
> 
> Hmm, if you ask me this is isn't the best solution because it breaks
> from what the dovecot wiki suggests thus making things more confusing
> for users. Also, it seems like setup could check the version of
> dovecot (dovecot --version) during install/upgrade and set the
>  correct configuration variable for the user. 

Nice idea, I'll consider a check in setup.php. But it needs to be error-
proof in case someone doesn't have dovecot installed etc.

>  Of course I guess maybe
>  the issue then is how to migrate the quota table for the user?
>  Really deleting and re-creating the quota table isn't a huge deal
>  except that dovecot will be forced to re-compute the quota for each
>  user as they get new mail. This would happen anyways when migrating
>  to the new version of Dovecot though.

This isn't as easy as it might look - at least I think so ;-)

setup.php/upgrade.php would need a way to change the table to v1.2 and 
in rare cases even back to v1.1. And of course it would need to know if 
you just changed the dovecot version (version would have to be stored 
somewhere), and it would also mean you have to run setup.php if you 
upgrade dovecot. IMHO that's not nice...

I'd like to keep all database modifications in setup.php/upgrade.php 
independent of some $CONF setting for various reasons. Just creating 
both tables in parallel (with one of them unused) is much easier, and 
one unused table won't hurt.

Oh, and even if setup.php would switch the table format, you'd still 
need different queries because of the different table format. I'd say 
you can also include a different table name then ;-)

The only downside I see is that the dovecot wiki uses "quota" as table 
name - but this is something that can (and should) be mentioned in the 
postfixadmin docs.

> > Regarding PostgreSQL: If I get http://wiki.dovecot.org/Quota/Dict
> > right, dovecot needs a trigger for updating the quota.
> 
> Yeah, Postgres doesn't support ON DUPLICATE KEY UPDATE (which has
> never really been an issue) thus the need for the trigger. I'm the
>  one that added the v1.1 trigger to the dovecot wiki. Of course, if
>  you add support for v1.2 there will need to be two triggers in the
>  setup file which goes back to the need to check the version of 
>  dovecot...

As with the tables - it shouldn't hurt to create both triggers ;-)


Regards,

Christian Boltz
-- 
Meine Rechner sind seit einem Jahr ein Naturschutzgebiet
für Pinguine. ;))           [Michael Raab in suse-linux]

Re: [Postfixadmin-devel] Patch to make domain quota split between all users

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

Hello,

Am Sonntag, 4. Oktober 2009 schrieb Warren Volz:
> On Sep 27, 2009, at 2:44 PM, Christian Boltz wrote:
...
> Ok, so a question, would it be good to add a new field to the domain
> creation screen for "Domain quota" in addition to the existing "Max
> Qupta" field?

Yes.

> That way a admin could decide which style of quota to
> use on a per domain basis. Ie: foo1.com has no domain quota, but can

(no domain quota = unlimited)

> only have mailboxes of a size max_quota and foo2.com has a domain
> quota of 10MB to split amongst as many mailboxes as needed?

Exactly.

And foo3.com has a domain quota of 50 MB which can be used for up to 10 
mailboxes. Maximum mailbox size is 10 MB, but obviously not for all 10 
mailboxes (10*10 = 100 which is more than the 50 MB domain quota).

> > Another small issue with your patch: I'd prefer to read the domain
> > from
> > the username instead of adding another parameter to check_quota().
> 
> As in parse the domain from the username? 

Yes.

> Are there any potential security issues from using a regex instead of 
> confirming via the database? I guess you are already doing this in 
> quite a few places, so maybe I'm just being lazy...

I'm just trying to avoid possible issues in case someone accidently 
hands over a domain different from the domain in the username when 
calling check_quota() ;-)

Splitting off the domain with a regex or with explode('@', $username) is 
fine. (If someone tries to inject an invalid domain, he should already 
be catched by the existing checks in create-/edit-mailbox.php.)


Regards,

Christian Boltz
-- 
>That release went far too smooth after we had everything together ;-)
That on it's own should have set off the alarm bells :-)
[> Andreas Jaeger and David Bolt in opensuse-factory]

Re: [Postfixadmin-devel] Patch to make domain quota split between all users

[Warren V. <wa...@wa...>]

On Sep 27, 2009, at 2:44 PM, Christian Boltz wrote:

> Thanks for your patch!
> I like your idea of having a per-domain total quota which can be used
> for one big or 100 small mailboxes. However, I'd like to ask to to do
> some changes to your changes ;-)

No problem, I realize it's most likely not in the best shape as it  
stands.

> If I get your patch right (I just had a quick look at it), you are
> _replacing_ the current quota implementation with a per-domain total
> quota. I'd like to have both - a per-domain quota as in your patch  
> and a
> quota limit for each mailbox (as in the current implementation) for  
> some
> reasons:
> - admins might still want to have a maximum per-mailbox size
> - replacing the meaning of the maxquota field from "max quota per
>  mailbox" to "quota per domain" would cause big problems on upgrade
> - we would also break backwards compatibility (by replacing the  
> meaning
>  of maxquota) without a real need
> - with a separate field, upgrading would be easy. The per-domain quota
>  could be calculated on upgrade:
>      allowed mailboxes * quota per mailbox = quota for the domain
>
> There's an unused column "quota" in the domain table - you can use it
> for the per-domain quota.

Ok, so a question, would it be good to add a new field to the domain  
creation screen for "Domain quota" in addition to the existing "Max  
Qupta" field? That way a admin could decide which style of quota to  
use on a per domain basis. Ie: foo1.com has no domain quota, but can  
only have mailboxes of a size max_quota and foo2.com has a domain  
quota of 10MB to split amongst as many mailboxes as needed?

> Another small issue with your patch: I'd prefer to read the domain  
> from
> the username instead of adding another parameter to check_quota().

As in parse the domain from the username? Are there any potential  
security issues from using a regex instead of confirming via the  
database? I guess you are already doing this in quite a few places, so  
maybe I'm just being lazy...

-Warren