[Mailman-Users] Some requirements questions

[Scott Balmos]

Thanks for the answers. A few clarifications below. I'm rather familiar 
with Sympa, so a lot of the counterexamples are from it, unfortunately. :/

Mark Sapiro wrote:

>Scott Balmos wrote:
>  
>
>>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.
>
>  
>
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.

Maybe someone else on the list has a better idea to handle this? :)

>>2) 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.
>
>  
>
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. :D

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.

>>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 
>>username+folder at blah 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 
>>username at blah, *not* username+folder at blah 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
>listname-bounces+user=user.domain at list.domain (user=user.domain is the
>members e-mail with "@" changed to"="). Mailman can also be configured
>to send other messages with VERP like senders.
>
>  
>
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.

The first paragraph I think we confused each other. The address that 
Mailman would have in its list subscriber DB would be user+foo at blah, 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 user at blah, like normal. Mailman, thus, receives posts as such, 
and because it has user+foo at blah in its subscriber db, not user at blah, 
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?

>>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.
>
>  
>
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.

Sorry for all the constant questions. Mailman, right now, is a black box 
to me, despite my somewhat working knowledge of Python.

--Scott