In this document:
It is possible to configure SqWebMail to transmit the userid and password via secure HTTP. If secure HTTP is not available, the userid and password is transmitted over the network in the clear, which can be picked up by a sniffer.
Technically, the mailboxid that's generated by recent versions of sqwebmail are of the form "userid.method", where method represents the authentication module that was used.
A mailboxid is sent with every HTTP request, in the request itself. Note that the mailboxid is transmitted over the network in the clear. It is also possible to use secure HTTP for the every HTTP request, not just initial authentication, but this has not been tested.
Unless the mailboxid is the same as a userid, there aren't many security considerations in having the mailboxid broadcasted over the network. That's because the mailboxid in the HTTP request is usually validated based on a time-limited IP address (see "Authentication"). Note that there certain other potential ways - in addition to network traffic sniffing - for an unauthorized party to attempt to grab mailboxids. See "Browser Security - HTML", and "Browser Security - Referrer: Tags".
By default, SqWebMail permits access to the mailbox only from the same IP address as the one where the user ID and password was authenticated from. This can be selectively turned off at login time, in cases where the client is behind a load-balancing firewall that uses multiple IP addresses. In all cases, a 128-bit random number must be transmitted with every HTTP request, and it must match the number generated during the login, which is saved in the Maildir directory.
The Maildir directory must therefore have any group or world access rights disabled. Additionally, every page served by SqWebMail includes HTTP headers containing instructions to proxies and browsers that prohibit this page from being cached. There are some buggy web browsers out there - most of them originating in Redmond,WA - that ignore these caching directives, and they end up saving the 128-bit random number in the local cache. Unless access to the physical machine is secured, the local cache can be trawled to obtain the 128-bit authentication token.
However, access to the mailbox is allowed only for a maximum period of time after the initial authentication. Access is allowed only if the HTTP requests come within a different, shorter period of time. If no access requests have been made for a certain period of time, access will no longer be available even if it comes from the right IP address, with the right authentication token.
The IP address of the initial authentication, the dates and times involved, are all stored in files in the maildir directory, with group and world permissions turned off.
SqWebMail uses a frame window in an attempt to keep the browser from recording visited URLs. This approach works for most popular web browsers that support frames - these browsers do not maintain history for individual frames. Note that frames are not required to access the full SqWebMail functionality.
SqWebMail depends on the mail server to read the headers for recipients and to strip out the Bcc: header. SqWebMail uses the black-box authentication module to set the contents of the From: header and provide the envelope return address.
The IP address of the HTTP client is not inserted into the headers,
however the wrapper and the mail server are invoked under the userid of an
authenticated user. The wrapper shell script can be modified to insert the IP
address, if so desired. The wrapper shell script has access to the CGI
REMOTE_ADDR environment variable.
sqwebmaild is the meat of the code. It's a daemon process
that runs as root, and listens on a publicly-available UNIX domain socket.
The tiny sqwebmail CGI binary is a stub that connects to the
daemon, forwards the HTTP request, and passes along sqwebmaild
output to the HTTP client.
sqwebmaild essentially receives a bunch of environment
variables that comprise the HTTP request. Anyone on the system may connect to
sqwebmaild's socket, and send it a bunch of environment
variables, just like anyone can connect to the server and send any HTTP
request to it. However, sqwebmaild places an upper limit on the
size of the environment, and will only accept the environment variables which
are used in HTTP request, discarding any environment variables that it does
not recognize (PATH, LD_LIBRARY_PATH, etc...).
When virtual mailboxes are being used, it is possible to run
sqwebmaild under the virtual userid, instead of root. Apart from
the obvious changes, the --with-cacheowner option must be used
so that the login cache is owned by the virtual userid also.
On some platforms this may not work without some additional tweaking. If authenticating with sqwebmail setuided to the virtual userid doesn't work:
void authchangegroup() {}
void authchangeuidgid() {}
void authchangeusername() {}
sqwebmaild takes the following action when it receives an
HTTP request via the local socket: