ive.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[EMAIL PROTECTED]>
X-Comment: no
User-Agent: Mutt/1.5.8i
X-Decanonizer: decanon-milter version 0.2005.05.10
for j4RFQS1W022264 from localhost [127.0.0.1]
at 1117207588: Fri May 27 15:26:28 2005 [0.165s]
[Daniel Senie:]
>> Are these features that would make sense to consider integrating into
>> the qpopper code base and configuring with options?
I think so (perhaps obviously). We used the patch for about three years
between developing it and being switched over to a mail appliance for
most of our users. It's still in production here for a small subset of
users, though.
The happymail features are all configurable with config file and/or
command-line options, and they are completely inactive if you don't set
those options. It might be worth a compile-time option in configure.in,
but only (to my thinking) to detect whether the system supports System V
shared memory.
* On 2005.05.27, in <[EMAIL PROTECTED]>,
* "Ken A" <[EMAIL PROTECTED]> wrote:
>
> I would also like to see some way to limit users (per user) to a number
> of pop3 checks per minute, but without generating support calls because
> of an error message. It would be better to simply return "no new
> messages on server" for x minutes if possible (still with no i/o). I'm
> not at all sure how difficult that change would be to implement.
This can be a runtime option.
> Short of that, I'd definitely like to see the HappyMail patch put into
> the main codebase.
I know I've said this before, but I'll look soon at the pending requests
on happymail and at Joe's patches, and put together an updated,
integrated patch suitable for inclusion in the core code base. If
nothing else, it'll be a better basis for a new maintainer, and a more
respectable handoff on my part. :)
--
-D. [EMAIL PROTECTED] NSIT University of Chicago
