
                            Known bugs in SqWebMail

     * This  is really not an SqWebMail bug. The UNIX version of Netscape
       Communicator  reliably  crashes  when  you edit a lot of text in a
       TEXTAREA input for some time. First, it attempts to allocate about
       40  megabytes of RAM, then crashes soon thereafter. This is not my
       problem.  Hit 'PREVIEW' periodically, to save your unsent work. If
       Communicator  crashes,  you can recover most of your text from the
       Drafts folder.
     * Another   Communicator   bug.   When   uploading   an  attachment,
       Communicator  will  hang  if  you  select a directory instead of a
       file.
     * In  practice,  SqWebMail  is  somewhat  tolerant  of  the  mailbox
       contents  being  changed  in a middle of a session by another mail
       client,  accessing  the same account. Still, all bets are off, and
       be  aware  of  potential  consequences  (such  as  clicking on one
       message,  and  the  message  coming  up  blank, or another message
       appearing).
     * A  lot  of  disk  space  is temporarily required when a message is
       sent,  or  a  new  attachment is uploaded. When a message is sent,
       first the message is saved as a draft, in the Drafts folder. Then,
       the  draft is rewritten to the Sent folder, and the copy in Drafts
       is  deleted.  Which means that if disk quotas are used, low quotas
       will  make  it  somewhat  difficult  to  send  messages with large
       attachments.  It  gets  even  worse  when  files  are  uploaded as
       attachments.  Say  you  already  have  a message with attachments,
       totalling  500KBs.  You  are  about  to upload another 200KB file.
       First, your HTTP POST is saved in a temporary file - 200KB+change.
       Then, the uploaded file is extracted into another temporary file -
       200KB.  Then,  a  new version of your message is created, with the
       new   attachment   encoded   using  base64  -  500KB+264KB.  Total
       additional  disk  space  required  to  handle  a 200KB attachment:
       200KB+200KB+764KB.   If   you're  using  filesystem-based  quotas,
       everything  gets  counted  against  your quota. It's not as bad if
       you're  using  the  deliverquota  maildir agent, which will ignore
       most of the baggage.
     * And  from  the  "it's  not  a  bug  but a feature" department. New
       caching  and  handling  algorythm effective with version 0.11. The
       Trash  folder  is  introduced.  Instead  of  deleted  messages now
       hanging  around  in their original folder before being purged (but
       displayed  separately),  deleted  messages will now migrate to the
       Trash folder, before being purged later. When you select a message
       to  be deleted, it will show up marked with the status of D in its
       original  folder, if you go back to the folder contents page. When
       you leave the folder, it will now be moved to the Trash folder.
       What  really  happens is that when you delete a message, SqWebMail
       will  create  a  hard  link  into  the Trash folder, then mark the
       message  as  deleted  in  the  original folder. When you leave the
       folder,  SqWebMail  will  go  through  the  folder  and unlink all
       deleted messages.
       Moving  a message to another folder works exactly the same, except
       that the message is linked into that folder, instead of Trash.
       If  you  move  a message to another folder, and you immediately go
       back to the folder contents window (or you move a message directly
       from  the  folder  contents  window),  the message will show up as
       deleted.  If  you try to move a message again into another folder,
       this  operation  will  quietly  fail  without  giving you an error
       message.
     * Because  messages  are  displayed  as a part of an HTML page (as a
       table cell, actually), styles and BODY attributes of HTML messages
       are  lost. BGCOLOR should really become BGCOLOR of the table cell;
       similarly  LINK, ALINK, VLINK should be implemented as a style, as
       well as any STYLE attributes from the BODY tag.
     * Netscape   Communicator   does   not  yet  support  all  HTML  4.0
       attributes. Once you move or delete a message from a mailbox, it's
       marked as a 'D', and you can't do anything with it. If you want to
       move the message again, go to the folder where you moved it to. In
       the  folder contents page, messages marked with a D get a DISABLED
       attribute  for  their checkmark. Communicator does not support the
       disabled  tag,  so if you try to move or delete the message again,
       it'll be a no-op.
