+/* regenerate the session id to avoid session hyijacking */
+//FIXME! IMPORTANT! SOMEONE PLEASE EXPLAIN THE SECURITY CONCERN HERE; THIS session_destroy() BORKS ANY SESSION INFORMATION ADDED ON THE LOGIN PAGE (SPECIFICALLY THE SESSION RESTORE DATA, BUT ALSO ANYTHING ADDED BY PLUGINS, ETC)... I HAVE DISABLED THIS (AND NOTE THAT THE LOGIN PAGE ALREADY EXECUTES A session_destroy() (see includes/init.php)), SO PLEASE, WHOEVER ADDED THIS, PLEASE ANALYSE THIS SITUATION AND COMMENT ON IF IT IS OK LIKE THIS!! WHAT HIJACKING ISSUES ARE WE SUPPOSED TO BE PREVENTING HERE?
+//sqsession_destroy();
+//@sqsession_is_active();
+//session_regenerate_id();
+/**
+* The cookie part. session_start and session_regenerate_session normally set
+* their own cookie. SquirrelMail sets another cookie which overwites the
+* php cookies. The sqsetcookie function sets the cookie by using the header
+* function which gives us full control how the cookie is set. We do that
+* to add the HttpOnly cookie attribute which blocks javascript access on
+* IE6 SP1.
+*/
+sqsetcookie(session_name(),session_id(),false,$base_uri);
+sqsetcookie('key', $key, false, $base_uri);
+
+sqsession_register($onetimepad, 'onetimepad');
+
+$sqimap_capabilities = sqimap_capability($imapConnection);
+
+/* Server side sorting control */
+if (isset($sqimap_capabilities['SORT']) && $sqimap_capabilities['SORT'] == true &&
+ isset($disable_server_sort) && $disable_server_sort) {
+ unset($sqimap_capabilities['SORT']);
+}