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 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 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] ssl for admin pages
Quoth matze [EMAIL PROTECTED]:
...
| so i dived into the mailman sources and figured out a possible
| solution. it seems to me that the best way to achieve ssl connections
| for the admin is putting a condition in ScriptURL() in Utils.py.
|
| if((0 != mm_cfg.DEFAULT_ADMIN_USE_SSL) and
|(target[0:5] == 'admin')):
| web_page_url = replace(web_page_url, 'http:', 'https:')
|
| as you see a new paramerter DEFAULT_ADMIN_USE_SSL has been added to
| Default.py. i tested this on the lists of both projects and it's
| working fine. as i'm sure that there are more ppl out there who would
| like this feature i ask you whether you are interrested in adding it
| to the mailman distribution. i uploaded a patch for mailman 2.1 on the
We don't support passwords for admin at all, at our site, so I didn't
have exactly the same problem. We do use cookies for authentication,
though (as does standard Mailman password authentication), and we
needed to make these ``secure'' cookies that only go to the server
via SSL. And we need that for everyone, not only admin.
I added a parameter to ScriptURL(..., upgrade=0) and a couple of
functions to deal with the protocol part of the URL (http vs. https.)
The upgrade parameter indicates that the URL must be https. And then
I had to change a few modules other than Utils.py - some to specify a
true value for upgrade, if for example the link is to an archive
page that is protected, and some to pass this upgrade parameter through
from there to ScriptURL() (GetScriptURL(), for example.)
The effect is to present either an http or an https view of the site,
depending on the preceding URL. If you get there via https, the links
will _all_ be https, even to listinfo etc. This gets a little complicated,
but is in my opinion better than making everything https hard coded, which
would cause problems for some people, and yet it does support an all-https
site as an option for SSL browsers.
Following is highlights of the code changes.
Donn Cave, University Computing Services, University of Washington
[EMAIL PROTECTED]
===
RCS file: RCS/SecurityManager.py,v
retrieving revision 1.3
diff -c -r1.3 SecurityManager.py
*** 1.3 2003/04/28 22:50:48
--- SecurityManager.py 2003/02/21 00:18:39
***
*** 239,244
--- 239,245
# We use session cookies, so don't set `expires' or `max-age' keys.
# Set the RFC 2109 required header.
c[key]['version'] = 1
+ c[key]['secure'] = 'yes'
return c
def ZapCookie(self, authcontext, user=None):
===
RCS file: RCS/Utils.py,v
retrieving revision 1.3
diff -c -r1.3 Utils.py
*** 1.3 2003/04/28 22:50:48
--- Utils.py2003/06/09 22:23:50
***
*** 238,254
return [p for p in path.split('/') if p]
return None
! def ScriptURL(target, web_page_url=None, absolute=0):
target - scriptname only, nothing extra
web_page_url - the list's configvar of the same name
absolute - a flag which if set, generates an absolute url
if web_page_url is None:
! web_page_url = mm_cfg.DEFAULT_URL_PATTERN % get_domain()
if web_page_url[-1] '/':
web_page_url = web_page_url + '/'
fullpath = os.environ.get('REQUEST_URI')
if fullpath is None:
fullpath = os.environ.get('SCRIPT_NAME', '') + \
--- 238,288
return [p for p in path.split('/') if p]
return None
+ def CurrentHTTPProtocol(default):
+ server_port = os.environ.get('SERVER_PORT', None)
+ if server_port is None:
+ return default
+ elif server_port == '443':
+ return 'https'
+ else:
+ return 'http'
+
+ def DefaultURL(host = None):
+ protocol = CurrentHTTPProtocol('http')
+ if host is None:
+ host = mm_cfg.DEFAULT_URL_HOST
+ return mm_cfg.PROTOCOL_URL_PATTERN % (protocol, host)
+
+ def UpgradeURL(old, force):
+ if force:
+ protocol = 'https'
+ else:
+ protocol = CurrentHTTPProtocol(None)
+ if protocol is None:
+ return old
+ try:
+ oldproto, rest = old.split(':', 1)
+ except ValueError, TypeError:
+ return old
+ if protocol == 'http' or oldproto == protocol:
+ return old
+ else:
+ return protocol + ':' + rest
! def ScriptURL(target, web_page_url=None, absolute=0, upgrade=0):
target - scriptname only, nothing extra
web_page_url - the list's configvar of the same name
absolute - a flag which if set, generates an absolute url
if web_page_url is None:
! web_page_url = DefaultURL(get_domain())
! if upgrade:
! web_page_url = UpgradeURL(web_page_url, upgrade)
if web_page_url[-1] '/':
web_page_url = web_page_url + '/'
+ else:
+ web_page_url = UpgradeURL
Re: [Mailman-Developers] Re: [Spambayes] spambayes fronting a mailinglist?
Quoth [EMAIL PROTECTED] (Barry A. Warsaw): ... | False positives get caught on the admindb screen, so you approve and | train them in one action. Although I never saw any false negatives, I | think the way to handle these will be to add a -spam address that | people can send messages to. If the list admin sends it then it gets | spam trained. If not, the list admin will have a chance to decide | whether to spam train it or not. I thought of that, but had some doubts. I'd strike the ``if the list admin sends it'' part, but maybe other sites are OK with admin passwords or whatever it takes to make that work. But mainly I'm not sure I see how an average admin is going to re-send something and make it look like the original - I'd hate to accidentally train a spam filter to reject all mail from the admin! 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] mm2.1 - DEFAULT_PLAIN_DIGEST_KEEP_HEADERS
Quoth Phil Barnett [EMAIL PROTECTED]: | On Tuesday 14 January 2003 4:25 pm, Barry A. Warsaw wrote: ... | BTW, if anybody else is going to be at the Spam conference, let me | know. I'd love to have a chat about Mailman, spam and other stuffis. | I'll be getting in Thursday night. | | I'd love to see mailman get some spam recognition and some thresholds that we | can set to deliberately get rid of the most obvious stuff. The statistical approach sounds very good to me for lists - I guess the spambayes project that some notable Python people have been working with falls in that category, I've been using something called spamoracle, etc. In this case, though, before you start thinking about thresholds, you have to train the classifier for your list's traffic - furnish it with examples of good and bad mail. After a couple of batches, it's surprisingly accurate with my own mail, and since lists should normally follow a narrower range of subject matter it ought to do even better there. I haven't thought of a real good way to set up the training, though. You want to be able to select particular messages from the archives and feed them into the classifier intact (headers and everything.) That sounds like writing a new archive index from the ground up (which might be a good thing anyway, but I hope I'm wrong and that isn't necessary!) Donn Cave, [EMAIL PROTECTED] ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Alternate authentication mechanism (was ...RELEASED Mailman 2.1 beta 5)
Quoth Terri Oda [EMAIL PROTECTED]: | On Wed, Nov 20, 2002 at 03:10:29PM -0500, Stonewall Ballard wrote: ... | Nobody on any of the lists I run would have a clue on how to use this. | And to contrast, I've not only had people request this sort of thing, or | express surprise that there is no secure way to do passwords, but I've also | gotten mail from one user had some, um, choice words for the list | administrators when she discovered that her password was sent in plaintext. I think at our site, most fall into both categories. They're generally not interested in computing technology of this kind and you can't make them understand something they won't think about. But we've worked hard enough to make them conscious of a password security issue here - I mean, they will sense an incongruity. As do we. Mailman is one of the few, if not the only, application at our site that uses passwords, and we had to make a case for it. Part of the deal is that we avoid password authentication for our own site local users, so they (we hope) will not be tempted to set their Mailman password the same as their site (Kerberos) password. Instead they use their Kerberos password to authenticate to the site web authentication service, whereupon they're authenticated automatically to Mailman (as their Kerberos principal, which I map to mailman ID.) That's our fig leaf. Donn Cave, [EMAIL PROTECTED] ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] mailman-bugs list?
Quoth J C Lawrence [EMAIL PROTECTED]: | On Mon, 16 Sep 2002 12:11:44 -0600 | Jason R Mastaler [EMAIL PROTECTED] wrote: | How about shuffling all the Sourceforge bug reports/replies to a | separate list, instead of here? | | They used to be separate and were deliberately moved to the -developers | list as a way of keeping them under scrutiny and review. For me, it would be more effective to that end if the original subject appeared in my mailer's presentation of the Subject header. I mean, in this morning's mail, I see [Mailman-Developers] [ mailman-Bugs-610570 ] RFC and that's better than usual. I know this is my fault - you all probably have fancier mailers or more screen real estate or whatever, but I thought I'd share that anyway. I probably overlook some traffic that I could be scrutinizing and reviewing, if the first 2 or 3 letters of the subject don't grab me. Donn Cave, University Computing Services, University of Washington [EMAIL PROTECTED] ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman-21/listinfo/mailman-developers
[Mailman-Developers] External domain web authentication
My site (University of Washington) has a central authentication domain, and we like to use it for everything. I have hacked up 2.1b2 to support external authentication, meaning that your site-wide (UW) login ID is attached to your Mailman email addresses, and once authenticated by our web login you're authorized to deal with those emails. We're getting set to use Mailman for a bunch of lists, like seriously several thousand. List membership varies, some are all UW (course mailing lists), some have hardly any UW members. Non-UW members will not be affected, they'll use the existing password system. UW members can use the password system too (so far, anyway), but they will normally (we hope) use their UW web login authentication. That's a cookie based central system, http://www.washington.edu/computing/pubcookie/ I process the potential UW login prior to WebAuthenticate(), and if it works, I can get per list email addresses for that ID, pick the right one for the page in question, if any, and authorize. Or if not, go on to WebAuthenticate() for the email and password. If authenticated by ID, I fill in the blanks in the listinfo page. I have it roughly working, can't tell if anyone but me has really even tried it yet. So it's real early in the development cycle. I can certainly release the code, but at this point it's more like a bunch of hacks to support our environment, than a solution to the general problem. Is there anyone else out there who is doing this kind of thing, or contemplating it? The changes are primarily in Cgi/*.py, plus a couple of policy refinements in MailList.py, and of course a module to handle all the new stuff and the external database that holds the list/email data for an ID. The database in particular is just a stop-gap implementation. Donn Cave, University Computing Services, University of Washington [EMAIL PROTECTED] ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman-21/listinfo/mailman-developers
