Re: [Mailman-Developers] bugs on launchpad
On 3/22/2012 5:48 PM, Stephen J. Turnbull wrote: On Fri, Mar 23, 2012 at 1:09 AM, Barry Warsaw ba...@list.org wrote: If we add something like $archive_url to the decoration interpolation dictionary, what happens when we have multiple archivers that support permalink() enabled? Do we chose one at random (these are unordered)? -1 I agree so -2. I thinking is if you list administrator/owner has not defined an order, make it simple and impose a known order in that case - alphabetize/sort the order and pick the first one. Do we add a configuration variable to select a primary archiver for this? +1 +2 This would allow the list administrator/owner to define and pick the primary archiver. For any other archivers, people can go to the Archived-At header(s). If there's *no* archiver configuration variable, we don't know where to point to anyway for Gmane-like archivers (yes, I know, catering to Gmane will give Brad hives, but some people like Gmane). The local archive, if it exists, may seem TOOWTDI, but it might not be the preferred one even if it's the only one configured in Mailman (although that seems a lot less likely than the case where somebody just grandfathers an existing Gmane subscription as the archive URL of choice). Do we allow something like $archive_url.prototype as an interpolation variable to select e.g. the 'prototype' archiver? -1 Too complex. If people want alternative archives, they can go to the list FAQ or the Archived-At headers. If we go this way, we'd better have a *really* good comment and a pre-existing entry in the FAQ to save Mark some time. :-) I agree with Stephen. Too complex and can be confusing without it being well documented with a number of examples. ___ 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] New RFC on using DKIM with MLMs
Hello Ian, Sorry I am a bit late in responding but with our Thanksgiving holiday and me taking a few days of vacation I was away from email. I understand what you are saying in your message but I think you possibly missed my point. Given the definitions previously proposed for the Mediator header, I believe it is far too generic to be useful. To paraphrase the previous definitions for the Mediator header, any program/instance/etc. that modifies, adds content, regulates Users, etc. can use it [the 'Mediator' header]. To me, a reasonable reading and understanding of the definition[s] tells me the MUA, the MTA, any appliances, any other program/instance [including devices]/etc. can add the Mediator header REGARDLESS of whether or not that appliance/program/instance/device has added a Received header, a User-Agent header, or any other pertinent header(s). Since I think the Mediator header is, at this time, poorly defined and the initial point of the discussion was about having a List-Agent header for MLMs, I say List-Agent. As for my example you pulled apart :), I deliberately made it a worst case scenario just to highlight how the Mediator header was poorly defined. In fact, given the Mediator header definitions and your comments, you also highlight how poor the definition is since not only will the Mediator headers be added but also all the additional Received headers. I may be wrong in that you assume that if Received headers are used then the Mediator headers won't be used. However, the definition does not precluded having both, thus doubling (or more) on the number of headers. Again, I say stick with the List-Agent header for MLMs. It is narrowly defined and limited in scope, precisely what a header should be to be effective. Thanks for listening/reading :), Chris On 11/23/2011 5:16 AM, Ian Eiloart wrote: On 16 Nov 2011, at 16:10, C Nulk wrote: I can't help but consider the rash of useless Mediator headers. Consider the following example: Person 1 sends a message to a list which is then sent to Person 2. Person 1's site has separate appliances for the MTA, Spam checking, Anti-Virus, and Spy-ware, likewise for the receiver's site and the site the MLM is for the list. My reading of the above definitions tells me: 1. Person 1's MUA adds a Mediator header (creating a message is a simple special case of modifying/adding a message, But, there are already headers to identify the creator. There's no need to use a mediator header to duplicate other information. 2. Person 1's site adds 4 additional Mediator headers (one each for the MTA, Spam, Anti-Virus, Spy-ware since each modify/forward/add to the message, The MTA would use a received header, not a mediator header. If the message is routed through the other systems, then they should already add received headers. If the message isn't routed through those systems (e.g., the systems are plugged in to the MTA, then there's no need to add mediator headers). 3. The MLM's site adds 9 additional Mediator headers (4 inbound [item 2], 1 for the MLM [maybe more], and 4 outbound), 4. Person 2's site adds 4 additional Mediator headers (4 inbound [item 2]), 5. Person 2's MUA may or may not add a Mediator header depending on any rules/filters Person 2 has in place. ___ 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
[Mailman-Developers] Mailman v3 and ban-list
Hello, I thought I would ask a quick question on the development of Mailman 3. Over in the Mailman-Users list, Mark Sapiro mentions that he adds a regex into the ban_list of all of his lists. Is there any consideration being given to having a global ban_list which applied across all lists for a mailman instance? It would be nice to have both a global and a list-specific ban_list mechanism. The global version would allow one to put in one ban entry in for all lists. An example would be Mark's regex for answerpot (a list message harvester). Just a thought, Chris ___ 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] New RFC on using DKIM with MLMs
On 11/15/2011 6:52 PM, Barry Warsaw wrote: On Oct 29, 2011, at 06:39 AM, Patrick Ben Koetter wrote: I suggest we use the term 'Mediator' as introduced by D. Crocker in RFC 5598 http://www.rfc-editor.org/in-notes/rfc5598.txt instead: A Mediator attempts to preserve the original Author's information in the message it reformulates but is permitted to make meaningful changes to the message content or envelope. A Mediator's role is complex and contingent, for example, modifying and adding content or regulating which Users are allowed to participate and when. The common example of this role is a group Mailing List. (see section 2.1.4. Mediator and also section 5. Mediators) That makes a good case for Mediator. Hmmm. To me, the above definition for Mediator is reason enough to abandon it (for the time at least) because it is not well thought out regarding everything that may touch, modify, add content, regulate user, etc. Together with the above and a line from a previous message Patrick sent to the list: The term 'Mediator' describes the same, but it is general in meaning. Any instance modifying and forwarding a message can use it. I can't help but consider the rash of useless Mediator headers. Consider the following example: Person 1 sends a message to a list which is then sent to Person 2. Person 1's site has separate appliances for the MTA, Spam checking, Anti-Virus, and Spy-ware, likewise for the receiver's site and the site the MLM is for the list. My reading of the above definitions tells me: 1. Person 1's MUA adds a Mediator header (creating a message is a simple special case of modifying/adding a message, 2. Person 1's site adds 4 additional Mediator headers (one each for the MTA, Spam, Anti-Virus, Spy-ware since each modify/forward/add to the message, 3. The MLM's site adds 9 additional Mediator headers (4 inbound [item 2], 1 for the MLM [maybe more], and 4 outbound), 4. Person 2's site adds 4 additional Mediator headers (4 inbound [item 2]), 5. Person 2's MUA may or may not add a Mediator header depending on any rules/filters Person 2 has in place. So, at the end of this simple posting of a message to a list, we have 18+ Mediator headers, one for each time an instance adds content, modifies a message, or regulates a user. Granted, I may be making this a worst case scenario, but also consider any sites the message is relayed through - adding even more Mediator headers. Looking at a worst case scenario helps see where the problems occur and cracks in specifications happen. I am not opposed to a Mediator header. I just think since our discussion is focused on MLMs that List-Agent is the best choice that all MLM developers can come to an agreement on. As for other applications (news, web forum, etc), a discussion with those developers should (and needs to) take place to come up with a more generic header - be it Mediator or not. In any case, let's focus on MLM related headers, like List-Agent :), and then work on a more generic, non-conflicting header for others at a later time. I just see including non-MLM information into a MLM header discussion as feature-creep. Hmm, if there are no intermediate processes between receiving a message and approving it a List-Approved-Date seems fine. But if there are we run into the same problem as described below with List-Archived-Date - you can't tell when it was queued and when processing took place. Adding a second header might make the useful distinction: List-Received-Date RFC 2822 date timestamp when message was received by MLM List-Approved-Date RFC 2822 date timestamp when message was approved by moderator What if the message is automatically approved? Does it get a List-Approved-Date header? Merging with Murray's concept of Received states, it might just make more sense to put all that information into Received headers. The only issue I can see is if the Received headers are removed as part of processing, whether in an appliance, an MTA, or an MUA. I know it shouldn't happen but I received messages with missing Received headers. Having the information in a List-* header wouldn't hurt. Another header that might be useful here would be List-Approved-By which could be the name or email address of the moderator who approved it. Right now, MM3 doesn't fill that in, and it could of course be filled in by say list-ow...@example.com, but in MM3 it could be potentially filled in with the preferred address for the moderator that approved it. I see the benefit because it helps if you moderate in a team. But I fear the anger of people whose postings we decline. They search for moderator identities and then start molesting them e.g. by subscribing them to mailing lists that don't require opt-in. (Happend to me python.org postmaster. The angry person subscribed my address to various pr0n mailing lists and it took me weeks to get unsubscribed.) Good point. I do
Re: [Mailman-Developers] Mailman headers roundup
On 11/10/2011 12:33 PM, Patrick Ben Koetter wrote: * Barry Warsaw ba...@list.org: X-Mailman-Version The version of Mailman that sent the message. It can lose the X- prefix. Modify to: List-Agent, Mediator Next Step: Discuss I like List-Agent much more than User-Agent, since Mailman is only tenuously under any control of the user. I like having this header under the List- prefix, so I Mediator doesn't appeal to me. Here's why I would prefer Mediator: What we want is a header field name that indicates the message has been accepted, modified and forwared by a program. The header field name 'List-Agent' does that, but it is specific to mailing lists. The term 'Mediator' describes the same, but it is general in meaning. Any instance modifying and forwarding a message can use it. If we use List-Agent others will have to register another header field name - 'Mediator' would fit for all. p@rick I understand what you are saying. To me Mediator doesn't describe the same information specifically because it is too general in meaning. List-Agent as the header makes sense to me. Mailman manages whatever email distribution lists I create or manage, dealing with lists and the message traffic back and forth to it and subscribers. To me, it acts as a agent, thus List-Agent makes more sense. In addition, when I am or have to look through a messages headers to see what is happening, I want to be able to group common headers together. All the Received headers, all the List- headers so I can get a sense of things faster. The Mediator header doesn't lend itself to doing so. It is out on its own. This header discussion, to me, is about identifying and registering common headers useful for Mailman in particular and Mailing List Managers in general. The List-Agent header works best and working with other MLMs to register the common headers is for the best. I don't think we are trying to solve all the issues associated with email processing, only a little piece. If other software packages that may have some small interaction with email need a header, then let them build a consensus around their header and then register it. If, later in time, it turns out there is a need for a super-set of headers that includes MLMs, then maybe the Mediator header is appropriate which wouldn't conflict with List-Agent. For now, I think List-Agent is the best solution to provide a descriptive header for Mailman and other MLMs which when used with other proposed List- headers allows one to easily identify a MLM and its interactions with a message. Sorry for the long post. Thanks, Chris ___ 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] Mailman headers roundup
On 11/2/2011 8:06 AM, Barry Warsaw wrote: Thanks for coordinating this Patrick. On Oct 30, 2011, at 08:04 PM, Patrick Ben Koetter wrote: X-List-Received-Date This only gets added when the message is sent to the archive. Modify to: List-Archive-Sent Next Step: Discuss List-Archive-Sent (maybe with -Date) makes sense to me. This really is different than Received headers IMO since it's not recording any receiving event in Mailman. To the extent that it's useful to know when an MLM sends the message to its archivers, getting the direction right seems important. I agree with having a List-Archive-Sent header for when the message is sent to one (or more archivers). However, I still think there is a need for the date and time when the List actually receives the message. Let's say Mailman is running on the same system as a spam/anti-virus software package. The message comes into the systems MTA which then routes the message to the spam/anti-virus software where it is held for approval. Two days later, someone approves the message which is returned to the MTA for delivery. The MTA passes the message to Mailman. Mailman adds the List-Received-Date header since that is when Mailman received it. A similar argument can be made about the List-Archive-Sent header. The header should not be added until the last moment, basically right before calling the archiving module. If a list is moderated or a message is held, that will affect the List-Archive-Sent header because the message can't be sent unless a disposition is known about the message. The question in my mind is what to do about the case where, as in MM3, we have multiple archivers. Multiple L-A-S headers should be allowed, but then I wonder whether the headers need to record which archiver the header applies to. TBH, in MM3 when we send to one archiver, we send to them all so I'm not sure the extra complexity is worth it. I also don't know whether any other MLM supports multiple archivers. X-Message-ID-Hash propose an RFC as an extension of RFC 5064 Modify to: unclear Next Step: Discuss As an RFC, obviously we'd drop the X- prefix, but also Hash might be too vague. Personally I think Message-ID-Hash is fine and the theoretical RFC shouldn't allow much leeway in implementations (i.e. only one hash algorithm is allowed). This will probably be bikeshedded to death. Still, since Message-ID must be unique (and generally is, as backed up by The Mail Archive's data), I think base-32 of SHA-1 will in practice be just fine. X-Mailman-Version The version of Mailman that sent the message. It can lose the X- prefix. Modify to: List-Agent, Mediator Next Step: Discuss I like List-Agent much more than User-Agent, since Mailman is only tenuously under any control of the user. I like having this header under the List- prefix, so I Mediator doesn't appeal to me. I would much more prefer List-Agent over User-Agent. I agree Barry about Mailman tenuously under any control of the user. My experience is that users generally exercise no control over Mailman. Mediator also doesn't make much sense to me. Mailman settle any disputes for me. Nor, do I see it as an intermediate agency. I see lists in general and Mailman in particular as a collecting point or aggregator for messages for a common topic which then distributes the received messages to interested parties. So, instead of a Mediator header, I can see a Collector header, or Aggregator header, or a Distributor header, and even then none of them really make sense. To me, List-Agent makes the most sense. X-Mailman-Approved-At lose the X-prefix Modify to: List-Approved-Date Next Step: Create RFC or Extend RFC 2369? To generalize, it might be useful to have List-Moderation-Action and List-Moderation-Date headers. The former would have values like Approved, Held, Rejected, or Discarded, while the latter would have the date of the disposition. Seemingly useless actions like Discarded and Held would still be useful because even a discarded message may end up in some email graveyard for future data mining. II. MODIFY X-Mailer Only used when Mailman originates messages such as autoresponses. Modify to: User-Agent Next Step: Change code Similar to the above, I don't like User-Agent much here. I think this could be simply folded into List-Agent since there are probably plenty of other header clues to know that a message was originated by Mailman. I can see this one both ways. Since Mailman is the List-Agent doing the work, add to the message the List-Agent header. And because Mailman is generating the content, add to the message the User-Agent header and make it the same information from the List-Agent header. Then when you are reading the headers, you can see the MTAs Received headers, List-Agent tells you the list the message came from and User-Agent tells you who
Re: [Mailman-Developers] New RFC on using DKIM with MLMs
On 10/26/2011 5:43 AM, Ian Eiloart wrote: On 25 Oct 2011, at 02:04, Barry Warsaw wrote: On Oct 13, 2011, at 11:41 PM, Murray S. Kucherawy wrote: There's movement afoot to deprecate use of X- in header field names. Just call it Mailman-Topic. And if it's worthwhile, consider registering it with IANA. If registering headers is to be pursued, perhaps a standardized list of headers should be discussed with other MLM's and then put forth to IANA. The standardized headers should be able to handle generic list information along with MLM specific. My thought would be for List-* are generic headers all MLM's and MUA's can refer to for information. List-Mailman-* would be Mailman specific headers List-ListServ-* would be ListServ specific headers I wonder if we should remove the X- prefixes for Mailman 3. Here's a list of ones we still add or recognize (some might be used only in the test suite): X-Message-ID-Hash This could be replaced with DKIM sigs, I guess. X-Mailman-Rule-Hits X-Mailman-Rule-Misses This might be useful for diagnostics, but probably wants to be off in general. My view is that Mailman should not be doing message filtering. X-BeenThere I guess that's useful for avoiding list loops, perhaps? X-Mailman-Version I think this should be replaced with X-Mailer, or even User-Agent. That's not currently an SMTP header, but I think it should be. And it is in quite widespread use. I agree and disagree. I may be wrong but I see the X-Mailer specifying the MTA and User-Agent specifying the MUA. Perhaps a different header added by the MLM called List-Agent or List-ListAgent. X-Mailman-Approved-At X-Archive Does this do the same as List-Archive? X-No-Archive What does this mean? X-Ack X-No-Ack X-Peer X-MailFrom X-RcptTo Isn't that usually in the Received header? X-Originally-To Doesn't that do the same thing as List-post? X-Original-CC What's the purpose of including this? X-Original-Content-Transfer-Encoding X-MIME-Version X-Mailman-Copy X-List-Administrivia List-help? X-Content-Filtered-By X-Topics X-Mailer I think we should use User-Agent here. Thunderbird does, as do some other mail clients. Or, we should push for introduction of a List-Agent header. List-Agent header is my vote (see above :)) X-List-Received-Date Don't the Received headers carry this information? Maybe. They certainly contain the date the MTA received the message but not necessarily when the MLM received the message. Consider a message to be posted to a list. The MTA receives it and it is passed on to a Spam/AntiVirus device. The message is held at the device because is fails whatever checks are in place. Five days later, the device administrator goes through the held queue on the device, sees the message as okay and releases it. The MLM then receives the message to be posted. Now, when did the MLM really receive the message? When the MTA received it or five days later. I think there is enough of a possibility that keeping Received headers different from say a List-Received-Date header. X-Approve X-Approved -Barry Generally, I think we should avoid the use of headers that duplicate other existing headers. Where we want to add more information, then extend the List-* header set if the information might be generally useful for mailing list software. Otherwise, use X-Mailman-* (or even Mailman-*) so that people know where the header came from. I agree. Reduce and avoid duplication. Discussions should also occur with other MLM's to come up with a generic List-* header set. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 Hope I made sense, Thanks, Chris ___ 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/cnulk%40scu.edu 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] Proposal for a new menu grouping in MM3webUI
Yeah, I took a look at what I wrote and I wasn't as clear as I thought I was. By SCHEDULED digest, I mean a digest sent out on a set time period or frequency (like Years, Months, Weeks, etc.). Those digests would have the volume number incremented and the digest number reset to 1. Any digests sent within (or BETWEEN) the scheduled digests time period / freq. for whatever reason - size, number of msgs - would increment the digest number only. If there are no digests/msgs to send, then the volume number does not increment. Thanks Mark, Chris On 5/24/2011 3:50 PM, Mark Sapiro wrote: C Nulk wrote: Thank you for the work also. I did view your latest diagram and the volume/digest issue seems to be correct. But just to make sure, the volume number is increased for every SCHEDULED digest sent out (with the digest number reset to 1). Next, any addition digests sent out BETWEEN scheduled digests (whether due to size of digest or number of messages in the digest) increase the digest number but not the volume number. If that is true, then I am in agreement with you :) because it mimics the magazine style of volume/issue. This is not the way it works in MM 2.1. In MM 2.1, the volume increments and the issue resets to one for the first digest produced in a new period, where period is Year, Quarter, Month, Week or Day as set in Digest options - digest_volume_frequency. The issue increments for each digest produced in that period whether the digest is produced 'periodically' or by size. If there are no posts/digests produced during a period, the volume doesn't increment for that period. -- 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] Proposal for a new menu grouping in MM3 webUI
On 5/24/2011 5:23 AM, Barry Warsaw wrote: On May 24, 2011, at 01:39 PM, Benedict Stein wrote: 5. showing stats within the archives view instead of the config Yep. We need to do a much better job of collecting and exposing stats. I don't know if this is the place to mention it but along with increased accessibility to statistics and archives, the ability to look at or review the logging information is also very important. Anywhere in the code that output's to a log file should provide enough information to follow a message coming into Mailman, through the various Mailman processes, and out of Mailman. I went through Mailman v2.1.9 to add additional logging information so I can track a message. My users call on a regular basis to check if their message went out to a list they can post to but not read (it gets complicated). Once I had the logging information (message-id, listname, sender, etc.), I wrote a web app that parses the vette, smtp, and post logs and combines the information so I can see what happened to the message either by list or by sender. It works well for me but additional logging information for tracking messages and problems is also need. I know I drifted a bit but additional logging is needed and an administrative interface to view the information is also needed. Thanks for you help improving this work. Thank *you*! -Barry Thank you for the work also. I did view your latest diagram and the volume/digest issue seems to be correct. But just to make sure, the volume number is increased for every SCHEDULED digest sent out (with the digest number reset to 1). Next, any addition digests sent out BETWEEN scheduled digests (whether due to size of digest or number of messages in the digest) increase the digest number but not the volume number. If that is true, then I am in agreement with you :) because it mimics the magazine style of volume/issue. Thanks for yours and Barry's hard work, Chris ___ 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
[Mailman-Developers] Adding a message id to the vette log
Hello all,
I am using Mailman v2.1.9 with some minor local mods on CentOS 5.5. In
looking through the vette log, I noticed some of the log entries for
refused postings and discarded postings do not indicate what message
(via the message id) was acted upon. I would like to the message id to
those entries. I found where the entries are written to in
ListAdmin.py. I made a few changes to the file. Since I am barely
literate with python, I thought I would post my changes to the list and
ask you fine people if I did will work, or am I doomed. There changes
are (in diff -u format):
--- /usr/lib/mailman/Mailman/ListAdmin.py2008-05-24
13:44:12.0 -0700
+++ ListAdmin.py.SCU2011-01-28 13:26:12.0 -0800
@@ -340,13 +340,21 @@
fmsg.send(self)
# Log the rejection
if rejection:
+try:
+msg = readMessage(path)
+except IOError, e:
+if e.errno errno.ENOENT: raise
+return LOST
+msg = readMessage(path)
note = '''%(listname)s: %(rejection)s posting:
\tFrom: %(sender)s
-\tSubject: %(subject)s''' % {
+\tSubject: %(subject)s
+\tMessage-id: %(messageid)''' % {
'listname' : self.internal_name(),
'rejection': rejection,
'sender' : str(sender).replace('%', '%%'),
'subject' : str(subject).replace('%', '%%'),
+'messageid': msg.get('message-id', 'n/a').replace('%',
'%%'),
}
if comment:
note += '\n\tReason: ' + comment.replace('%', '%%')
Also, are there any other files I may need to change?
Thanks,
Chris
___
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] password handling in MM3
Ian Eiloart wrote: --On 9 July 2010 12:11:50 +0200 Anna Granudd anna.gran...@gmail.com wrote: Hi, when subscribing a user or creating a list in Mailman 3.0 we need to implement the use of a password for security reasons. Later the same password will be used for logging in to the settings pages. At the moment passwords are not handled at all which is why I filed bug #600780 (see [1]). However, we're not sure how to handle the passwords at the moment and would like your help with ideas and possible ways to implement this, which is why I want to start a discussion about the password handling/ login function. What do we need to think of and how should this best be dealt with? Most importantly, passwords must be securely hashed, so that they can't be read by the site or list admins, or by third parties. That means that password resets must be offered to users, instead of password reminders. Also, for sites like mine, it would be nice to have more than one password store. For example, I'd like to have users with addresses in the sussex.ac.uk domain authenticated against my current LDAP db, but non-local users authenticate against some other db (perhaps a different branch of the LDAP tree, but perhaps something local). Agreed, passwords must be securely hashed. No one should be able to reverse the hash to derive a password. I toss would also like to have multiple authentication stores whether via LDAP or intrinsic to default Mailman. Likewise, I would also like to have multiple membership stores, obviously the default intrinsic Mailman member store, but also LDAP, database, etc. Optimally, if both multiple password/member stores are combined, when a member authenticates, the member is looked up in the appropriate password/member store for validity whether it be LDAP, a database, or Mailman intrinsic. Likewise, a posting to a list should send a message to members listed in all password/member stores associated with the list. Thanks, Chris Thanks, Anna [1] https://bugs.launchpad.net/mailman/+bug/600780 ___ 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/iane%40sussex.a c.uk Security Policy: http://wiki.list.org/x/QIA9 -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ 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/cnulk%40scu.edu 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] Problem with Moderate.py
Hello Mark,
I am posting the matches_p function below. I believe the problem is an
off-shoot of the lce/cpe problem with the LDAPMembership adapter you
helped me with earlier. I did get it to work by changing the condition
in matches_p from
if mother.members.has_key(sender):
to
if mother.isMember(sender):
It works for both statically created lists and the ldap dynamically
created lists.
Here is the complete matches_p function (from Mailman v2.1.9 with the
@list patch applied and my changes):
def matches_p(sender, nonmembers):
# First strip out all the regular expressions
plainaddrs = [addr for addr in nonmembers if not addr.startswith('^')]
addrdict = Utils.List2Dict(plainaddrs, foldcase=1)
if addrdict.has_key(sender):
return 1
# Now do the regular expression matches
for are in nonmembers:
if are.startswith('^'):
try:
cre = re.compile(are, re.IGNORECASE)
except re.error:
continue
if cre.search(sender):
return 1
elif are.startswith('@'):
try:
mother = MailList(are[1:], lock=0)
# Changed the condition to use the list's isMember method
--CN 28-Sep-2009
# if mother.members.has_key(sender.lower()):
if mother.isMember(sender):
return 1
except Errors.MMUnknownListError:
syslog('error', 'filter references non-existent list %s',
are[1:])
return 0
Is the change I made the correct way of fixing the problem? If so,
should other places where 'mlist.members.has_key(variable)' also be changed?
I have also added the 'accept_special_posters' attribute I mentioned on
the Mailman-users list. Can you take at least a quick look at the
changes to make sure I didn't mess things up to bad? I have the diffs
for MailList.py, versions.py, Version.py, Gui/Privacy.py and
Handler/Moderate.py.
Thanks for your help, Mark.
Chris
Mark Sapiro wrote:
Chris Nulk wrote:
I believe I have narrowed down the problem to the 'matches_p' function in
Moderate.py.
Can you post your matches_p definitiopn?
___
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] Proposed: remove address-obfuscation code from Mailman 3
I am pretty sure allowing the raw email addresses to be available is going to go over like a lead balloon here. Anything (however minor) to help protect the users/clients email addresses is helpful despite what others think. It is fine if someone considers the obfuscation that Mailman uses is trivial, however, anything I can do to make it harder or more computationally time-invested to get the email address is better than giving it away. Sure bots are out there but if what I do helps slow down someones system to make them look at it (and hopefully get rid of the bot), then great. But at least give me the choice to be able to do it. I happened to like Barry's (?) earlier comment about the send me this message link. Or maybe send my message to the original poster link where you can click on the link, compose your message, and send it through Mailman all without the original sender's address. Mailman or whatever process can figure out the original sender and pass on the your message. Yes, I know it is more work that is why we have computers :) As for using robots.txt, hmm, it is not the legitimate search engines I care about, it is the search engines/crawlers that do not respect my robots.txt file that I care about. If I had an effective way to consistently identify those non-legitimate crawlers, I would add what I needed to drop them into my firewall as I recognized them. Chris Julian Mehnle wrote: Bob Puff wrote: That's the logical progression of that argument, and is the good reason why obfuscation or even removal of parts is not only a good idea, its a necessity. Exposing raw email addresses in their normal form is real low-hanging fruit. Regardless of what I think, my clients will cry bloody murder if emails leak out. I had one person recently google their email address, and found a link to an archive file that should have been private. I had removed all links to the archives, but somehow Google found it, indexed it, and the guy threatened me with bloody murder if I didn't take it down. Sheesh. There's robots.txt, you know? If this is just about user outcry, then robots.txt will fix it (since all legitimate search engines honor it). -Julian ___ 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/cnulk%40scu.edu 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] Proposed: remove address-obfuscation code from Mailman 3
Barry Warsaw wrote: On Aug 31, 2009, at 1:15 PM, C Nulk wrote: I am pretty sure allowing the raw email addresses to be available is going to go over like a lead balloon here. Anything (however minor) to help protect the users/clients email addresses is helpful despite what others think. It is fine if someone considers the obfuscation that Mailman uses is trivial, however, anything I can do to make it harder or more computationally time-invested to get the email address is better than giving it away. Sure bots are out there but if what I do helps slow down someones system to make them look at it (and hopefully get rid of the bot), then great. But at least give me the choice to be able to do it. Agreed. I happened to like Barry's (?) earlier comment about the send me this message link. Or maybe send my message to the original poster link where you can click on the link, compose your message, and send it through Mailman all without the original sender's address. Mailman or whatever process can figure out the original sender and pass on the your message. Yes, I know it is more work that is why we have computers :) The difficult part about the latter is that I hate web interfaces for reading/composing email (Gmail included). I want to use my mail reader for that! Actually, I had more of a mailto style link in mind that sends the message to the list (run by Mailman naturally) and as part of the body/subject include an encrypted form of the message id (providing it is unique). You would use your mail client to read/compose. Maybe something similar to a list's listname-bounces address but with the message id could be done. Don't know. Mailman would receive your message, decrypt the message id, look up the message, then forward your message to the original sender. I am not particularly fond of web interfaces for reading/composing email. Well, maybe when I travel overseas without a laptop, then it is minimally okay. As for using robots.txt, hmm, it is not the legitimate search engines I care about, it is the search engines/crawlers that do not respect my robots.txt file that I care about. If I had an effective way to consistently identify those non-legitimate crawlers, I would add what I needed to drop them into my firewall as I recognized them. Agreed. -Barry Now, totally off-topic, anyone have a recommendation for a book on learning Python so I am no longer truly dangerous, just slightly. Thanks, Chris ___ 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] Proposed: remove address-obfuscation codefrom Mailman 3
Mark Sapiro wrote: Barry Warsaw wrote: On Aug 31, 2009, at 1:15 PM, C Nulk wrote: As for using robots.txt, hmm, it is not the legitimate search engines I care about, it is the search engines/crawlers that do not respect my robots.txt file that I care about. If I had an effective way to consistently identify those non-legitimate crawlers, I would add what I needed to drop them into my firewall as I recognized them. Agreed. The point in the original post about robots.txt was that if you think obfuscation is undesirable and don't do it, but you get complaints from people who find their unobfuscated addresses on your pages via legitimate search engines, you can use robots.txt to keep the search engines out. I understood the original post and I agree. However, robots.txt is not completely effective in this. You can use it to prevent Google from crawling your site or portions thereof, but it won't prevent Google from indexing your pages that it finds via external links. To prevent this, you need a meta name=robots content=noindex tag on the pages themselves. I agree with you here. The robots.txt and the meta html header work great for search engines that respect those conventions. My point is that neither of them are effective for crawlers that do not respect the conventions. By putting raw email address in the archives without a means to obfuscate them simple hands over the addresses to those disreputable crawlers. And, if I was writing a web crawler to harvest email addresses, I am pretty sure I would ignore convention which stops me from getting what I want. BTW, I DON'T WRITE WEB CRAWLERS so no yelling at me. :) It is those disreputable crawlers I was addressing in my comment - robots.txt and the meta header are insufficient in that particular case. Chris ___ 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] Mailman and Extend.py
Barry Warsaw wrote: I also looked to see if there was an URL type interface for LDAP. There is however it would be primary be an anonymous bind to a LDAP service. Most if not all places will not allow anonymous binds which can update/change their LDAP information. I just don't know enough about Storm to say whether or not the DN bind can be worked in. The current LDAPMembership.py get the LDAP data. It might be possible to use the ideas there to implement LDAP in Storm. I don't think LDAP is a good fit for Storm, which really wants to be talking to a relational database via SQL. The bad news is that using Storm is the easy way to hook MM3 up to a different backend. The good news is that (hopefully) that's not necessary to use LDAP for your user data. I think you would need to re-implement things like the UserManager, but this is mostly uncharted waters. As I walked to the train station last night, I came to the same conclusion. Since LDAP is not relational, Storm would need to make exceptions for LDAP. Definitely not a good fit. I'd be happy to help anybody who's interesting in building out an LDAP backend. My poor knowledge of Python most likely leaves me out with respect to developing, however, I would be happy to be involved in contributing ideas towards the development. One idea I did have is about keeping unsubscribe information. Since an LDAP query will always return every entry matching the query, someone that wishes to unsubscribe cannot because their entry is included in the query. If whatever mechanism is used to track a given list member's config settings (mod, ack, nomail, etc) also includes whether the person unsubscribed or not, then whenever the getMembers()/isMember() or equivalent functions are called, the query results minus the unsubscribed is checked/validated/etc. depending on the function. Sorry if the above sounds like gibberish. Could really figure out how to say it better. I think I see what you're saying. You really want to split user data across LDAP and say a relational database. While I think it could be done (and probably /should/ be doable), it will take some clever model-layer programming to make it work. I don't have a clear picture in my mind about how to do that right now, but it's worth an interested developer to take a look at it. -Barry Well, not really splitting up the data between LDAP and a relational DB because you will end up with sync problems at some point in time. It was more of adding/modifing text attribute values in LDAP. I will explain it more fully next week when I start a new thread (I just saw your responses and I need to close up and head for the train). Chris ___ 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] Mailman and Extend.py
Mark Sapiro wrote:
C Nulk wrote:
While I waited, I did do some reading/researching on __init__ which lead
me to reading about __getattr__ and getattr. If I understand correctly,
the LDAPMemberships uses them to get the isMember() and getMembers()
methods among others.
Not exactly. Since the MemberAdaptor is replaceable, it can't simply be
a super class of the MailList class. Thus, it's methods are not in the
name space of the MailList object so we need an __getattr__ method to
access them from whatever class is assigned as the list's
_memberadaptor. So when you reference a method such as
mlist.isMember() that is not directly in the name space of the mlist
instance so mlist.__getattr__('isMember') is called (behind the
scenes) and it finds mlist._memberadaptor.isMember() and returns that.
Sorry about that. Your explanation is what I understood was the correct
action(s) for the interaction between MailList and the MemberAdaptor. I
just way to short in my explanation.
This is true whether _memberadaptor is the default OldStyleMemberships
class or the LDAPMemberships class or something else. The only thing
that is specific to LDAPMemberships is the fact that the list's
extend.py module assigned LDAPMemberships to _memberadaptor.
From then on, whenever a member adaptor method is called for that list,
the method that is called is the one defined in LDAPMemberships.py.
So, for example, if your Mailman version is 2.1.10 or later so that it
supports the @LISTNAME entry in *_these_nonmembers, and you put say
@list2 in accept_these_nonmembers of list1, list1's processing of a
non-member post will call list2's isMember() method to see if the
poster is a member of list2, and if list2 already uses
LDAPMemberships, that's it - it's isMember() method will use its LDAP
database.
Unfortunately, I am stuck at v2.1.9 for now.
See the matches_p function in Mailman/Handlers/Moderate.py for more
detail.
I did look at Mailman/Handlers/Moderate.py, specifically the matches_p
function. What I envisioned doing was to modify the matches_p function
to single out ldap entries similar to the regex entries. Then for
each ldap entry, call an LDAP2Dict function (to be written) which
returns a dictionary of email addresses, then check if the sender was in
the returned dictionary.
That would work, but if this dictionary could be equated to the
membership of some list, it seems to me that it would be easier to
just backport the @listname feature to 2.1.9. You can find the
original patch at
http://sourceforge.net/tracker/?func=detailaid=1220144group_id=103atid=300103.
The 2.1.10 implementation is a bit more elaborate, but the SourceForge
patch should be sufficient for your purpose.
Note that there is nothing magic about the dictionary in
plainaddrs = [addr for addr in nonmembers if not
addr.startswith('^')]
addrdict = Utils.List2Dict(plainaddrs, foldcase=1)
if addrdict.has_key(sender):
return 1
This could just as easily have been spelled
plainaddrs = [addr.lower() for addr in nonmembers if not
addr.startswith('^')]
if sender in plainaddrs:
return 1
I will have to take a closer look at the patch. And, I probably will
apply it. From the quick glance on sourceforge, it looks like it should
work for v2.1.9. All I should have to do is adjust the diff lines to
point to the actual locations.
Being able to use another list as a source is great. I would still like
to try to have everything defined/set within the list itself without
cross-referencing other management lists. For us, it would be easier
to manage.
The changes made to LDAPMemberships.py would help since you explained to
me that one of your changes was to make members a dictionary. The
getMembers() method would essentially return that dictionary.
No. getMembers() MUST return a list or everything breaks.
Okay. My mistake. Still trying to figure out Python and how things
work. Since getMembers() returns a list, I suppose I could use the
List2Dict() function to convert the list to a dictionary to be returned
by my LDAP2Dict() function.
The key would be the changes to extend.py so everything works.
If you are accessing some LDAP directly (not via the @list construct)
in the matches_p function, extend.py has nothing to do with it.
You will have to correct me if I am really off-base here on my
understanding.
The extend.py module defines the extend() function which appears to set
ldap (as an object of the LDAPMemberships class)
ldap = LDAPMemberships(list)
along with additional definitions, like
ldap.ldapsearch = (uid=somebody)
ldap.ldapserver = ldap.example.net
and to tie it to the list, set the _memberadaptor to the object by
list._memberadaptor = ldap
So when the list membership or some other method is accessed and not in
the list namespace, your
Re: [Mailman-Developers] Mailman and Extend.py
Mark Sapiro wrote: Consider the following instead. Create a list named say posters with it's own extend.py with settings like ldap = LDAPMemberships(list) ldap.ldapsearch = (role=list-poster) # as an example ldap.ldapserver = ldap3.example.net list._memberadaptor = ldap etc. Then all you need do is install the patch and put @posters in the original list's accept_these_nonmembers. You would also want to set the 'posters' list with attributes like archive = No advertised = No default_member_moderation = Yes member_moderation_action = Discard generic_nonmember_action = Discard so people wouldn't be aware of it and posts would not be accepted. That way, the different LDAP functions would be defined for different pseudo lists and you wouldn't need any Mailman modifications other than installing a feature that's already implemented in current versions. Okay, okay, you've beaten me down. :):):) I do see your point. It is an additional management issue I wanted to avoid with the unadvertised lists. Will this @list method also work for the other parameters/options that have a list of email addresses (like owner, moderator, ban_list, ...) or just the *_these_nonmembers options? It probably sounds silly to do but if those options also take the @list method, I can set up several of my lists so all the options (with email address lists) are based out of ldap and have our system for creating accounts out of our HR system build the ldap entries, resulting minimal list management (for me at least :):)) The ban_list would not be an ldap list but in theory it could. If not, I guess I will have to live with it. :) Thanks, Chris ___ 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] Mailman and Extend.py
Mark Sapiro wrote: C Nulk wrote: Will this @list method also work for the other parameters/options that have a list of email addresses (like owner, moderator, ban_list, ...) or just the *_these_nonmembers options? It only works for *_these_nonmembers. It could be implemented for owner/moderator/etc, but these are more difficult as owner and moderator are referred to in more than one place. Note that Mailman 3 will support a true back-end database for list membership and other roles. At that time, this will all become much easier. I figured as much. And thank you for answering my next question about Mailman 3. Is there documentation somewhere I can read how to configure MM3 for using LDAP or any other back-end database? Now back to the patch. Thanks again, Chris ___ 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] Mailman and Extend.py
Thank you for replying Mark. Mark Sapiro wrote: C Nulk wrote: I have recently implemented the LDAPMembership adapter. It provides some good functionality in creating the list membership. However, the concept is there to provide access to one or more lists of email addresses (list membership is essentially a list of email addresses). I would like to use the LDAP functionality in other areas which require or use a list of email addresses (e.g. accept_these_nonmembers, hold_these_nonmembers, etc). I have looked at the F.A.Q. on custom handlers and read the MailList.py file (under __init__) to see the 'extend.py' file being loaded. Can someone better explain how loading the 'extend.py' file incorporates the files code and how the 'def extend' function is called? If I can understand how it works, perhaps, a solution to adding multiple LDAP search queries can be added to the extend.py file and used in other places in Mailman. Chris, The extend.py mechanism as you use it basically just replaces the default mamber adaptor OLDStyleMembertships.py with LDAPMemberships.py for any list that has the extend.py file in it's lists/LISTNAME/ directory. In addition, it defines a few attributes which may or may not be list-specific which allow LDAPMemberships.py to get to the appropriate LDAP database. If you've read the __init__ method in MailList.py, you've seen everything there is to see about extend.py. It gets called there and there only when the list is instantiated and sets the lists ._memberadaptor attribute to LDAPMemberships. While I waited, I did do some reading/researching on __init__ which lead me to reading about __getattr__ and getattr. If I understand correctly, the LDAPMemberships uses them to get the isMember() and getMembers() methods among others. From then on, whenever a member adaptor method is called for that list, the method that is called is the one defined in LDAPMemberships.py. So, for example, if your Mailman version is 2.1.10 or later so that it supports the @LISTNAME entry in *_these_nonmembers, and you put say @list2 in accept_these_nonmembers of list1, list1's processing of a non-member post will call list2's isMember() method to see if the poster is a member of list2, and if list2 already uses LDAPMemberships, that's it - it's isMember() method will use its LDAP database. Unfortunately, I am stuck at v2.1.9 for now. See the matches_p function in Mailman/Handlers/Moderate.py for more detail. I did look at Mailman/Handlers/Moderate.py, specifically the matches_p function. What I envisioned doing was to modify the matches_p function to single out ldap entries similar to the regex entries. Then for each ldap entry, call an LDAP2Dict function (to be written) which returns a dictionary of email addresses, then check if the sender was in the returned dictionary. The changes made to LDAPMemberships.py would help since you explained to me that one of your changes was to make members a dictionary. The getMembers() method would essentially return that dictionary. The key would be the changes to extend.py so everything works. I hope this helps. If you still have questions, keep asking. It has helped. I have made some changes to Mailman/Handlers/Moderate.py and Utils.py (to add the LDAP2Dict function). Let me know if you would like to see what I came up with and I can send the diffs and explaination to you off-list. You may have a better way to implement what I am doing. Well, actually, you probably do have a better way. :) Thanks, Chris ___ 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
[Mailman-Developers] Mailman and Extend.py
Hello, I have recently implemented the LDAPMembership adapter. It provides some good functionality in creating the list membership. However, the concept is there to provide access to one or more lists of email addresses (list membership is essentially a list of email addresses). I would like to use the LDAP functionality in other areas which require or use a list of email addresses (e.g. accept_these_nonmembers, hold_these_nonmembers, etc). I have looked at the F.A.Q. on custom handlers and read the MailList.py file (under __init__) to see the 'extend.py' file being loaded. Can someone better explain how loading the 'extend.py' file incorporates the files code and how the 'def extend' function is called? If I can understand how it works, perhaps, a solution to adding multiple LDAP search queries can be added to the extend.py file and used in other places in Mailman. Thanks, Chris P.S. When explaining, please realize I am moving from knowing absolutely nothing about Python to knowing next to nothing. :):) ___ 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
