Mailman 3 April 2013 - Mailman-Developers

before next release: disable backscatter in default installation
by Jo Rhett 08 Nov '22

08 Nov '22

Hi. There's a fairly simple problem here that needs to be addressed. And it's mostly a documentation/install problem. I'm hoping we can get this resolved before the next release. PROBLEM: Mailman comes out of the box ready to backscatter spam people. Yes, it's easy enough to fix. But because it comes stock this way, and is documented to install this way, most people install it to do this. Those of us who work in abuse departments are tired of hearing "well that's how Mailman works". We also object to having to teach people how to fix their mailman installations because it's not documented in the current manual. This is *exactly* like Sendmail 14 years ago. We didn't accept it then, and Sendmail fixed the problem. RESOLUTION: Mailman default installation should not backscatter in a default configuration. 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by default. Nearly everyone uses web based signup. 2. Discard or hold messages from non-subscribers by default. I would think that it would be perfectly reasonable to have documentation on how to enable the 1980s-style -request / -subscribe etc aliases. However this documentation should have a note that this is against the AUP of nearly every network provider, and enabling it will likely cause them to get listed in various blacklists as a backscatter source. FYI: I know that this goes against the instincts of many old-time mailing list advocates here. But after dealing with a 10k/hour backscatter DoS my tolerance for this problem is understandably limited. Yes, it was a sweet day back in the 1980s. I was running a mailing list server and several UUCP gateways at the time, so I remember them well. But those days are past, and we need to deal with the reality of today. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

21 168

Re: [Mailman-Developers] Architecture for extra profile info
by Stephen J. Turnbull 30 Apr '13

30 Apr '13

Xu Wang writes: > As oauth supported google's userinfo API, one need to present a valid > google's oauth access token to get access. > s/google/mailman/g on above statement, it will be true too. I disagree, in the sense that Google (as an OAuth provider) is in the business of *providing* enterprise workflows such as AppEngine. That's why they need to be an OAuth provider. Mailman is a support function for workflows (enterprise or otherwise). So it's not a "Mailman" token. It's an <enterprise> token, and the enterprise, not Mailman, should be the provider. If Mailman provides, then we have to take responsibility for foreseeing enterprise needs. If we go Wacky's route and make everything as generic as possible, we may need the power of OAuth to handle all that genericity. (We may also then need another 5 years to release Mailman 3....) But if we stick to the current role-based authorization model with a small fixed set of roles, then OpenID-like workflows (whether implemented via OAuth protocol or otherwise) should be enough. If a site demands more control over authentication than public OpenID providers can afford, then Basic Auth over HTTPS fits into the "user has role" authorization model as well as OpenID does. I don't see a need for Mailman to provide an authentication provider, and there are serious downsides to the proliferation of authentication providers. Steve

4 12

Using Mailman scripts from cgi
by Stephen J. Turnbull 30 Apr '13

30 Apr '13

Tom Browder writes: > I've tried: > $ ./add_member -r - listname joe(a)test.org > > and > > $ ./add_member -r - listname < joe(a)test.org > > but neither works. I just get the command's help output. > > I am in the bin dir with the script and I'm a member of the list group. echo joe(a)test.org | ./add_member -r - mailman works for me. (Tip: If I don't have a test list handy, I use the mailman list.)

1 0

Re: [Mailman-Developers] Architecture for extra profile info
by Richard Wackerbarth 30 Apr '13

30 Apr '13

Abhilash, Thanks for the summary. Let me add a bit about what I think we should present in this interface. First, it should be RESTful and self documenting. The format of information delivered will be controlled by the http Accept: header The standard representation for communication between various modules of the MM system (core, user-manager,webUI, etc.) will be "application/hal+json" https://server.example.com/mailman/list/ABCDEFG/attribute/join_address returns the email address to which subscription requests should be sent. https://server.example.com/mailman/list/ABCDEFG/attributes https://server.example.com/mailman/attribute/posting_address/test_list@exam… would return the URI representing the list https://server.example.com/mailman/attribute/posting_address/test_list@exam… might return test_list-join(a)example.com See https://gist.github.com/hjr3/2289546 (an E-commerce platform specification) to get a representative idea of the json formatting. I envision the simplified model to have the following core resources: user - A person address - An email address each address is owned by one person credential - An authentication binding associating a user with an identifier such as username/password, browserid, or oAuth list - A mailing list. Lists have attributes that apply to the list and also have a set of preferences which supplies defaults for subscription preferences subscription - the binding of an email address to a list. attributes - a dictionary of the parameters that characterize the list preferences - a dictionary of the parameters that apply to a subscription I am suggesting two primary differences from the MM core style of representation. First, rather than having multiple attributes and preferences as "columns" in a table, I would portray them as multiple rows in a table where the attribute names are a key that is used to select the corresponding value. Additionally, I would generalize the grouping of lists into a hierarchical tree that represents the enterprise organization rather than aspects of the internet namespace. By treating the preferences as a table of key-value pairs, we can easily extend the list of elements with plug-in modules without having to change the data handling or display mechanisms. Richard On Apr 26, 2013, at 7:00 PM, Abhilash Raj <raj.abhilash1(a)gmail.com> wrote: > Hi all, > I wrote a brief summary[1] of this thread. Its in the form of notes sorted > according to participants and a small summary at the end( showing off > whatever I could understand reading the thread twice from head to toe ). > However I might have misunderstood ( or not understood at all ) or missed a > few things, forgive me for that. > > [1]: https://gist.github.com/maxking/5471211 > > Thanks, > Abhilash > > > On Sat, Apr 27, 2013 at 1:06 AM, Terri Oda <terri(a)zone12.com> wrote: > >> So... What have we decided? :) >> >> From my fuzzy "I read my email on a plane after delta woke me up at 3am to >> tell me my flight was cancelled" level of recollection.... >> >> The few things I we actually agreed on: >> >> - We like the idea of a rest interface. >> >> - That interface/API should probably be decided now and relatively >> permanently >> >> - then implementation details can be changed later as necessary (so it >> doesn't matter if we start with Django or whether mailman-user reads from >> mailman-core or vice versa, as long as it gets done and fulfills the >> promises of the API) >> >> - something something oauth something >> >> Can someone sketch out what that REST interface will look like as an >> actual architectural document that we can comment on? I don't care who >> does this; we just need somewhere to start, so any subscriber to this list >> can probably summarize the emails into a useful document. >> >> Terri >> >> >> >> ______________________________**_________________ >> Mailman-Developers mailing list >> Mailman-Developers(a)python.org >> http://mail.python.org/**mailman/listinfo/mailman-**developers<http://mail.python.org/mailman/listinfo/mailman-developers> >> Mailman FAQ: http://wiki.list.org/x/AgA3 >> Searchable Archives: http://www.mail-archive.com/** >> mailman-developers%40python.**org/<http://www.mail-archive.com/mailman-developers%40python.org/> >> Unsubscribe: http://mail.python.org/**mailman/options/mailman-** >> developers/raj.abhilash1%**40gmail.com<http://mail.python.org/mailman/options/mailman-developers/raj.abhilash1%40g…> >> >> Security Policy: http://wiki.list.org/x/QIA9 >> > > > > -- > Abhilash Raj > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers(a)python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://wiki.list.org/x/AgA3 > Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/rkw%40dataplex.net > > Security Policy: http://wiki.list.org/x/QIA9

4 29

Using Mailman scripts from cgi
by Tom Browder 30 Apr '13

30 Apr '13

I'm probably going in the wrong direction, but I'm trying to create my own page for subscribers on an Ubuntu server. Before I get my cgi form working, I'm trying to use the command line script "add_members" and can't get the right syntax for using stdin. I've tried: $ ./add_member -r - listname joe(a)test.org and $ ./add_member -r - listname < joe(a)test.org but neither works. I just get the command's help output. I am in the bin dir with the script and I'm a member of the list group. What am I doing wrong? Thanks, -Tom

1 0

Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration
by Stefan Schlott 29 Apr '13

29 Apr '13

On 25.04.2013 21:10, Abhilash Raj wrote: >> Abhilash, i don't see any mention in your proposal of how you plan to >> deal with the secret key material. will there be a way for mailman to >> use a secret key that is stored in a password-protected form? If so, how? >> >> Well I am not quite proficient in cryptography but I tried to answer how > could it be done and have updated on the same link[1]. Here is a copy of > only that part: > > One of the biggest issues of any cryptographic procedure is to secure and > manage the keys. Firstly for the lists, when the list is created by the > owner the keypair is generated by mailman in some time(because when i was > trying to create one using gnupg, it asked me to wait for sometime and keep > doing some work to get threshold entropy. Although in reality I don't have > much idea about how the keys are created, but I am guessing that it > somewhere uses the random bits from the memory of the host where key is > created and thus required a threshold entropy for the proper randomization > of the key. On virtualised Linux systems, this can often be achieved by > installing the rng-tools package.) and is stored in the database against > the name of the list. It will then be available for download to the May I suggest that mailman doesn't create the list key by itself, but ask the list maintainer to upload a public/private key pair (if no crypto hardware is used, see below)? On a virtualized system, getting real randomness is tricky. > subscribers. [python-gnupg][2] also allows one to encrypt/decrypt using the > keys that are protected by a paraphrase. Such paraphrase though would then > be stored in cleartext format in database. Though this poses a security > thread but even if you encrypt and store the paraphrase, you can only slow > the process of decryption once the server is compromised since the > private-paraphrase-encryption key will also be needed to be stored > somewhere on the local disk. I would distinguish the following two scenarios: 1. The list is not-so-high-sec that you can risk storing the secret key without a password (which is the equivalent to storing the passphrase in the database). 2. Your list has elevated security requirements. In this case, you can use gpg-agent to manage the secret key (and its passphrase). This would require the sysadmin to start the gpg-agent and enter the list's passphrase before firing up mailman (or mailman could queue incoming mails until the secret key becomes available). This would open you the option to have the mailing list's secret key on a hardware token (e.g. the CryptoStick http://shop.kernelconcepts.de/product_info.php?cPath=1_26&products_id=133). Stefan.

7 9

Re: [Mailman-Developers] Web Posting Interface: Additional Features.
by Ian Eiloart 29 Apr '13

29 Apr '13

On 29 Apr 2013, at 09:39, Peter Markou <markoupetr(a)gmail.com> wrote: > Hello everyone in the community. As you may or may not know, > I've applied a proposal in Melange for Web Posting Interface. > The description of the project idea states: "the interface > itself may not take the whole summer", so I've come up with > some features that I would like to implement for Mailman web > interface. These features are listed below: ** > 3.) Keyword Summary, > 6.) User Profiles(support for name, photo, bio, past posts & files, > statistics about how people post), > 10.) Top X Threads of all-time, > 11.) Topics to be Wary Of, > 12.) User's Filter Tools, > 14.) Keyword-Based Thread Browse, > 17.) List Monthly Health, > 22.) Mentioned in thread refs. > > I would appreciate any feedback from developers/users, about > which of them would be useful and fit well with Mailman web > interface. Hi, The first thing to remember is that there are at least three types of user: Site admins List admins List members And, of course there will be a variety of levels of technical skill within each user set. I imagine that a Web Posting Interface will be for List Members. They'll need to be able to access their personal profile, list archives, and a form for composing and sending a message to the list. In my view, the essential features for that are: 1. A nice editing tool, that a list admin can configure to send ONLY unformatted text. That should probably be the default for new lists, for new members, and for new messages. 2. The tool should do it's utmost to preserve threads when a member is replying to a message, but not otherwise. 3. If the message is a reply, then the rest of the thread messages should have some visibility: to discourage members from replying before they've seen the whole thread. 4. There should be a link to a profile page, but it would be neat if the profile page could leverage some existing identity. Various options exist, but given that we have an email address, we can often get some profile information from the email service provider, for example when they're openid providers. Don't work on this until 1-3 are complete. 5. There should be a link to a list archive. An archive browser is probably a project of its own. My view is that the keyword and topic type stuff all belong in (5), if anywhere at all. In the message posting page, they'd be unnecessary clutter. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148

1 0

Web Posting Interface: Additional Features.
by Peter Markou 29 Apr '13

29 Apr '13

Hello everyone in the community. As you may or may not know, I've applied a proposal in Melange for Web Posting Interface. The description of the project idea states: "the interface itself may not take the whole summer", so I've come up with some features that I would like to implement for Mailman web interface. These features are listed below: ** 3.) Keyword Summary, 6.) User Profiles(support for name, photo, bio, past posts & files, statistics about how people post), 10.) Top X Threads of all-time, 11.) Topics to be Wary Of, 12.) User's Filter Tools, 14.) Keyword-Based Thread Browse, 17.) List Monthly Health, 22.) Mentioned in thread refs. I would appreciate any feedback from developers/users, about which of them would be useful and fit well with Mailman web interface. ** The numbering comes from the source I've found these ideas: http://blog.linuxgrrl.com/2012/03/13/mailman-brainstorm/ , http://blog.linuxgrrl.com/2012/03/14/mailman-brainstorm-2/ .

1 0

Re: [Mailman-Developers] Architecture for extra profile info
by Richard Wackerbarth 29 Apr '13

29 Apr '13

My understanding of the use of oAuth to provide "login" information from Google, Twitter, etc. is based on the following description provided by Google. Below is a trivial example of how to use Google's OAuth 2.0 endpoint to gain access to a Google API. It's a Python web application running on App Engine. The flow of the example is fairly straightforward: When the application loads, it shows the you a "Login" link. When you click that link, you are asked to login to Google and asked to release basic account information to the application (user consent). If you grant consent, the application receives an access token. Once it has the access token, the application presents the access token to the Google API that provides basic account information (https://www.googleapis.com/oauth2/v1/userinfo) The application renders the basic account information in a simple table. In particular, a user grants our server the permission to access some information pertaining to the user as it is stored by Google and accessed through their API for the purpose. Based on that information, our server grants permission to the user thus identified and based on authorization data stored in our system. Once we have identified the user, our system can use tokens such as session keys, or other mechanisms, to maintain the association. Richard On Apr 28, 2013, at 2:42 PM, Xu Wang <xuwang(a)gmail.com> wrote: > On Sun, Apr 28, 2013 at 11:27 AM, Stephen J. Turnbull <stephen(a)xemacs.org>wrote: > >> Xu Wang writes: >>> On Sun, Apr 28, 2013 at 12:15 AM, Stephen J. Turnbull < >> stephen(a)xemacs.org> >>> wrote: >>>> Xu Wang writes: >>>> >>>>> The problem is how do you "confirm ownership of the subscribed >>>>> address" when a request coming with an access token. >>>> >>>> You don't. That was done when the OAuth ID was linked to the address, >>>> using the usual 3-step handshake (submit the association, receive an >>>> email containing a secret, confirm ownership by replying with the >> secret). >>> >>> I'm not sure what you mean by "OAuth ID". >> >> In the case of Mailman's use cases, it will typically be an email >> address at Gmail, Yahoo, or Launchpad, or some other well-known OpenID >> provider. Often, but not necessarily, it will be the subscribed address. >> >> > OpenID is about authentication. OAuth is about authorisation. > What are we talking about here? Support to OpenID or support to OAuth or > both? > >> As a resource server, the API need to validate the access token but >>> how to validate the access token is not part of OAuth. >> >> This is some of the excess complexity (if you prefer, "enterprise >> readiness") in OAuth 2.0. In Mailman usage, the resource that the >> consumer gets access to will be a user ID. Eg, I might be "user: >> stephen; name: Stephen Turnbull; email: stephen(a)xemacs.org; >> email:stephen.turnbull.fw@u.tsukuba.ac.jp; owner: >> fs-phil(a)turnbull.sk.tsukuba.ac.jp; owner: xemacs-beta(a)xemacs.org ...; >> OpenID: stephenjturnbull(a)gmail.com". So when I login via OpenID >> (which uses the OAuth v1 protocol AFAIK), > > No OpenID does not uses OAuth protocol. > > >> the provider (GMail) asks me >> to verify who I am by presenting my credential (most users will think >> of this as "getting the login screen"), and in turn it testifies to >> the client that I own that email at GMail, and the consumer (eg, the >> HyperKitty app) then looks it up, identifies me, logs me in as >> "stephen", and gives me a cookie (session auth token). The >> authentication *is* the validation here. >> > > Mailman can't use GMail as OAuth provider to protect mailman's own resource > as a general authorization solution. > > OAuth v2 envisions more complex scenarios where the client may present >> the same token repeatedly, or consumers might hang on to them and >> present them to the resource owner repeatedly, or even pass them on to >> other consumers. In those cases, yes, there will need to be >> validation etc going on. For example, the token might be a (ID, URI, >> expiration-date) tuple encrypted with the resource owner's private >> key. Being able to decrypt and getting a syntactically correct, >> unexpired tuple would then be validation of an authorization to fetch >> that URI. (In this particular case I'm thinking of "any valid user is >> OK".) This does require prior coordination between the provider and >> the resource owner on token format and exchange of keys. >> >> But AFAICS Mailman's currently envisioned applications don't require >> this complexity. >> > > As you put it, mailman don't have to support OAuth, but if it dose, it's > better stick to the protocol. > > >> Do you have any ideas for Mailman that might require something more >> fine-grained than just "this user is logged in"? >> > > I'm new to mailman and have a very limited knowledge about what kind of > "fine-grained" authorization it may need other than authentication. (read: > Xu had no clue ...) > > From the api implementation point of view, a role base authorization can > be bundled in, which allows admin or resource owner to associate user with > roles and roles with endpoints/methods. > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers(a)python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://wiki.list.org/x/AgA3 > Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/rkw%40dataplex.net > > Security Policy: http://wiki.list.org/x/QIA9

2 1

Re: [Mailman-Developers] Architecture for extra profile info
by Stephen J. Turnbull 29 Apr '13

29 Apr '13

Xu Wang writes: > No OpenID does not uses OAuth protocol. My mistake. Let's talk about what Mailman needs, then. OpenID (or an equivalent based on a more general system) is all that Mailman needs as far as I can see. AIUI, the resources that can be accessed or mutated, in order of frequency of use, are 1. Moderation queues. Moderators need access. List owners grant access on the basis of identity of the moderator. 2. Subscriptions. Subscribers and list owners need access. Subscribers usually own the subscribed address and have a privacy (no spam) right. (In employment and education cases, subscribers may have restricted rights, but ID == authorization holds.) List owners are delegated authority from site (or vhost) admin. They may have "legal" (or "precedent") rights to the subscriber list and archives. Either way, ID is authorization. 3. Lists. List owners need access. List owners are delegated authority from site (or vhost) admin. ID is authorization. 4. Virtual hosts (vhosts). A namespace for lists based on a domain name (DNS MX). Delegated by site admins. ID is authorization. 5. Site (collection of vhosts). A physical system. Delegated to site admin from outside. ID is authorization. Corner cases: (1) People with multiple roles may prefer to have to re-login (or "su") use "higher" privilege. "su" or "sudo" mechanisms can address this. (2) Delegators may wish to de-authorize delegatees. An ID-based authorization means some lag. This can be mitigated by granting authorization with short expiration, but that has its issues too. > Mailman can't use GMail as OAuth provider to protect mailman's own > resource as a general authorization solution. Evidently it can't use it at all, if OpenID isn't based on OAuth (and the OAuth protocol exposed to GMail users). > As you put it, mailman don't have to support OAuth, but if it dose, it's > better stick to the protocol. I don't see how anything general I said doesn't stick to protocol. *Validation* is a syntactic operation. Contacting the resource owner and asking "is this token one of yours?" is one way to validate. (Traditional 3-way handshake for validating mail addresses when subscribing is exactly this.) But using encryption or signatures is another way. > I'm new to mailman and have a very limited knowledge about what > kind of "fine-grained" authorization it may need other than > authentication. (read: Xu had no clue ...) > > >From the api implementation point of view, a role base authorization can > be bundled in, which allows admin or resource owner to associate user with > roles and roles with endpoints/methods. AFAICS this is all we need, see above.

1 0