o $myfold always points to the correct folder key
o When reseting, no need to count, just set. The
replacements have been created anyway, no matter what.
the references to the images with a link to download.php?something, this link is not valid for
the recipient and causes logout if it uses telaen (because the params are not valid).
All logouts are replaced with a simple die(), so the script ends without cause problem at
the rest of the system.
1. Clean up cases where the user has pre-post whitespace
which can cause folder problems
2. Clean up "valid folders" concept. Also, make sure
that any filters which cause a MOVE to a folder
actually points to a valid folder ;)
Alignment on name-style for forms elements. (Jim It's better to remove also the f_ prefix from the old ones?)
Some cleanups on default theme, restyled button. (Do you like it??)
use a multi command, the Imap session id will be attached at the headers like this:
-> 45f17bb0e16e5 APPEND "sent" (\SEEN) {544}
-> 45f17bb0e16e5 Date: Fri, 9 Mar 2007 16:22:24 +0100 ............. rest of msg ...........
and the date header is compromised on the saved message. This cause a wrong display of the date in sent folder (with
imap only)
Now html code is build on template, its natural place. Removed um prefix from smarty vars :)
Needs some more little works but works, please test!
I found smarty helpers very cools!!
don't adjust them (reduce them). Our "id" is simply an
internal store that doesn't always map to the message
number on the server. If we have messages 1-10 and delete
message number 7, then message 8 is still number
8, not the "new" number 7 (as far as the server is
concerned), even though it's in slot 7 (and it's id
should be 7).
We should just get rid of 'id'...
Performance tweak. The message numbers are actual numbers, so first
of all force that, and secondly allow for a faster sorting by
doing integer comparisons rather than natural string sorts.
BIG fix... The 'msg' field contains the actual message number,
as far as how the server marks it. The 'id' field is simply
an array counter. This means that although normally the
2 are in sync, if a message is removed internally, this is no
longer the case, and the 'id' field will not point to the
correct message. Look at below: In the first case, id 8
maps to msg 8. Now look after we delete a message. In this
case id 8 is the 8th element, or msg 9! To fetch the real
message 9 we need to look at msg (which is 9) and not
id (which would be 8, since it's the 8th message).
LIST
+OK
1 13580
2 40003
3 40697
4 3744
5 41679
6 41856
7 12043
8 2878
9 41497
10 42444
11 1117
12 1133
.
DELE 6
+OK
LIST
+OK
1 13580
2 40003
3 40697
4 3744
5 41679
7 12043
8 2878
9 41497
10 42444
11 1117
12 1133
.
This was cause by a prev. patch. Now the expunge is done always after processing al messages,
and not on every message (so the indexes don't change).
I have also added a better check when we are working on pop3 so we avoid to reconnect
on mark/unmark and with imap.
