SV: [exim] Exim / POP3 with Compressed mails

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Charlie Elgholm
Datum:  
To: Nigel Metheringham
CC: exim-users
Betreff: SV: [exim] Exim / POP3 with Compressed mails
Hi Nigel!

For us it might be worth it since we're thinking of providing SMTP/POP3
access for a couple of thousand accounts. Instead of being lame and saying
something like "well, you may only store up to 10MB of email data in your
account" one might say "well, you can store up to 1000MB of email data in
your account", or "we don't care". I've seen that 1 GB of email data can be
compressed down to around 20-30 MB using bzip2 (which is slow and
CPU-intense), and maybe 50MB using gzip (which is faster).

Since our goal is to provide a fairly good and easy to use service for our
users it seems sad that one must implement quotas and limits for
everything..

I've received emails telling me to lowe my quotas and lower the amount of
email accounts a user might have. What's the fun with that? Isn't the whole
idea to actually _USE_ the computer?

I agree to everything you say about the Courier IMAP-server and how it needs
access to the individual mails (as pure text), that's also why we aren't
going to use IMAP. We do not want the emails being saved on our server when
it's un-necessary for POP3 access (as we see it).

I've also been thinking of writing my own "Webmail" interface to the
maildir. This also needs to know stuff to be able to show something for the
user. The idea here is to extract what I need BEFORE i compress the email
MIME-file. Very easy, just extract stuff like Subject, From, To, Date,
No.of.files etc.. Save this information in some kind of database backend
together with the filename to the actual email-file, and then your home
free... Jippi..

Well, I'll try and implement something using procmail or I'll write a
delivery-agent myself which implements the zlib or something. But it seems
sad to tweak the Courier-POP3 daemon as well, could be a pain in the a**
later - when you try to upgrade it.

/Charlie

> -----Ursprungligt meddelande-----
> Från: exim-users-bounces@???
> [mailto:exim-users-bounces@exim.org]För Nigel Metheringham
> Skickat: den 31 augusti 2004 16:07
> Till: exim-users@???
> Ämne: Re: [exim] Exim / POP3 with Compressed mails
>
>
> On Tue, 2004-08-31 at 15:09 +0200, Charlie Elgholm wrote:
> > Hi!
> >
> > Is there anyway to make Exim compress the mail when saving in
> in the users
> > maildir?
> > For instance:
> > post_save_command = bzip2 $file_name
>
> Ugh - maildir implementations have enough fun with filenames changing to
> implement flags without you tagging a .bz2 on the end,.
>
> > On the other hand, is there anyway for the Courier POP3D daemon to
> > "uncompress" the file before streaming them to the user via TCP/IP??
>
> I'd be surprised if there was an implementation of this for courier.  As
> well as the already stated reasons of disk being cheaper than CPU, there
> are other reasons:-
>       * Courier is primarily an IMAP server not a pop server
>       * As an IMAP server it needs to get access to the various
>         components of the MIME message, rather than treat the message as
>         a whole.
>       * This means it probably needs to seek to specific parts of a
>         message.
>       * Seeking within a simply compressed file can be a real bitch -
>         you typically have to rewind to the start and byte count from
>         there.  To get round this you need to save it as a set of
>         compressed MIME components
>       * and BINGO you have just invented a mail storage database....

>
> Theres a chance you could do something funky with appropriate use of
> zlibc - and depending on your usage patterns and hardware you might find
> the CPU is not so much of a problem as some people have indicated (crap
> IDE hardware can use significant CPU transfering to/from disk, however I
> am unconvinced that the savings would be worth it).
>
>     Nigel.

>
> --
> [ Nigel Metheringham           Nigel.Metheringham@??? ]
> [ - Comments in this message are my own and not ITO opinion/policy - ]

>
>
>
> --
>
> ## List details at

http://www.exim.org/mailman/listinfo/exim-users Exim details at
http://www.exim.org/ ##