[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Webmail - considerations...

On Sunday 10 June 2001 17:16, Przemyslaw Wegrzyn wrote:
> 1. Almost every available webmail system uses the following way of
> handling (rreceiving, in this example) attachements: load the whole
> message body from IMAP server or message file, decode it and send to
> the client.
> The _whole_ attachement gets loaded into server's RAM. Isn't it waste
> of resources/ killing the server ?
> I think it should read/decode/send the attachement on a line-by-line
> (or part-by-part generaly) manner. Am I right ?

That depends what your average message size is.  If you have some 
unlikely situation such as people using the webmail system for no other 
purpose than to send messages with Word documents attached then that 
would be a serious performance issue.

However my experience is that average message sizes tend to be around 10K 
to 20K.  When you consider the overhead of an Apache process, the kernel 
buffers for a connected socket, the data used for the PHP or Perl 
interpreter, etc then 20K of message probably isn't a large proportion of 
the memory in use for the connection.

> 2. Which one is better - accessing maildirs directly, or using IMAP ?
>  I can see that IMAP seems to be more scalable / universal... Maildirs
> probably can be much faster to work with directly, but probably less
> secure...
> Any other pros/contras ?

One issue is that when using IMAP the WebMail system can consider that 
anyone with the correct credentials to connect to IMAP can access the 
account.  That means that all the password checking code is in the IMAP 
and POP servers.  If you access the Maildir directly then it's a third 

Another thing, do the webmail systems use directory notifications?  With 
directory notifications the application can be informed by the kernel 
when new files are created.  The IMAP protocol supports announcing new 
mail to the client.  If the mail store and the webmail system are on 
separate machines then IMAP is the only way to avoid polling for new mail 
(AFAIK directory notifications don't work over NFS).

> 3. I'm going to develop the front-end  using Apache::ASP or php, not
> decided yet, and access the mails through the middle-tier daemon.
> The question is - is it a good way to use persistent IMAP connections ?
> If so, there will be no overhead of authentication on every operation,
> but there can be many open IMAP connections to the local imap server
> (probably Courier-IMAP) at the same time.
> Which strategy is better ?

So now you're planning to write your own webmail program?

I suggest that when a user logs in they get an IMAP connection.  An 
option to have the IMAP connection timeout and be closed before the 
webmail system times out (webmail timeout on no activity should be long 
like 30 minutes while IMAP timeout should be 10 minutes at most) would be 
handy, but isn't required.  But generally IMAP connections should stay 
open for the duration of the session.

Good luck!

http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page

Reply to: