postfixadmin-devel Mailing List for PostfixAdmin (Page 25)

Brought to you by: christian_boltz, gingerdog

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

You can subscribe to this list here.

2007	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (1)	Oct (39)	Nov (29)	Dec (4)
2008	Jan (5)	Feb	Mar (8)	Apr (8)	May	Jun (11)	Jul (21)	Aug (4)	Sep (9)	Oct (5)	Nov (25)	Dec (11)
2009	Jan (40)	Feb (16)	Mar (1)	Apr (46)	May (3)	Jun	Jul (1)	Aug (9)	Sep (9)	Oct (27)	Nov (35)	Dec (20)
2010	Jan (3)	Feb (2)	Mar (8)	Apr (1)	May (9)	Jun (8)	Jul (1)	Aug (7)	Sep (2)	Oct (2)	Nov (12)	Dec (7)
2011	Jan (45)	Feb (11)	Mar (18)	Apr (15)	May (20)	Jun	Jul (5)	Aug (1)	Sep	Oct (8)	Nov	Dec (14)
2012	Jan (30)	Feb (36)	Mar (6)	Apr (32)	May (20)	Jun (5)	Jul (2)	Aug	Sep (4)	Oct	Nov (22)	Dec (1)
2013	Jan (13)	Feb (4)	Mar (70)	Apr (10)	May (6)	Jun (11)	Jul (1)	Aug (3)	Sep (2)	Oct (15)	Nov (4)	Dec (4)
2014	Jan	Feb	Mar (2)	Apr (2)	May (3)	Jun (2)	Jul	Aug	Sep	Oct (1)	Nov (8)	Dec (2)
2015	Jan (1)	Feb (9)	Mar	Apr	May (1)	Jun	Jul	Aug	Sep (6)	Oct	Nov	Dec
2016	Jan (4)	Feb	Mar (10)	Apr (3)	May	Jun (2)	Jul	Aug	Sep (1)	Oct (4)	Nov	Dec (13)
2017	Jan (1)	Feb (6)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (2)	Dec (3)
2018	Jan (2)	Feb	Mar (2)	Apr (7)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2019	Jan	Feb	Mar (10)	Apr	May (1)	Jun (2)	Jul	Aug	Sep	Oct	Nov (7)	Dec
2020	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (2)	Nov	Dec
2021	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (2)	Dec
2023	Jan	Feb (2)	Mar (3)	Apr	May	Jun (3)	Jul	Aug	Sep	Oct	Nov	Dec
2024	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (2)	Dec (3)

Flat | Threaded

<< < 1 .. 23 24 25 26 27 .. 41 > >> (Page 25 of 41)

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[824] branches/postfixadmin-2.3

From: Christian B. <pos...@cb...> - 2010-06-22 22:49:54

Hello,

good news: we are near the 2.3.1 release [1] - at least that's what I 
think ;-)

The code is not bug-free (probably it will never be), but all major bugs 
should be fixed. (And of course there will always be someone saying that 
his "favorite" bug is still unfixed ;-)

Missing parts:
- merge debian/* changes from r805 -> normes? hello? ;-)
- testing - I did not even test the code after the merge I commited some 
  minutes ago ;-)

Still very important:
> @everybody: Please checkout the 2.3 branch from SVN and check if
> everything works. Especially check if everything listed in the
> CHANGELOG.txt works ;-)


@GingerDog: 
Notes regarding the release:
a) version an revision numbers in changelog and functions.inc.php need 
   to be updated
b) Please send me the tarball in advance so I can create a RPM package 
   _before uploading to SF_. 
   The reason for this request is the "latest files" section on SF, 
   which makes uploading the RPM later a no-go :-/ - we have to upload 
   everything at once.


Regards,

Christian Boltz

[1] if we manage to do the release before someone finds another major 
    bug *g*

-- 
> Was haltet ihr von Lindows??
Tonne auf, Lindows rein, Lindows 'Erfinder' dazustopfen, Tonne zu, mit 
Stacheldraht umwickeln, in die Sonne schiessen. Problem gelöst..
[> Glenn Charpantier und Phillip Richdale in suse-linux]

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[824] branches/postfixadmin-2.3

From: Christian B. <pos...@cb...> - 2010-05-17 23:40:22

Hello,

Am Montag, 17. Mai 2010 schrieb David Goodwin:
> > not yet merged and/or to be discussed:
> > - r805 - debian/* - normes or GingerDog, can you merge this part,
> > please? I don't want to change stuff that I don't understand ;-)
> 
> Just blindly merge it - I think only normes really understands it.

The best solution would be if normes does this part of the merge.

-> normes? ;-)

> > - r800, r806, r821 - Squirrelmail Plugin
> 
> please do.

OK

> > - r811, r812 - Squirrelmail Plugin / Zend - not sure if we really
> > should include the whole Zend framework in the tarball, it's
> > laaaaaarge and only useful for squirrelmail users.
> >    I'd vote for a "Requires: Zend" in the documentation.
> 
> This is tempting. At the moment it should be an svn:external - and
> perhaps we can view that as just being useful for development.

OK, then I won't include Zend in the 2.3 branch.

I would even remove the svn:external from trunk - I don't see a real 
advantage compared to having it in the PHP include_path or symlinked. 
OTOH, the svn:external slows down several svn commands...

> > - r815: the change in users/index.php makes access to users/ too
> > easy if someone forgot to logout (security by obscurity, but
> > still...)
> 
> Don't understand this ^^^ comment, can you elabourate/

old users/index.php:
   header("Location: login.php")
new (r815) users/index.php:
   header("Location: main.php")

Why I don't like this change: If someone forgot to logout and just went 
to another site, the login cookie stays valid. Let's also assume he 
leaves his computer and someone else wants to configure his mailbox 
under users/.

Old behaviour: login form is shown
New behaviour: instant access to the (still logged in) mailbox

Therefore I'd prefer to revert to the old behaviour. I know that it's 
somewhat security by obscurity (one can still directly go to 
users/main.php), but that's very different from actively being pushed 
into the foreign mailbox.

> > - r817 - ADDITIONS/cyrus (config file path?)

config file path changed to /etc/mail/postfixadmin/cyrus.conf + merged 
to 2.3 branch

> > - r819 - maildir path hook (BTW: the example function should be
> > moved to config.inc.php)
> 
> Where is/was it - 

in functions.inc.php - I just moved it to config.inc.php.

> but I think I'd agree... it would make it more
>  obvious to a sysadmin what's going on.
> 
> Sorry for being relatively silent lately - life is busy.

You don't need to tell me that ;-)


The good news: If I get it right, merging (except the debian/ stuff) 
should be complete - we are near the 2.3.1 release :-)

@everybody: Please checkout the 2.3 branch from SVN and check if 
everything works. Especially check if everything listed in the 
CHANGELOG.txt works ;-)


Regards,

Christian Boltz
-- 
<suseROCKs> henne: [...] Can you link me to any documentation [...]?
<henne> suseROCKs: brain://henne/hardware/touchsmart
<suseROCKs> Firefox:   Oops!  There appears to be no brain:// associated
            with henne
[from #opensuse-project]

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[824] branches/postfixadmin-2.3

From: David G. <da...@co...> - 2010-05-17 13:13:48

On 17/05/10 13:53, Tanstaafl wrote:
> On 2010-05-17 6:03 AM, David Goodwin wrote:
>> Sorry for being relatively silent lately - life is busy.
>
> Glad you're still alive and well at least David... :)
>
> Any chance of a 2.3.1 release anytime soon? I think there have been lots
> of small bug fixes since 2.3 was released...


I think Christian is working towards it...

David.
-- 
David Goodwin

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

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[824] branches/postfixadmin-2.3

From: Tanstaafl <tan...@li...> - 2010-05-17 12:53:52

On 2010-05-17 6:03 AM, David Goodwin wrote:
> Sorry for being relatively silent lately - life is busy.

Glad you're still alive and well at least David... :)

Any chance of a 2.3.1 release anytime soon? I think there have been lots
of small bug fixes since 2.3 was released...

Thanks!

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[824] branches/postfixadmin-2.3

From: David G. <da...@co...> - 2010-05-17 10:22:16

>
> not yet merged and/or to be discussed:
> - r805 - debian/* - normes or GingerDog, can you merge this part, please?
>    I don't want to change stuff that I don't understand ;-)

Just blindly merge it - I think only normes really understands it.

> - r800, r806, r821 - Squirrelmail Plugin

please do.

> - r811, r812 - Squirrelmail Plugin / Zend - not sure if we really should
>    include the whole Zend framework in the tarball, it's laaaaaarge and
>    only useful for squirrelmail users.
>    I'd vote for a "Requires: Zend" in the documentation.

This is tempting. At the moment it should be an svn:external - and 
perhaps we can view that as just being useful for development.

> - r815: the change in users/index.php makes access to users/ too easy if
>    someone forgot to logout (security by obscurity, but still...)

Don't understand this ^^^ comment, can you elabourate/


> - r817 - ADDITIONS/cyrus (config file path?)
> - r819 - maildir path hook (BTW: the example function should be moved to
>    config.inc.php)

Where is/was it - but I think I'd agree... it would make it more obvious 
to a sysadmin what's going on.

Sorry for being relatively silent lately - life is busy.

David.



-- 
David Goodwin

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

Re: [Postfixadmin-devel] temporary forward for an existing mailbox

From: Luigi R. <li...@lu...> - 2010-05-15 14:58:46

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

Valkuma said the following on 15/05/10 16:19:

> You have to edit the alias. With alias_control you should see for each
> mailbox an alias in the alias view.

Shame on me!

Apologies an thank you once again for the hint.



Ciao,
luigi

- -- 
/
+--[Luigi Rosa]--
\

Medical community applauds first double-hand transplant in U.S
    --fark.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvutpcACgkQ3kWu7Tfl6ZT6BwCfa7Xsedk2SsKnELE0RgpGLD+l
WiUAnRslWVCPxvAfCqrWDvFrpDFF4mjk
=7v+F
-----END PGP SIGNATURE-----

Re: [Postfixadmin-devel] temporary forward for an existing mailbox

From: Valkuma <va...@go...> - 2010-05-15 14:19:19

Am 15.05.2010 10:52, schrieb Luigi Rosa:
> me...@td... said the following on 13/05/10 00:06:
>
> >> A user requested a temporary forward for his incoming mails: his
> mail should be
> >> delivered to his mailbox and a colleague's mailbox.
> >>
> >> How can I accomplish this using postfixadmin console? I tried with
> "Add Alias"
> >> but it does not allow me to creat an alias for an existing user.
>
> > Try setting $CONF['alias_control'] = 'YES';
> > I just went through this a couple of weeks ago and I think this was the
> > parameter I changed to get the ability to add aliases to existing users.
>
> Thank you for your answer.
>
> Unfortunately, setting this parameter yo 'YES' does not solve the issue.
>
> After setting alias_control to YES I tried to create an alias of an
> existing
> user, but postfixadmin displays this error message: "This email
> address already
> exists, please choose a different one!"
>
>
> Ciao,
> luigi
>
You have to edit the alias. With alias_control you should see for each
mailbox an alias in the alias view.
Click there on edit and add  an email in the to field. One emailaddress
per line.

Greetz Valkum
------------------------------------------------------------------------------

_______________________________________________
Postfixadmin-devel mailing list
Pos...@li...
https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel

Re: [Postfixadmin-devel] temporary forward for an existing mailbox

From: Luigi R. <li...@lu...> - 2010-05-15 08:52:43

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

me...@td... said the following on 13/05/10 00:06:

>> A user requested a temporary forward for his incoming mails: his mail should be
>> delivered to his mailbox and a colleague's mailbox.
>>
>> How can I accomplish this using postfixadmin console? I tried with "Add Alias"
>> but it does not allow me to creat an alias for an existing user.

> Try setting $CONF['alias_control'] = 'YES';
> I just went through this a couple of weeks ago and I think this was the
> parameter I changed to get the ability to add aliases to existing users.

Thank you for your answer.

Unfortunately, setting this parameter yo 'YES' does not solve the issue.

After setting alias_control to YES I tried to create an alias of an existing
user, but postfixadmin displays this error message: "This email address already
exists, please choose a different one!"


Ciao,
luigi

- -- 
/
+--[Luigi Rosa]--
\

Dear Mr. President: The canal system of this country is being threatened
by a new form of transportation known as 'railroads' ... As you may well
know, Mr. President, 'railroad' carriages are pulled at the enormous
speed of 15 miles per hour by 'engines' which, in addition to
endangering life and limb of passengers, roar and snort their way
through the countryside, setting fire to crops, scaring the livestock and
frightening women and children. The Almighty certainly never intended
that people should travel at such breakneck speed.
       --Martin Van Buren, governatore di New York, 1830
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvuYM0ACgkQ3kWu7Tfl6ZT0JQCgqY1IotDEhVZCLrxHpiEbrrvI
FVMAoLH9HN5+gr85P/woOqHwJkXNulS5
=9TfG
-----END PGP SIGNATURE-----

Re: [Postfixadmin-devel] temporary forward for an existing mailbox

From: <me...@td...> - 2010-05-12 22:33:21

On Wed, 12 May 2010, Luigi Rosa wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
> I have the latest (2.3) version of postfixadmin.
>
> A user requested a temporary forward for his incoming mails: his mail should be
> delivered to his mailbox and a colleague's mailbox.
>
> How can I accomplish this using postfixadmin console? I tried with "Add Alias"
> but it does not allow me to creat an alias for an existing user.

Try setting $CONF['alias_control'] = 'YES';

I just went through this a couple of weeks ago and I think this was the
parameter I changed to get the ability to add aliases to existing users.

Regards,

-- 
Tom			me...@td...		Spamtrap address	 		me...@td...

[Postfixadmin-devel] temporary forward for an existing mailbox

From: Luigi R. <li...@lu...> - 2010-05-12 07:27:32

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

Hi,
I have the latest (2.3) version of postfixadmin.

A user requested a temporary forward for his incoming mails: his mail should be
delivered to his mailbox and a colleague's mailbox.

How can I accomplish this using postfixadmin console? I tried with "Add Alias"
but it does not allow me to creat an alias for an existing user.



Ciao,
luigi

- -- 
/
+--[Luigi Rosa]--
\

Elliot Carver: Mr. Jones, are we ready to release our new software?
Jones: Yes, sir. As requested, it's full of bugs, which means
  people will be forced to upgrade for years.
Elliot Carver: Outstanding.
    --"007 Tomorrow Never Dies"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvqVIcACgkQ3kWu7Tfl6ZSzSwCfXdofxps/gjt0jgTrPdPnQelj
a8MAn129iEvIc6vXir8jo+bnQ3AewH33
=9dmk
-----END PGP SIGNATURE-----

Re: [Postfixadmin-devel] mass user creation by script

From: Christian B. <pos...@cb...> - 2010-04-06 17:43:10

Hello,

Am Freitag, 19. März 2010 schrieb Robert Schetterer:
> anybody help with using
> create-mailbox.php with an accountlist in in csv
> format
> 
> something like
> 
> for i in list
> do php create-mailbox.php user pass ...

Sometimes it helps that I'm too busy to answer mails early ;-)

Yesterday we got a script from Valkum that can add and remove mailboxes. 
Your mail sounds like you would be a perfect tester for it ;-)
(Disclaimer: No guarantees given, I did not read the source code yet.)

You can download the script from the patches tracker at 
http://sourceforge.net/tracker/?func=detail&aid=2981966&group_id=191583&atid=937966

Feedback welcome ;-)


Regards,

Christian Boltz
-- 
> > Dafür verwende ich GUI-Applikationen, daß ich nicht selber denken
> > muß.
> Oder so ;-)
Oder umgekehrt. ("Da ich nicht denke, verwende ...")
[> Christian Boltz und Ratti in fontlinge-devel]

[Postfixadmin-devel] mass user creation by script

From: Robert S. <ro...@sc...> - 2010-03-19 11:29:03

Hi all,
anybody help with using
create-mailbox.php with an accountlist in in csv
format

something like

for i in list
do php create-mailbox.php user pass ...

etc ?


-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

[Postfixadmin-devel] [patch] native SSHA (dovecot compatible) support

From: Laurento F. <lau...@gm...> - 2010-03-16 15:04:13

Attachments: postfixadmin-2.3-native_ssha.patch

Hi all,
another simple patch against postfixadmin-2.3 to add "SSHA native
support" because the existing dovecotpw based solution doesn't work at
all with SSHA.

NOTE: The patch needs 'mhash' php function library.

The generated passwords *WORK* with dovecot as expected (I'm using it
and developed it with this goal in mind).


--- DEV NOTES ---
I think we need to rewrite the password check code in a way like I did
for the new password_verify(). Actually I only wrote the 'ssha' part and
simply fallback to the original pacrypt() approach for the other cases.


PS: I found the original SSHA generation/verify code on the php.net
website ( http://www.php.net/manual/en/function.md5.php#40225 )

Cheers,
Laurento

[Postfixadmin-devel] ERROR with UTF-8 mysql tables

From: Snaky L. <sna...@go...> - 2010-03-13 15:18:46

Hi,

I tried to install postfixadmin into a mysql utf-8 table and came across
this error:

Specified key was too long; max key length is 1000 bytes

As I can see in the sf bugtracker, you already found this, but ATM there
seems to be only a workaround - not to use utf-8 tables.

Also already mentioned was the thread in the mysql bug tracker:
http://bugs.mysql.com/bug.php?id=4541

however I would like to recommend developers of postfixadmin to revisit this
link and scroll down to the very bottom and read the post of [23 Feb 3:34]
Jason Urrich:

I post the text here for your convenience and to have everything in one
place:

------------------------------------
TO ANYONE WHO RUNS INTO THIS PROBLEM
------------------------------------

Before trying to work around this problem, consider what this error is
telling you: you
are trying to set up a key (i.e., a tree searching index) that needs more
than a certain
number of bytes. If you are getting this error for something that you've
marked as a
primary key and your keylength is over 20 bytes (latin1) or 60 bytes (utf8),
then stop
right and go back to your design - this is not a suitable primary key.

If you are running into this problem for a non-primary key or an indexed
column, the
problem comes down to the same thing: you're trying to use an enormously
long string to
do tree index lookup, which means you've probably not understood how keys
are used in
database management systems.

----------------------------------
HOW TO PROPERLY SOLVE THIS PROBLEM
----------------------------------

- if this is for a primary key, redesign your table. It really is this
simple: if you're
trying to do lookups based on very long keys, your table design is bad.
Consider this an
attack on your database designing skills if you must, but search keys should
be short.

- if this is for a non-primary key, redesign your table. Either this is not
a key, and
you should not term it as such, or it is, and it should be a hell of a lot
shorter.

- if this is for an index (INDEX or FULL TEXT), consider what an "index"
means: you are
saying that your entire column should act as a search key. While you may
want to take
advantage of this functionality because it lets you do natural text searches
in your
databases, this is *not* what MySQL is for. If you need full text indexing
for vast data
(say your columns represent full article texts) then you should not be using
MySQL for
this in the first place, but text indexers like Apache's "Lucene" or the
like.

-------------------------------
WHAT MAKES THIS WARNING SO BAD?
-------------------------------

Tree indices let MySQL speed up the process of finding data in your table.
Keys and
index/full text indices speed up the search process by building a separate
data
structure, with the keys ordered in a way that allows quick searching.

These structures are sorted structures, which means that whatever you called
a key or an
index is stored sorted (typically) alphanumerically, regardless of whether
that's how
you've put it in your own table. Being guaranteed sorted helps mysql to very
quickly find
these keys. However, this quickly finding keys is only possible if the keys
are short.

Think of it this way - when you look for a word "cat" in an ordered list of
three letter
words, you're going to first find the place where words start with "c", then
after that,
words with second letter "a", and then words with third letter "t".

This is fast. MySQL will be able to find you the right row(s) of data in
your original
table lightning fast... unless you told it to build an index or to key on
something
huge.

If you're using a key or index of type varchar(255), for instance, you're
telling MySQL
that it may have to do 255 byte comparisons before it can even get to the
list of
matching rows in your original table. This completely destroys mysql's -or
any database
management system for that matter- ability to quickly get you the data you
need. In fact,
it will probably be slower than doing a full table scan of your original
data, because
when you're telling mysql that it needs to do this:

select * from mytable where mykeycolum like 'my huge selection criterium';

where "mykeycolumn" is keyed/indexed, what you're actually telling MySQL to
do is this:

rowids = collapse (select rowids from mytable_mykeycolumn_index where
mykeycolumn like
'my huge selection criterium');
select * form mytable where mykeycolumn in rowids;

-----------------------------------------------
IF YOU THINK YOU NEED MORE BYTES IN KEYS ANYWAY
-----------------------------------------------

It is possible that you're just using MySQL for something simple, and either
don't have
the time or the skill to work out a good table layout to get MySQL to
swiftly do what you
would like. This is entirely possible, and it is understandable that you
might run into
this problem, but consider that this error is not thrown just because the
size limit was
arbitrarily chosen by the developers, and you "just need a few bytes more".

This error is an indicator that you're trying to make MySQL do something
that you really
shouldn't want to make it do. Now is a great time to sit down for half a day
to a day and
learn a bit about how to properly design tables, and what you should and
shouldn't expect
a database management system to do.

-------------
IN CONCLUSION
-------------

Q - Why am I getting this warning?
A - Because you're using a construction intended to speed up the query
process in a way
that will likely slow things down considerably, instead.

Q - How do solve this?
A - Optimise your tables so that you key on short keys, and do full text
searching using
full text indexers (do not rely on a dababase management system to do full
text searching
for you. In order to be efficent, dbms don't know what "languages" are, they
just know
byte sequences and if you're lucky, collation rules).

Q - Will this bug be fixed?
A - Pray it doesn't; if anything, it should be tightened to not allow keys
over 128 bytes
for latin1, or 384 for utf8.

The reason for this is that the "specified key was too long" warning is the
best
indicator that the database designer does not understand the purpose of
table keys and
indices, and needs to smarten up, because he or she's trying to use speed-up
techniques
in a way that'll slow mysql down, instead.