Re: [Mailman-Developers] Build a mailman3 development virtual machine with Vagrant and Chef
I'm not sure I have the permission to edit the wiki page. If anyone with the permission and know how, please feel free to add the link. Xu Wang On Thu, Apr 18, 2013 at 12:54 PM, Terri Oda te...@zone12.com wrote: Yeay, thanks! If you've got time, could you make sure your vm is linked on the mailman wiki docs? You can replace the comment I have on the GSoC page for sure, and there's probably a good place to link it in a couple setting up your dev environment pages. Terri On 13-04-18 1:39 AM, Xu Wang wrote: Hi there, Although mailman3 installation is well documented, but putting everything together is still not a trivial job. To ease the task, I made a mailman3 chef cookbook and vagrant file: https://github.com/xuwang/**mailman3-vboxhttps://github.com/xuwang/mailman3-vbox If you already had virtualbox/vagrant installed on your mac or pc, build a working mailman3 vm should only take a few minutes. I'm sure there will be things I missed or got it wrong, but it just a starter. Hope this helps, Xu Wang __**_ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/**mailman/listinfo/mailman-**developershttp://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/terri%40zone12.comhttp://mail.python.org/mailman/options/mailman-developers/terri%40zone12.com Security Policy: http://wiki.list.org/x/QIA9 ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] anti-spam filter
On 15 Apr 2013, at 11:22, Stephen J. Turnbull step...@xemacs.org wrote: OTOH, a generic interface to the Mailman REST API, which could be used by Sendmail milters or whatever else is out there and somewhat standard (is it Postfix or Exim that can handle milters? I forget), with example implementation of a milter that checks whether the poster is subscribed by asking Mailman, would be useful as an extension to any MTA used with Mailman. I think Mailman supports SMTP/LMTP calls to discover whether a sender is permitted to post to a list, doesn't it? Exim doesn't handle Milters, but can do the calls forward. Provided Mailman is making the judgement, and issuing L/SMTP rejects at L/SMTP time before accepting the message, Exim is fine. Content filtering *could* also be done at L/SMTP time. I think that where the Mailman and the MTA installations are managed by the same person or organisation, then the better place to have content filtering performed is at the MTA, but there might be exceptions to this. For example, a medical mailing list might want to be more liberal with regard to drugs that are commonly marketed in spam. Conversely, a list might have a particular subscriber demographic that makes it more sensitive to bad language. Or perhaps different lists might have different primary languages, and therefore different views on the value of messages in that language. So, I can see that different lists on the same system might have different requirements for spam filtering. However, the solution is probably to provide hooks into Spamassassin, or another existing spam solution, and to provide ways that list owners can manage a configuration file on a per list basis. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] anti-spam filter
* Ian Eiloart i...@sussex.ac.uk: On 15 Apr 2013, at 11:22, Stephen J. Turnbull step...@xemacs.org wrote: OTOH, a generic interface to the Mailman REST API, which could be used by Sendmail milters or whatever else is out there and somewhat standard (is it Postfix or Exim that can handle milters? I forget), with example implementation of a milter that checks whether the poster is subscribed by asking Mailman, would be useful as an extension to any MTA used with Mailman. I think Mailman supports SMTP/LMTP calls to discover whether a sender is permitted to post to a list, doesn't it? Exim doesn't handle Milters, but can do the calls forward. Provided Mailman is making the judgement, and issuing L/SMTP rejects at L/SMTP time before accepting the message, Exim is fine. It would be great if Exim as third MTA in the OSS troika of MTAs would. Content filtering *could* also be done at L/SMTP time. I think that where the Mailman and the MTA installations are managed by the same person or organisation, then the better place to have content filtering performed is at the MTA, but there might be exceptions to this. For example, a medical mailing list might want to be more liberal with regard to drugs that are commonly marketed in spam. Conversely, a list might have a particular subscriber demographic that makes it more sensitive to bad language. Or perhaps different lists might have different primary languages, and therefore different views on the value of messages in that language. ACK So, I can see that different lists on the same system might have different requirements for spam filtering. However, the solution is probably to provide hooks into Spamassassin, or another existing spam solution, and to provide ways that list owners can manage a configuration file on a per list basis. ACK. SpamAssassin knows how to apply different policies per recipient(domain). It is possible to provide policies via file config, SQL or LDAP. p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Architecture for extra profile info
Barry, Are you starting to come around to the concept that I have been advocating for a long time? In particular, rather than owning the user information, core simply views it. I assume that you are reluctant to store foreign keys to external databases because you worry that consistency might be broken when another process alters the database. I ask that you consideration the following as it applies to that view: First, as viewed from the other side (the enterprise, etc.), your same concerns apply to accessing their user. For example, when you store the user password, how do they assure availability and consistency? Second, particularly if you separate the administration functions, core message handling should, at most, rarely care about the user information. The subscription information, which seldom changes, should contain sufficient information to handle the time-critical task of message dispatch. Richard On Apr 18, 2013, at 8:20 PM, Barry Warsaw ba...@list.org wrote: Terri, thanks for kicking off this discussion! On Apr 18, 2013, at 01:34 PM, Terri Oda wrote: On 13-04-18 2:28 AM, Stephen J. Turnbull wrote: Main comment: Sounds like LDAP to me. Actually, this is a really important comment. I was sort of wondering that too when I started writing the description. LDAP is a moderately frequently requested feature already. Would it make sense to use that probably rather than rest, or make a rest framework that talked to ldap under the hood? I agree that this is a really interesting suggestion. What's interesting to me about it is that this acknowledges that administrative control of this extra user information may fall to folks not at all directly involved in mailing list administration. You can imagine that a company would already have their LDAP database of additional user information, from postal addresses, to phone numbers, to IRC handles, pictures and icons, birthdays, etc. Further, I can imagine that if that company were to be running MM3 and HyperKitty, they'd probably not want to duplicate that information in multiple databases, they'd just want to pull the pictures and IRC nicks out of LDAP. For their purposes, their LDAP database *is* their user database. Of course, some of that information may also be used in part or in whole for the core, e.g. display names (which actually are useful in places, such as crafting the From header for a virgin notification). Now, at least conceptually, I've always thought about the user database as one of the three pillars of information in the core, the other two being the list database and the message store. This is why for example subscriptions do not just link a foreign key for the mlist to a foreign key to the address, because this would not allow for separation of these two pillars[1]. Furthermore, the use of interfaces internally is meant to allow for alternative implementations of the lowest database layer of these pillars, without affecting any functionality above it. So let's say even in the core, user passwords, display names, and preferences were kept in LDAP. An alternative implementation of user.py would pull the data in from there and as long as it satisfied the syntactic and semantic APIs of the IUser interface, everything else in MM3 would continue to work. You could extend this to the idea expressed elsewhere that the core could use this external user database. Why not? The external user database could be accessible over REST or a via a database server, etc. We'd need an implementation of the underlying data objects that could talk to this user database and satisfy the interfaces, and that should be all you'd need. Making it performant enough for the core is just an engineering exercise wink. -Barry [1] Whether any of this works or has the right separation is another matter entirely. ;) For example, looking at it now, I'm not so sure Members shouldn't be part of the MailingList pillar rather than the user database pillar. ___ Mailman-Developers mailing list Mailman-Developers@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 ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Build a mailman3 development virtualmachine with Vagrant and Chef
Xu Wang wrote: I'm not sure I have the permission to edit the wiki page. If anyone with the permission and know how, please feel free to add the link. As it says at the upper left of the wiki home (dashboard) page to add or edit content you must sign up and log in, and you must also request write permission for your user name by sending a note to the Mailman Steering Committee. (sorry it's the only way to control wiki spam). You now have permission. -- Mark Sapiro m...@msapiro.netThe highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] anti-spam filter
On Apr 19, 2013, at 10:28 AM, Stephen J. Turnbull wrote: Barry Warsaw writes: I still think this wouldn't be a handler, but a rule. Is this distinction implemented and enforced by the API? It is. There are two distinct interfaces, IHandler and IRule, with different signatures. It's also enforced by design and implementation, since rules are generally attached to actions via links in a chain and get executed during incoming processing, whereas handlers are processed sequentially without interruption, and only after the message has been accepted for posting. If not, it's going to be hard to persuade myself to make the distinction in discussion. Ie, I'll probably just go on calling everything a Handler unless somebody asks don't you really mean a Rule? There are several ways to think about it, but I guess the easiest one is does this chunk of processing change the message or make a non-destructive moderation decision? Or more simply, is it moderation or modification? If it's moderation, then it's a rule. If it's modification then it's a handler. (There are some corner cases in each, but it's a good general distinction.) Thus a chunk that asks does this message contain administrivia? is a moderation question and thus a rule. A chunk that adds an informative footer to the message is a modification handler. Aside: I wanted to find a better name than handler for the modification bits, but I failed. I would have rather done away with the term handler in MM3 so suggestions are welcome for the term naming the units that plug into the modification pipeline. The interfaces are important too because MM3 initialization will auto-discover both rules and handlers and stick them in different collections. If we ever expose this in the REST API, then you would be able to compose them in different ways, appropriate for the interface. Hope that helps. -Barry signature.asc Description: PGP signature ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] anti-spam filter
On Apr 19, 2013, at 11:48 AM, Ian Eiloart wrote: I think Mailman supports SMTP/LMTP calls to discover whether a sender is permitted to post to a list, doesn't it? MM3's LMTP server currently only does a limited sanity check on the messages. E.g. does the To: field name an existing mailing list[1] Exim doesn't handle Milters, but can do the calls forward. Provided Mailman is making the judgement, and issuing L/SMTP rejects at L/SMTP time before accepting the message, Exim is fine. As a side note, right now only Postfix is officially supported, mostly because that's what I use so I can easily debug it. I would love to have contributions to support at least Exim and Sendmail out of the box. If you're an expert willing to contribute that code, please get in touch. Content filtering *could* also be done at L/SMTP time. I think that where the Mailman and the MTA installations are managed by the same person or organisation, then the better place to have content filtering performed is at the MTA, but there might be exceptions to this. Currently, I'm trying to keep the processing that the LMTP server does at acceptance time to a minimum, just because I'm concerned about its single threaded performance. While it does async I/O, and it runs in a separate process, time consuming processing for a single message will still block acceptance of all other messages. The answer to this is to somehow multiplex the LMTP server, but ideally without using multiple threads (MM3 is currently single threaded everywhere). In any case, this would also be interesting to work on. -Barry [1] I just noticed https://bugs.launchpad.net/mailman/+bug/1170726 ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Architecture for extra profile info
On Apr 19, 2013, at 07:18 AM, Richard Wackerbarth wrote: Are you starting to come around to the concept that I have been advocating for a long time? It's always been part of my thinking, and it's most evident in the use of interfaces internally. Time will tell whether we've accomplished that or not. However, it's also important to realize that probably the vast majority of users who roll their own just install what we give them and go (well, most likely with their stack of distro patches). So I think in that case, it still makes sense for the core to provide, by default, a minimally useful user database, as it does today. I ask that you consideration the following as it applies to that view: First, as viewed from the other side (the enterprise, etc.), your same concerns apply to accessing their user. For example, when you store the user password, how do they assure availability and consistency? It's a great question, which I cannot answer. My opinion is that we have to let such enterprise users drive that development, while we give them an architecture that supports their use cases. Second, particularly if you separate the administration functions, core message handling should, at most, rarely care about the user information. The subscription information, which seldom changes, should contain sufficient information to handle the time-critical task of message dispatch. Our users (specifically IUser) is extremely minimal. A user consists of a display name, a password[1], an id, and a created on date. There are some additional methods or properties which are just convenient APIs for queries and membership updates, but really it's not much more than a way to collate a set of registered addresses under one unit. -Barry [1] With Persona, we can *probably* get rid of the password. It's only going to be used to do authenticated email commands, but it sucks for security. It's also probably true that few people actually use the email command interface - heck even I rarely use it. It's important to keep, but I think it would be better to base that on OpenPGP rather than plain text passwords. signature.asc Description: PGP signature ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Architecture for extra profile info
On Apr 18, 2013, at 10:26 AM, Terri Oda wrote: I thinks case, case we have to be *much* more conservative about dependencies. I think Django would be right out as a dependency for Mailman core, for example. Plus, we're going to have to care a lot more about speed and all. Definitely. However (and I'm not saying it has to be this way ;) if the user database were a Django app, and there were REST APIs that the core could call to do updates, then when something in the core changes, an event would get triggered that would make the RESTish call to update the user database. Similarly, when something in the user database changes that the core needs to know about, it would call the core's REST API to make that change. We would have to design something that would be robust enough to deal with failures, but I think it could be done. 2. The user module reads from mm-core and augments it. This gives us the ability to supplement mm-core without impeding speed. We discussed possibly filling in the blanks with respect to things like the user preferences (which are currently set by membership, by user and by email address... but a lot of those return an empty set when queried if nothing is set directly there...) so this is maybe something we already want. Conceptually, #1 is probably easier because everything will be in one place, but if we do #2 right, we can make it just as conceptually easy for HyperKitty/Postorius/etc. without impeding Barry's core dev at all. That does mean in case 2 that Mailman Extraneous User Stuff is going to depend on Mailman Core, though. Which I think is fine for now. Without the core, what do you have? :) a) It doesn't add any dependencies to Mailman core. b) It doesn't require big changes in Mailman Core. Given that core is pretty much ready to release, now would be a bad time for changes, and I'm just not sure we can justify that amount of work for the types of features that will be built on the extraneous user stuff. c) It will be much easier to rip this out and replace it when we better understand our actual needs. (e.g. Right now, I think a case could be made that a quick mock-up in django would be fine, but I suspect that requiring django for some potential applications would border on ridiculous) We're probably going to be running around with a bit of a hack job for the user database in the near future (either done by a student who needs it in a hurry or done by one of the core devs to support a student who needs it in a hurry) so while I don't like to design on the assumption it's going to go wrong, I think in this case planning for a redesign might be prudent because it's pretty clear we don't actually know all our requirements. +1 -Barry ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Architecture for extra profile info
On Apr 18, 2013, at 09:39 PM, Florian Fuchs wrote: I think in this case it makes sense to spend a more time on the API as seen from the outside (urls, methods, json responses) than the actual implementation. If the API is good, it's totally acceptable if the underlying implementation will be redesigned later. +1 -Barry ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Architecture for extra profile info
On Apr 19, 2013, at 10:22 AM, Stephen J. Turnbull wrote: 2) use some other authentication method. What's wrong with HTTPS + Basic Auth? Oh, one thing about HTTPS + Basic Auth. Right now, MM3 core has only one admin user and password for access to its REST API. So it can't be used to authenticate individual users, only the root user of the REST API. -Barry ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] anti-spam filter
On 13-04-18 6:40 PM, Patrick Ben Koetter wrote: If we stop at a programmable interface - which I understand is what you and Terri suggest - they will not be able to use Mailman in more complex setups, because integrating additional mail processing components would require them to program. Oi, I hope that's not what it sounded like I was advocating. I want a fair bit more than just an generic interface. In my ideal world, the deliverable for this project will be everything a sysadmin needs to integrate SpamBayes, SpamAssassin, and maybe 2 other related mail filtering tools (e.g. ClamAV?) This includes an installer for each one or at least a set of INSTALL_$SPAM_SOLUTION.TXT files and all the work necessary so that they have about 2 steps that amount to install the thing and enable the thing in mailman by flipping this switch/changing this config option. So I think in that respect, Patrick and I are on the same page. I don't think we're saying exactly oh, all sysadmins could do this in a few minutes so much as is this really worth a whole summer of mentoring time given that most of our mentors could write it in 2 weeks themselves if they had need? The question is whether it's a viable GSoC project, not so much whether it's a thing that would be useful to someone, someday. *I* still think that there's potential for a good GSoC proposal that includes spam filtering, assuming the student understands that this is more of an integration project (NOT a build a spam filter! project) and the student is willing to pair this with some other useful features in order to be sure of having 12 weeks of work. Terri PS - milters sound like something any students interested in this project should read up on and mention in their proposals why they did/didn't choose to go that route. It's a good way to show that you've been paying attention to discussions here! :) ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Architecture for extra profile info
Richard Wackerbarth writes: On Apr 18, 2013, at 8:25 PM, Stephen J. Turnbull step...@xemacs.org wrote: Richard Wackerbarth writes: Since we consider the user manager to be a part of the MM complex, what have we gained by hiding the underlying credential from the web interface? Security. See the OAuth 2.0 spec (RFC 6749) which recommends (at SHOULD level) this practice. RFC 6749 addresses the implementation of an OAuth authorization system. In this context, SHOULD refers to the implementation of this RFC. It does not imply that other authorization schemes also need to meet those same criteria. True, but logically irrelevant: it does not mean that the recommendations of the RFC are irrelevant in the design of authorization schemes. OAuth has reasons for recommending that you avoid passing user- supplied credentials around. These include (among others I haven't the imagination to supply here, I'm sure) (1) privacy of the user (the component the user wants access to may have no need to know who the user is) (2) security of the user credentials (leaking the auth token does not allow an attacker to access all resources the user is authorized for) (3) the accessed component doesn't know the importance of the user credentials (the user may have used the same password in several systems, or the user may have very high privileges in other parts of this system), increasing the risk involved in (2). I see no reason to suppose Mailman is not subject to these considerations. (3) is certainly relevant, as I know that I am simultaneously a site owner, a list owner, a moderator, and a subscriber for some lists. There is a plausible workflow in which a user (who happens to be a list owner) who is browsing the archives is given a subscriber-level token, and when they decide to access a list admin page, they need to re-authenticate to upgrade their authorization to list owner. If they then access a non-admin page, or they time out before accessing another admin page, the owner-level token is downgraded to a subscriber token. (This is like sudo on POSIX systems.) I'm not arguing that Mailman should default to such a workflow, but I think we should be able to support it. Passing around user credentials makes it harder to audit such a workflow. As for security, exposing the authorization server to direct Internet access is, in itself, a security weak point. I wouldn't say necessarily weak, but it certainly expands the attack surface that needs to be defended. That's why I don't want to include an auth server implemented by security amateurs (us!) ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] anti-spam filter
Barry Warsaw writes: There are several ways to think about it, but I guess the easiest one is does this chunk of processing change the message or make a non-destructive moderation decision? Or more simply, is it moderation or modification? At least for me, the concept is not a problem. The issue is (mental) duck-typing, that's all. Aside: I wanted to find a better name than handler for the modification bits, but I failed. I would have rather done away with the term handler in MM3 so suggestions are welcome for the term naming the units that plug into the modification pipeline. +1 ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] anti-spam filter
Barry Warsaw writes: I would love to have contributions to support at least Exim and Sendmail out of the box. If you're an expert willing to contribute that code, please get in touch. I'm not an Exim expert, but my production[1] system uses Exim. I'm working (slowly) on Mailman 3 integration. Footnotes: [1] It's part of the daily workflow, but high availability is not a requirement. :-) ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Architecture for extra profile info
Barry Warsaw writes: It's also probably true that few people actually use the email command interface - heck even I rarely use it. Emacs and (some) Debian folks do, though. It's not random, there are whole constituencies (small) out there for this feature. ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Architecture for extra profile info
Barry Warsaw writes: but also remember how much pain we had at the sprint trying to get Postorius and HyperKitty deployed together (how's that coming by the way?). I got mail from Yarko, does that help? :-) I hope to get back to that this week, now that I've initialized my classes. Dunno if Yarko has done anything, or if anyone else is working on it. Eventually OAuth is a good idea and I'm not aware of anything else that fits the bill as well, for authenticated scripting of REST APIs. But we probably don't need it for now. We don't *need* anything we don't already have :-), but I'd like to see OAuth and Persona for subscribers. One important requirement is that for any data that is kept in both the core and the user database, we must have a way of keeping them in sync. The easiest way of doing that I think is to allow two way communication between them so that if data changes in the core (e.g. an address gets verified by reply instead of link-click), the core can inform the user database of this event. This isn't going to fly for enterprise usage. I mean, you can inform the enterprise DB, but it's highly unlikely to do anything useful with the information. I think in the core user has to be a rather abstract class, which provides links to profile information (perhaps in a Mailman-supplied component, or in an enterprise DB, or both[1]), and to list-related information. Footnotes: [1] UI note: if both, enterprises may want official information to be visually distinguished from unofficial information. ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
