Mark Sapiro wrote:
Scott Balmos wrote:Igg... Sounds nasty. Sympa has a subscribe_option & unsubscribe_option named "closed" which outright refused all requests. I guess ban_list would work for subscribers. Unsubscribing is what I'm worried about. Most of my lists will be in LDAP and SQL. Some of them are "managed", which means they're really supposed to be admin'd through my web app's list manager, not in Mailman's admin interface. A person's not supposed to be able to unsubscribe on their own. For one, if I'm reading right, this would cause the LDAP MemberAdaptor to bomb, because it's read-only (attempting to delete a record from LDAP?). And for SQL... Supposedly it would delete, but I don't want that to happen.
1) Can a list be set to refuse any subscribing/unsubscribing action? I intend to use the LDAP adapter, so subscribing/unsubscribing actions are both unnecessary, but also undesirable.
Lists can be set so subscription requires owner approval, but then the owner has to reject them, but the owner can supply an informative message.
There is a ban_list of addresses prevented from subscribing. An entry in this list can be a pattern such as ^.*$ which prevents anyone from subscribing, but you may or may not like the reject message.
Maybe someone else on the list has a better idea to handle this? :)
I honestly like the first suggestion. But I'm completely unfamiliar with Mailman's internals, and there doesn't seem to be any type of internal design document or such for me to decipher such. I'm moderately familiar with Python itself. But I quickly went cross-eyed looking at some of Mailman's source. :) Any hints on where to start with this? What parts of MemberAdaptor handle the user moderation bit? Bad enough I have to find a suitable attribute in the LDAP object classes to store this. :D2) Say I have a list mixed with some subscribers who should, and some subscriber who should not, have posting access to the list. I am assuming this means the only way I can do this is to have all of the can-post subscribers be explicitly listed in the posting rights preferences?
That's one way to do it. Perhaps a better way is to moderate all members except those allowed to post and either reject or discard posts from moderated members. I *guess* the moderation bit would have to be part of the LDAP directory and be returned by the LDAP MemberAdaptor. That solves the issue below.
Yet another way to do this is moderate everyone and allow only posts with an Approved: "header" as discussed in FAQ articles 3.11 and 3.34.
One thing I just realized is that the LDAP store would have to store the moderation bit *per user per list*. I can't just set a "global" moderation bit on the user record itself, that wouldn't make sense. More "internals" question, then. Where, or rather how, is the list moderation settings stored anyway? I'm assuming MemberAdaptors could be written all over the place for lists, but the list-specific stuff, like moderation bits, are still stored in some internal DB.
This is starting to look like a nasty rewrite of the LDAP & SQL MemberAdaptors. And this "explicit posting rights" feature really was what I thought would win me over from Sympa to Mailman.
Err... Okay... The second paragraph I understand. Though really, those addresses shouldn't be necessary. Like one page says (I forget where), if you have bouncing addresses in your enterprise LDAP directory, you've got bigger problems. Likewise for unsubscribe and other "dynamic" management addresses, as I said I didn't want them.In this case, if/when one of those can-post subscribers changes their email address in the LDAP directory, do I have to also manually go into all the lists that they're members of, and somehow manually (through human intervention, or extra code in my LDAP manager web-app) change their email addresses in there too, or does Mailman somehow "realize" that it's still the same person, but with an updated address.
3) Since my native mail server is Cyrus, many of my users use the [EMAIL PROTECTED] extended address syntax in order to directly deliver mailing list posts to a specific folder in their IMAP store. Messages coming from this user, obviously, will look like they're from [EMAIL PROTECTED], *not* [EMAIL PROTECTED] as stored in the subscriber list. Is there any way to get Mailman to recognize this (maybe by stripping off the extended username after the + sign)? Whereabouts in the code would I look for this?
Only with full personalization enabled are posts addressed To: the member. Otherwise, the To: header is unchanged and may have the list and other addresses in it. So if you're not going to enable full personalization, there's no need to have username+folder addresses in the member list. If you want this addressing, you have to enable full personalization which has performance considerations.
There may be other conflicts with the "+" addressing. Mailman sends bounce probes with VERP like sender addresses that look like [EMAIL PROTECTED] (user=user.domain is the members e-mail with "@" changed to"="). Mailman can also be configured to send other messages with VERP like senders.
The first paragraph I think we confused each other. The address that Mailman would have in its list subscriber DB would be [EMAIL PROTECTED], so that the subscriber's MTA (Postfix) receives that address in the envelope-receiver, and delivers accordingly into the folder. It is not dependent on the To: header line, which can be whatever it wants. No personalization necessary. What I'm more concerned about is from the subscriber to Mailman. In that direction, the user's mail client has set up just [EMAIL PROTECTED], like normal. Mailman, thus, receives posts as such, and because it has [EMAIL PROTECTED] in its subscriber db, not [EMAIL PROTECTED], the post looks like it's coming from a non-subscriber. I was wondering if there was a config variable or something to handle this, or where in the post handling code does the subscriber-to-email matching take place, so I can possibly hack this?
Okay... I guess it's better to ask if we can have multiple MemberAdaptors per list? I see there is an LDAP MemberAdaptor and an SQL MemberAdaptor. Can I theoretically define both in extend.py for the list somehow? Honestly grasping at straws because I'm so new to Mailman. Sympa was easy, as you just kept defining separate include_user_data_* paragraphs for each data source of a list.5) Can Mailman pull list subscriber data from multiple sources? In my setup, I have the normal subscribers, who should have posting access, in LDAP, and then a set of "observer" can't-post subscribers in an SQL table. Is it possible to combine LDAP & SQL subscriber lists for a single mailing list like this?
This is up to the MemberAdaptor and whatever it can do.
Sorry for all the constant questions. Mailman, right now, is a black box to me, despite my somewhat working knowledge of Python.
--Scott
------------------------------------------------------ Mailman-Users mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
