SquirrelMail

On Tue, Nov 25, 2008 at 5:40 AM, Michal Hlavinka <mhlavink@...> wrote:
> Hi,
>
> we're trying to fix squirrelmail's problem with UIDs bigger than 2^31.
>
> (sf#1855717 , rhbz#450780, ...)
>
> in short:
> IMAP server uses UIDs to identify emails which are 32 bit values. Some
> servers use lower values, but for example dovecot can gets to really
> high values.
>
> Squirrelmail handles these UIDs like integers, but PHP (on 32-bit
> system) has only 32 bit signed integer, so only first 31 bits are
> usable. If UID is bigger, squirrelmail can't communicate about this
> email with imap server.
>
>
> solution:
> In sf tracker (no change for 10 months) is recommended to "cast" input
> values to strings and change them to zero if input value is not numeric.
> I was finishing patch for this

I hope against 1.5.2.  I'm not sure we want to change this much code
for 1.4.x.  Please send the patch when you are done.

> but I've found squirrelmail uses also
> ++, -- and comparison operators for UIDs (in
> plugins/delete_move_next/setup.php: 152: delete_move_next_read(...)
> function). So strings can't be used for this.

I think you are using an outdated version of SM.

> There is maybe another solution. Use not integers but floats.
> http://www.php.net/float says : "The size of a float is
> platform-dependent, although a maximum of ~1.8e308 with a precision of
> roughly 14 decimal digits is a common value (the 64 bit IEEE format)." I
> can confirm that php keeps number without exponent exactly up to 14
> digits (tested on i386, x86_64 and ppc64). For 32 bit values 10 digits
> are needed. Also we have one squirrelmail instance running with floats
> instead of ints and it's running fine (of course, I can't say all
> possible function combination was tested).
>
> What do you think about this? Or, do you think, there is another solution?

I'd vote for the string implementation (in 1.5.2).

Paul Lesniewski wrote:
> On Tue, Nov 25, 2008 at 5:40 AM, Michal Hlavinka <mhlavink@...> wrote:
>   
>> ...
>>
>> solution:
>> In sf tracker (no change for 10 months) is recommended to "cast" input
>> values to strings and change them to zero if input value is not numeric.
>> I was finishing patch for this
>>     
>
> I hope against 1.5.2.  I'm not sure we want to change this much code
> for 1.4.x.  Please send the patch when you are done.
>   
In fact it's not so much code. Only replace $a=(int)$b; to 
$a=sqrestrict_to_num($b);
sqrestrict_to_int contains only : return (is_numeric($b) ? $b : 0); 
Casting not int to int
results to 0, so there is no change.
I was making this patch against 1.4 svn version, but I can make it for 
devel version,
that's not a problem.



>> but I've found squirrelmail uses also
>> ++, -- and comparison operators for UIDs (in
>> plugins/delete_move_next/setup.php: 152: delete_move_next_read(...)
>> function). So strings can't be used for this.
>>     
>
> I think you are using an outdated version of SM.
>   
svn 1.4 is outdated?
( 
http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4-STABLE/squirrelmail/ 
)

>> ...
>> What do you think about this? Or, do you think, there is another solution?
>>     
>
> I'd vote for the string implementation (in 1.5.2).
>   
Yes, but what about that numeric operators? Of course, making functions for
=, !=, <, <=, ++ and -- is not so difficult, but also it's not too nice IMO.


Btw, what is 1.5.2 svn directory?
Is it http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/trunk/ ?
It looks it contains some files 7 years old... for example
plugins/delete_move_next/setup.php
from the above looks older than from 1.4

On Wed, Nov 26, 2008 at 7:50 AM, Michal Hlavinka <mhlavink@...> wrote:
> Paul Lesniewski wrote:
>> On Tue, Nov 25, 2008 at 5:40 AM, Michal Hlavinka <mhlavink@...> wrote:
>>
>>> ...
>>>
>>> solution:
>>> In sf tracker (no change for 10 months) is recommended to "cast" input
>>> values to strings and change them to zero if input value is not numeric.
>>> I was finishing patch for this
>>>
>>
>> I hope against 1.5.2.  I'm not sure we want to change this much code
>> for 1.4.x.  Please send the patch when you are done.
>>
> In fact it's not so much code. Only replace $a=(int)$b; to
> $a=sqrestrict_to_num($b);
> sqrestrict_to_int contains only : return (is_numeric($b) ? $b : 0);
> Casting not int to int
> results to 0, so there is no change.

Not sure what you mean by "no change", but this seems about right.
The "this much code" comment was based more on the number of pages
that may need to be changed, not that the change itself is big.
However, I'm not sure we'd want to use is_numeric().  See the PHP
manual regarding how it accepts scientific notation and hex numbers
and decimal points.  Rather, I believe we only want
preg_match('/^[0-9]$/'), no?

> I was making this patch against 1.4 svn version, but I can make it for
> devel version,
> that's not a problem.

Thanks

>>> but I've found squirrelmail uses also
>>> ++, -- and comparison operators for UIDs (in
>>> plugins/delete_move_next/setup.php: 152: delete_move_next_read(...)
>>> function). So strings can't be used for this.
>>>
>>
>> I think you are using an outdated version of SM.
>>
> svn 1.4 is outdated?
> (
> http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4-STABLE/squirrelmail/
> )

Hmm, well, your comments about the delete_move_next plugin didn't
match what I see there, but I am not sure I've updated it in a while.
I can double-check, but so should you.

>>> What do you think about this? Or, do you think, there is another solution?
>>>
>>
>> I'd vote for the string implementation (in 1.5.2).
>>
> Yes, but what about that numeric operators? Of course, making functions for
> =, !=, <, <=, ++ and -- is not so difficult, but also it's not too nice IMO.

I don't see them in delete_move_next.

> Btw, what is 1.5.2 svn directory?
> Is it http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/trunk/ ?

Yes, trunk.

> It looks it contains some files 7 years old... for example
> plugins/delete_move_next/setup.php
> from the above looks older than from 1.4

trunk/squirrelmail

Paul Lesniewski wrote:
> On Wed, Nov 26, 2008 at 7:50 AM, Michal Hlavinka <mhlavink@...> wrote:
>   
>> In fact it's not so much code. Only replace $a=(int)$b; to
>> $a=sqrestrict_to_num($b);
>> sqrestrict_to_int contains only : return (is_numeric($b) ? $b : 0);
>> Casting not int to int
>> results to 0, so there is no change.
>>     
>
> Not sure what you mean by "no change", but this seems about right.
>   
"no change" as invalid values will still be changed to 0.

> The "this much code" comment was based more on the number of pages
> that may need to be changed, not that the change itself is big.
>   
the number of pages (at least in 1.4svn) wasn't so high

> However, I'm not sure we'd want to use is_numeric().  See the PHP
> manual regarding how it accepts scientific notation and hex numbers
> and decimal points.  Rather, I believe we only want
> preg_match('/^[0-9]$/'), no?
>   
I've preferred is_numeric because it checks if variable is a numeric 
string or a number.
The reason for is_numeric/other check is because of sanitizing "ugly" 
"accidental" values
and number (even in scientific form) can cause no harm at all. Also 
is_numeric was
my first thought and it works :)


>>>> but I've found squirrelmail uses also
>>>> ++, -- and comparison operators for UIDs (in
>>>> plugins/delete_move_next/setup.php: 152: delete_move_next_read(...)
>>>> function). So strings can't be used for this
>>> I think you are using an outdated version of SM.
>>>       
>> svn 1.4 is outdated?
>> (
>> http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4-STABLE/squirrelmail/
>> )
>>     
>
> Hmm, well, your comments about the delete_move_next plugin didn't
> match what I see there, but I am not sure I've updated it in a while.
> I can double-check, but so should you.
>   
in 1.4svn2008-11-27: plugins/delete_move_next/setup.php:
function delete_move_next_read: lines 169-173
there are used operators > and --

in 1.5svn2008-11-27: there is no delete_move_next plugin and also I've 
found no arithmetic
operators (just quick search).

so... arithmetic operators are used only in 1.4 in delete_move_next 
plugin, but this is the
version I need to fix the most (can't take devel version into on the 
production hosts).

On Thu, Nov 27, 2008 at 9:01 AM, Michal Hlavinka <mhlavink@...> wrote:
> Paul Lesniewski wrote:
>> On Wed, Nov 26, 2008 at 7:50 AM, Michal Hlavinka <mhlavink@...> wrote:
>>
>>> In fact it's not so much code. Only replace $a=(int)$b; to
>>> $a=sqrestrict_to_num($b);
>>> sqrestrict_to_int contains only : return (is_numeric($b) ? $b : 0);
>>> Casting not int to int
>>> results to 0, so there is no change.
>>>
>>
>> Not sure what you mean by "no change", but this seems about right.
>>
> "no change" as invalid values will still be changed to 0.
>
>> The "this much code" comment was based more on the number of pages
>> that may need to be changed, not that the change itself is big.
>>
> the number of pages (at least in 1.4svn) wasn't so high
>
>> However, I'm not sure we'd want to use is_numeric().  See the PHP
>> manual regarding how it accepts scientific notation and hex numbers
>> and decimal points.  Rather, I believe we only want
>> preg_match('/^[0-9]$/'), no?
>>
> I've preferred is_numeric because it checks if variable is a numeric
> string or a number.
> The reason for is_numeric/other check is because of sanitizing "ugly"
> "accidental" values

SquirrelMail does not create "accidental" values.  As far as I know,
UIDs should only contain digits.  is_numeric() allows things other
than digits.  My regexp is very easy to understand - easier than
looking up what is_numeric() allows in fact.  I do not see any reason
why using is_numeric() is better than that regexp, especially if the
target format is a string.

> and number (even in scientific form) can cause no harm at all. Also
> is_numeric was
> my first thought and it works :)
>
>>>>> but I've found squirrelmail uses also
>>>>> ++, -- and comparison operators for UIDs (in
>>>>> plugins/delete_move_next/setup.php: 152: delete_move_next_read(...)
>>>>> function). So strings can't be used for this
>>>> I think you are using an outdated version of SM.
>>>>
>>> svn 1.4 is outdated?
>>> (
>>> http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4-STABLE/squirrelmail/
>>> )
>>>
>>
>> Hmm, well, your comments about the delete_move_next plugin didn't
>> match what I see there, but I am not sure I've updated it in a while.
>> I can double-check, but so should you.
>>
> in 1.4svn2008-11-27: plugins/delete_move_next/setup.php:
> function delete_move_next_read: lines 169-173
> there are used operators > and --

Right.

> in 1.5svn2008-11-27: there is no delete_move_next plugin and also I've
> found no arithmetic
> operators (just quick search).

Yes, the UIDs are kept in an ordered array, from which positional
judgments can be more accurately made.

> so... arithmetic operators are used only in 1.4 in delete_move_next
> plugin, but this is the
> version I need to fix the most (can't take devel version into on the
> production hosts).

Then I suggest you put a patch together for your float implementation
and put it on the SquirrelMail tracker (feel free to post a link to it
here).  We will review it, but again, as of now, I think the only
place we plan to make this change is in our 1.5.x branch.

Thanks a lot for your help.

Hi,

all patches, we were talking about are ready (attached).

patches are against 1.4 svn and 1.5 svn (yesterday)
In the end, I've used conversion to string in both of them. Only 1.4 
contains
additional conversion in sources of delete_and_next plugin to float
to perform arithmetic operations.

I've tested both of them with dovecot and manually created messages with 
high
uids. Both versions were working on systems with 64bit php, both of them
resulted with imap error on 32 bit system.

Now both of them works on 64 and 32 bit systems. I've checked this 
functions:
send email (created email got big uid from dovecot) - successfully 
stored in Sent and readable
move emails between folders
next & prev
delete and next & delete and prev
delete email
forward
edit
view header
forward as attachment and read both email and the attachment in Sent folder

Both patches has only changes to the code text for changelog/other 
document is missing.

Regards,

Michal Hlavinka


Paul Lesniewski wrote:
> On Thu, Nov 27, 2008 at 9:01 AM, Michal Hlavinka <mhlavink@...> wrote:
>   
>> Paul Lesniewski wrote:
>>     
>>> On Wed, Nov 26, 2008 at 7:50 AM, Michal Hlavinka <mhlavink@...> wrote:
>>>
>>>       
>>>> In fact it's not so much code. Only replace $a=(int)$b; to
>>>> $a=sqrestrict_to_num($b);
>>>> sqrestrict_to_int contains only : return (is_numeric($b) ? $b : 0);
>>>> Casting not int to int
>>>> results to 0, so there is no change.
>>>>
>>>>         
>>> Not sure what you mean by "no change", but this seems about right.
>>>
>>>       
>> "no change" as invalid values will still be changed to 0.
>>
>>     
>>> The "this much code" comment was based more on the number of pages
>>> that may need to be changed, not that the change itself is big.
>>>
>>>       
>> the number of pages (at least in 1.4svn) wasn't so high
>>
>>     
>>> However, I'm not sure we'd want to use is_numeric().  See the PHP
>>> manual regarding how it accepts scientific notation and hex numbers
>>> and decimal points.  Rather, I believe we only want
>>> preg_match('/^[0-9]$/'), no?
>>>
>>>       
>> I've preferred is_numeric because it checks if variable is a numeric
>> string or a number.
>> The reason for is_numeric/other check is because of sanitizing "ugly"
>> "accidental" values
>>     
>
> SquirrelMail does not create "accidental" values.  As far as I know,
> UIDs should only contain digits.  is_numeric() allows things other
> than digits.  My regexp is very easy to understand - easier than
> looking up what is_numeric() allows in fact.  I do not see any reason
> why using is_numeric() is better than that regexp, especially if the
> target format is a string.
>
>   
>> and number (even in scientific form) can cause no harm at all. Also
>> is_numeric was
>> my first thought and it works :)
>>
>>     
>>>>>> but I've found squirrelmail uses also
>>>>>> ++, -- and comparison operators for UIDs (in
>>>>>> plugins/delete_move_next/setup.php: 152: delete_move_next_read(...)
>>>>>> function). So strings can't be used for this
>>>>>>             
>>>>> I think you are using an outdated version of SM.
>>>>>
>>>>>           
>>>> svn 1.4 is outdated?
>>>> (
>>>> http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4-STABLE/squirrelmail/
>>>> )
>>>>
>>>>         
>>> Hmm, well, your comments about the delete_move_next plugin didn't
>>> match what I see there, but I am not sure I've updated it in a while.
>>> I can double-check, but so should you.
>>>
>>>       
>> in 1.4svn2008-11-27: plugins/delete_move_next/setup.php:
>> function delete_move_next_read: lines 169-173
>> there are used operators > and --
>>     
>
> Right.
>
>   
>> in 1.5svn2008-11-27: there is no delete_move_next plugin and also I've
>> found no arithmetic
>> operators (just quick search).
>>     
>
> Yes, the UIDs are kept in an ordered array, from which positional
> judgments can be more accurately made.
>
>   
>> so... arithmetic operators are used only in 1.4 in delete_move_next
>> plugin, but this is the
>> version I need to fix the most (can't take devel version into on the
>> production hosts).
>>     
>
> Then I suggest you put a patch together for your float implementation
> and put it on the SquirrelMail tracker (feel free to post a link to it
> here).  We will review it, but again, as of now, I think the only
> place we plan to make this change is in our 1.5.x branch.
>
> Thanks a lot for your help.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> -----
> squirrelmail-devel mailing list
> Posting guidelines: http://squirrelmail.org/postingguidelines
> List address: squirrelmail-devel@...
> List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
> List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel
>

one note... in patch for 1.4 there is wrongly specified tag @since 1.5.3 
instead of 1.4.18
(squirrelmail/functions/global.php, on the top of the patch)

Michal Hlavinka wrote:
> Hi,
>
> all patches, we were talking about are ready (attached).
>
> patches are against 1.4 svn and 1.5 svn (yesterday)
> In the end, I've used conversion to string in both of them. Only 1.4 
> contains
> additional conversion in sources of delete_and_next plugin to float
> to perform arithmetic operations.
>
> I've tested both of them with dovecot and manually created messages 
> with high
> uids. Both versions were working on systems with 64bit php, both of them
> resulted with imap error on 32 bit system.
>
> Now both of them works on 64 and 32 bit systems. I've checked this 
> functions:
> send email (created email got big uid from dovecot) - successfully 
> stored in Sent and readable
> move emails between folders
> next & prev
> delete and next & delete and prev
> delete email
> forward
> edit
> view header
> forward as attachment and read both email and the attachment in Sent 
> folder
>
> Both patches has only changes to the code text for changelog/other 
> document is missing.
>
> Regards,
>
> Michal Hlavinka
>

Please do not top-post.  Please review our mailing list posting
guidelines (linked at the bottom of all messages on this list) for
more information about how to post on our lists.

>>>>> In fact it's not so much code. Only replace $a=(int)$b; to
>>>>> $a=sqrestrict_to_num($b);
>>>>> sqrestrict_to_int contains only : return (is_numeric($b) ? $b : 0);
>>>>> Casting not int to int
>>>>> results to 0, so there is no change.
>>>>>
>>>>>
>>>>
>>>> Not sure what you mean by "no change", but this seems about right.
>>>>
>>>>
>>>
>>> "no change" as invalid values will still be changed to 0.
>>>
>>>
>>>>
>>>> The "this much code" comment was based more on the number of pages
>>>> that may need to be changed, not that the change itself is big.
>>>>
>>>>
>>>
>>> the number of pages (at least in 1.4svn) wasn't so high
>>>
>>>
>>>>
>>>> However, I'm not sure we'd want to use is_numeric().  See the PHP
>>>> manual regarding how it accepts scientific notation and hex numbers
>>>> and decimal points.  Rather, I believe we only want
>>>> preg_match('/^[0-9]$/'), no?
>>>>
>>>>
>>>
>>> I've preferred is_numeric because it checks if variable is a numeric
>>> string or a number.
>>> The reason for is_numeric/other check is because of sanitizing "ugly"
>>> "accidental" values
>>>
>>
>> SquirrelMail does not create "accidental" values.  As far as I know,
>> UIDs should only contain digits.  is_numeric() allows things other
>> than digits.  My regexp is very easy to understand - easier than
>> looking up what is_numeric() allows in fact.  I do not see any reason
>> why using is_numeric() is better than that regexp, especially if the
>> target format is a string.
>>
>>
>>>
>>> and number (even in scientific form) can cause no harm at all. Also
>>> is_numeric was
>>> my first thought and it works :)
>>>
>>>
>>>>>>>
>>>>>>> but I've found squirrelmail uses also
>>>>>>> ++, -- and comparison operators for UIDs (in
>>>>>>> plugins/delete_move_next/setup.php: 152: delete_move_next_read(...)
>>>>>>> function). So strings can't be used for this
>>>>>>>
>>>>>>
>>>>>> I think you are using an outdated version of SM.
>>>>>>
>>>>>>
>>>>>
>>>>> svn 1.4 is outdated?
>>>>> (
>>>>>
>>>>> http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4-STABLE/squirrelmail/
>>>>> )
>>>>>
>>>>>
>>>>
>>>> Hmm, well, your comments about the delete_move_next plugin didn't
>>>> match what I see there, but I am not sure I've updated it in a while.
>>>> I can double-check, but so should you.
>>>>
>>>>
>>>
>>> in 1.4svn2008-11-27: plugins/delete_move_next/setup.php:
>>> function delete_move_next_read: lines 169-173
>>> there are used operators > and --
>>>
>>
>> Right.
>>
>>
>>>
>>> in 1.5svn2008-11-27: there is no delete_move_next plugin and also I've
>>> found no arithmetic
>>> operators (just quick search).
>>>
>>
>> Yes, the UIDs are kept in an ordered array, from which positional
>> judgments can be more accurately made.
>>
>>
>>>
>>> so... arithmetic operators are used only in 1.4 in delete_move_next
>>> plugin, but this is the
>>> version I need to fix the most (can't take devel version into on the
>>> production hosts).
>>>
>>
>> Then I suggest you put a patch together for your float implementation
>> and put it on the SquirrelMail tracker (feel free to post a link to it
>> here).  We will review it, but again, as of now, I think the only
>> place we plan to make this change is in our 1.5.x branch.
>>
>> Thanks a lot for your help.
>
> all patches, we were talking about are ready (attached).

Thank you.  (No need to paste them in the email body too.)

> patches are against 1.4 svn and 1.5 svn (yesterday)
> In the end, I've used conversion to string in both of them. Only 1.4
> contains
> additional conversion in sources of delete_and_next plugin to float
> to perform arithmetic operations.

Thank you.  We won't be applying this to 1.4 for now, but I have
attached it to the tracker item you created.  For 1.5, I have just
applied some changes that are different from yours, so we'd really
appreciate if you could download the newest 1.5.2 SVN code (if using
snapshots, wait at least 24 hours, or see the attached patch) and test
that it works.

I have a couple plugins (beside the core ones I changed in 1.5.2) that
need corresponding changes, which I will release soon, especially if I
can get feedback on the 1.5.2 changes.

Thanks again very much for your help.

> I've tested both of them with dovecot and manually created messages with
> high
> uids. Both versions were working on systems with 64bit php, both of them
> resulted with imap error on 32 bit system.
>
> Now both of them works on 64 and 32 bit systems. I've checked this
> functions:
> send email (created email got big uid from dovecot) - successfully stored in
> Sent and readable
> move emails between folders
> next & prev
> delete and next & delete and prev
> delete email
> forward
> edit
> view header
> forward as attachment and read both email and the attachment in Sent folder
>
> Both patches has only changes to the code text for changelog/other document
> is missing.

>> all patches, we were talking about are ready (attached).
>>
>> patches are against 1.4 svn and 1.5 svn (yesterday)
>> In the end, I've used conversion to string in both of them. Only 1.4
>> contains
>> additional conversion in sources of delete_and_next plugin to float
>> to perform arithmetic operations.
>>
>> I've tested both of them with dovecot and manually created messages
>> with high
>> uids. Both versions were working on systems with 64bit php, both of them
>> resulted with imap error on 32 bit system.
>>
>> Now both of them works on 64 and 32 bit systems. I've checked this
>> functions:
>> send email (created email got big uid from dovecot) - successfully
>> stored in Sent and readable
>> move emails between folders
>> next & prev
>> delete and next & delete and prev
>> delete email
>> forward
>> edit
>> view header
>> forward as attachment and read both email and the attachment in Sent
>> folder
>>
>> Both patches has only changes to the code text for changelog/other
>> document is missing.
>
> one note... in patch for 1.4 there is wrongly specified tag @since 1.5.3
> instead of 1.4.18
> (squirrelmail/functions/global.php, on the top of the patch)

There is no such thing as 1.5.3, so it's wrong in both places, but no
big deal!  :-)

...
>> all patches, we were talking about are ready (attached).
>>     
>
> Thank you.  (No need to paste them in the email body too.)
>
>   
I didn't paste them in email body, only attached them. Maybe thunderbird 
did it?
Anyway, on the mailing list archive they are not pasted in text too.

> There is no such thing as 1.5.3, so it's wrong in both places, but no
> big deal! 
I meant actual released version is 1.5.2 so first time, it'd be released 
in 1.5.3

>> patches are against 1.4 svn and 1.5 svn (yesterday)
>> In the end, I've used conversion to string in both of them. Only 1.4
>> contains
>> additional conversion in sources of delete_and_next plugin to float
>> to perform arithmetic operations.
>>     
>
> Thank you.  We won't be applying this to 1.4 for now, but I have
> attached it to the tracker item you created.  For 1.5, I have just
> applied some changes that are different from yours, so we'd really
> appreciate if you could download the newest 1.5.2 SVN code (if using
> snapshots, wait at least 24 hours, or see the attached patch) and test
> that it works.
>   
I've checked this functions:
* send email (created email got big uid from dovecot) - successfully 
stored in Sent and readable
* move emails between folders
* next & prev
* delete and next & delete and prev
* delete email
* forward
* edit
* view header
* forward as attachment and read both email and the attachment in Sent 
folder

it works.

I need 1.4 working with big uids, so I'm going to apply this (or 
modified) patch to our
squirrelmail rpm packages, so I wonder what's the destiny of the 1.4 patch?

> I have a couple plugins (beside the core ones I changed in 1.5.2) that
> need corresponding changes, which I will release soon, especially if I
> can get feedback on the 1.5.2 changes.
>
> Thanks again very much for your help.
>   
Is there any ETA for 1.5 beta, rc, final?

Michal

>> There is no such thing as 1.5.3, so it's wrong in both places, but no
>> big deal!
> I meant actual released version is 1.5.2 so first time, it'd be released
> in 1.5.3

1.5.2 has not been released yet.  It would in fact be released in version 1.5.2.

>>> patches are against 1.4 svn and 1.5 svn (yesterday)
>>> In the end, I've used conversion to string in both of them. Only 1.4
>>> contains
>>> additional conversion in sources of delete_and_next plugin to float
>>> to perform arithmetic operations.
>>>
>>
>> Thank you.  We won't be applying this to 1.4 for now, but I have
>> attached it to the tracker item you created.  For 1.5, I have just
>> applied some changes that are different from yours, so we'd really
>> appreciate if you could download the newest 1.5.2 SVN code (if using
>> snapshots, wait at least 24 hours, or see the attached patch) and test
>> that it works.
>
> I've checked this functions:
> * send email (created email got big uid from dovecot) - successfully
> stored in Sent and readable
> * move emails between folders
> * next & prev
> * delete and next & delete and prev
> * delete email
> * forward
> * edit
> * view header
> * forward as attachment and read both email and the attachment in Sent
> folder
>
> it works.

THANK YOU SO VERY MUCH.  We really appreciate the help!!!!

> I need 1.4 working with big uids, so I'm going to apply this (or
> modified) patch to our
> squirrelmail rpm packages, so I wonder what's the destiny of the 1.4 patch?

It will continue to be available in our tracker for people who want
it, and depending on feedback and team opinions based on how popular
it is, we may decide at some time in the future that the changes in
the (stable) code are worth adding.

>> I have a couple plugins (beside the core ones I changed in 1.5.2) that
>> need corresponding changes, which I will release soon, especially if I
>> can get feedback on the 1.5.2 changes.
>>
>> Thanks again very much for your help.
>
> Is there any ETA for 1.5 beta, rc, final?

Not yet, but I'd personally like to see the heat turned up on this.
We'll see.  Help is always appreciated.