[Mailman-Developers] (2.0.6) pipermail takes 1 minute to rebuild indexes on large lists

2001-09-13 Thread Stephen J. Turnbull
Sorry about the busted references, I'm on the digest. ben == Ben Gertzfield [EMAIL PROTECTED] writes ben On a massive list (Mailman 2.0.6) I run that regularly gets a ben few hundred or more emails every day, things begin to slow ben down to molasses after a week or two each month,

Re: [Mailman-Developers] USE_ENVELOPE_SENDER is not flexible enough

2002-01-30 Thread Stephen J. Turnbull
BAW == Barry A Warsaw [EMAIL PROTECTED] writes: BAW evil laugh=manical BAW Mailman shall rule THE WORLD! BAW /evil Take a number, man. (See .sig.) -- University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences

Re: [Mailman-Developers] Interesting study -- spam onpostedaddresses...

2002-02-18 Thread Stephen J. Turnbull
Chuq == Chuq Von Rospach [EMAIL PROTECTED] writes: Chuq Are there any other benefits to being googled than being a Chuq walking billboard to the list? Yes. I do see a fair number of non-subscriber posts that go we need to do job X, and according to a post I dug up googling for `job X'

Re: [Mailman-Developers] Interesting study -- spam onpostedaddresses...

2002-02-20 Thread Stephen J. Turnbull
Chuq == Chuq Von Rospach [EMAIL PROTECTED] writes: Chuq On 2/20/02 1:37 PM, Damien Morton Chuq [EMAIL PROTECTED] wrote: As far as I can see thay are using url/cgi encoding in the email address. This is trivial to circumvent, as is using html entities, or any other

Re: [Mailman-Developers] Save the world from spam

2002-02-22 Thread Stephen J. Turnbull
Chuq == Chuq Von Rospach [EMAIL PROTECTED] writes: Chuq You know, now that I think of it, there's another approach: Chuq you don't get the admin's email address until you Chuq authenticate. Then you get it. [...] Chuq Thoughts? You've just reinvented TMDA, basically, except

Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...

2002-02-22 Thread Stephen J. Turnbull
I repeat myself, but only Chuq seems to have noticed the other post. John == John Morton [EMAIL PROTECTED] writes: John This depends on just how temporary your 'solution' turns out John to be, and it's level of complexity and usability. I don't John think anyone has really advocate

Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...

2002-02-22 Thread Stephen J. Turnbull
Damien == Damien Morton [EMAIL PROTECTED] writes: Damien So obfuscation is imperfect, and the more effective it is, Damien the more value there is in cracking it. That's true, but that's not what I said. What I said is it is weak enough that a small amount of effort brings some payoff

Re: [Mailman-Developers] Protecting email addresses from spam harvesters

2002-02-25 Thread Stephen J. Turnbull
BAW == Barry A Warsaw [EMAIL PROTECTED] writes: BAW I /think/ I've caught up on this thread, Like JRA I think your synopsis is accurate, with respect to the issues that can be addressed by code. BAW I claim that the guessability [of list-related addresses] is BAW a feature, btw.

Re: [Mailman-Developers] Protecting email addresses from spam harvesters

2002-02-25 Thread Stephen J. Turnbull
John == John Morton [EMAIL PROTECTED] writes: John I find this feature is handy for small, private lists. Sure. I have a couple that could be handled that way, but we just defaulted them all off. We post the names and addresses (they're basically lists of project staff) on the home page,

Re: [Mailman-Developers] Protecting email addresses from spam harvesters

2002-02-25 Thread Stephen J. Turnbull
BAW == Barry A Warsaw [EMAIL PROTECTED] writes: BAW Yeah, it's just that I generally hate cookies too. So call them [Kerberos] tickets. (Me like cookies, one, two, I put them away now. Tickets have no flavor and are hard to chew.) You aren't going to make cookies go away, because they

Re: [Mailman-Developers] Re: [Zest-devel] Re: Pipermail replacement? Zest!

2002-02-26 Thread Stephen J. Turnbull
David == David Champion [EMAIL PROTECTED] writes: David On 2002.02.26, in David [EMAIL PROTECTED], David Jay R. Ashworth [EMAIL PROTECTED] wrote: ... and a generic web search engine, running locally on that machine, with access to the messages, will serve that purpose

Re: [Mailman-Developers] Missing footers with latest CVS

2002-03-04 Thread Stephen J. Turnbull
Ben == Ben Gertzfield [EMAIL PROTECTED] writes: Ben This would violate RFC 1522: That's right. People with broken mailers have broken mailers. Make sure that things are robust for those with decent software, and then do what we can for the former poor souls. Anyway, even my boss---who

Re: [Mailman-Developers] Missing footers with latest CVS

2002-03-07 Thread Stephen J. Turnbull
Ben == Ben Gertzfield [EMAIL PROTECTED] writes: Ben Mein Gott. If people start sending mail in UTF-16.. wow. Outhouse Abcess. wink, wink, nudge, nudge Say no more, eh? And yes, I have gotten such. (A _very_ broken beta of Outhouse for Lose2k beta was responsible: the HTML tags were in

Re: [Mailman-Developers] Please Allow Me To Introduce Myself...

2002-03-08 Thread Stephen J. Turnbull
Jay == Jay R Ashworth [EMAIL PROTECTED] writes re HTML email: Jay which is inherent, I think, in the (lack of) design thereof. What lack of design? It's a near-perfect implementation of form over substance. -- Institute of Policy and Planning Sciences

Re: [Mailman-Developers] two spaces in subject lines

2002-04-12 Thread Stephen J. Turnbull
Ben == Ben Gertzfield [EMAIL PROTECTED] writes: Ben I think the email.Header package I wrote is doing the wrong Ben thing here. Yup. Ben Either we need represent the whole thing as one or more Ben encoded-words, or we need to be super anal about whitespace Ben between

Re: [Mailman-Developers] two spaces in subject lines

2002-04-15 Thread Stephen J. Turnbull
Ben == Ben Gertzfield [EMAIL PROTECTED] writes: Ben On Saturday, April 13, 2002, at 02:59 , Stephen J. Turnbull Ben wrote: Ben Either we need represent the whole thing as one or more Ben encoded-words, or we need to be super anal about whitespace Ben between encoded-words

Re: [Mailman-Developers] Notifications for bug reports and patches

2002-04-28 Thread Stephen J. Turnbull
BAW == Barry A Warsaw [EMAIL PROTECTED] writes: BAW Currently the SourceForge bug and patch trackers for the BAW Mailman project are set to send messages to BAW [EMAIL PROTECTED] BAW I'm wondering if it would be useful to redirect those BAW messages to mailman-developers.

Re: [Mailman-Developers] Splitting long header lines and the bugdemonstration

2002-06-05 Thread Stephen J. Turnbull
BAW == Barry A Warsaw [EMAIL PROTECTED] writes: BAW but instead will get split like X-Foobar-Spoink-Defrobnit: wasnipoop; giraffes=very-long-necked-animals; spo oge=yummy; hippos=gargantuan; marshmallows=gooey If by split you mean RFC 2822 2.2.3 header folding, you can't split spooge

Re: suggestion for Full Customization [Mailman-Developers]

2004-05-11 Thread Stephen J. Turnbull
somuchfun == somuchfun [EMAIL PROTECTED] writes: somuchfun I am literally shocked to see that you think everyone somuchfun who does not agree with you is a Spamer! That's not what he said. He said he can't think of a good reason why a non-spammer would want to do this, while there are

Re: [Mailman-Developers] Maybe you guys can help me

2004-05-07 Thread Stephen J. Turnbull
Chuq == Chuq Von Rospach [EMAIL PROTECTED] writes: Chuq my current thought on that is: Chuq http://www.plaidworks.com/chuqui/blog/001447.html My now-ancient thought on this is http://turnbull.sk.tsukuba.ac.jp/Tools/Attitude/ Warning, it swears like a bounce. Chuq so my

Re: [Mailman-Developers] Python versions

2004-05-22 Thread Stephen J. Turnbull
Daniel == Daniel Buchmann [EMAIL PROTECTED] writes: Daniel Here's a summary of Python versions on other popular Daniel distro's: [Linux reports elided] On Mac OS X 10.3 (aka Panther), we have Apple - 2.3 IIRC Mac OS X 10.2 (aka Jaguar) was Python 2.1. On the third-party

Re: [Mailman-Developers] CTE base64 due to UTF-8?

2004-07-21 Thread Stephen J. Turnbull
Michael == Michael Heydekamp [EMAIL PROTECTED] writes: Michael I'm aware of all of these problems but that still doesn't Michael explain ... Michael a) why Mailman recodes the UTF-8 body to base64 rather Michael than qp (which would be the recommended and much better Michael

Re: [Mailman-Developers] SCRUBBER Question

2004-10-03 Thread Stephen J. Turnbull
Tokio == Tokio Kikuchi [EMAIL PROTECTED] writes: Tokio I think I should commit one of my unpublishd patch on Tokio SourceForge CVS. [...] Tokio With this patch, site manager can set Tokio SCRUBBER_USE_ATTACHMENT_FILENAME_EXTENSION = True in Tokio mm_cfg.py to use attachment

Re: [Mailman-Developers] in-reply-to problem

2004-10-04 Thread Stephen J. Turnbull
Brad == Brad Knowles [EMAIL PROTECTED] writes: Brad You could spend a trillion dollars on this problem and Brad not find a solution. The entire computer industry has been Brad working on AI since the early 1960s, and they haven't solve Brad it yet, and don't appear to be

Re: [Mailman-Developers] in-reply-to problem

2004-10-05 Thread Stephen J. Turnbull
Brad == Brad Knowles [EMAIL PROTECTED] writes: I don't think I'm being pessimistic here. I think I'm being realistic. There are no deterministic ways to figure out precisely which message is being replied to and which other messages are being referenced, unless

Re: [Mailman-Developers] Dates again

2004-11-22 Thread Stephen J. Turnbull
Steven == Steven Kuck [EMAIL PROTECTED] writes: At 3:31 AM -0500 2004-11-20, Steven Kuck wrote: Since all of these messages are, in fact, being sent by my server I think it quite reasonable to change the Date to reflect the time that it was processed and changed by the

[Mailman-Developers] Require 2.4? No thanks [was: Maybe it's time to release 2.1.6]

2004-12-02 Thread Stephen J. Turnbull
BAW == Barry Warsaw [EMAIL PROTECTED] writes: BAW On Tue, 2004-11-30 at 20:07, Tokio Kikuchi wrote: May be we can go forward to requirement of Python 2.4 because CJK codecs are integreted there. BAW I have no problems requiring Python 2.4 for Mailman 2.2, BAW although I

Re: [Mailman-Developers] Mailman 2.1.6 beta 2 released

2005-01-26 Thread Stephen J. Turnbull
Alan == Alan Batie [EMAIL PROTECTED] writes: Alan Tokio Kikuchi wrote: - Most of the installation instructions have been moved to a latex document. See admin/www/mailman-install/index.html for details. Alan This is *not* a positive move. Installation instructions

Re: [Mailman-Developers] Patch for Mail Archive mirroring

2005-04-30 Thread Stephen J. Turnbull
Brad == Brad Knowles [EMAIL PROTECTED] writes: Brad Lars was nice enough to comply with our request to Brad remove our lists from gmane, but these kinds of operations Brad should not be done without a positive and explicit approval Brad from the listmaster. Any subscriber

Re: [Mailman-Developers] Patch for Mail Archive mirroring

2005-04-30 Thread Stephen J. Turnbull
JC == JC Dill [EMAIL PROTECTED] writes: JC I personally don't see it as being a significant endorsement. JC AIUI, it's a patch that allows 2 software programs to work JC well together. My understanding is that the programs already work well together; you just type [EMAIL PROTECTED]

Re: [Mailman-Developers] Patch for Mail Archive mirroring

2005-05-06 Thread Stephen J. Turnbull
Bob == Bob Puff [EMAIL PROTECTED] writes: Bob Personally, I'd much rather see the HT/Dig patch implemented Bob before this one. That is IMHO more useful to the average Bob mailman admin than this. Jeff's patch is so simple you could prove its correctness mathematically. The

Re: [Mailman-Developers] Patch for Mail Archive mirroring

2005-05-06 Thread Stephen J. Turnbull
Brad == Brad Knowles [EMAIL PROTECTED] writes: Brad At 5:37 PM +0900 2005-05-03, Stephen J. Turnbull wrote: It's not a good idea to put the burden of proof on them, when either the list-owner can be more selective about membership, or they can use X-No-Archive. Brad

Re: [Mailman-Developers] Patch for Mail Archive mirroring

2005-05-13 Thread Stephen J. Turnbull
BAW == Barry Warsaw [EMAIL PROTECTED] writes: BAW On Thu, 2005-05-12 at 19:48, Chuq Von Rospach wrote: Does archiving need to be integrated into mailman in the first place? As opposed to, say, a place to specifiy the URL of the archives for display? BAW The key is that

Re: [Mailman-Developers] XML-RPC interface to mailman

2005-07-22 Thread Stephen J. Turnbull
Joseph == Joseph Tate [EMAIL PROTECTED] writes: Joseph Finally, I'd like some discussion of licensing. I think Joseph that the xmlrpc.py file itself should be LGPL just so that Joseph there is no ambiguity whatsoever about using XML-RPC calls Joseph from a non-GPL application.

Re: [Mailman-Developers] XML-RPC interface to mailman

2005-07-22 Thread Stephen J. Turnbull
BAW == Barry Warsaw [EMAIL PROTECTED] writes: BAW On Fri, 2005-07-22 at 02:08, Stephen J. Turnbull wrote: Unfortunately, linking is not a necessary condition for a program to be a derivative work, merely a sufficient one. I would suspect that Richard Stallman and Eben Moglen

Re: [Mailman-Developers] DomainKeys support

2005-08-04 Thread Stephen J. Turnbull
Nadim == Nadim Shaikli [EMAIL PROTECTED] writes: Nadim I've noticed of late that emails sent by yahoo users that Nadim get relayed by mailman end-up without the domainkey header Nadim entry and thus in various yahoo users' bulk (ie. spam) Nadim folder. Is there anything that can

Re: [Mailman-Developers] Mailman 2.X CVS MAIN is back

2005-09-01 Thread Stephen J. Turnbull
Brad == Brad Knowles [EMAIL PROTECTED] writes: Brad The problem is that a majority of the people who run Brad python.org are also heavily involved in Debian, so we're Brad pretty much guaranteed to be shackled by whatever the Debian Brad people want to do. Maybe so, but I

Re: [Mailman-Developers] Sibling list

2005-11-04 Thread Stephen J. Turnbull
Tokio == Tokio Kikuchi [EMAIL PROTECTED] writes: Tokio - Is the terminology 'sibling' appropriate? I hesistate to give it a +1 because I know I think differently from most people, but FWIW I *did* guess what it does from that name. -- School of Systems and Information Engineering

[Mailman-Developers] Informal MEP process, anyone? [was: PHP Wrappers?]

2005-11-16 Thread Stephen J. Turnbull
Kevin == Kevin McCann [EMAIL PROTECTED] writes: [about project management] Kevin - The Mailman project is not as open as it could be. There Kevin is too much control over who can contribute code, how they Kevin can do it, when they can do it. I understand wanting to Kevin

Re: [Mailman-Developers] Informal MEP process, anyone?

2005-11-17 Thread Stephen J. Turnbull
Kevin == Kevin McCann [EMAIL PROTECTED] writes: Kevin I guess I have to watch the words I choose. Erase the word Kevin beg, No. It's the right word for the behavior I've observed so far on the MM lists. (I'm excluding your most recent reply to Brad, which demonstrates (to me, anyway)

Re: [Mailman-Developers] Informal MEP process, anyone?

2005-11-17 Thread Stephen J. Turnbull
Kevin == Kevin McCann [EMAIL PROTECTED] writes: Kevin Is this fair, Stephen? The word I was used to indicate Kevin who had worked on the specs, not who would be involved in Kevin implementing them. Why insinuate a personality trait here? My point is that I know of two people who

Re: [Mailman-Developers] PHP Wrappers?

2005-11-21 Thread Stephen J. Turnbull
Brad == Brad Knowles [EMAIL PROTECTED] writes: Brad Show me a single open data format that all MTAs Brad understand. Hell, there aren't many file formats that they Brad all understand. C'mon, Brad, don't let the perfect be the enemy of all improvement. For access to the ACL

Re: [Mailman-Developers] PHP Wrappers?

2005-11-22 Thread Stephen J. Turnbull
Brad == Brad Knowles [EMAIL PROTECTED] writes: For access to the ACL database, we really need only to consider two MTAs (at most): Exim and Postfix. Brad You have to give the MTA direct access to the internal Brad filters of Mailman in some sense. To get all the way to

Re: [Mailman-Developers] PHP Wrappers?

2005-11-22 Thread Stephen J. Turnbull
Ian == Ian Eiloart [EMAIL PROTECTED] writes: Ian No, you've evidently completely misunderstood me. All I do Ian want is for Mailman to use *exactly* the same mechanisms for Ian sender ACLs that it does for rosters. If that's LDAP, that's Ian fine. If it's SQL, that's fine. If

Re: [Mailman-Developers] PHP Wrappers?

2005-11-23 Thread Stephen J. Turnbull
Ian == Ian Eiloart [EMAIL PROTECTED] writes: Ian I think Python regular expressions have enough in common with Ian the PCRE (perl compatible regular expressions) library to be Ian useful. For example, I think [EMAIL PROTECTED]@(.*\.)?sus(se)?\.ac\.uk$ Ian has the same meaning in

Re: [Mailman-Developers] Make web_page_url visible in the admin GUI?

2005-11-26 Thread Stephen J. Turnbull
Max == Max Bowsher [EMAIL PROTECTED] writes: Max Is there any reason not to add web_page_url to the Max configurable options in the admin GUI? Right below host_name Max in the general category would be a good place. Yes, please! -- School of Systems and Information Engineering

Re: [Mailman-Developers] Make web_page_url visible in the admin GUI?

2005-11-26 Thread Stephen J. Turnbull
John == John W Baxter [EMAIL PROTECTED] writes: John Thought experiment: 1. Make a typo which cripples the URL John such that you can't reach the admin web page. I actually don't care what the admin URL(s) are. That's what bookmarks are for, and my list admins can learn to use them,

Re: [Mailman-Developers] Make web_page_url visible in the admin GUI?

2005-11-27 Thread Stephen J. Turnbull
Max == Max Bowsher [EMAIL PROTECTED] writes: Max My point in saying what I did was that 'the URL to the user Max webpage' and 'the URL for the admin webpage' are not Max independently settable entities. They are, in fact, Max identical, just one has things like 'listinfo' or

Re: [Mailman-Developers] On-topic-ness for -users and -dev

2005-12-17 Thread Stephen J. Turnbull
JC == JC Dill [EMAIL PROTECTED] writes: JC The posts we are hoping to keep OFF of -dev and ON -users are JC the posts by users who are having what they believe are JC complicated use problems and they want advanced support [...] JC As long as the topic brought here is about

Re: [Mailman-Developers] [Mailman-Users] filename too long error - stopping list

2005-12-22 Thread Stephen J. Turnbull
Tokio == Tokio Kikuchi [EMAIL PROTECTED] writes: Tokio SCRUBBER_DONT_USE_ATTACHMENT_FILENAME = True Tokio May be we should set this default in Defaults.py.in in the Tokio next release of 2.1.7. Thoughts? I think that's a good idea. Very few users have any idea what the file name

Re: [Mailman-Developers] On allowing any list member to be an email moderator

2006-01-02 Thread Stephen J. Turnbull
R == R Bernstein [EMAIL PROTECTED] writes: R Where I think something inside GNU Mailman could be a little R better than a second list is that the integration could enforce R that the email associated with person logging in to the webpage R or sending moderation by email is also

Re: [Mailman-Developers] On allowing any list member to be an email moderator

2006-01-02 Thread Stephen J. Turnbull
Brad == Brad Knowles [EMAIL PROTECTED] writes: Brad But then we're getting dangerously close to tools like Brad Active Spam Killer or TMDA, Technically, yes. Brad which I am generally violently opposed to. Brad Maybe those kinds of tools are appropriate for mailing

Re: [Mailman-Developers] On allowing any list member to be an email moderator

2006-01-02 Thread Stephen J. Turnbull
BAW == Barry Warsaw [EMAIL PROTECTED] writes: BAW One of the problems that I have with the moderation workflow BAW is that I have to log into every list I'm going to moderate, BAW and then that login authentication is lost when I kill my BAW browser. I simply have a local file

Re: [Mailman-Developers] On allowing any list member to be an email moderator

2006-01-03 Thread Stephen J. Turnbull
Brad == Brad Knowles [EMAIL PROTECTED] writes: Brad I can't speak for Barry or anyone else, but when I use Brad Mailman to handle mailing lists for webmaster, postmaster, Brad etc..., there is a 99% chance that any one particular Brad message is spam, and I have to take a

Re: [Mailman-Developers] On allowing any list member to be an email moderator

2006-01-03 Thread Stephen J. Turnbull
Brad == Brad Knowles [EMAIL PROTECTED] writes: 3. Where possible, the information _and the controls_ for a single entry should be on a single line. I think it's reasonable to assume as a default that the moderator has at least a 1024px width screen Now there, I

Re: [Mailman-Developers] Feature Request: message_id as replaceable token for footers etc.

2006-01-17 Thread Stephen J. Turnbull
J == J C Lawrence J writes: J Long time no talk. Whaddya think of adding message_id as a J replaceable token for footers and the like? This would allow J footers to be constructed which direct URL-reference their own J post in an NNTP archive. Or in a mailing list archive

Re: [Mailman-Developers] [ mailman-Bugs-1416853 ] Jan 14 change toHandlers/SpamDetect.pyisincomplete

2006-01-29 Thread Stephen J. Turnbull
Mark == Mark Sapiro [EMAIL PROTECTED] writes: Mark The problem I see is that while header_filter_rules are in Mark the Spam filters section of the admin interface and enforced Mark by a module named SpamDetect, they can actually be used in Mark other ways to reject messages which

Re: [Mailman-Developers] incorrect generated HTML

2006-03-02 Thread Stephen J. Turnbull
BAW == Barry Warsaw [EMAIL PROTECTED] writes: BAW I really /wanted/ to use TAL but it was way too unwieldy to BAW develop. +1 Unfortunately, TAL doesn't seem to scale _down_ to typical volunteer-staffed open source. -- School of Systems and Information Engineering

Re: [Mailman-Developers] Unified Moderator Interface

2006-04-18 Thread Stephen J. Turnbull
Kevin == Kevin Kubasik [EMAIL PROTECTED] writes: Kevin Or a way for one moderator to view all pending messages by Kevin logging in once. Since it is not uncommon that one spammer Kevin crawls the site and sends the same message to every list, Kevin it can become a routine

Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [7858] trunk/mailman

2006-04-25 Thread Stephen J. Turnbull
BAW == Barry Warsaw [EMAIL PROTECTED] writes: BAW Ideally, we'd get rid of all that for 2.2 and deal only with BAW Unicode internally. The original encoded stuff should be squirreled away somewhere for debugging and maybe spam detection, though. BAW We may have to make

Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [7858] trunk/mailman

2006-04-25 Thread Stephen J. Turnbull
Brad == Brad Knowles [EMAIL PROTECTED] writes: Brad Personally, I think we should default to US-ASCII in Brad the log files, but I can see where some people might want to Brad select a different encoding in mm_cfg.py. I really think the log files should be UTF-8. The point is

Re: [Mailman-Developers] Sender field

2006-04-29 Thread Stephen J. Turnbull
BAW == Barry Warsaw [EMAIL PROTECTED] writes: BAW I agree that this is what we should hope for. Our data BAW supporting the rewriting of Sender is many years out of date, BAW so we need to gather more data. Who's brave enough to try BAW it? :) If this can be done by modifying

Re: [Mailman-Developers] Sender field

2006-04-29 Thread Stephen J. Turnbull
James == James Ralston [EMAIL PROTECTED] writes: James The Sender header should be employed by the orignator of James the message, and only the originator. Mailman is not the James originator of a message sent to a list; OK up to here. James it is merely a relay agent. That

Re: [Mailman-Developers] [Mailman-Users] Sender field

2006-04-29 Thread Stephen J. Turnbull
Brad == Brad Knowles [EMAIL PROTECTED] writes: At 7:50 PM -0400 2006-04-28, Barry Warsaw wrote: Whatever else we decide, I don't agree, or at least, it won't help us. $3.6.6 says that Resent-* headers are to be added by a user. It also says that these are purely informational

Re: [Mailman-Developers] dkim-signature headers

2007-02-02 Thread Stephen J. Turnbull
Michael Thomas writes: What it seems to me is that maybe we should look close at that behavior of when a list ought to take From: responsibility for a message ala digests. When a list completely mangles a message, is it really reasonable for it to keep acting as if it came from the

Re: [Mailman-Developers] dkim-signature headers

2007-02-05 Thread Stephen J. Turnbull
Michael Thomas writes: I'm afraid that intransigence from the mailing list community is likely to really backfire. Mailing list traffic is an extremely small percentage of traffic, and most admins are likely to just ignore the collateral damage if it's too much a nuisance. We know.

Re: [Mailman-Developers] dkim-signature headers

2007-02-06 Thread Stephen J. Turnbull
Michael Thomas writes: Let's be clear that I'm advocating a dialog here, In some sense, there's very little room for dialog, unless it involves substantial amendments to DKIM. This is inherent in the design: the whole message is signed. Preserve it nearly verbatim or break the signature.

Re: [Mailman-Developers] dkim-signature headers

2007-02-06 Thread Stephen J. Turnbull
Joe Peterson writes: With DKIM, according to my understanding, you are supposed to treat a bad sig the same way you'd treat no sig. I don't think the spec says that. It says: A verifier SHOULD NOT treat a message that has one or more bad signatures and no good signatures differently

Re: [Mailman-Developers] dkim-signature headers

2007-02-07 Thread Stephen J. Turnbull
Michael Thomas writes: I'm afraid that there's not much consensus on how to deal with the mailing list issue; the people who say resign are guessing as there is little/no evidence that resigning is actually a viable strategy. From the point of view of the mailing lists, resigning is

Re: [Mailman-Developers] dkim-signature headers

2007-02-07 Thread Stephen J. Turnbull
Barry Warsaw writes: Part of me agrees that this is what you'd like to see, but my gut tells me that this will never work in practice. First, no one but an email geek will even understand the question, let alone know how to answer it, Agreed. It's a stalking horse for the BCP;

Re: [Mailman-Developers] dkim-signature headers

2007-02-07 Thread Stephen J. Turnbull
Barry Warsaw writes: What should MM2.1 do now? Here's a proposal for 2.1.10: Add an mm_cfg.py variable that controls whether DKIM headers are stripped or not. I think Mark suggested that this should be a site-wide variable, and I tend to agree. I've expressed my reservations

Re: [Mailman-Developers] dkim-signature headers

2007-02-07 Thread Stephen J. Turnbull
Barry Warsaw writes: Make sure no spam gets through your double opt-in list, and you're golden, no? Ideally yeah. But python.org does get reported occasionally since while I think we do a pretty good job of blocking most spam, some nasties gated from Usenet still get through.

Re: [Mailman-Developers] dkim-signature headers

2007-02-07 Thread Stephen J. Turnbull
Michael Thomas writes: I'm not saying I think that resigning is a Bad Thing, I'm saying that it's speculative whether it's a Good Thing. You seem to keep ignoring the inherent attack involved with resigning: Have you actually read my posts, or just enough to feel defensive? I have

Re: [Mailman-Developers] dkim-signature headers

2007-02-08 Thread Stephen J. Turnbull
Barry Warsaw writes: Me too. Here's my discussion on the topic, including a concrete proposal for Mailman 2.1.10 and 2.2/3.0. Feel free to comment on the wiki on in this thread. I'll try to post to the wiki later (I'm not a member yet and I'm suffering mail delays---I expect I'll

[Mailman-Developers] Feature request: Reply-To Munging etc.

2007-03-05 Thread Stephen J. Turnbull
Sven Anderson writes: 1) Receiver clean-up (if Reply-To munging is NOT used) So what about an option to clean-up the receivers list in Mailman, that is Mailman removes all To/CC addresses which are members of the list? IIRC, if the user sets their subscription to no-dupes, that user's

Re: [Mailman-Developers] Feature request: Reply-To Munging etc.

2007-03-07 Thread Stephen J. Turnbull
Sven Anderson writes: IIRC, if the user sets their subscription to no-dupes, that user's address will be removed from the addressee list, as well as from the list of addresses that Mailman actually distributes to the post to. I just checked this to be sure, but only the latter is

Re: [Mailman-Developers] Feature request: Reply-To Munging etc.

2007-03-09 Thread Stephen J. Turnbull
Barry Warsaw writes: I think you're both right :). Mailman 2.1 will strip recipients from the CC header if explicitly named recipients are members of the list and have nodup set. But Mailman won't strip To headers, nor juggle CC and To headers after stripping. Ah, right. I

Re: [Mailman-Developers] Feature request: Reply-To Munging etc.

2007-03-09 Thread Stephen J. Turnbull
Dan MacNeil writes: Stephen J. Turnbull quoted out of context: I see your point, but why won't my suggestion of defaulting the per user no-dupes to on do fine from that point of view? For my selfish purposes, no-dupes off is a better default setting. Without a copy of the message

Re: [Mailman-Developers] Feature request: Reply-To Munging etc.

2007-03-09 Thread Stephen J. Turnbull
Mark Sapiro writes: I think Dan must be thinking of not-metoo, but note that even ensuring that not-metoo is off won't do the job for gmail users thanks to gmail's 'feature' of not showing 'duplicate' messages. Yeah, but that's irrelevant to use of no-dupes, because gmail is keying off a

Re: [Mailman-Developers] Advanced Reply-To-Munging

2007-03-15 Thread Stephen J. Turnbull
Sven Anderson writes: Stephen J. Turnbull, 11.03.2007 19:34: Sven Anderson writes: There is no RFC-way to set the default address for replies. Of course there is. For authors, it's Reply-To. For lists, it's List-Post. No, it's not. What I was referring here

Re: [Mailman-Developers] Templating the interface

2007-04-30 Thread Stephen J. Turnbull
Jon Reese writes: My desired hopes would include Mailman 2.1.9 support for Python 2.2.3 without patches or changes to Python coding (for users of RHEL3 and CentOS3); This is a cart-horse inversion IMO. Let's get the template system, with whatever Python and email module Barry feels like

Re: [Mailman-Developers] Should we move to Bazaar?

2007-05-03 Thread Stephen J. Turnbull
Edward Elhauge writes: Would you compare Bazaar to GnuArch (tla): http://www.gnuarch.org/arch/ Is your Bazaar a different branch of Arch? Yes. The bazaar Barry is talking about is commonly called bzr (the name of the command) or bazaar-ng. It's similar in that it is a distributed

[Mailman-Developers] Should we move to Bazaar?

2007-05-03 Thread Stephen J. Turnbull
Barry Warsaw writes: think this is a good time to ask whether we should move from Subversion to Bazaar http://www.bazaar-vcs.org for our source code revision control system. I would rank Bazaar(-ng == bzr) third behind git and Mercurial. I like git because it tastes like Mom's home

Re: [Mailman-Developers] Should we move to Bazaar?

2007-05-03 Thread Stephen J. Turnbull
Barry Warsaw writes: Your point about interoperability is an important one, and definitely a factor in the decision. I think the risk is mitigated by tools like Tailor, Tailor is great, but mitigated is as far as you can go. The basic stuff like branches and committer id is properly

[Mailman-Developers] Styling patch

2007-05-03 Thread Stephen J. Turnbull
A.M. Kuchling writes: [Aside: are there many patches in the tracker that could be useful? Could be useful, definitely. I've used several at one time or another. But typically they're unsatisfactory as-is because they hard-code the intended behavior. OTOH, they are non-trivial to integrate

Re: [Mailman-Developers] Should we move to Bazaar?

2007-05-04 Thread Stephen J. Turnbull
Barry Warsaw writes: So my take away from this is that while a conversion would be / possible/ it's not completely seamless or automatic. If we choose wrong, we'll suffer some pain, but we'll recover. ;) Would you say that's accurate? I could live with that. I really doubt we'd

Re: [Mailman-Developers] Should we move to Bazaar?

2007-05-04 Thread Stephen J. Turnbull
Barry Warsaw writes: Is anybody interested in trying to complete the Mercurial conversion? I can make a bz2-tarball of the svn repository available if you want to give it a shot. It's about 87MB. I'll take svn2hg via Tailor, since that's what I'm using anyway for XEmacs.

Re: [Mailman-Developers] Should we move to Bazaar?

2007-05-04 Thread Stephen J. Turnbull
Barry Warsaw writes: I propose that no matter which way we go (Mercurial, Bazaar or something else), we convert only the trunk. Let's leave the stable 2.1 branch on SF under Subversion, but do all new development in the dvcs. Why not do both? That is, if Tailor does its thing

Re: [Mailman-Developers] Should we move to Bazaar?

2007-05-05 Thread Stephen J. Turnbull
[Mike -- I'll get back to you on this, but wanted make sure I pinged you before I forget ] Barry Warsaw writes: On May 4, 2007, at 2:21 PM, Stephen J. Turnbull wrote: I'll take svn2hg via Tailor, since that's what I'm using anyway for XEmacs. Cool thanks. I'd love to see what

Re: [Mailman-Developers] Styling patch

2007-05-06 Thread Stephen J. Turnbull
A.M. Kuchling writes: I don't think this choice would work very well; requiring a rebuild would break backward compatibility. I don't know if that breakage would be OK for Mailman 2.2 or 3, but it's surely off-limits for a 2.1 point-release. Going to CSS at all is presumably off-limits

Re: [Mailman-Developers] Should we move to Bazaar?

2007-05-07 Thread Stephen J. Turnbull
Barry Warsaw writes: On May 5, 2007, at 12:49 PM, Stephen J. Turnbull wrote: I'm now a lot less happy with Mercurial than I was a day ago. Bummer. Well, Mike (XEmacs's Mercurial champion) accuses Tailor of abusing the Mercurial APIs. He has a point, although my worries retain some

Re: [Mailman-Developers] Styling patch

2007-05-08 Thread Stephen J. Turnbull
Barry Warsaw writes: Would you make $list.css editable by the list admin, a la listinfo.html? Does doing so open any additional security vulnerabilities? Yes to editable, I don't know to security vulnerabilities. View the CSS Zen Garden (better yet, get the book), and know fear.

Re: [Mailman-Developers] Improving the archives

2007-07-04 Thread Stephen J. Turnbull
Barry Warsaw writes: - archive links that won't break if the archive is rebuilt Yes, this is absolutely critical, in fact, I'd put it right at the top of the list, even more so than a u/i overhaul. Stable urls, with backward compatible redirecting links if at all possible, would

Re: [Mailman-Developers] Improving the archives

2007-07-09 Thread Stephen J. Turnbull
John A. Martin writes: In the absence of a Message-ID on an outgoing mail message many if not most MTAs will add one. Why not let Mailman anticipate the need to add a Message-ID when archiving the message rather than leaving it to the outgoing MTA? Quite. My reason for saying last

Re: [Mailman-Developers] Improving the archives

2007-07-20 Thread Stephen J. Turnbull
Barry Warsaw writes: First, I want to avoid talking about file system layout. To me, that's an implementation detail we needn't worry about right now. Agreed. How likely is it that two messages with the same message-id and date are /not/ duplicates? For message id generators that

Re: [Mailman-Developers] Improving the archives

2007-07-20 Thread Stephen J. Turnbull
Barry Warsaw writes: Second, things can happen to a list that might cause this sequence number to get corrupted. Add an X-Mailman-Sequence-Number header if not already present. That doesn't deal with your other comments, but as I point out elsewhere, if you don't use *any*

Re: [Mailman-Developers] Improving the archives

2007-07-20 Thread Stephen J. Turnbull
Barry Warsaw writes: But it would have to be subject to the same bounce rules as any other auto-response which could be used as a spam vector, e.g. limit the number of bounces per time period and don't include the entire original message in the bounce But that prevents detecting a

Re: [Mailman-Developers] Improving the archives

2007-07-24 Thread Stephen J. Turnbull
Jeff Breidenbach writes: Notice that of 325146 total messages, 624 of them had no message-id header. Even if you aggregate dup+col, you're still looking at a total duplicate rate of 0.29%. Message ID's are supposed to be unique. Fortunately, a rule more honored in the observance

Re: [Mailman-Developers] Improving the archives

2007-07-24 Thread Stephen J. Turnbull
John A. Martin writes: better to go ahead and use the mesage-id, rather than concoct yet another this time we mean it! unique identifier. st That's not the point. We're not going to impose this on st senders; I read the quote as meaning this time we mean it

Re: [Mailman-Developers] Improving the archives

2007-07-24 Thread Stephen J. Turnbull
Jeff Breidenbach writes: So we just specify a header to put it in, and subscribers will be able to use it, per definition of a canonical URL. It is the archive server's job to decide what is the canonical URL for a message. There's a good chance these archival URLs will be served by

  1   2   3   4   5   6   7   8   9   10   >