Re: Webmail - considerations...
> I would be pretty surprised if there is no c library for IMAP as well. GNU mailutils (libmailbox) has IMAP support. It is still in development. http://www.gnu.org/software/mailutils/ Jeremy C. Reed echo 'G014AE824B0-07CC?/JJFFFI?D64CB>D=3C427=>;>6HI2>
Re: Webmail - considerations...
> I would be pretty surprised if there is no c library for IMAP as well. GNU mailutils (libmailbox) has IMAP support. It is still in development. http://www.gnu.org/software/mailutils/ Jeremy C. Reed echo 'G014AE824B0-07CC?/JJFFFI?D64CB>D=3C427=>;>6HI2>
Re: Webmail - considerations...
Przemyslaw Wegrzyn wrote: > > On Tue, 12 Jun 2001, Jeremy Lunn wrote: > > > On Tue, Jun 12, 2001 at 02:59:00PM +0200, Przemyslaw Wegrzyn wrote: > > > Of course, I know... > > > But our middle-tier will be developed using C++ , AFAIK. > > > That's why I asked about c-client library... > > > > I would be pretty surprised if there is no c library for IMAP as well. > > Sure, but I'd like to check if there are any alternatives to > c-client. IMHO it's poorly documented. You may have already looked at this, but what does Mutt use? It does IMAP, and I get the impression that stuff was done from scratch.
Re: Webmail - considerations...
Przemyslaw Wegrzyn wrote: > > On Tue, 12 Jun 2001, Jeremy Lunn wrote: > > > On Tue, Jun 12, 2001 at 02:59:00PM +0200, Przemyslaw Wegrzyn wrote: > > > Of course, I know... > > > But our middle-tier will be developed using C++ , AFAIK. > > > That's why I asked about c-client library... > > > > I would be pretty surprised if there is no c library for IMAP as well. > > Sure, but I'd like to check if there are any alternatives to > c-client. IMHO it's poorly documented. You may have already looked at this, but what does Mutt use? It does IMAP, and I get the impression that stuff was done from scratch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Webmail - considerations...
http://packages.debian.org/testing/libs/libc-client4.7.html The above is a c client library for imap written by the University of Washington (not sure, but I don't think that package is the latest version but you can get the source from UW if you want). vector - Original Message - From: "Jeremy Lunn" <[EMAIL PROTECTED]> To: "Przemyslaw Wegrzyn" <[EMAIL PROTECTED]> Cc: "Russell Coker" <[EMAIL PROTECTED]>; ; Sent: Tuesday, June 12, 2001 7:03 AM Subject: Re: Webmail - considerations... > On Tue, Jun 12, 2001 at 02:59:00PM +0200, Przemyslaw Wegrzyn wrote: > > Of course, I know... > > But our middle-tier will be developed using C++ , AFAIK. > > That's why I asked about c-client library... > > I would be pretty surprised if there is no c library for IMAP as well. > > -- > Jeremy Lunn > Melbourne, Australia > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: Webmail - considerations...
On Tue, 12 Jun 2001, Jeremy Lunn wrote: > On Tue, Jun 12, 2001 at 02:59:00PM +0200, Przemyslaw Wegrzyn wrote: > > Of course, I know... > > But our middle-tier will be developed using C++ , AFAIK. > > That's why I asked about c-client library... > > I would be pretty surprised if there is no c library for IMAP as well. Sure, but I'd like to check if there are any alternatives to c-client. IMHO it's poorly documented. Probably I need to dig its source code... -=Czaj-nick=-
Re: Webmail - considerations...
http://packages.debian.org/testing/libs/libc-client4.7.html The above is a c client library for imap written by the University of Washington (not sure, but I don't think that package is the latest version but you can get the source from UW if you want). vector - Original Message - From: "Jeremy Lunn" <[EMAIL PROTECTED]> To: "Przemyslaw Wegrzyn" <[EMAIL PROTECTED]> Cc: "Russell Coker" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; Sent: Tuesday, June 12, 2001 7:03 AM Subject: Re: Webmail - considerations... > On Tue, Jun 12, 2001 at 02:59:00PM +0200, Przemyslaw Wegrzyn wrote: > > Of course, I know... > > But our middle-tier will be developed using C++ , AFAIK. > > That's why I asked about c-client library... > > I would be pretty surprised if there is no c library for IMAP as well. > > -- > Jeremy Lunn > Melbourne, Australia > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Webmail - considerations...
On Tue, 12 Jun 2001, Jeremy Lunn wrote: > On Tue, Jun 12, 2001 at 01:26:09PM +0200, Przemyslaw Wegrzyn wrote: > > Thanx, I didn't know this feature... Acctually, I'm not so familiar with > > IMAP protocol yet... > > Depending what language you use you won't need to know the IMAP > protocol. Things like perl and php have IMAP modules. Of course, I know... But our middle-tier will be developed using C++ , AFAIK. That's why I asked about c-client library... -=Czaj-nick=-
Re: Webmail - considerations...
On Tue, Jun 12, 2001 at 01:26:09PM +0200, Przemyslaw Wegrzyn wrote: > Thanx, I didn't know this feature... Acctually, I'm not so familiar with > IMAP protocol yet... Depending what language you use you won't need to know the IMAP protocol. Things like perl and php have IMAP modules. -- Jeremy Lunn Melbourne, Australia
Re: Webmail - considerations...
On Tue, 12 Jun 2001, Jeremy Lunn wrote: > On Tue, Jun 12, 2001 at 02:59:00PM +0200, Przemyslaw Wegrzyn wrote: > > Of course, I know... > > But our middle-tier will be developed using C++ , AFAIK. > > That's why I asked about c-client library... > > I would be pretty surprised if there is no c library for IMAP as well. Sure, but I'd like to check if there are any alternatives to c-client. IMHO it's poorly documented. Probably I need to dig its source code... -=Czaj-nick=- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Webmail - considerations...
On Tue, 12 Jun 2001, Russell Coker wrote: > 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). Thanx, I didn't know this feature... Acctually, I'm not so familiar with IMAP protocol yet... > So now you're planning to write your own webmail program? Yes, we need some nonusuall features... > 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. That's as I see it, thanx.. All the actual logic will be implemented in the middle tier daemon(s). -=Czaj-nick=-
Re: Webmail - considerations...
On Tue, Jun 12, 2001 at 02:59:00PM +0200, Przemyslaw Wegrzyn wrote: > Of course, I know... > But our middle-tier will be developed using C++ , AFAIK. > That's why I asked about c-client library... I would be pretty surprised if there is no c library for IMAP as well. -- Jeremy Lunn Melbourne, Australia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Webmail - considerations...
On Tue, 12 Jun 2001, Jeremy Lunn wrote: > On Tue, Jun 12, 2001 at 01:26:09PM +0200, Przemyslaw Wegrzyn wrote: > > Thanx, I didn't know this feature... Acctually, I'm not so familiar with > > IMAP protocol yet... > > Depending what language you use you won't need to know the IMAP > protocol. Things like perl and php have IMAP modules. Of course, I know... But our middle-tier will be developed using C++ , AFAIK. That's why I asked about c-client library... -=Czaj-nick=- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Webmail - considerations...
On Tue, Jun 12, 2001 at 01:26:09PM +0200, Przemyslaw Wegrzyn wrote: > Thanx, I didn't know this feature... Acctually, I'm not so familiar with > IMAP protocol yet... Depending what language you use you won't need to know the IMAP protocol. Things like perl and php have IMAP modules. -- Jeremy Lunn Melbourne, Australia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 place. 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
Re: Webmail - considerations...
On Tue, 12 Jun 2001, Russell Coker wrote: > 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). Thanx, I didn't know this feature... Acctually, I'm not so familiar with IMAP protocol yet... > So now you're planning to write your own webmail program? Yes, we need some nonusuall features... > 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. That's as I see it, thanx.. All the actual logic will be implemented in the middle tier daemon(s). -=Czaj-nick=- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 place. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Webmail - considerations...
We are going to develop web-mail system, that's capable of handling relatively high loads. I know, there are many open source web-mail systems , but they doesn't satisfy me. Almost every falls into one of two cateogries: php based, using imap; perl cgi based, using IMAP or direct filesystem access... I'd like someone experienced with such systems help me with the following: 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 ? 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 ? 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 ? 4. Are there any libraries similar to c-client, maybe some C++ ones ? 5. Does c-client library allow to retrieve the message body (attachements) partialy (see 1) ? I've seen some /tmp access in its source code - does it dowload whole message to /tmp ? Hmm, that's all for now... TIA -=Czaj-nick=-
Webmail - considerations...
We are going to develop web-mail system, that's capable of handling relatively high loads. I know, there are many open source web-mail systems , but they doesn't satisfy me. Almost every falls into one of two cateogries: php based, using imap; perl cgi based, using IMAP or direct filesystem access... I'd like someone experienced with such systems help me with the following: 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 ? 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 ? 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 ? 4. Are there any libraries similar to c-client, maybe some C++ ones ? 5. Does c-client library allow to retrieve the message body (attachements) partialy (see 1) ? I've seen some /tmp access in its source code - does it dowload whole message to /tmp ? Hmm, that's all for now... TIA -=Czaj-nick=- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
