RE: persistent Mail::ImapClient and webmail
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
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
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
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
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.
>
>
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.
