[Mailman3-dev] Suggested Features
Ian A B Eiloart
iane at sussex.ac.uk
Mon Mar 15 11:35:28 EST 2004
--On domingo, 14 marzo 2004 23:54 -0500 Vince Sabio <mm3 at vsabio.com> wrote:
> Hi folks,
> I am currently using Lyris List Manager on an Ultra I running Solaris 8.
> The hosting site is pretty large -- we have about 50 mailing lists, with
> a dozen of them numbering at 1000 or more subscribers. I have 15
> "Listmoms" who help manage the lists, including moderation
> approval/rejection of posts.
> Not surprisingly, MLM features are important to us. I'm considering a
> move to Mailman on FreeBSD, but it is difficult to tell if M2 has certain
> specific features that have become part of our day-to-day list management
> in Lyris. Now, I'm not expecting anyone to design an MLM around the
> features that we're looking for ... but since you're soliciting input for
> M3, I figure it can't hurt. So, with that in mind, the features in
> question are (see below before replying to these):
> * "Semi-moderated" mailing lists (i.e., subscribers are moderated for "N"
> posts when they subscribe, and "graduate" to unmoderated status after N
> _approved_ posts)
This is sort of supported, but the moderator has to do the counting, as far
as I know.
> * "Spot" moderation (i.e., the ability to [re-]moderate an individual for
> "N" posts, or to permanently moderate him, at the moderator's
> discretion). It is VERY IMPORTANT that moderation be persistent -- i.e.,
> if someone figures out he's been permanently moderated, he can't
> unsubscribe and resubscribe and thus go back to being moderated for only
> "N" posts. (Upon unsub/resub, the implementation should set his
> moderation for the higher of the default list moderation count and his
> previous moderation setting.)
I think this works, but I haven't tried it. Again, the moderator would have
to do the counting.
> * Moderation via e-mail -- both approve/reject (important) and ability to
> set/change a user's moderation state (less important).
That is supported
> * Ability to create "filters" (preferably via the web UI) that can act
> based on the content of incoming messages, and return a customized
> message to the subscriber -- e.g., if a message contains the word
> "dingleberries" (insert your favorite word there), it can reject the post
> and send the poster a customized document, with a copy of the post,
> including headers, attached at the bottom (in this case, the "customized
> document" would state that, e.g., the post was being returned because it
> contained profanity).
> - A modification to this feature is the ability to send messages to
> the moderation queue based on their content. That is, a message that
> would otherwise post to the list would instead be submitted for
> moderation if its content matches a specific filter. This particular
> feature is not in our version of Lyris (I do not know if it is in later
> * Ability to strip certain headers, such as "Precedence:", "Priority:",
> and the like.
Hmm, you could do this with your MTA, perhaps. Don't think you can do it
with mailman - but I don't know any mail clients that use them, so I'm not
sure why you would.
You can choose to munge reply-to: headers.
> * Ability to add custom headers, both static headers (same for all
> subscribers) and mail-merged headers (e.g., "X-Message-To: <address>",
> with the subscriber's address in the header).
Mailman supports variable envelope return paths - which let you know where
bounced messages came from. It also processes the bounces for you, and can
unsubscribe someone who keeps bouncing mail.
It also adds List-* headers and so on, which comply with RFC 2369
> * Ability for subscribers set NOMAIL mode for a specific length of time
> (and/or until a specific date), at which time their previous delivery
> mode will be restored. (This is useful when going on vacation; no need to
> remember to set their delivery mode back to MAIL, DIGEST, etc.)
No, I think you have to remember to turn it back on. You can do this for
one list or all lists on the host.
> * Ability to ban certain users from subscribing to mailing lists -- both
> on a per-list basis and on a site-wide basis.
Can do this on a per-list basis. Not sure about site wide. You could knock
up a shell script to do this, though.
> * Ability to ban certain subscribers from posting to mailing lists (i.e.,
> from ever even entering the moderation queue). (This feature isn't
> terribly important, since we can pretty well handle this in moderation.)
Yes, you can do this.
> That's a start. Now, I know that the feature list in M2 includes such
> things as "New moderation and privacy controls," "emergency moderation,"
Emergency moderation switches moderation ON for all users on a list - to
let a flame war die down, for example. When emergency moderation is
switched off, the list is restored to its previous state.
> "Majordomo-style e-mail commands," "regex-based topic filtering,"
Topics allow people to get just some of the list posts, for example, a
"fruit" list might have an "apple" topic and an "orange" topic. I could
choose whether to get posts that related to "apple" or posts related to
"orange", or all posts.
You could create a profanity topic, I guess, and let people opt out from
receiving profanity. I don't think it would work well, though.
> but I'm not sure if those features translate into the specifics that I
> mentioned above. Since we use these features on a daily (or nearly daily)
> basis, I wanted to be explicit about the feature set we're looking for.
> Again, I'm not expecting anyone to design an M3 around our requirements,
> but I igured it couldn't hurt to state them, and might stimulate some
> interesting discussion. :-)
> * Is the Welcome message customizable? If not, it would be necessary for
> us to be able to customize it.
It is customizable - globally and per list.
> * Can users request a copy of the customized Welcome message via e-mail?
> (I know they can get a "help" message via e-mail.)
> * The "Urgent" message feature in M2 is nice -- but can use of it be
> limited to just list owners/moderators?
> * Is it possible to REQUIRE/FORCE all e-mail addresses to be concealed?
> That is, not even give the users the option?
> Please feel free to ask for clarification on any of these points. There
> are probably more features that we'd be interested in, but I didn't want
> to wear out my welcome on the first message (figured I'd wait until the
> third or fourth message for that ;-).
Sussex University ITS
More information about the Mailman3-Dev