Re: [Mailman-Developers] Storing additional user data
On Thu 2003-07-10 15:21:44 -0400, Barry Warsaw wrote: On Thu, 2003-07-10 at 15:12, David Birnbaum wrote: It's easy enough to add members to the list and remove them from an external source, but it would be really nice if we could have Mailman call a program of our choice, with some arguments/environment variable/STDIN whenver it reacts to a bounce or something similar like that, passing in the relevant information about which email address is being affected and what's being done to it. Ug. I think forking is too expensive. What I could imagine would be an XMLRPC backend against which you could write a server in your language of choice. Now, whether XMLRPC is more efficient than fork/popen/and friends, I don't know, but at least you won't have to worry about funny shell escapes and other nonsense. An XML/SOAP-like interface would be nice! Listserv supports something it calls 'list exits', which are programs called in response to significant happenings (a bit of an old and crufty mechanism, but better than nothing). Their manual documents the 'exit points' they support. They all look quite obvious, but it might be of some use if something similar is being planned for Mailman3. Section 5.2 of their manual: http://www.lsoft.com/manuals/1.8e/developer/developer.pdf -- Write friendlier email : http://www.math.fu-berlin.de/~guckes/mail/edit.html Certify your signature : http://sig.jellybaby.net/ [101f42d9ex623] ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
[Mailman-Developers] Storing additional user data
Hi, I'm hoping to use Mailman, but have a few requirements which may not be addressed 'out of the box'. In particular, I'm integrating with another system and would like to store the foreign system's user IDs in Mailman so that I can correlate our users with Mailman subscribers. This will then allow us to do things like replicate changes to users' email addresses, which they currently enter in the foreign system. I've considered using clone_member from the command line, but this seems like it might not be problem-free. For instance, a user could change his email address to match someone else's who's already subscribed to one or more lists, and then change it back, and thus hijack that user's identity (identifying only be email address, the users would become indistinguishable to us). Does Mailman support the storage of any sort of user metadata? If not, would it be easyish to add? I'm not terribly familiar with Python, but it looks like I could add attributes to a class and then have them persisted by Python's 'marshalling' into a (non-standard) Mailman database. Thanks, Chris -- Write friendlier email : http://www.math.fu-berlin.de/~guckes/mail/edit.html Certify your signature : http://sig.jellybaby.net/ [101f42d9ex623] ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Storing additional user data
On Tuesday, July 8, 2003, at 06:19 AM, Chris Boulter wrote: I'm hoping to use Mailman, but have a few requirements which may not be addressed 'out of the box'. In particular, I'm integrating with another system and would like to store the foreign system's user IDs in Mailman so that I can correlate our users with Mailman subscribers. This will then allow us to do things like replicate changes to users' email addresses, which they currently enter in the foreign system. I've considered using clone_member from the command line, but this seems like it might not be problem-free. For instance, a user could change his email address to match someone else's who's already subscribed to one or more lists, and then change it back, and thus hijack that user's identity (identifying only be email address, the users would become indistinguishable to us). Right. You need an extra database, user-id :: list :: role :: mailman-id (maybe you wouldn't need role, we do because our external IDs authenticate also.) Does Mailman support the storage of any sort of user metadata? If not, would it be easyish to add? I'm not terribly familiar with Python, but it looks like I could add attributes to a class and then have them persisted by Python's 'marshalling' into a (non-standard) Mailman database. It isn't easyish to add. There are a boat-load of places where that extra user-ID needs to be carried around and accounted for in various ways. I think in the long run there will be enough interest in this that we'll see some support for it in Mailman, but at best I imagine it's a long way off. In your case, I'm wondering if some arrangement could be made so that email delivery unifies everything with the foreign system, and your user just uses that ID as an email address. Put the final destination address in an LDAP database and have sendmail look it up. No changes to Mailman. Or is that what you're doing already? Well, anyway, without some real Python expertise I think you're better off working around Mailman than trying to make this kind of change to it. Donn Cave, University Computing Services, University of Washington [EMAIL PROTECTED] ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Storing additional user data
On Thu 2003-07-10 09:20:20 -0700, Donn Cave wrote: On Tuesday, July 8, 2003, at 06:19 AM, Chris Boulter wrote: Does Mailman support the storage of any sort of user metadata? If not, would it be easyish to add? I'm not terribly familiar with Python, but it looks like I could add attributes to a class and then have them persisted by Python's 'marshalling' into a (non-standard) Mailman database. It isn't easyish to add. There are a boat-load of places where that extra user-ID needs to be carried around and accounted for in various ways. I think in the long run there will be enough interest in this that we'll see some support for it in Mailman, but at best I imagine it's a long way off. Yes, I can imagine others might be also interested in storing data in addition to subscribers' email addresses - having external system UIDs would help with 'single sign-on' integration too, which I've seen discussed here. In your case, I'm wondering if some arrangement could be made so that email delivery unifies everything with the foreign system, and your user just uses that ID as an email address. Put the final destination address in an LDAP database and have sendmail look it up. This sounds interesting. So you're suggesting that rather than storing email addresses of subscribers in Mailman, we store our external system UIDs, then have sendmail resolve those into email addresses just before the mail gets sent? This sounds neat, but wouldn't it break other parts of Mailman? Anything which compares the From address of an incoming email would break, so that would probably screw with moderation among lots of other things. I'll carry on thinking about it, but we might be able to just enforce a unique constraint on email addresses, so we know a given email address always refers to a particular user in our external system. Thanks for your help so far. Chris -- Write friendlier email : http://www.math.fu-berlin.de/~guckes/mail/edit.html Certify your signature : http://sig.jellybaby.net/ [101f42d9ex623] ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Storing additional user data
On Tue, 2003-07-08 at 09:19, Chris Boulter wrote: Does Mailman support the storage of any sort of user metadata? If not, would it be easyish to add? I'm not terribly familiar with Python, but it looks like I could add attributes to a class and then have them persisted by Python's 'marshalling' into a (non-standard) Mailman database. Donn and Charlie posted good responses. I'll just add two things: - I'm designing Mailman3's user database so that additional foreign information can be stored with Mailman's concept of a user. We'll see if this works out as planned. - You can just add attributes to the MailList object, e.g. via the extend.py machinery, and it will persist automatically, as long as the value is pickleable. Cheers, -Barry ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Storing additional user data
On Thu, 10 Jul 2003, Chuq Von Rospach wrote: This sounds interesting. So you're suggesting that rather than storing email addresses of subscribers in Mailman, we store our external system UIDs, then have sendmail resolve those into email addresses just before the mail gets sent? Personally, I wouldn't try to extend Mailman to do this. Instead, I'd set it up so Mailman could use external data sources easily, and allow people to write adaptors to fit into that. I've been following related threads on this a bit, and I was wondering if it would be possible to implement an external mechanism that works via a fork() for those of us who don't speak Python. It's easy enough to add members to the list and remove them from an external source, but it would be really nice if we could have Mailman call a program of our choice, with some arguments/environment variable/STDIN whenver it reacts to a bounce or something similar like that, passing in the relevant information about which email address is being affected and what's being done to it. For our specific purposes, we just need to know when Mailman gets a bounce and disables someone - that way, the appropiate flags in our MySQL database can be adjusted. Cheers, David. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Storing additional user data
On Thu, 2003-07-10 at 15:05, Chuq Von Rospach wrote: you risk turning mailman into yet another CMS, rather than allowing mailman to interconnect with all of the existing CMS's... the latter is a much easier and more powerful task. ...and is /definitely/ the direction Mailman 3 is going in. If I were to do this, I'd find two volunteers, one running php-nuke, one running slashcode, and have them write the plug-ins for those CMSes while Barry wrote the interface they'd talk to, and once Mailman worked friendly with both of those, it'd likely work easily with any CMS. and/or Zope hint, hint. Soon, I hope to have a strawman membership API for Mailman 3. Stay tuned... -Barry ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Storing additional user data
On Thursday, July 10, 2003, at 11:50 AM, Chris Boulter wrote: ... Yes, I can imagine others might be also interested in storing data in addition to subscribers' email addresses - having external system UIDs would help with 'single sign-on' integration too, which I've seen discussed here. Right. With luck. In your case, I'm wondering if some arrangement could be made so that email delivery unifies everything with the foreign system, and your user just uses that ID as an email address. Put the final destination address in an LDAP database and have sendmail look it up. This sounds interesting. So you're suggesting that rather than storing email addresses of subscribers in Mailman, we store our external system UIDs, then have sendmail resolve those into email addresses just before the mail gets sent? This sounds neat, but wouldn't it break other parts of Mailman? Anything which compares the From address of an incoming email would break, so that would probably screw with moderation among lots of other things. I'll carry on thinking about it, but we might be able to just enforce a unique constraint on email addresses, so we know a given email address always refers to a particular user in our external system. I think that might be what I meant. Say your site is zoo.org, and your ID in your external system is cboulter. Set up a host y that references that data, so mail to [EMAIL PROTECTED] forwards to [EMAIL PROTECTED] Use [EMAIL PROTECTED] in Mailman. Voila'. If that made sense, I suppose you would already be doing it, but at any rate that was the idea. I only threw in LDAP to sound like I know what I'm talking about. Donn Cave, University Computing Services, University of Washington [EMAIL PROTECTED] ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Storing additional user data
On Thu, 2003-07-10 at 15:12, David Birnbaum wrote: It's easy enough to add members to the list and remove them from an external source, but it would be really nice if we could have Mailman call a program of our choice, with some arguments/environment variable/STDIN whenver it reacts to a bounce or something similar like that, passing in the relevant information about which email address is being affected and what's being done to it. Ug. I think forking is too expensive. What I could imagine would be an XMLRPC backend against which you could write a server in your language of choice. Now, whether XMLRPC is more efficient than fork/popen/and friends, I don't know, but at least you won't have to worry about funny shell escapes and other nonsense. just-musing-ly y'rs, -Barry ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Storing additional user data
Chuq's right on the money here. I'd be happy to do stuff on the PHP interface side. This would allow connectivity with PHP-Nuke, Postnuke, Xaraya, and any other PHP-based CMS. Barry, continuing our recent conversation, I'd be happy to try to do something on the PHP side but I'll need to get some pointers on how to do things in a more elegant way than I had initially suggested - running $mailman/bin commands and parsing (yuck). - Kevin On Thu, 2003-07-10 at 15:05, Chuq Von Rospach wrote: Personally, I wouldn't try to extend Mailman to do this. Instead, I'd set it up so Mailman could use external data sources easily, and allow people to write adaptors to fit into that. That way, users could write adaptors for their favorite system (php-nuke, slashcode, drupal, yada yada yada), where there's already an existing account management system in place, and let it manage the subscriptions and feed delivery data to mailman, and have mailman feed undeliverable data back to the system. you risk turning mailman into yet another CMS, rather than allowing mailman to interconnect with all of the existing CMS's... the latter is a much easier and more powerful task. If I were to do this, I'd find two volunteers, one running php-nuke, one running slashcode, and have them write the plug-ins for those CMSes while Barry wrote the interface they'd talk to, and once Mailman worked friendly with both of those, it'd likely work easily with any CMS. chuq (nope. haven't been thinking about doing that myself. nope. not me. Just shooting from the hip here) ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Storing additional user data
On Thursday, July 10, 2003, at 12:19 PM, Barry Warsaw wrote: friendly with both of those, it'd likely work easily with any CMS. and/or Zope hint, hint. Zope should be one of the interfaces, definitely, but I really think it's time Mailman is interfaced with some non-Python tools so it can play better with the world beyond Python. It'll help it become that much more accepted Out There... ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Storing additional user data
On Thu, 2003-07-10 at 15:37, Chuq Von Rospach wrote: Zope should be one of the interfaces, definitely, but I really think it's time Mailman is interfaced with some non-Python tools so it can play better with the world beyond Python. It'll help it become that much more accepted Out There... Sure. MM3 will be much more toolkit oriented, with replaceable web components, user database, user interface, etc. The core code will always be Python, but I intend to write interfaces to all the pluggable stuff. The question is what the medium for pluggability is going to be. Python has good IPC support, including XMLRPC and ORB-ish interfaces. It's always going to be easiest to extend and embed in Python, but it should be possible to interface it with non-native applications. But how, and how much of that should come with the Mailman core? For example, I know a lot of people want to interface Mailman with PHP. I don't really know what that means though. Do you want to be able to write the entire web interface in PHP? If we defined a classic CGI interface to Mailman, would that be enough? E.g. The privacy screen takes the following form variables: blah, foo, baz which must be a string, int, and a float respectively. That ought to be doable to some reasonable approximation. Interfacing a Python library with an external system has all the issues that any such system will have. How do you interface a C++ web application with a Perl U/I? I think we need to map out what components people want to replace, and then define mechanisms and interfaces for other things to be slotted in. I don't want to lose sight of the requirement for Mailman to be usable out of the box though. -Barry ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Storing additional user data
On Thu, 10 Jul 2003, Barry Warsaw wrote: It's easy enough to add members to the list and remove them from an external source, but it would be really nice if we could have Mailman call a program of our choice, with some arguments/environment variable/STDIN whenver it reacts to a bounce or something similar like that, passing in the relevant information about which email address is being affected and what's being done to it. Ug. I think forking is too expensive. What I could imagine would be an XMLRPC backend against which you could write a server in your language of choice. Now, whether XMLRPC is more efficient than fork/popen/and friends, I don't know, but at least you won't have to worry about funny shell escapes and other nonsense. Somewhat expensive, perhaps...BUT it has the advantage of being pretty quick to write and very simple for those who don't have the time, knowledge, or resources (#1 and #3, in my case) to build something more complicated. And, how many requests per second are really going to hit the server, in any case? Just a thought David. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Storing additional user data
On Thu, 2003-07-10 at 17:37, David Birnbaum wrote: Somewhat expensive, perhaps...BUT it has the advantage of being pretty quick to write and very simple for those who don't have the time, knowledge, or resources (#1 and #3, in my case) to build something more complicated. And, how many requests per second are really going to hit the server, in any case? I'm not against a command line interface that meets your needs, if that's the most expedient way to hook Mailman up to foreign systems. I /would/ however like to have some requirements for that hookup so we can tailor the scripts to those specific needs. For example, the current crop of scripts in bin/ were written primarily to solve a problem that the human operator was having. That may not be the most efficient or useful interface for hooking two programs up. -Barry ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Storing additional user data
On Thursday, July 10, 2003, at 02:48 PM, Chuq Von Rospach wrote: ... 4) write a script that processes ~mailman/logs/bounce once a day and feeds bounce data back to the subscription management program. That might be the key point - if the information he needs is in logs/bounce, then something can read that and do the MySQL flags as required. If that also means the web pages have to be disabled, subscriber lists reloaded, etc. -- that would also have to be done when using the proposed external interface program, true? I may have missed something, this thread took kind of an odd turn a couple of messages back and I'm not sure where I am. In any case, logging seems like a fine way to satisfy external interface needs when they're asynchronous. When they're synchronous, you have bigger problems anyway. Donn Cave, University Computing Services, University of Washington [EMAIL PROTECTED] ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Storing additional user data
On Thu, 10 Jul 2003, Barry Warsaw wrote: Somewhat expensive, perhaps...BUT it has the advantage of being pretty quick to write and very simple for those who don't have the time, knowledge, or resources (#1 and #3, in my case) to build something more complicated. And, how many requests per second are really going to hit the server, in any case? I'm not against a command line interface that meets your needs, if that's the most expedient way to hook Mailman up to foreign systems. I /would/ however like to have some requirements for that hookup so we can tailor the scripts to those specific needs. For example, the current crop of scripts in bin/ were written primarily to solve a problem that the human operator was having. That may not be the most efficient or useful interface for hooking two programs up. Hmmm...well, for this particular application, we pretty much need a simple way to link in to our main database when bounces occur. If I were to craft a quick and dirty interface, it might look like this: [command] -e(mail) '[EMAIL PROTECTED]' -l(list) 'listname' -b(ounce) [ soft | hard ] and when a person gets removed (due to bounces, or anything else, I suppose): [command] -e(mail) '[EMAIL PROTECTED]' -l(ist) 'listname' -u(nsubscribe) People can't subscribe directly to the list, we handle that elsewhere, so the mailing interface and such does not apply. So this would take care of my immediate needs. The other option as was suggested in the list, would be to write a script that tails the bounce or other logs, and handles things asynchronously that way. I'm considering that as an alternative that's also relatively straightforward to write. David. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
