postfixadmin-tracker — Postfix Admin tracker notification - READ ONLY!

[ postfixadmin-Bugs-1783149 ] Username in maildir path is not converted to lowercase

[SourceForge.net <no...@so...>]

Bugs item #1783149, was opened at 2007-08-28 11:17
Message generated for change (Comment added) made by christian_boltz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1783149&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Michael Beiter (michaelbeiter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Username in maildir path is not converted to lowercase

Initial Comment:
The entered username is not converted to lowercase in the maildir when adding a new mailbox.

If the username is entered as i.e. Te...@do...valid, the resulting username (for login) will be te...@do...valid, what is correct. When the maildir is chosen to be made up of domain and username, it will result as domain.invalid/TeST - what is incorrect, as at least maildrop in my setup won't be able to deliver mails: it expects domain.invalid/test as maildir (what is only consequent).

The fix is easy, it is sufficient to add a "strtolower" function call at the appropriate lines:

admin/create-mailbox.php

143c143
<             $maildir = $fDomain . "/" . escape_string ($_POST['fUsername']) . "/";
---
>             $maildir = $fDomain . "/" . strtolower(escape_string ($_POST['fUsername'])) . "/";


create-mailbox.php

154c154
<             $maildir = $fDomain . "/" . escape_string ($_POST['fUsername']) . "/";
---
>             $maildir = $fDomain . "/" . strtolower(escape_string ($_POST['fUsername'])) . "/";

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

>Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-08 13:53

Message:
Logged In: YES 
user_id=593261
Originator: NO

> Probably you didn't expect these difficulties because you use the
> alternative maildir structure (domain_in_mailbox==YES [...]

I use the same setting as you do and even tested it: the maildir is
created with uppercase letters. However this didn't matter on my system
because maildrop reads the maildir from the database itsself ("WHERE
username=...") instead of using the value it got from postfix. I tested:
- delivery with postfix / maildrop
- fetching mails with courier
and everything worked with the uppercase maildir name.

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

Comment By: Michael Beiter (michaelbeiter)
Date: 2007-10-08 08:46

Message:
Logged In: YES 
user_id=76720
Originator: YES

Regarding my maildroprc: I used the username and domainname as provided by
the database to create the maildirs. However, postfix always provides
lowercase credentials when it delivers a mail to maildrop. 

Probably you didn't expect these difficulties because you use the
alternative maildir structure (domain_in_mailbox==YES, what actually is the
default IIRC). This results in using $fUsername on which a strtolower is
applied in an earlier step somewhere around line 80. Unfortunately, at that
place $fUsername ist tainted with the domain name, what requires using the
POST-variable as described to restore $fUsername to its original value.

In other words: I could use a strtolower when creating the maildir in my
maildroprc. However, this could lead to inconsistencies in other
applications. As imlemented by postfixadmin in the alternative maildir
structure, user- and domainnames should be lowercase - and that's why I
reported :-)

HTH, Michael


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

Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-07 21:52

Message:
Logged In: YES 
user_id=593261
Originator: NO

Just curious: How does your maildroprc look like? (I'm also using maildrop
and using uppercase mailbox names works without problems.)

Anyway: Your change won't do any harm or backwards compatibility issues
(because it only affects creation of new mailboxes). I just applied your
patch to create-mailbox.php in the SVN.

Thanks for reporting this!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1783149&group_id=191583

[ postfixadmin-Feature Requests-1790011 ] Improved Vacation

[SourceForge.net <no...@so...>]

Feature Requests item #1790011, was opened at 2007-09-07 12:37
Message generated for change (Comment added) made by stoffldick
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1790011&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Vacation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: MikeH (stoffldick)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improved Vacation

Initial Comment:
As dicussed in the forum here's a patch for some unfinished improvements in virtual vacation.

Created the patch with svn diff from a postfixadmin-2.1.0 with changes applied. Hope i didn't forget anything.


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

>Comment By: MikeH (stoffldick)
Date: 2007-10-08 09:43

Message:
Logged In: YES 
user_id=1302149
Originator: YES

Yup, that's exactly the problem. I didn't look at your current version of
vacation.pl but i think it should not be that hard to implement the missing
features there. As i said: let me know if you need some help on this. Maybe
i find some time to modify vacation.pl.

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

Comment By: GingerDog (gingerdog)
Date: 2007-10-08 09:08

Message:
Logged In: YES 
user_id=1761957
Originator: NO

It looks like you've potentially added quite a bit of functionality to the
vacation support; but the vacation.pl changes you've attached don't seem to
reflect any of this... is this why/where it is unfinished?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1790011&group_id=191583

[ postfixadmin-Bugs-1771320 ] vacation.pl dies with very long recipient e-mail addresses

[SourceForge.net <no...@so...>]

Bugs item #1771320, was opened at 2007-08-09 23:19
Message generated for change (Comment added) made by gingerdog
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1771320&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Thomas Witzenrath (tom_witzenrath)
Assigned to: Nobody/Anonymous (nobody)
Summary: vacation.pl dies with very long recipient e-mail addresses

Initial Comment:
When receiving a message to a realy long e-mail address (i.e. "myrealylongfirstname myrealylongfamilyname <myr...@my...>"), the recipient mail address is not on the same header-line as the "To:", so

-------------snip------------------
# Take headers apart
while (<STDIN>) {
   last if (/^$/);
   if (/^from:\s+(.*)\n$/i) { $from = $1; }
   if (/^to:\s+(.*)\n$/i) { $to = $1; }
   if (/^cc:\s+(.*)\n$/i) { $cc = $1; }
   if (/^subject:\s+(.*)\n$/i) { $subject = $1; }
   if (/^message-id:\s+(.*)\n$/i) { $messageid = $1; }
   if (/^precedence:\s+(bulk|list|junk)/i) { exit (0); }
   if (/^x-loop:\s+postfix\ admin\ virtual\ vacation/i) { exit (0); }
}
-----------snap-------------------

will not return the correct value for $to. This can be fixed doing something like this:

------------snip------------------
use Mail::Internet;
$header = new Mail::Header \*STDIN;

$from=$header->get('from');
$to=$header->get('to');
$Return_Path=$header->get('Return-Path');
$cc=$header->get('Cc');
$subject=$header->get('subject');
$messageid=$header->get('message-id');
$precedence=$header->get('precedence');
$loop=$header->get('x-loop');

if ( $loop=~ m/Postfix Admin Virtual Vacation/ ) { do_debug("[LOOP]: ",$messageid, $from, "-", $to, $subject); exit (0); }
if ( $precedence=~ m/[Bb]ulk|[Ll]ist|[Jj]unk/ ) { do_debug("[BULK]: ",$messageid, $from, "-", $to, $subject); exit (0); }

------------snap----------------------

I am aware that the loop-detection part does not work like this, I don't know much about perl, so perhaps some perl-a-holic might want to fix that. :-)

The recipient address could as well be provided by postfix, but thats another story I guess...

Also, where can I post an alternate vacation script written in python? :-)



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

>Comment By: GingerDog (gingerdog)
Date: 2007-10-08 07:17

Message:
Logged In: YES 
user_id=1761957
Originator: NO

Hi,

I like the use of Mail::Internet and the header parsing; it certainly
looks better than what we have aleady.

Anyway, I believe this problem is already fixed in the vacation.pl that's
within SVN as it has code which checks for header lines that start with
space[s].

Thanks
David.

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

Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-07 19:01

Message:
Logged In: YES 
user_id=593261
Originator: NO

In the meantime, vacation.pl was replaced by the former
vacation-pgsql.pl.

If I get the code right, this bug should be fixed. Please check the latest
SVN version and reopen this bugreport if I'm wrong.

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

Comment By: GingerDog (gingerdog)
Date: 2007-08-17 15:40

Message:
Logged In: YES 
user_id=1761957
Originator: NO

create a patch/ticket for it, if you still have a python version. Note
someone's already posted a PHP version. I would love to see a single
vacation script which internally handled the differences between pgsql and
mysql.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1771320&group_id=191583

[ postfixadmin-Feature Requests-1790011 ] Improved Vacation

[SourceForge.net <no...@so...>]

Feature Requests item #1790011, was opened at 2007-09-07 10:37
Message generated for change (Comment added) made by gingerdog
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1790011&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Vacation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: MikeH (stoffldick)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improved Vacation

Initial Comment:
As dicussed in the forum here's a patch for some unfinished improvements in virtual vacation.

Created the patch with svn diff from a postfixadmin-2.1.0 with changes applied. Hope i didn't forget anything.


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

>Comment By: GingerDog (gingerdog)
Date: 2007-10-08 07:08

Message:
Logged In: YES 
user_id=1761957
Originator: NO

It looks like you've potentially added quite a bit of functionality to the
vacation support; but the vacation.pl changes you've attached don't seem to
reflect any of this... is this why/where it is unfinished?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1790011&group_id=191583

[ postfixadmin-Bugs-1783149 ] Username in maildir path is not converted to lowercase

[SourceForge.net <no...@so...>]

Bugs item #1783149, was opened at 2007-08-28 09:17
Message generated for change (Settings changed) made by michaelbeiter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1783149&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Michael Beiter (michaelbeiter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Username in maildir path is not converted to lowercase

Initial Comment:
The entered username is not converted to lowercase in the maildir when adding a new mailbox.

If the username is entered as i.e. Te...@do...valid, the resulting username (for login) will be te...@do...valid, what is correct. When the maildir is chosen to be made up of domain and username, it will result as domain.invalid/TeST - what is incorrect, as at least maildrop in my setup won't be able to deliver mails: it expects domain.invalid/test as maildir (what is only consequent).

The fix is easy, it is sufficient to add a "strtolower" function call at the appropriate lines:

admin/create-mailbox.php

143c143
<             $maildir = $fDomain . "/" . escape_string ($_POST['fUsername']) . "/";
---
>             $maildir = $fDomain . "/" . strtolower(escape_string ($_POST['fUsername'])) . "/";


create-mailbox.php

154c154
<             $maildir = $fDomain . "/" . escape_string ($_POST['fUsername']) . "/";
---
>             $maildir = $fDomain . "/" . strtolower(escape_string ($_POST['fUsername'])) . "/";

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

Comment By: Michael Beiter (michaelbeiter)
Date: 2007-10-08 06:46

Message:
Logged In: YES 
user_id=76720
Originator: YES

Regarding my maildroprc: I used the username and domainname as provided by
the database to create the maildirs. However, postfix always provides
lowercase credentials when it delivers a mail to maildrop. 

Probably you didn't expect these difficulties because you use the
alternative maildir structure (domain_in_mailbox==YES, what actually is the
default IIRC). This results in using $fUsername on which a strtolower is
applied in an earlier step somewhere around line 80. Unfortunately, at that
place $fUsername ist tainted with the domain name, what requires using the
POST-variable as described to restore $fUsername to its original value.

In other words: I could use a strtolower when creating the maildir in my
maildroprc. However, this could lead to inconsistencies in other
applications. As imlemented by postfixadmin in the alternative maildir
structure, user- and domainnames should be lowercase - and that's why I
reported :-)

HTH, Michael


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

Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-07 19:52

Message:
Logged In: YES 
user_id=593261
Originator: NO

Just curious: How does your maildroprc look like? (I'm also using maildrop
and using uppercase mailbox names works without problems.)

Anyway: Your change won't do any harm or backwards compatibility issues
(because it only affects creation of new mailboxes). I just applied your
patch to create-mailbox.php in the SVN.

Thanks for reporting this!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1783149&group_id=191583

[ postfixadmin-Bugs-1783149 ] Username in maildir path is not converted to lowercase

[SourceForge.net <no...@so...>]

Bugs item #1783149, was opened at 2007-08-28 09:17
Message generated for change (Comment added) made by michaelbeiter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1783149&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: None
>Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Michael Beiter (michaelbeiter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Username in maildir path is not converted to lowercase

Initial Comment:
The entered username is not converted to lowercase in the maildir when adding a new mailbox.

If the username is entered as i.e. Te...@do...valid, the resulting username (for login) will be te...@do...valid, what is correct. When the maildir is chosen to be made up of domain and username, it will result as domain.invalid/TeST - what is incorrect, as at least maildrop in my setup won't be able to deliver mails: it expects domain.invalid/test as maildir (what is only consequent).

The fix is easy, it is sufficient to add a "strtolower" function call at the appropriate lines:

admin/create-mailbox.php

143c143
<             $maildir = $fDomain . "/" . escape_string ($_POST['fUsername']) . "/";
---
>             $maildir = $fDomain . "/" . strtolower(escape_string ($_POST['fUsername'])) . "/";


create-mailbox.php

154c154
<             $maildir = $fDomain . "/" . escape_string ($_POST['fUsername']) . "/";
---
>             $maildir = $fDomain . "/" . strtolower(escape_string ($_POST['fUsername'])) . "/";

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

>Comment By: Michael Beiter (michaelbeiter)
Date: 2007-10-08 06:46

Message:
Logged In: YES 
user_id=76720
Originator: YES

Regarding my maildroprc: I used the username and domainname as provided by
the database to create the maildirs. However, postfix always provides
lowercase credentials when it delivers a mail to maildrop. 

Probably you didn't expect these difficulties because you use the
alternative maildir structure (domain_in_mailbox==YES, what actually is the
default IIRC). This results in using $fUsername on which a strtolower is
applied in an earlier step somewhere around line 80. Unfortunately, at that
place $fUsername ist tainted with the domain name, what requires using the
POST-variable as described to restore $fUsername to its original value.

In other words: I could use a strtolower when creating the maildir in my
maildroprc. However, this could lead to inconsistencies in other
applications. As imlemented by postfixadmin in the alternative maildir
structure, user- and domainnames should be lowercase - and that's why I
reported :-)

HTH, Michael


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

Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-07 19:52

Message:
Logged In: YES 
user_id=593261
Originator: NO

Just curious: How does your maildroprc look like? (I'm also using maildrop
and using uppercase mailbox names works without problems.)

Anyway: Your change won't do any harm or backwards compatibility issues
(because it only affects creation of new mailboxes). I just applied your
patch to create-mailbox.php in the SVN.

Thanks for reporting this!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1783149&group_id=191583

[ postfixadmin-Feature Requests-1748385 ] let admin manage users' mails

[SourceForge.net <no...@so...>]

Feature Requests item #1748385, was opened at 2007-07-05 14:41
Message generated for change (Comment added) made by christian_boltz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1748385&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
>Summary: let admin manage users' mails

Initial Comment:
maybe you adda a support to SMTP/IMAP/POP3+SASL+SSL/TLS that will be more scure :D

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

>Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-07 23:56

Message:
Logged In: YES 
user_id=593261
Originator: NO

changing summary to a better one - Gingerdog, you should have the
permissions to do this yourself

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

Comment By: GingerDog (gingerdog)
Date: 2007-10-07 15:31

Message:
Logged In: YES 
user_id=1761957
Originator: NO

It's an interesting question - should administrators be allowed to see
user(s) email, with e.g. the intention of marking it as spam or whatever.

I think, due to the privacy implications, at the very least, there would
have to be some sort of 'opt-in' request from the user allowing an admin to
do this - along the lines of allowing sharing mailboxes within
outlook/exchange.


I'm not sure how the technical aspect of this could be undertaken - most
passwords are encrypted, so it wouldn't be easy/feasible to open the
mailbox via IMAP/POP3/whatever. I suppose if you were using Cyrus for the
backend mailstore you could alter the permissions on the mailbox, but this
isn't something you could do with Courier.

FWIW, the title of this ticket is misleading.

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

Comment By: Sergey Litvinenko (lisergey)
Date: 2007-10-06 04:32

Message:
Logged In: YES 
user_id=1902244
Originator: NO

grep'ing maildirs??
with what argument? 
if this works, it is the solution of misdirected mails problem without
breaking privacy, yes.
but how to produce a string for grep search?

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

Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-05 23:47

Message:
Logged In: YES 
user_id=593261
Originator: NO

Personal note: I don't want to be the admin in a company that follows your
example (it would be a very annoying admin job) and don't think that going
through everybody's mailbox to delete a specific mail is reasonable. In
this case, grep'ing through the maildirs on the disk is ways faster and
also reduces privacy implications (because you don't see other mails
"accidently").

Anyway: I really think this could (and will) cause privacy problems, and
it's not a real difference if you call it "read" or "manage misdirected
mails" ;-)  I also see no real difference in (not) encrypting the password
and would _always_ ask for the password.

So IMHO we are down to "link to squirrelmail, with the mail address
already entered in the login form".

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

Comment By: Sergey Litvinenko (lisergey)
Date: 2007-10-05 12:38

Message:
Logged In: YES 
user_id=1902244
Originator: NO

if passwords are encrypted, than the admin who wish to check the mailbox
for spam or misdirected mails, would be forced to enter the passwords, and
it's okay for that case.

the idea is for admin not to READ the other's mails, but to MANAGE
misdirected mails.
example - one of employee by impulse of her bad mood was to sent alot of
stupid jokes to everyones addresses - practically spam.

if there would be interface for admin to remove erroneously sent mails, I
think, it would be of great help.


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

Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-05 01:26

Message:
Logged In: YES 
user_id=593261
Originator: NO

I see two problems here:

a) technical: passwords are often encrypted in the database, therefore it
could be 
   difficult or even impossible to pass them to squirrelmail etc.

b) legal: In germany, you aren't allowed to read other people's mails, and
I guess 
   there are similar rules in other countries as well. Even if it isn't
forbidden
   by law, this would make it too easy to ignore the privacy of your
users.

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

Comment By: Sergey Litvinenko (lisergey)
Date: 2007-10-05 00:32

Message:
Logged In: YES 
user_id=1902244
Originator: NO

what kind of support to PostfixAdmin??

I'd love to see the ability for admin of a domain to see/manage the mail
in any mailbox for that domain.
probably with squirrelmail or alike, but without intermediate additional
login/password interaction

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1748385&group_id=191583

[ postfixadmin-Bugs-1694669 ] Improper Use of crypt()

[SourceForge.net <no...@so...>]

Bugs item #1694669, was opened at 2007-04-05 02:14
Message generated for change (Comment added) made by christian_boltz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1694669&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: v1.0 (example)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improper Use of crypt()

Initial Comment:
Inside the pacrypt() function in functions.inc.php, crypt() is used for the 'system' encryption type.  Salt is first calculated, with the below code:

if (ereg ("\$1\$", $pw_db))
{
  $split_salt = preg_split ('/\$/', $pw_db);
  $salt = $split_salt[2];
}
else
{
  $salt = substr ($pw_db, 0, 2);
}

... however, that is improper according to the php.net documentation (http://www.php.net/crypt) for the crypt() call: 

...
You should pass the entire results of crypt() as the salt for comparing a password, to avoid problems when different hashing algorithms are used. (As it says above, standard DES-based password hashing uses a 2-character salt, but MD5-based hashing uses 12.)
...

Simply modifying the code to read:
if ($pw_db)
{
  $password = crypt ($pw, $pw_db);
}
else
{
  $password = crypt ($pw);
}

... fixed the problem in my case.

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

>Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-07 22:03

Message:
Logged In: YES 
user_id=593261
Originator: NO

Your arguments are valid, but the question is:

    Will this break existing passwords?

(If yes, it will be problematic to do this change.)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1694669&group_id=191583

[ postfixadmin-Bugs-1779823 ] function escape_string() incorrectly handles no magic quotes

[SourceForge.net <no...@so...>]

Bugs item #1779823, was opened at 2007-08-22 15:23
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1779823&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: FredKilbourn (fredkilbourn)
Assigned to: Nobody/Anonymous (nobody)
Summary: function escape_string() incorrectly handles no magic quotes

Initial Comment:
When magic quotes is turned off in php, unable to enter any data into postfixadmin and php throws errors in the error_log.

Attached is a patch to fix with more detail on problem and solution.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2007-10-07 13:01

Message:
Logged In: NO 

Christian,
  Looked at the code, looks real good.  I see no more immediate issue and
looks like it should work fine with magic quotes on or off.

Regards,
  Fred

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

Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-07 12:31

Message:
Logged In: YES 
user_id=593261
Originator: NO

This is fixed in the latest SVN version. escape_string was rewritten and
now always uses the db-specific escape functions.

BTW: I didn't check the whole code, but I'm quite sure that this function
is only used to escape strings for SQL queries. Everything else usually
needs htmlentities() ;-)

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

Comment By: FredKilbourn (fredkilbourn)
Date: 2007-09-06 09:51

Message:
Logged In: YES 
user_id=1873536
Originator: YES

nobody @ 2007-09-06:
  What you say is actually the correct fix when magic quotes is off, but
it does not address the base problem(s) here:

Problem:
1 The escape_string() function calls these specific database escape
functions only if magic_quotes_gpc is off.
2 This is the only place these specific database escape functions are
called anywhere in the codebase.
3 When magic_quotes is on, all these database escape functions are
skipped
4 When magic_quotes_gpc is on, it is the equivalent of PHP function
addslashes() on any get/post/cookie data.
5 PHP function addslashes() is strictly inappropriate for escaping
database query variables

Therefore:
1 When magic_quotes_gpc is on, no database queries are properly escaped
2 With my attached patch, no database queries are properly escaped if
magic_quotes_gpc is on or off

The even greater issue is this:
- In what cases is escape_slashes being called to escape a db query, or to
escape for another purpose?
- I don't have time to go through the entire codebase and analyze this
question but the more appropriate escaping implementation is to have:
--- escape_string_db - for escaping db query vars only
--- escape_string - for escaping other vars (if necessary - i didnt go
through the code base so i dont know for sure)

escape_string_db pseudocode:
if( magic_quotes_gpc == on )  //if magic quotes is on, stripslashes to
undo addslashes that was auto-done
  stripslashes( $var )
return db_specific_escape( $var )    //use appropriate db specific escape
function


escape_string pseudocode:
if( magic_quotes_gpc == off ) //if magic gpc is off use addslashes to
emulate functionality
  return addslashes( $var )

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

Comment By: Nobody/Anonymous (nobody)
Date: 2007-09-06 03:34

Message:
Logged In: NO 

The problem is that db_query function connects to the database, run the
query, and close db connection.

escape_string() calls mysql_real_escape_string($string).
when no dblink is given to mysql_real_escape_string() as 2nd parameter, it
takes the last connection opened by mysql_connect. If it cannot find any
connection, the function tries to connect with default mysql connection
parameters (not set for me).

The workaround I found is to comment mysql_close() in the fonction
db_query() in the functions.inc.php

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

Comment By: yves teixeira (nictuku)
Date: 2007-08-29 22:15

Message:
Logged In: YES 
user_id=572172
Originator: NO

Thanks, Fred. It works for me.

You saved the day. :-)

Yves (rimuhosting.com)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1779823&group_id=191583

[ postfixadmin-Bugs-1783149 ] Username in maildir path is not converted to lowercase

[SourceForge.net <no...@so...>]

Bugs item #1783149, was opened at 2007-08-28 11:17
Message generated for change (Comment added) made by christian_boltz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1783149&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Michael Beiter (michaelbeiter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Username in maildir path is not converted to lowercase

Initial Comment:
The entered username is not converted to lowercase in the maildir when adding a new mailbox.

If the username is entered as i.e. Te...@do...valid, the resulting username (for login) will be te...@do...valid, what is correct. When the maildir is chosen to be made up of domain and username, it will result as domain.invalid/TeST - what is incorrect, as at least maildrop in my setup won't be able to deliver mails: it expects domain.invalid/test as maildir (what is only consequent).

The fix is easy, it is sufficient to add a "strtolower" function call at the appropriate lines:

admin/create-mailbox.php

143c143
<             $maildir = $fDomain . "/" . escape_string ($_POST['fUsername']) . "/";
---
>             $maildir = $fDomain . "/" . strtolower(escape_string ($_POST['fUsername'])) . "/";


create-mailbox.php

154c154
<             $maildir = $fDomain . "/" . escape_string ($_POST['fUsername']) . "/";
---
>             $maildir = $fDomain . "/" . strtolower(escape_string ($_POST['fUsername'])) . "/";

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

>Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-07 21:52

Message:
Logged In: YES 
user_id=593261
Originator: NO

Just curious: How does your maildroprc look like? (I'm also using maildrop
and using uppercase mailbox names works without problems.)

Anyway: Your change won't do any harm or backwards compatibility issues
(because it only affects creation of new mailboxes). I just applied your
patch to create-mailbox.php in the SVN.

Thanks for reporting this!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1783149&group_id=191583

[ postfixadmin-Bugs-1753060 ] add mailbox doesn't use domain's default quota

[SourceForge.net <no...@so...>]

Bugs item #1753060, was opened at 2007-07-13 02:09
Message generated for change (Comment added) made by christian_boltz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1753060&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Alan Batie (abatie)
Assigned to: Nobody/Anonymous (nobody)
Summary: add mailbox doesn't use domain's default quota

Initial Comment:
If you set a domain default quota, then add a mailbox, the default value filled in for quota is the system default, not the domain default.  A minor nuisance, but easily fixed...


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

>Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-07 21:39

Message:
Logged In: YES 
user_id=593261
Originator: NO

Thanks for your bugreport!

This is fixed in the latest SVN version (to be exact, I fixed it in August
in r38).

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1753060&group_id=191583

[ postfixadmin-Bugs-1779823 ] function escape_string() incorrectly handles no magic quotes

[SourceForge.net <no...@so...>]

Bugs item #1779823, was opened at 2007-08-23 00:23
Message generated for change (Comment added) made by christian_boltz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1779823&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: FredKilbourn (fredkilbourn)
Assigned to: Nobody/Anonymous (nobody)
Summary: function escape_string() incorrectly handles no magic quotes

Initial Comment:
When magic quotes is turned off in php, unable to enter any data into postfixadmin and php throws errors in the error_log.

Attached is a patch to fix with more detail on problem and solution.

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

>Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-07 21:31

Message:
Logged In: YES 
user_id=593261
Originator: NO

This is fixed in the latest SVN version. escape_string was rewritten and
now always uses the db-specific escape functions.

BTW: I didn't check the whole code, but I'm quite sure that this function
is only used to escape strings for SQL queries. Everything else usually
needs htmlentities() ;-)

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

Comment By: FredKilbourn (fredkilbourn)
Date: 2007-09-06 18:51

Message:
Logged In: YES 
user_id=1873536
Originator: YES

nobody @ 2007-09-06:
  What you say is actually the correct fix when magic quotes is off, but
it does not address the base problem(s) here:

Problem:
1 The escape_string() function calls these specific database escape
functions only if magic_quotes_gpc is off.
2 This is the only place these specific database escape functions are
called anywhere in the codebase.
3 When magic_quotes is on, all these database escape functions are
skipped
4 When magic_quotes_gpc is on, it is the equivalent of PHP function
addslashes() on any get/post/cookie data.
5 PHP function addslashes() is strictly inappropriate for escaping
database query variables

Therefore:
1 When magic_quotes_gpc is on, no database queries are properly escaped
2 With my attached patch, no database queries are properly escaped if
magic_quotes_gpc is on or off

The even greater issue is this:
- In what cases is escape_slashes being called to escape a db query, or to
escape for another purpose?
- I don't have time to go through the entire codebase and analyze this
question but the more appropriate escaping implementation is to have:
--- escape_string_db - for escaping db query vars only
--- escape_string - for escaping other vars (if necessary - i didnt go
through the code base so i dont know for sure)

escape_string_db pseudocode:
if( magic_quotes_gpc == on )  //if magic quotes is on, stripslashes to
undo addslashes that was auto-done
  stripslashes( $var )
return db_specific_escape( $var )    //use appropriate db specific escape
function


escape_string pseudocode:
if( magic_quotes_gpc == off ) //if magic gpc is off use addslashes to
emulate functionality
  return addslashes( $var )

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

Comment By: Nobody/Anonymous (nobody)
Date: 2007-09-06 12:34

Message:
Logged In: NO 

The problem is that db_query function connects to the database, run the
query, and close db connection.

escape_string() calls mysql_real_escape_string($string).
when no dblink is given to mysql_real_escape_string() as 2nd parameter, it
takes the last connection opened by mysql_connect. If it cannot find any
connection, the function tries to connect with default mysql connection
parameters (not set for me).

The workaround I found is to comment mysql_close() in the fonction
db_query() in the functions.inc.php

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

Comment By: yves teixeira (nictuku)
Date: 2007-08-30 07:15

Message:
Logged In: YES 
user_id=572172
Originator: NO

Thanks, Fred. It works for me.

You saved the day. :-)

Yves (rimuhosting.com)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1779823&group_id=191583

[ postfixadmin-Bugs-1771320 ] vacation.pl dies with very long recipient e-mail addresses

[SourceForge.net <no...@so...>]

Bugs item #1771320, was opened at 2007-08-10 01:19
Message generated for change (Comment added) made by christian_boltz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1771320&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Thomas Witzenrath (tom_witzenrath)
Assigned to: Nobody/Anonymous (nobody)
Summary: vacation.pl dies with very long recipient e-mail addresses

Initial Comment:
When receiving a message to a realy long e-mail address (i.e. "myrealylongfirstname myrealylongfamilyname <myr...@my...>"), the recipient mail address is not on the same header-line as the "To:", so

-------------snip------------------
# Take headers apart
while (<STDIN>) {
   last if (/^$/);
   if (/^from:\s+(.*)\n$/i) { $from = $1; }
   if (/^to:\s+(.*)\n$/i) { $to = $1; }
   if (/^cc:\s+(.*)\n$/i) { $cc = $1; }
   if (/^subject:\s+(.*)\n$/i) { $subject = $1; }
   if (/^message-id:\s+(.*)\n$/i) { $messageid = $1; }
   if (/^precedence:\s+(bulk|list|junk)/i) { exit (0); }
   if (/^x-loop:\s+postfix\ admin\ virtual\ vacation/i) { exit (0); }
}
-----------snap-------------------

will not return the correct value for $to. This can be fixed doing something like this:

------------snip------------------
use Mail::Internet;
$header = new Mail::Header \*STDIN;

$from=$header->get('from');
$to=$header->get('to');
$Return_Path=$header->get('Return-Path');
$cc=$header->get('Cc');
$subject=$header->get('subject');
$messageid=$header->get('message-id');
$precedence=$header->get('precedence');
$loop=$header->get('x-loop');

if ( $loop=~ m/Postfix Admin Virtual Vacation/ ) { do_debug("[LOOP]: ",$messageid, $from, "-", $to, $subject); exit (0); }
if ( $precedence=~ m/[Bb]ulk|[Ll]ist|[Jj]unk/ ) { do_debug("[BULK]: ",$messageid, $from, "-", $to, $subject); exit (0); }

------------snap----------------------

I am aware that the loop-detection part does not work like this, I don't know much about perl, so perhaps some perl-a-holic might want to fix that. :-)

The recipient address could as well be provided by postfix, but thats another story I guess...

Also, where can I post an alternate vacation script written in python? :-)



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

>Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-07 21:01

Message:
Logged In: YES 
user_id=593261
Originator: NO

In the meantime, vacation.pl was replaced by the former
vacation-pgsql.pl.

If I get the code right, this bug should be fixed. Please check the latest
SVN version and reopen this bugreport if I'm wrong.

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

Comment By: GingerDog (gingerdog)
Date: 2007-08-17 17:40

Message:
Logged In: YES 
user_id=1761957
Originator: NO

create a patch/ticket for it, if you still have a python version. Note
someone's already posted a PHP version. I would love to see a single
vacation script which internally handled the differences between pgsql and
mysql.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1771320&group_id=191583

[ postfixadmin-Bugs-1743279 ] mysql_real_escape_string() is called w/o db_connection

[SourceForge.net <no...@so...>]

Bugs item #1743279, was opened at 2007-06-26 03:36
Message generated for change (Comment added) made by christian_boltz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1743279&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Database
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: chnad (chnad)
Assigned to: Nobody/Anonymous (nobody)
Summary: mysql_real_escape_string() is called w/o db_connection

Initial Comment:
without magic_quotes_gpc, mysql_real_escape_string() is called but it is not checked if a database connection exists / no connection is made.

It generates a warning like:

PHP Warning:  mysql_real_escape_string() [<a href='function.mysql-real-escape-string'>function.mysql-real-escape-string</a>]: Access denied for user 'apache'@'localhost' (using password: NO) in /var/www/html/padm/functions.inc.php on line 131, referer: http://host/padm/login.php

a database connection is probaby needed for mysqli and pgsql as well, so a db_connect() call in the if (get_magic_quotes_gpc () == 0) {} block is probably the right fix. 



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

>Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-07 20:55

Message:
Logged In: YES 
user_id=593261
Originator: NO

This seems to be fixed in the latest SVN version.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2007-07-30 12:41

Message:
Logged In: NO 

Had the same Problem, PHP4.4 MySQL 5.0, tried the same fix, worked for
me.

Greets Peter

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

Comment By: Nobody/Anonymous (nobody)
Date: 2007-07-23 13:21

Message:
Logged In: NO 

Fast workaround for this, add the following line on line 130:

$link = db_connect ();


The function "escape_string" looks after the fix so:

    122 // escape_string
    123 // Action: Escape a string
    124 // Call: escape_string (string string)
    125 //
    126 function escape_string ($string)
    127 {
    128    global $CONF;
    129
    130    $link = db_connect ();
    131
    132    if (get_magic_quotes_gpc () == 0)
    133    {
    134       if ($CONF['database_type'] == "mysql")  $escaped_string =
mysql_real_escape_string ($string);
    135       if ($CONF['database_type'] == "mysqli")  $escaped_string =
mysqli_real_escape_string ($string);
    136       if ($CONF['database_type'] == "pgsql")  $escaped_string =
pg_escape_string ($string);
    137    }
    138    else
    139    {
    140       $escaped_string = $string;
    141    }
    142    return $escaped_string;
    143 }

This works for me.

Hf, Jens

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1743279&group_id=191583

[ postfixadmin-Feature Requests-1785513 ] Password and username restrictions

[SourceForge.net <no...@so...>]

Feature Requests item #1785513, was opened at 2007-08-31 13:15
Message generated for change (Comment added) made by christian_boltz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1785513&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: suprune (suprune)
Assigned to: Nobody/Anonymous (nobody)
Summary: Password and username restrictions

Initial Comment:
A user can change its password, and a domain administrator can set the password of a user. It would be nice if there were the following parameters in config.inc.php:

password minimum length;

and/or characters a password may contain, e.g. a regular expression for a password, like this: "!^[\\x21-\\x7E]{3,}$!"

The same thing is desired for the users' names.

Thanks.

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

>Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-07 20:49

Message:
Logged In: YES 
user_id=593261
Originator: NO

Status:

Minimum password length is implemented in the latest SVN version as config
option.

Checking the password against a RegEx shouldn't be too hard to implement,
but I'm not sure if we really need it.

Usernames always have to be (valid) mail addresses and are already
checked.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1785513&group_id=191583

[ postfixadmin-Feature Requests-1766629 ] default alias everybody@

[SourceForge.net <no...@so...>]

Feature Requests item #1766629, was opened at 2007-08-03 10:49
Message generated for change (Settings changed) made by christian_boltz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1766629&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
>Summary: default alias everybody@

Initial Comment:
Is it possible to set a default alias like everyone@

So if i add a mailbox the mailaddress is automaticly added to the default alias.

regards
Johan  

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

Comment By: Christian Boltz (christian_boltz)
Date: 2007-09-25 00:26

Message:
Logged In: YES 
user_id=593261
Originator: NO

This isn't possible at the moment (except if you want to send a mail to
all users in all domains, which can be done as superadmin).

I'll move your request to the feature request tracker.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1766629&group_id=191583

[ postfixadmin-Feature Requests-1690408 ] Show out of office status on the overview page.

[SourceForge.net <no...@so...>]

Feature Requests item #1690408, was opened at 2007-03-29 09:24
Message generated for change (Comment added) made by christian_boltz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1690408&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Show out of office status on the overview page.

Initial Comment:
It would be nice if the domain administrator could see who has the out of office set.

Also if it is set could it not show the autoreply adres in the alias field, because if you need to edit the alias field with out of office set it errors out with a wrong adres error.

regards,
Johan

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

>Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-07 20:43

Message:
Logged In: YES 
user_id=593261
Originator: NO

This was fixed by agregc32's commit in June. You can test it the current
SVN version. (If something is still missing or broken, please reopen this
request.)

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

Comment By: Greg C (agregc32)
Date: 2007-06-20 00:50

Message:
Logged In: YES 
user_id=1809263
Originator: NO

I just committed updates to the trunk code that show status and allows for
setting, removing, and editing of vacation config by admins and
superadmins.  Make sure vacation_control_admin is set to YES.  I'm using
MySQL, so postgres users may find bugs.

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

Comment By: Colin Viebrock (cviebrock)
Date: 2007-04-04 21:06

Message:
Logged In: YES 
user_id=22560
Originator: NO

I think what is really needed is a way for the administrator to not only
view but to also set/unset the vacation status for any user.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1690408&group_id=191583

[ postfixadmin-Feature Requests-1801649 ] better method than admin@domain.tld for initial superadmin

[SourceForge.net <no...@so...>]

Feature Requests item #1801649, was opened at 2007-09-24 23:50
Message generated for change (Comment added) made by christian_boltz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1801649&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Christian Boltz (christian_boltz)
Assigned to: Nobody/Anonymous (nobody)
Summary: better method than ad...@do...d for initial superadmin

Initial Comment:
Currently, postfixadmin comes with a preconfigured ad...@do...d account in the SQL dump. This causes some problems:
- security: people might forget to delete the default account
- if password encryption is switched off, login won't work

Better solution:
setup.php should contain a form to create the superadmin account. Since this file *must* be deleted to make postfixadmin working, the security risk of forgetting this step doesn't exist.

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

>Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-07 20:39

Message:
Logged In: YES 
user_id=593261
Originator: YES

I commited this some minutes ago, see the SVN log (r135 and r137) for
details.

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

Comment By: GingerDog (gingerdog)
Date: 2007-10-07 15:33

Message:
Logged In: YES 
user_id=1761957
Originator: NO

seems a good idea to me...

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1801649&group_id=191583

[ postfixadmin-Feature Requests-1801649 ] better method than admin@domain.tld for initial superadmin

[SourceForge.net <no...@so...>]

Feature Requests item #1801649, was opened at 2007-09-24 21:50
Message generated for change (Comment added) made by gingerdog
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1801649&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Boltz (christian_boltz)
Assigned to: Nobody/Anonymous (nobody)
Summary: better method than ad...@do...d for initial superadmin

Initial Comment:
Currently, postfixadmin comes with a preconfigured ad...@do...d account in the SQL dump. This causes some problems:
- security: people might forget to delete the default account
- if password encryption is switched off, login won't work

Better solution:
setup.php should contain a form to create the superadmin account. Since this file *must* be deleted to make postfixadmin working, the security risk of forgetting this step doesn't exist.

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

>Comment By: GingerDog (gingerdog)
Date: 2007-10-07 13:33

Message:
Logged In: YES 
user_id=1761957
Originator: NO

seems a good idea to me...

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1801649&group_id=191583

[ postfixadmin-Feature Requests-1807305 ] sieve db column

[SourceForge.net <no...@so...>]

Feature Requests item #1807305, was opened at 2007-10-04 05:25
Message generated for change (Comment added) made by gingerdog
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1807305&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Database
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ondras (ondras)
Assigned to: Nobody/Anonymous (nobody)
Summary: sieve db column

Initial Comment:
It would be nice to add a column 'sieve' to 'mailbox' table; this would be used to store a path to user sieve script. I am using dovecot+cmusieve for virtual delivery and the filter needs to know, where is the relevant script located.


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

>Comment By: GingerDog (gingerdog)
Date: 2007-10-07 13:32

Message:
Logged In: YES 
user_id=1761957
Originator: NO

Could you not solve this through convention - e.g. the sieve script always
has the same name as the username?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1807305&group_id=191583

[ postfixadmin-Feature Requests-1748385 ] SMTP/IMAP/POP3+SASL+SSL/TLS

[SourceForge.net <no...@so...>]

Feature Requests item #1748385, was opened at 2007-07-05 12:41
Message generated for change (Comment added) made by gingerdog
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1748385&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: SMTP/IMAP/POP3+SASL+SSL/TLS

Initial Comment:
maybe you adda a support to SMTP/IMAP/POP3+SASL+SSL/TLS that will be more scure :D

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

>Comment By: GingerDog (gingerdog)
Date: 2007-10-07 13:31

Message:
Logged In: YES 
user_id=1761957
Originator: NO

It's an interesting question - should administrators be allowed to see
user(s) email, with e.g. the intention of marking it as spam or whatever.

I think, due to the privacy implications, at the very least, there would
have to be some sort of 'opt-in' request from the user allowing an admin to
do this - along the lines of allowing sharing mailboxes within
outlook/exchange.


I'm not sure how the technical aspect of this could be undertaken - most
passwords are encrypted, so it wouldn't be easy/feasible to open the
mailbox via IMAP/POP3/whatever. I suppose if you were using Cyrus for the
backend mailstore you could alter the permissions on the mailbox, but this
isn't something you could do with Courier.

FWIW, the title of this ticket is misleading.

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

Comment By: Sergey Litvinenko (lisergey)
Date: 2007-10-06 02:32

Message:
Logged In: YES 
user_id=1902244
Originator: NO

grep'ing maildirs??
with what argument? 
if this works, it is the solution of misdirected mails problem without
breaking privacy, yes.
but how to produce a string for grep search?

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

Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-05 21:47

Message:
Logged In: YES 
user_id=593261
Originator: NO

Personal note: I don't want to be the admin in a company that follows your
example (it would be a very annoying admin job) and don't think that going
through everybody's mailbox to delete a specific mail is reasonable. In
this case, grep'ing through the maildirs on the disk is ways faster and
also reduces privacy implications (because you don't see other mails
"accidently").

Anyway: I really think this could (and will) cause privacy problems, and
it's not a real difference if you call it "read" or "manage misdirected
mails" ;-)  I also see no real difference in (not) encrypting the password
and would _always_ ask for the password.

So IMHO we are down to "link to squirrelmail, with the mail address
already entered in the login form".

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

Comment By: Sergey Litvinenko (lisergey)
Date: 2007-10-05 10:38

Message:
Logged In: YES 
user_id=1902244
Originator: NO

if passwords are encrypted, than the admin who wish to check the mailbox
for spam or misdirected mails, would be forced to enter the passwords, and
it's okay for that case.

the idea is for admin not to READ the other's mails, but to MANAGE
misdirected mails.
example - one of employee by impulse of her bad mood was to sent alot of
stupid jokes to everyones addresses - practically spam.

if there would be interface for admin to remove erroneously sent mails, I
think, it would be of great help.


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

Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-04 23:26

Message:
Logged In: YES 
user_id=593261
Originator: NO

I see two problems here:

a) technical: passwords are often encrypted in the database, therefore it
could be 
   difficult or even impossible to pass them to squirrelmail etc.

b) legal: In germany, you aren't allowed to read other people's mails, and
I guess 
   there are similar rules in other countries as well. Even if it isn't
forbidden
   by law, this would make it too easy to ignore the privacy of your
users.

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

Comment By: Sergey Litvinenko (lisergey)
Date: 2007-10-04 22:32

Message:
Logged In: YES 
user_id=1902244
Originator: NO

what kind of support to PostfixAdmin??

I'd love to see the ability for admin of a domain to see/manage the mail
in any mailbox for that domain.
probably with squirrelmail or alike, but without intermediate additional
login/password interaction

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1748385&group_id=191583

[ postfixadmin-Feature Requests-1748385 ] SMTP/IMAP/POP3+SASL+SSL/TLS

[SourceForge.net <no...@so...>]

Feature Requests item #1748385, was opened at 2007-07-05 16:41
Message generated for change (Comment added) made by lisergey
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1748385&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: SMTP/IMAP/POP3+SASL+SSL/TLS

Initial Comment:
maybe you adda a support to SMTP/IMAP/POP3+SASL+SSL/TLS that will be more scure :D

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

Comment By: Sergey Litvinenko (lisergey)
Date: 2007-10-06 06:32

Message:
Logged In: YES 
user_id=1902244
Originator: NO

grep'ing maildirs??
with what argument? 
if this works, it is the solution of misdirected mails problem without
breaking privacy, yes.
but how to produce a string for grep search?

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

Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-06 01:47

Message:
Logged In: YES 
user_id=593261
Originator: NO

Personal note: I don't want to be the admin in a company that follows your
example (it would be a very annoying admin job) and don't think that going
through everybody's mailbox to delete a specific mail is reasonable. In
this case, grep'ing through the maildirs on the disk is ways faster and
also reduces privacy implications (because you don't see other mails
"accidently").

Anyway: I really think this could (and will) cause privacy problems, and
it's not a real difference if you call it "read" or "manage misdirected
mails" ;-)  I also see no real difference in (not) encrypting the password
and would _always_ ask for the password.

So IMHO we are down to "link to squirrelmail, with the mail address
already entered in the login form".

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

Comment By: Sergey Litvinenko (lisergey)
Date: 2007-10-05 14:38

Message:
Logged In: YES 
user_id=1902244
Originator: NO

if passwords are encrypted, than the admin who wish to check the mailbox
for spam or misdirected mails, would be forced to enter the passwords, and
it's okay for that case.

the idea is for admin not to READ the other's mails, but to MANAGE
misdirected mails.
example - one of employee by impulse of her bad mood was to sent alot of
stupid jokes to everyones addresses - practically spam.

if there would be interface for admin to remove erroneously sent mails, I
think, it would be of great help.


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

Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-05 03:26

Message:
Logged In: YES 
user_id=593261
Originator: NO

I see two problems here:

a) technical: passwords are often encrypted in the database, therefore it
could be 
   difficult or even impossible to pass them to squirrelmail etc.

b) legal: In germany, you aren't allowed to read other people's mails, and
I guess 
   there are similar rules in other countries as well. Even if it isn't
forbidden
   by law, this would make it too easy to ignore the privacy of your
users.

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

Comment By: Sergey Litvinenko (lisergey)
Date: 2007-10-05 02:32

Message:
Logged In: YES 
user_id=1902244
Originator: NO

what kind of support to PostfixAdmin??

I'd love to see the ability for admin of a domain to see/manage the mail
in any mailbox for that domain.
probably with squirrelmail or alike, but without intermediate additional
login/password interaction

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1748385&group_id=191583

[ postfixadmin-Feature Requests-1748385 ] SMTP/IMAP/POP3+SASL+SSL/TLS

[SourceForge.net <no...@so...>]

Feature Requests item #1748385, was opened at 2007-07-05 14:41
Message generated for change (Comment added) made by christian_boltz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1748385&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: SMTP/IMAP/POP3+SASL+SSL/TLS

Initial Comment:
maybe you adda a support to SMTP/IMAP/POP3+SASL+SSL/TLS that will be more scure :D

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

>Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-05 23:47

Message:
Logged In: YES 
user_id=593261
Originator: NO

Personal note: I don't want to be the admin in a company that follows your
example (it would be a very annoying admin job) and don't think that going
through everybody's mailbox to delete a specific mail is reasonable. In
this case, grep'ing through the maildirs on the disk is ways faster and
also reduces privacy implications (because you don't see other mails
"accidently").

Anyway: I really think this could (and will) cause privacy problems, and
it's not a real difference if you call it "read" or "manage misdirected
mails" ;-)  I also see no real difference in (not) encrypting the password
and would _always_ ask for the password.

So IMHO we are down to "link to squirrelmail, with the mail address
already entered in the login form".

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

Comment By: Sergey Litvinenko (lisergey)
Date: 2007-10-05 12:38

Message:
Logged In: YES 
user_id=1902244
Originator: NO

if passwords are encrypted, than the admin who wish to check the mailbox
for spam or misdirected mails, would be forced to enter the passwords, and
it's okay for that case.

the idea is for admin not to READ the other's mails, but to MANAGE
misdirected mails.
example - one of employee by impulse of her bad mood was to sent alot of
stupid jokes to everyones addresses - practically spam.

if there would be interface for admin to remove erroneously sent mails, I
think, it would be of great help.


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

Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-05 01:26

Message:
Logged In: YES 
user_id=593261
Originator: NO

I see two problems here:

a) technical: passwords are often encrypted in the database, therefore it
could be 
   difficult or even impossible to pass them to squirrelmail etc.

b) legal: In germany, you aren't allowed to read other people's mails, and
I guess 
   there are similar rules in other countries as well. Even if it isn't
forbidden
   by law, this would make it too easy to ignore the privacy of your
users.

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

Comment By: Sergey Litvinenko (lisergey)
Date: 2007-10-05 00:32

Message:
Logged In: YES 
user_id=1902244
Originator: NO

what kind of support to PostfixAdmin??

I'd love to see the ability for admin of a domain to see/manage the mail
in any mailbox for that domain.
probably with squirrelmail or alike, but without intermediate additional
login/password interaction

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937967&aid=1748385&group_id=191583

[ postfixadmin-Bugs-1698485 ] vacation.pl source address problem.

[SourceForge.net <no...@so...>]

Bugs item #1698485, was opened at 2007-04-11 16:07
Message generated for change (Settings changed) made by christian_boltz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1698485&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Vacation
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: vacation.pl source address problem.

Initial Comment:
If a mail is sent to the vacation with an header to like: 
To: "pippo" <pi...@di...>

The vacation.pl will try to run sendmail with these arguments:

sendmail -t -f "pippo" <pi...@di...>

as you can see the arguments are incorrect and sendmail will die.





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

Comment By: Dalibor Straka (dast_panelnet)
Date: 2007-10-05 13:47

Message:
Logged In: YES 
user_id=1678716
Originator: NO

The SVN version seems to be fixed.

I didn't test it. The change is exactly the same.
This could be closed.

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

Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-05 02:53

Message:
Logged In: YES 
user_id=593261
Originator: NO

In the meantime, vacation.pl has been replaced by the former
vacation-pgsql.pl.

I just checked the code - as far as I can say, this fix is included.
Please test it using the latest SVN version and reopen this bugreport if
necessary.

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

Comment By: Dalibor Straka (dast_panelnet)
Date: 2007-09-28 18:40

Message:
Logged In: YES 
user_id=1678716
Originator: NO

Here is a patch that fixes this bug in 2.1.0 version

diff -ur a/vacation.pl b/vacation.pl
--- a/vacation.pl       2007-09-28 18:36:31.000000000 +0200
+++ b/vacation.pl       2007-09-28 18:37:55.000000000 +0200
@@ -160,7 +160,7 @@
       my @row = $sth->fetchrow_array;
       if (do_cache ($email, $orig_from)) { return; }
       do_debug ("[SEND RESPONSE] for $orig_messageid:\n", "FROM: $email
(orig_to: $orig_to)\n", "TO: $orig_from\n", "SUBJECT: $orig_subject\n",
"VACATION SUBJECT: $row[0]\n", "VACATION BODY: $row[1]\n");
-      do_mail ($orig_to, $orig_from, $row[0], $row[1]);
+      do_mail ($email, $orig_from, $row[0], $row[1]);
       do_log ($orig_messageid, $orig_to, $orig_from, $orig_subject); 
    }


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

Comment By: Nobody/Anonymous (nobody)
Date: 2007-04-29 22:06

Message:
Logged In: NO 

In line 85 of vacation script change $email to '$email'

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1698485&group_id=191583

[ postfixadmin-Bugs-1698485 ] vacation.pl source address problem.

[SourceForge.net <no...@so...>]

Bugs item #1698485, was opened at 2007-04-11 16:07
Message generated for change (Comment added) made by dast_panelnet
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1698485&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Vacation
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: vacation.pl source address problem.

Initial Comment:
If a mail is sent to the vacation with an header to like: 
To: "pippo" <pi...@di...>

The vacation.pl will try to run sendmail with these arguments:

sendmail -t -f "pippo" <pi...@di...>

as you can see the arguments are incorrect and sendmail will die.





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

Comment By: Dalibor Straka (dast_panelnet)
Date: 2007-10-05 13:47

Message:
Logged In: YES 
user_id=1678716
Originator: NO

The SVN version seems to be fixed.

I didn't test it. The change is exactly the same.
This could be closed.

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

Comment By: Christian Boltz (christian_boltz)
Date: 2007-10-05 02:53

Message:
Logged In: YES 
user_id=593261
Originator: NO

In the meantime, vacation.pl has been replaced by the former
vacation-pgsql.pl.

I just checked the code - as far as I can say, this fix is included.
Please test it using the latest SVN version and reopen this bugreport if
necessary.

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

Comment By: Dalibor Straka (dast_panelnet)
Date: 2007-09-28 18:40

Message:
Logged In: YES 
user_id=1678716
Originator: NO

Here is a patch that fixes this bug in 2.1.0 version

diff -ur a/vacation.pl b/vacation.pl
--- a/vacation.pl       2007-09-28 18:36:31.000000000 +0200
+++ b/vacation.pl       2007-09-28 18:37:55.000000000 +0200
@@ -160,7 +160,7 @@
       my @row = $sth->fetchrow_array;
       if (do_cache ($email, $orig_from)) { return; }
       do_debug ("[SEND RESPONSE] for $orig_messageid:\n", "FROM: $email
(orig_to: $orig_to)\n", "TO: $orig_from\n", "SUBJECT: $orig_subject\n",
"VACATION SUBJECT: $row[0]\n", "VACATION BODY: $row[1]\n");
-      do_mail ($orig_to, $orig_from, $row[0], $row[1]);
+      do_mail ($email, $orig_from, $row[0], $row[1]);
       do_log ($orig_messageid, $orig_to, $orig_from, $orig_subject); 
    }


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

Comment By: Nobody/Anonymous (nobody)
Date: 2007-04-29 22:06

Message:
Logged In: NO 

In line 85 of vacation script change $email to '$email'

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1698485&group_id=191583