RE: persistent Mail::ImapClient and webmail

2002-06-10 Thread Joe Breeden

That's not necessarily the most secure way. We have found that even though IMAP is 
supposed to be a long state protocol many clients (PINE, Netscape, Balsa, M$ Outlook 
Express, etc) implement as connect/work/disconnect cycle. So I don't think this 
persistency of connection across multiple accesses is really necessary.

> -Original Message-
> From: Ask Bjoern Hansen [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, June 08, 2002 5:32 PM
> To: Richard Clarke
> Cc: [EMAIL PROTECTED]
> Subject: Re: persistent Mail::ImapClient and webmail
> 
> 
> On Fri, 7 Jun 2002, Richard Clarke wrote:
> 
> > p.s. Yes quite obviously if I have 100 children then I'll 
> be connected to
> > the IMAP server 100 times per user, hence possibly the need 
> to have a either
> > a dedicated daemon connected to the IMAP server once or 
> some successfuly way
> > of sharing IMAP objects between children.
> 
> the trivial way would be to have the mod_perl processes login (once
> each) as some kind of super user and then access the folders as
> "[username]/INBOX" etc.
> 
> 
>  - ask
> 
> -- 
> ask bjoern hansen, http://ask.netcetera.dk/   !try; do();
> 
> 



RE: persistent Mail::ImapClient and webmail

2002-06-10 Thread Joe Breeden



We 
implemented our own because mail is one part of a larger application and we 
needed it to be integrated with all the other part of the application. For 
a pointer on the backend server config we used see the url http://howtos.eoutfitters.net/email. 
I believe that the webmail that comes with courier-imap should work with this 
configuration.
 
Thanks,
 
Joe

  -Original Message-From: Medi Montaseri 
  [mailto:[EMAIL PROTECTED]]Sent: Saturday, June 08, 2002 5:13 
  PMTo: Joe BreedenCc: 
  [EMAIL PROTECTED]Subject: Re: persistent Mail::ImapClient and 
  webmailI was wondering why you implemented your own vs 
  using any of the following 
  - twig http://twig.screwdriver.net - Open 
  WebMail http://www.openwebmail.org 
  - WING http://users.ox.ac.uk/~mbeattie/wing/ 
  - IMP http://www.horde.org/imp/ 
  I am asking because I'm also interested in such an application (ie a 
  webmail app) Did you find something wrong with the above list, etc... 
  I tried WING, its PostgreSQL and Perl based, and very scalable but I found 
  the installation a hellas all complex systems would be 
  Thanks 
  Joe Breeden wrote: 
  We implemented a webmail front end with 
Mail::IMAPClient and Mail::IMAPClient::BodyStructure without persistent 
connections and it seems to work fine with several hundred connections. We 
just opened up a connection to server do what we want then disconnect on 
each request. I'm sure through persistent objectification we could have 
reduced the load on the IMAP server and sped up the retrieval process, but 
what we did worked fine. 
We use qmail/maildrop/courier-imap for the mail storage see http://howtos.eoutfitters.net/email 
for destructions on how to config that setup. I would share the code we used 
for the IMAP client, but my company does sell that as a service so I think 
they might get mad if I gave away our product. 
I hope this helps. 
Joe 
> -Original Message- > From: Richard Clarke [mailto:[EMAIL PROTECTED]] 
> Sent: Friday, June 07, 2002 9:28 AM > To: 
[EMAIL PROTECTED] > Subject: persistent Mail::ImapClient and 
webmail > > > List, > I 
have the task in my hands of creating a web mail > application. 
Initial > thoughts lead me to think I would use an external popper to 
> pop mail and > parse it into a database for retrieval by the 
modperl > application. The only > problem here is that I must 
provide the implementation of the > mail storage > and folder 
management etc. Something I would rather not spend > my time on. So 
> my thoughts turned to IMAP. Retrieve the mail from an IMAP > 
server. IMAP > itself supports most mail management methods such as 
move > message, delete > message, save draft, mark seen etc. 
So a few lines of perl > later I had a > PerlChildInitHandler 
which connected to the IMAP server and saved the > connection object. 
I wanted to know if people saw any > immediate problems > with 
this solution and also if anyone could explain the following > 
percularities. > > If I store a single imap object in $imap, 
e.g. > my $imap; > sub connect { 
> my ($self,$centro_id) = @_; 
> print STDERR $imap,"\n"; 
> unless (defined $imap) { 
> print STDERR 
"Connecting to IMAP for $centro_id\n"; 
> $imap = 
Mail::IMAPClient->new( Server => > 'cyrus.andrew.cmu.edu', 
>    
User   => 'anonymous', 
>    
Password => '[EMAIL PROTECTED]', 
>    
); > } > 
return $imap; > } > > This seems to successfully save 
the connection object. > However if I attempt > to store the 
object in a hash, e.g. > my %imap_cache; > sub connect { 
> my ($self,$centro_id) = @_; 
> print STDERR $imap,"\n"; 
> unless (exists $imap_cache{$centro_id}) { 
> print STDERR 
"Connecting to IMAP for $centro_id\n"; 
> 
$imap_cache{$centro_id} = Mail::IMAPClient->new( Server => > 
'cyrus.andrew.cmu.edu', 
>    
User   => 'anonymous', 
>    
Password => '[EMAIL PROTECTED]', 
>    
); > } > 
return $imap_cache{$centro_id}; > } > > I seem to have 
intermitent success in retrieving an already connected > object. 
Using the first example, as far as I can tell the > object remains 
> available flawlessley. But storing the object in the hash > 
doesn't. Am I > making a mistake here? > > Another 
question sprung to mind, should I think about using > 
Persistant::Base > or some similar approach to store the IMAP 
objects?, or should I lean > towards Randal's and others suggestions 
of having a seperate > (possibles SOAP >

Re: persistent Mail::ImapClient and webmail

2002-06-08 Thread Ask Bjoern Hansen

On Fri, 7 Jun 2002, Richard Clarke wrote:

> p.s. Yes quite obviously if I have 100 children then I'll be connected to
> the IMAP server 100 times per user, hence possibly the need to have a either
> a dedicated daemon connected to the IMAP server once or some successfuly way
> of sharing IMAP objects between children.

the trivial way would be to have the mod_perl processes login (once
each) as some kind of super user and then access the folders as
"[username]/INBOX" etc.


 - ask

-- 
ask bjoern hansen, http://ask.netcetera.dk/   !try; do();




Re: persistent Mail::ImapClient and webmail

2002-06-08 Thread Medi Montaseri


I was wondering why you implemented your own vs using any of the following
- twig http://twig.screwdriver.net
- Open WebMail http://www.openwebmail.org
- WING http://users.ox.ac.uk/~mbeattie/wing/
- IMP http://www.horde.org/imp/
I am asking because I'm also interested in such an application (ie a
webmail app)
Did you find something wrong with the above list, etc...
I tried WING, its PostgreSQL and Perl based, and very scalable but
I found the
installation a hellas all complex systems would be
Thanks
Joe Breeden wrote:
We implemented a webmail front end with Mail::IMAPClient
and Mail::IMAPClient::BodyStructure without persistent connections and
it seems to work fine with several hundred connections. We just opened
up a connection to server do what we want then disconnect on each request.
I'm sure through persistent objectification we could have reduced the load
on the IMAP server and sped up the retrieval process, but what we did worked
fine.
We use qmail/maildrop/courier-imap for the mail storage see http://howtos.eoutfitters.net/email
for destructions on how to config that setup. I would share the code we
used for the IMAP client, but my company does sell that as a service so
I think they might get mad if I gave away our product.
I hope this helps.
Joe
> -Original Message-
> From: Richard Clarke [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 07, 2002 9:28 AM
> To: [EMAIL PROTECTED]
> Subject: persistent Mail::ImapClient and webmail
>
>
> List,
> I have the task in my hands of creating a
web mail
> application. Initial
> thoughts lead me to think I would use an external popper to
> pop mail and
> parse it into a database for retrieval by the modperl
> application. The only
> problem here is that I must provide the implementation of the
> mail storage
> and folder management etc. Something I would rather not spend
> my time on. So
> my thoughts turned to IMAP. Retrieve the mail from an IMAP
> server. IMAP
> itself supports most mail management methods such as move
> message, delete
> message, save draft, mark seen etc. So a few lines of perl
> later I had a
> PerlChildInitHandler which connected to the IMAP server and saved
the
> connection object. I wanted to know if people saw any
> immediate problems
> with this solution and also if anyone could explain the following
> percularities.
>
> If I store a single imap object in $imap, e.g.
> my $imap;
> sub connect {
> my ($self,$centro_id) = @_;
> print STDERR $imap,"\n";
> unless (defined $imap) {
> print STDERR "Connecting
to IMAP for $centro_id\n";
> $imap = Mail::IMAPClient->new(
Server =>
> 'cyrus.andrew.cmu.edu',
>   
User   => 'anonymous',
>   
Password => '[EMAIL PROTECTED]',
>   
);
> }
> return $imap;
> }
>
> This seems to successfully save the connection object.
> However if I attempt
> to store the object in a hash, e.g.
> my %imap_cache;
> sub connect {
> my ($self,$centro_id) = @_;
> print STDERR $imap,"\n";
> unless (exists $imap_cache{$centro_id}) {
> print STDERR "Connecting
to IMAP for $centro_id\n";
> $imap_cache{$centro_id}
= Mail::IMAPClient->new( Server =>
> 'cyrus.andrew.cmu.edu',
>   
User   => 'anonymous',
>   
Password => '[EMAIL PROTECTED]',
>   
);
> }
> return $imap_cache{$centro_id};
> }
>
> I seem to have intermitent success in retrieving an already connected
> object. Using the first example, as far as I can tell the
> object remains
> available flawlessley. But storing the object in the hash
> doesn't. Am I
> making a mistake here?
>
> Another question sprung to mind, should I think about using
> Persistant::Base
> or some similar approach to store the IMAP objects?, or should I
lean
> towards Randal's and others suggestions of having a seperate
> (possibles SOAP
> or LWP::Daemon or even apache server in single user mode) server
> specifically designed for performing IMAP requests?
>
> Finally, does anyone with experience in having to write
> webmail interfaces
> see any problems with using the functionality provided by IMAP.
>
> Richard
>
> p.s. Yes quite obviously if I have 100 children then I'll be
> connected to
> the IMAP server 100 times per user, hence possibly the need
> to have a either
> a dedicated daemon connected to the IMAP server once or some
> successfuly way
> of sharing IMAP objects between children.
>
>

-- 
-
Medi Montaseri   [EMAIL PROTECTED]
Unix Distributed Systems Engineer    HTTP://www.CyberShell.com
CyberShell Engineering
-
 


RE: persistent Mail::ImapClient and webmail

2002-06-07 Thread Joe Breeden

We implemented a webmail front end with Mail::IMAPClient and 
Mail::IMAPClient::BodyStructure without persistent connections and it seems to work 
fine with several hundred connections. We just opened up a connection to server do 
what we want then disconnect on each request. I'm sure through persistent 
objectification we could have reduced the load on the IMAP server and sped up the 
retrieval process, but what we did worked fine. 

We use qmail/maildrop/courier-imap for the mail storage see 
http://howtos.eoutfitters.net/email for destructions on how to config that setup. I 
would share the code we used for the IMAP client, but my company does sell that as a 
service so I think they might get mad if I gave away our product.

I hope this helps.

Joe

> -Original Message-
> From: Richard Clarke [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 07, 2002 9:28 AM
> To: [EMAIL PROTECTED]
> Subject: persistent Mail::ImapClient and webmail
> 
> 
> List,
> I have the task in my hands of creating a web mail 
> application. Initial
> thoughts lead me to think I would use an external popper to 
> pop mail and
> parse it into a database for retrieval by the modperl 
> application. The only
> problem here is that I must provide the implementation of the 
> mail storage
> and folder management etc. Something I would rather not spend 
> my time on. So
> my thoughts turned to IMAP. Retrieve the mail from an IMAP 
> server. IMAP
> itself supports most mail management methods such as move 
> message, delete
> message, save draft, mark seen etc. So a few lines of perl 
> later I had a
> PerlChildInitHandler which connected to the IMAP server and saved the
> connection object. I wanted to know if people saw any 
> immediate problems
> with this solution and also if anyone could explain the following
> percularities.
> 
> If I store a single imap object in $imap, e.g.
> my $imap;
> sub connect {
> my ($self,$centro_id) = @_;
> print STDERR $imap,"\n";
> unless (defined $imap) {
> print STDERR "Connecting to IMAP for $centro_id\n";
> $imap = Mail::IMAPClient->new( Server => 
> 'cyrus.andrew.cmu.edu',
>User   => 'anonymous',
>Password => '[EMAIL PROTECTED]',
>);
> }
> return $imap;
> }
> 
> This seems to successfully save the connection object. 
> However if I attempt
> to store the object in a hash, e.g.
> my %imap_cache;
> sub connect {
> my ($self,$centro_id) = @_;
> print STDERR $imap,"\n";
> unless (exists $imap_cache{$centro_id}) {
> print STDERR "Connecting to IMAP for $centro_id\n";
> $imap_cache{$centro_id} = Mail::IMAPClient->new( Server =>
> 'cyrus.andrew.cmu.edu',
>User   => 'anonymous',
>Password => '[EMAIL PROTECTED]',
>);
> }
> return $imap_cache{$centro_id};
> }
> 
> I seem to have intermitent success in retrieving an already connected
> object. Using the first example, as far as I can tell the 
> object remains
> available flawlessley. But storing the object in the hash 
> doesn't. Am I
> making a mistake here?
> 
> Another question sprung to mind, should I think about using 
> Persistant::Base
> or some similar approach to store the IMAP objects?, or should I lean
> towards Randal's and others suggestions of having a seperate 
> (possibles SOAP
> or LWP::Daemon or even apache server in single user mode) server
> specifically designed for performing IMAP requests?
> 
> Finally, does anyone with experience in having to write 
> webmail interfaces
> see any problems with using the functionality provided by IMAP.
> 
> Richard
> 
> p.s. Yes quite obviously if I have 100 children then I'll be 
> connected to
> the IMAP server 100 times per user, hence possibly the need 
> to have a either
> a dedicated daemon connected to the IMAP server once or some 
> successfuly way
> of sharing IMAP objects between children.
> 
>