> Although it is possible to optimize the POP3 server for huge mailboxes, I'm
> reluctant to do so, because it's going to be a pain in the neck, and I still
> believe that IMAP is the appropriate solution here.
It's probably the most appropriate - but in an ISP environment it's hard to
stop people (ab)using POP3 in this way.
Which optimisations were you thinking of?
One thing which occurs to me is that you could defer calculating the size of
each message until it's actually needed. The main time is LIST, but ISTM
that a well-behaved client would use UIDL to work out which messages it has
seen before, and not bother to LIST them.
The spanner in the works is STAT, which needs to return "the size of the
maildrop in octets ... messages marked as deleted are not counted"
But AFAICS, RFC1939 does not actually define "the size of the maildrop" to
be equal to the sum of the message sizes calculated individually :-) So you
might be able to get away with an estimate based on the file size.
Or were you thinking of encoding the POP3 size in the filename, say
,S=10000,P=10043 ?
If it comes to that, I'd be quite happy to have ,S=<POP3 size> rather than
,S=<real size>. People won't miss a few bytes off their quotas :-)
Regards,
Brian.
-------------------------------------------------------
This sf.net email is sponsored by: Are you worried about
your web server security? Click here for a FREE Thawte
Apache SSL Guide and answer your Apache SSL security
needs: http://www.gothawte.com/rd523.html
_______________________________________________
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
