Re: Next steps for ezmlm-idx

I dont know if my requested features are already available or not.
but if there are not, I wish you could make it come true.

1. add latest milist activity info. so I can know when is the last time 
member send email to that milis.
then I can delete those inactive milis (automatically / manually) to 
save resource.

2. semi open type milist. currently there are only 5 type of posting..
a. anyone can post
b. only subscribers can post, other bounce
c. only subscribers can post, others go to moderator
d. only moderators can post, other bounce
e. only moderators can post, other go to moderator

in company, there is possibility that 1 milist should open (can receive 
email ) from anyone, but still with in the same company (domain)
i.e itsupport dept can rcvd email from any body with in those company 
(domain) email address..
but the itsupport milist can't rcvd milist from outside the company domain

I have ask this before to you, and you said I have to enter each email 
that allowed to post..
it will be difficult because I need to enter all employee address just 
to minimize spam to that milist.

that's all from me.. I'll think later if any..
thank before...


Bruce Guenter wrote:
> Greetings.
>
> I have a lot of ideas for some big things things that should be changed
> in or added to ezmlm-idx, but I would like to hear from you what you
> would most like changed.
>
> Here are some of my ideas:
>
> 1. A custom ezmlm outgoing queueing and delivery system, equivalent to
> qmail-queue+qmail-remote, that is able to do custom substitutions on the
> messages as they are being delivered.  The most obvious substitution
> would be the subscriber address, but in time the subscriber's name could
> also be substituted.
>
> 2. Alternate storage mechanisms for the archive, such as being able to
> store the archive in SQL much like the subscriber list, or in a DBM file
> etc.
>
> 3. Standardized web interface.  This would be a CGI script or set of
> scripts, probably written in Python, with two parts: an administrative
> part for setting up and managing lists, and a subscriber part for web
> based subscription management and the like.
>
> Do you have other ideas?
>
> Thanks.
>
>