Re: [Mailman-Developers] before next release: disable backscatterin default installation

Kenneth Porter writes: > [Wikipedia says:] > > A vigilante is a person who ignores due process of law and enacts his own > > form of justice when they deem the response of the authorities to be > > insufficient. > > I see nothing wrong with that. Where I live, self-defense is > acceptable.

Re: [Mailman-Developers] before next release: disable backscatterin default installation

Julian Mehnle writes: > You expect me to provide URLs showing what? Actually, I consider you rather unlikely to provide any URLs at all. > You seem to be missing that the e-mail system is essentially an > anarchy. No, I just don't apply judgmental terms like "rightfully blacklisted" and "ant

Re: [Mailman-Developers] Google Summer of Code - Spam Defense

Cristóbal Palmer writes: > Part of this involves the backstory. 500+ lists that have never been > in any way filtered, and many vocal list administrators concerned that > having something imposed on them that they can't control will break > things. "Beggars can't be choosers." > Personall

Re: [Mailman-Developers] Google Summer of Code - Spam Defense

Barry Warsaw writes: > Mailman to something like SpamAssassin. One of course would be a > fairly simple handler to recognize SA headers and do the appropriate > thing. Why have a Handler when you can already use header scanning in the privacy filters? Ie, isn't this a documentation or UI

Re: [Mailman-Developers] Google Summer of Code - Spam Defense

Eino Tuominen writes: > I agree, it's a UI problem. What I'd like is that privacy/spam > administration page had two checkboxes for "Filter obvious spam" and > "Filter propable spam" (or smthng like that). Do you mean "Filter SpamAssassin score >15" and "Filter SpamAssassin >5", or equivalen

Re: [Mailman-Developers] Google Summer of Code - Spam Defense

Barry Warsaw writes: > On Mar 29, 2008, at 11:17 PM, Stephen J. Turnbull wrote: > > > For this reason I am looking forward to a way to issue SMTP rejects > > based on content. Eg, for sendmail and postfix, this could be > > implemented via a Mailman-provided milte

[Mailman-Developers] Configurable options in Mailman 3

Mark Sapiro writes: > What are you asking, and what is the issue? > > Upon rereading, I think your question is "is it possible to have > OLD_STYLE_PREFIXING = No in mm_cfg.py, but use the old style for > selected lists through some list setting". Unfortunately, the answer > to that is no.

[Mailman-Developers] LMTP delivery (was Re: ANNOUNCE: GNU Mailman 3.0a1 (Leave That Thing Alone))

Barry Warsaw writes: > Okay. BTW, wouldn't you think that the majority of messages sent to a > Mailman list will have exactly one RCPT? Cross-posting is relatively > rare for most sites, isn't it? It's not just cross-posting, though. Consider this message, except assume that you posted

Re: [Mailman-Developers] GNU Mailman Site Redesign

Barry Warsaw writes: > Maybe not though. Ideally, most of the www content really could live > on the wiki. We'd lose the mirrors, but I'm not really sure how much > value there is in them anyway. Radical thought: with a front page we > can better design, and pages we can lock down fro

Re: [Mailman-Developers] GNU Mailman Site Redesign

Barry Warsaw writes: > There doesn't seem to have been much debate on this, but I'm up for > moving it. I think the two options at this point are probably > Launchpad or trying to get a Roundup instance up on python.org. I > think Martin just did something similar for setuptools so he

[Mailman-Developers] Intern

Ian Eiloart writes: > Also, can you give me pointers to a good place to learn about doctest, > please? In public, please! Inquiring minds want to know ... ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailm

Re: [Mailman-Developers] bounce info not updating in MM 2.1.11rc1 + patch

Barry Warsaw writes: > Wow, it's shocking to realize how long I've been hacking on Mailman > then! :) Isn't http://www.vimeo.com/1093745 even more impressive as proof of Barry's longevity, though! ___ Mailman-Developers mailing list Mailman-D

[Mailman-Developers] Web UI

Terri Oda writes: > Not very. Not only is it tightly integrated, but any text change > will have to go through all the many translators for various > languages. Aha. You beat me to that one. I think that one way to deal with that, though, would be to simply refactor the existing interfa

Re: [Mailman-Developers] better logging of undiscernable bounces

Mark Sapiro writes: > discernable addresses' message, so the list name isn't really required > since the list will be identifiable with the first change, and it may > even seem redundant, but I think it's more consistent to include it on > all the messages. +1 +1 Consistency and (some) redund

Re: [Mailman-Developers] [Mailman-Users] GNU Mailman Site Redesign

Brad Knowles writes: > That implies their client is misconfigured and that should be their problem > and not ours. Right? Actually, all existing clients are pretty much broken, since they don't allow you to enforce your own CSS. But I guess they figure that nearly all existing users are brok

Re: [Mailman-Developers] [Mailman-Users] Subscribers suddenly"disappear"

Mark Sapiro writes: > 1) add_member saves the list with the first member. > 2) VirginRunner gets there first, instantiates and caches the list. >It then locks the list, processes the welcome and saves and unlocks >the list. > 3) add_member gets the lock, adds the second member and sav

[Mailman-Developers] Enabling topics with only one topic: can't exclude topic?

Context: The bzr developers are considering splitting their Mailman list into a -dev and a -user list, but they don't like that because they feel it would split their community in an undesirable way. So the proposal is to create a [codereview] topic which gets workflow-related posts (nitty-gritty

Re: [Mailman-Developers] "Orignal" MySQL Member Adaptor - 1.71

kyrian (List) writes: > PS. Is Trac really as good as people seem to think it is? I've not > started using it, but I certainly like the *look* of it? Well, the MacPorts people switched to Trac advertising it as "our wonderful new Trac", and indeed for the first year I wondered how to use it, e

[Mailman-Developers] MM command prefix and-or single mm-admin CLI frontend

Andy Buckley writes: > In MM, there is no common prefix Since most commands work best from the Mailman home directory, "bin/" works fine for me. > is to have a single admin command which can either behave like a > non-interactive process or a subcommand interpreter, depending on > how it is

[Mailman-Developers] PyCon 2009 sprint

Barry Warsaw writes: > If you're attending PyCon this year and want to get your hands dirty > with Mailman 3, please sign up! For me it's, ah, "inordinately expensive" to get there. Will there be an IRC channel and virtual whiteboards, etc? ___ Ma

Re: [Mailman-Developers] [Branch~mailman-coders/mailman/2.2] Rev 1046: - Changed someold messages for more current meaning.

Barry Warsaw writes: > A style I've adopted for MM3 is that if the object is definitely supposed to > be a sequence, emptiness is checked with len(). E.g. for a string, list, > tuple, dictionary, you'd use: > > if len(data) == 0: > > If the object could be a sequence or None, then ba

[Mailman-Developers] Putting the FAQ link in with error messages?

Terri Oda writes: > I know, it's another line of work for the translators, This is not a problem. This is precisely what they signed up for. Communicating important information. ___ Mailman-Developers mailing list Mailman-Developers@python.org http:/

[Mailman-Developers] Should Mailman provide periodic activity summaries to list owners?

A quick search didn't find anything, so I'll do a more careful check and if there's nothing I'll add a tracker RFE and a short wiki page of the imagined feature, probably on Monday. Unfortunately, I can't volunteer to implement at this time. Details: I noticed that we've been getting a lot of po

Re: [Mailman-Developers] Should Mailman provide periodic activity summaries to list owners?

Ian Eiloart writes: > There's already a script, "mmdsr" knocking about that does this. There's a > version at > , > Sure, but that script requires being mailman in a shell on the host. The people I'm worried ab

Re: [Mailman-Developers] Should Mailman provide periodic activity summaries to list owners?

Mark Sapiro writes: > The real issue is that mmdsr is a global report. Stephen appears to be > thinking more of a list specific report for list owners. Yes. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.pyth

[Mailman-Developers] openID enabled mailman

Malveeka Tewari writes: > 2. Sign in with existing openID login for your subscription > > *1. Enable/Disable openID login for your subscription* *account* > For enabling and diabling the openID feature, the users login their > subscribed accounts as they do now for changing any of the subcri

Re: [Mailman-Developers] [Mailman-Users] openID enabled mailman

Malveeka Tewari writes: > Our focus is on providing Single Sign On but we do not want to delegate > authentication to a third party. Hence we want to implement OpenID provider > for our Mailman service. I don't think this is a good idea. Mailman is designed to deliver single messages to multi

Re: [Mailman-Developers] Searchable archives for MM

Bernd Siggy Brentrup writes: > [Barry Warsaw contributed the comment:] > > You can do this for Mailman lists, at least when you are explicitly > > CC'd with an address that's subscribed to the list. You'll get the > > direct copy and not the list copy though. That's the best Mailman > > can

Re: [Mailman-Developers] Searchable archives for MM

Bernd Siggy Brentrup writes: > On Sat, Aug 08, 2009 at 15:43 +0900, Stephen J. Turnbull wrote: > > They don't come *better* than mutt, though. At best, "different". > > Oh no, no yamuad (Yet Another MUA Discussion) please. Oh, fer shure. My point was to re

Re: [Mailman-Developers] Searchable archives for MM

Bernd 'Siggy' Brentrup writes: > learn from ht://Dig or Xapian (both written in perl and C iirc) > to implement an enhanced pipermail. Xapian is written in C++ (I'm pretty sure about that) and has Python bindings. Python bindings for sure: it's used in Roundup (though like much in Roundup I ca

[Mailman-Developers] RELEASED GNU Mailman 3.0 alpha 3 (Working Man)

Barry Warsaw writes: > I am happy to announce the release of the third alpha version of > Mailman 3, code named "Working Man". Congratulations! ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo

[Mailman-Developers] RELEASED GNU Mailman 3.0 alpha 3 (Working Man)

Shouldn't these release messages for 3.0 alphas redirect to mailman-developers? Barry Warsaw writes: > Please note that this is an alpha release and as such is not ready for > production use. > > You can get the code from the Cheeseshop: And do what with it? Check it in to a git repo, ri

Re: [Mailman-Developers] RELEASED GNU Mailman 3.0 alpha 3 (Working Man)

Bernd Siggy Brentrup writes: > > Problems: > > > > (1) Debian stable doesn't have Python2.6. *sigh* (Not your fault, > > but it's now 0237, and I'm in a bitchin' mood and even Pure > > Prairie League doesn't make me feel better.) > > Neither does Debian testing aka squeeze, as I

Re: [Mailman-Developers] RELEASED GNU Mailman 3.0 alpha 3 (Working Man)

Hi Bernd, Bernd Siggy Brentrup writes: > Looking at the python2.6[1] page in Debian's PTS you'll notice it is > still in experimental so don't hold your breath waiting for it > appearing in testing. I didn't plan to. I don't actually mind installing my own Python. It's just that I've been pr

[Mailman-Developers] Proposed: remove address-obfuscation code from Mailman 3

Rich Kulawiec writes: > Pretending that address obfuscation in mailing list [or newsgroup] > archives will have any meaningful effect on this process gives > users a false sense of security and has zero anti-spam value. You're missing the point. Our (often non-technical) users demand this fea

Re: [Mailman-Developers] Proposed: remove address-obfuscation code fromMailman 3

Justin Hopkins writes: > Obfuscating the email addresses is just a part of 'defense in > depth' - same as patching your computer, using a firewall, > etc. Each layer, no matter how thin, still adds something. That's true. Rich's argument is more subtle than a claim that obfuscation is worth n

Re: [Mailman-Developers] Proposed: remove address-obfuscation code from Mailman 3

uot;, but I have to tell bzr that my ID is "stephen-xemacs". Wow, that's transparent. But at least it's guessable. Getting from "Stephen J. Turnbull " to "stephen-xemacs" is not going to be easy if you don't already know me. ___

Re: [Mailman-Developers] Proposed: remove address-obfuscation code from Mailman 3

Barry Warsaw writes: > What I'm thinking is that there should be a "send me this message" > link in the archive, which gets you a copy as it was originally sent > to the list. That let's you jump into a conversation as if you'd been > there originally. I don't understand. Do you mean

Re: [Mailman-Developers] Proposed: remove address-obfuscation code from Mailman 3

Barry Warsaw writes: > Let's say I just joined the XEmacs development mailing list after a > long absence. Hey, welcome back! Do you plan to return to Supercite maintenance? > I find a message in the archive from two years ago that is relevant > to an issue I'm having. I'd like to follow

Re: [Mailman-Developers] dkim and email list software - potential solution

Daniel Black writes: > > You're saying that with ADSP, that's not adequate unless Mailman > > first rewrites the "From:" address. > yes In that case it is very often a violation of RFC 733 (most familiarly known as RFC 822, also STD 11, whose most recent incarnation is RFC 5322). Surely you

Re: [Mailman-Developers] dkim and email list software - potential solution

Daniel, > > [hacking the from] is not going to be acceptable to a lot of folks, > Apart from the assertions of mailing list software developers I'm > yet to receive a strong assertion from list operators or > users. Er, do you think we write open source purely out of charity? We are all ope

Re: [Mailman-Developers] dkim and email list software

Daniel Black writes: > quite right. sorry. I'm sorry for being sharp about it. You gave it the old college try, but similar proposals have been floated before. I was also in a bad mood for reasons that have nothing to do with Mailman Developers and not really to do with Mailman at all. The re

Re: [Mailman-Developers] [Mailman-Users] A modest proposal: Reply-To munging considered *carefully*

Barry Warsaw writes: > [Your original message probably didn't make it to mailman-developers > since it was spelled "mailman-de...@python.org" -BAW] Thanks. > In general, I like Stephen's proposal as a way to help reduce the > ambiguity in this very common workflow. I'll bikeshed on this

Re: [Mailman-Developers] [Mailman-Users] A modest proposal: Reply-To munging considered *carefully*

Barry Warsaw writes: > Perhaps a good place to start is to write up a draft on > wiki.list.org? Will do. Is there a good place to put it? ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailma

Re: [Mailman-Developers] [Mailman-Users] A modest proposal: Reply-To munging considered *carefully*

Since we're getting concrete here, redirecting to Mailman Developers. Barry Warsaw writes: > On Oct 12, 2009, at 4:46 PM, Stephen J. Turnbull wrote: > I would start by putting it under Initiatives here: > > http://wiki.list.org/display/DEV/Home > > But really, we

Re: [Mailman-Developers] Reply-To munging considered *carefully*

Michael B. Trausch writes: [This was me, stephen, but the attribution was dropped:] > > The upshot is that there is no RFC-sanctioned way for a list to say > > "please respond here", and no way at all that doesn't usurp *both* the > > author's and the r

Re: [Mailman-Developers] Reply-To munging considered *carefully*

Michael B. Trausch writes: > Permit me to rephrase so that you understand what I said: I understand what you said. You are not responding to what I said, except emotionally. Stripped of emotional language, the fact is that there are use cases for Reply-To which Reply-To munging overrides. The

Re: [Mailman-Developers] Reply-To munging considered *carefully*

Sorry, I didn't have time in my reply earlier to look up the citation in RFC 5322 (and (nearly?) identical language in RFC 2822). Here it is, along with an apology. Michael B. Trausch writes: > On Wed, 2009-10-14 at 12:55 +0900, Stephen J. Turnbull wrote: > > Michael B.

Re: [Mailman-Developers] Reply-To munging considered *carefully*

Barry Warsaw writes: > It's actually easy too. An MUA need only recognize List-Post and add > a Reply to List button which would strip all the recipients and put > the List-Post value in the To header. Problem solved. Wrong problem. The users Michael is representing want a one-button MU

Re: [Mailman-Developers] Reply-To munging considered *carefully*

Michael B. Trausch writes: > Now, _this_ is where the situation is _bad_. It's _awful_. If every > single ML worked in precisely the same way, there would be _zero_ > issues. Well, yes. That's why there are RFCs, so that software and its users can interoperate over the Internet. You either

Re: [Mailman-Developers] Reply-To munging considered *carefully*

Michael B. Trausch writes: > That said, I think the MUA is simply the wrong place for it; > current models aim to control the user in one way or another, or > lack flexibility in exchange for convenience or vice versa. It > doesn't have to be that way; it's not 1970, folks. How you can get f

Re: [Mailman-Developers] Reply-To munging considered *carefully*

Michael B. Trausch writes: > My main, central, and driving point is a desire to create a system that > is both idiot friendly and expert friendly, and my desire is to have all > known common (end-user) and uncommon (technical user) use cases be > handled in a manner that is consistent and port

Re: [Mailman-Developers] [Mailman-Users] GNU Mailman roadmap

Brian J Mingus writes: > I have only recently subscribed to this list and I can say that you > and every other person that read my e-mail saw fit to ignore > it. I don't see anything in my folder or in the archives for this list (Mailman Developers). Perhaps you are referring to your post "E-m

[Mailman-Developers] Mailman and Submission port

Patrick Ben Koetter writes: > I'd like to propose a change in MM3s default SMTP client port from port 25 > (transport) to port 587 (submission). I don't see a real justification for such a change, given the authentication requirement. While Mailman can be used in relatively closed setups, its

Re: [Mailman-Developers] Mailman and Submission port

Patrick Ben Koetter writes: > To clarify: I don't want to require users to authenticate in order > to allow them to send. I want mailman to use a stanardized port for > message submission (and that brings in the authentication > requirement). Oh, so this is outgoing? Now I see. I still don'

Re: [Mailman-Developers] Reply-To munging considered *carefully*

Earl Ruby writes: > I've read back through this thread, and forgive me if this has been > discussed before, but have you considered giving subscribers the > option of deciding for themselves whether their replies should go to > the list or to the poster? No, I hadn't considered it, and upon c

Re: [Mailman-Developers] Feature Request - Interactive HTML Digests

Tanstaafl writes: > Most MUAs can render HTML email messages fine. That depends on your definitions of "HTML", "email messages", and "fine". All of them are pretty ambiguous, and different *senders* view them differently. That makes it very difficult for an application like Mailman which often

Re: [Mailman-Developers] Feature Request - Interactive HTML Digests

Tanstaafl writes: > I think you misunderstand. I'm not talking about normal list > traffic. Not as far as I can tell, and I'm talking about digests, too. > I'm talking about creating a special HTML formatted List Digest message > that MM3 would generate *itself*. Exactly. "Special HTML" an

Re: [Mailman-Developers] Feature Request - Interactive HTML Digests

Tanstaafl writes: > On 2/20/2010 10:53 AM, Stephen J. Turnbull wrote: > > My users expect to be able to view the messages in a digest as an > > email folder. That's the most important digest feature for them; > > I wouldn't have had a clue what you&#

Re: [Mailman-Developers] Feature Request - Interactive HTML Digests

Tanstaafl writes: > > That's not the point. The point is that in my experience these are > > minimum requirements for a digest view, > > Sorry, maybe I'm dense but I don't know what you mean by 'these' when > you said 'these are minimum requirements'... and reading the previous > messages

Re: [Mailman-Developers] Feature Request - Interactive HTML Digests

Tanstaafl writes: > Ok... but again (how many times have I said this now??), > MIME and plain text digest versions will continue to work as they > currently do. And how many times do I have to reply that that is not the point, I am discussing the design of the new feature? I'm drawing an analo

Re: [Mailman-Developers] Feature Request - Interactive HTML Digests

Tanstaafl writes: > Also, maybe peeking at the message source for one of the Yahoo and > Google Digests could make this easier... All 250KB of Javascript? There is *serious* magic in there; this is *wa-a-ay* beyond the remit of Mailman. Mailman is *not* a full-featured MUA, and it never will

Re: [Mailman-Developers] Feature Request - Interactive HTML Digests

Tanstaafl writes: > The point I'm getting at is, I'd like to see the basic framework for a > new HTML digest added to MM. Barry said he is fine with it as long as it > is done right, and Mark seems to concur. Well, you have to start > somewhere, so why not just start with the really simple/bas

Re: [Mailman-Developers] Feature Request - Interactive HTML Digests

Tanstaafl writes: > A really dumb question - is there no way to (reliably, or even at all?) > 'interact' with just the headers of messages that are attached? Yes, there is. It's called a "MIME digest", and Mailman already provides that feature as a subscriber option. This gives the receiving

Re: [Mailman-Developers] Mailman 3.0 UI Status?

Kovács Zoltán writes: > Dear All, do you have some screenshots about the upcoming Mailman3 UI? I > have been Googling for some time but I didn't got appropriate results. If you think screenshots of the UI are important, then Mailman 3 is not for you, yet. Please have some patience, it will be

[Mailman-Developers] MM3 WUI :: Memberships Management

Adam McGreggor writes: > I'm wondering if with MM3, admins will be able to delegate the various > aspects of admin-tasks to owners/other users -- e.g., I want to be > able to allow person X to just be able to add/remove users from a > given list; I want to allow person Y to be able to change a

Re: [Mailman-Developers] MM feature request - spread out the pain

David Andrews writes: > Some other list software, I believe, has a feature that sends out a > canned message once a month, such as list rules. I would like to see > this in MM3 -1. This is mission creep. A cron job will serve perfectly well. Something that assists in setting up such cron

Re: [Mailman-Developers] MM feature request - spread out the pain

s...@pobox.com writes: > I assume the monthly reminder emails have be canned for a reason. They do > have the nice property of sending something to every subscribed address, > even those who are set NOMAIL. That's a good point. I think a better way to handle this might be an Urgent flag (I g

Re: [Mailman-Developers] MM3 WUI :: Memberships Management

Adam McGreggor writes: > Inspired by , here's > my annotated mock-up screen-shot: > > Looks good as a rough cut. What I worry about is that there are a lot of options, and maybe a lot of

Re: [Mailman-Developers] MM feature request - spread out the pain

David Andrews writes: > I disagree, not everyone who runs a list has access to the command > line, and/or the means or ability to set up a Cron Job, so something > through the Web UI would be useful! Of course it would be useful to people who are using platforms that were designed to make Ma

Re: [Mailman-Developers] MM feature request - spread out the pain

s...@pobox.com writes: > Stephen> If Mailman can do it *better* than cron, that would be another > Stephen> matter. That point is arguable, but my personal preference > Stephen> would be to provide a generic feature that both cron and other > Stephen

Re: [Mailman-Developers] Ham, mailing lists, and oddball character sets

Cristóbal Palmer writes: > On Tue, May 04, 2010 at 12:32:42PM -0600, Philip A. Prindeville wrote: > > > > And thereby, it would be trivial to bounce a message sent to an > > English-language only mailing list that wasn't encoded in USASCII or > > Latin1 (iso-8859-1) as the charset. > > > >

Re: [Mailman-Developers] UI for Mailman 3.0 update

Barry Warsaw writes: > We'll probably end up using Launchpad since our branches and bug trackers are > there, but Transifex does look nice. File an RFE on Launchpad! Then go twist some arms at the next Ubuntu summit, or better yet, lull them into submission with slow sexy bass line. Maybe you

Re: [Mailman-Developers] UI for Mailman 3.0 update

Patrick Ben Koetter writes: > Geoff, > > I am really happy to find out you, as a blind person, Yeah, a big +1 on that. Good to hear that we can get first person feedback. Interesting to hear that Mailman 2 has a reasonably usable interface, as AFAIK that wasn't a design consideration. _

Re: [Mailman-Developers] UI for Mailman 3.0 update

Eric Bloch writes: > I am a lurker here and can concur with Cristóbal's sentiments wrt > captchas . I run http://markmail.org where we provide a search > index for thousands of public mailman lists (and google groups and > other mailing lists as well). The captchas we use (for a variety > o

Re: [Mailman-Developers] UI for Mailman 3.0 update

Eric Bloch writes: > My experience is not limited nor second hand. We get scanned by > plenty of bots every day. Heck, I can beat that: some of my sites get scanned by more bots than they have actual users. The question of "limited" is "how many different sites/kinds of sites do you have expe

Re: [Mailman-Developers] UI for Mailman 3.0 update

Cristóbal Palmer writes: > While I could in theory maintain a patch, I have a lot of machines to > herd, and I am unlikely to customize anything unless I must do so in > order to meet a requirement. This is a straw man in the context of the Mailman pipelined architecture and the CheeseShop.

Re: [Mailman-Developers] UI for Mailman 3.0 update

Cristóbal Palmer writes: > On Wed, Jun 16, 2010 at 01:03:20PM +0900, Stephen J. Turnbull wrote: > > > > The question is "what are they protecting?" My claim is that if > > you're protecting economic resources (bandwidth, accurate counts of > > r

Re: [Mailman-Developers] UI for Mailman 3.0 update

Barry Warsaw writes: > It's an interesting idea, but I'm not quite sure how a webserver pipeline > would work. The way the list server pipeline works now is by treating > messages as jobs that flow through the system. A web request is kind of a > different beast. Why? Abstractly, both web

Re: [Mailman-Developers] Archives! Two neat demos from my GSoC students

Terri Oda writes: > But there's only a handful of developers working on this, and I think > the overhead, however small, is more than it's worth at the moment. So > maybe we could keep them integrated for now until it's more clearly a > win to split the tree off? What worries me is that

[Mailman-Developers] Can i use the Bouncer API a Programm wich is not GPL?

Marc Egli writes: > Now my question is: can i release my application under a less > restrictive license like the bsd license? Probably not. > According to the gpl-faq this is a borderline case because i only > invoke a function and wait for the response. > http://www.gnu.org/licenses/gpl-fa

Re: [Mailman-Developers] Can i use the Bouncer API a Programm wich is not GPL?

Marc Egli writes: > Ok but i can add a script to Mailman which accepts a path to a mail > file, then reads that file and gives a csv list back. Yes, I would think so. The FSF likes to bluster that programs running in separate processes that interact with each other via standard interprocess ch

[Mailman-Developers] Suggestions about Mailman bounce processing

Superticker2 (Mark) writes: > I'm not a subscriber to this list, so please include me > superticker2{at}iastate.edu on your cc: line. > > I have two suggestions I would like to make concerning Mailman bounce > processing: > > 1) All bounces from either a Mass Subscribe or Mass Invite oper

Re: [Mailman-Developers] Suggestions about Mailman bounce processing

Executive summary: It seems to me that your best bet is to modify Mailman as I suggest, and at times when you have a lot of paper signups, switch off "bounce processing" temporarily, and switch on (preferably it wasn't off in the first place) "bounce unrecognized goes to list owner". If modificat

[Mailman-Developers] Bounce processing in MM3

Barry Warsaw writes: > There are a couple of interesting things in MM3 that makes it different from > MM2. In MM3, users and addresses are global to the system, while membership > is specific to a mailing list. This means if we register a bounce on an > address, we can have that score affect

Re: [Mailman-Developers] Mailman Security Patch Announcement

Restricting to "developers". I wonder if hunks like > @@ -471,7 +471,7 @@ > if fullname is None: > fullname = _('Not available') > else: > -fullname = Utils.uncanonstr(fullname, lang) > +fullname = Utils.websafe(Utils.uncanonstr(fullname, lang)) > ta

Re: [Mailman-Developers] Call for volunteers: convert wiki to Moin

Barry Warsaw writes: > The Moin folks have agreed to provide the hardware and admins. I feel much better. Why-yes-I-follow-emacs-devel-since-they-adopted-bzr-why-do-you-ask-ly y'rs, ___ Mailman-Developers mailing list Mailman-Developers@python.org ht

Re: [Mailman-Developers] GnuPG support

Stanisław Findeisen writes: > On 2011-05-22 16:03, Mark Sapiro wrote: > > Stanislaw Findeisen wrote: > >> I have a feature idea: GnuPG encryption and signing. > > > > > > See and > >

Re: [Mailman-Developers] GnuPG support

Barry Warsaw writes: > My own inclination is that most sites won't need this, FWIW, I disagree. Much of the world is moving in the direction of personal IDs, perhaps backed up by an organization (eg, OpenID), rather than IDs tied to a host. Given the prevalence of systems "for the rest of us (

Re: [Mailman-Developers] MailMan Usage

Aamir Khan writes: > time or make something like whenever a mail is arrived at may mail it is > delivered directly to "procmail" then it would be really helpful.. This is possible, but how to do it depends on your system. In my case, I use postfix and exim (on different hosts), and they allow

Re: [Mailman-Developers] MM3: list disabling/enabling?

Barry Warsaw writes: > But maybe the OP has a different use case in mind and we could have a need > for > both a long-term, permanently failing retired lists, and shorter term, > temporarily failing disabled lists. I don't really understand under what circumstances a list owner would want to

Re: [Mailman-Developers] MM3: list disabling/enabling?

Barry Warsaw writes: > Do you really think it needs to be configurable? I mean, if we > can't think of a reason to not make it 5xx, why not just wait for > the first wishlist bug report? :) No, on second thought after reviewing the codes, the only appropriate 5xx code is 550. So there's no

Re: [Mailman-Developers] New RFC on using DKIM with MLMs

Murray S. Kucherawy writes: > Essentially to be "DKIM-friendly" you're free to make any changes > you want to the message so long as they are confined to those parts > of the message not "covered" by the DKIM signature. So if a > signature doesn't cover Subject:, you're fine. Obviously there

Re: [Mailman-Developers] New RFC on using DKIM with MLMs

Murray S. Kucherawy writes: > My point is that if using header fields is the right way to encode > this information in a protocol sense, then the issue is really that > the MUAs need to expose that information somehow. The success of the IETF RFC process is due to the fact that protocol is bui

Re: [Mailman-Developers] New RFC on using DKIM with MLMs

Joshua Cranmer writes: > On 10/24/2011 8:04 PM, 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 i

Re: [Mailman-Developers] New RFC on using DKIM with MLMs

Murray S. Kucherawy writes: > I don't have a reality suspension field in effect on this topic. I > was simply disputing the claim that complying with the > List-Unsubscribe RFC constitutes "hiding" of those details. It's not deliberate, let alone malicious, but it does conceal the details fro

Re: [Mailman-Developers] New RFC on using DKIM with MLMs

Patrick Ben Koetter writes: > Is it possible to register a prefix (namespace) such as mailman-. Anything > below would be mailman related. Stupid idea? Very plausible, but I suspect there are good reasons not to allow it in the RFC 822/1036 messaging series. In any case, no, it's not possible.

Re: [Mailman-Developers] New RFC on using DKIM with MLMs

Murray S. Kucherawy writes: > What it says is the list should re-sign if it modifies the message > (or, in general, re-sign anyway). So append whatever you want, > just re-sign the message. Are you insisting that advice is > defective? Defective, maybe not. But I don't think I would follow

Re: [Mailman-Developers] New RFC on using DKIM with MLMs

Mark Sapiro writes: > SMTPD32. You'd have to ask ipswitch if you want to know what it means, > but it appears to duplicate the To: header. I would guess that it actually copies the envelope recipient. ___ Mailman-Developers mailing list Mailman-Deve

Re: [Mailman-Developers] New RFC on using DKIM with MLMs

Barry Warsaw writes: > I think it makes sense to have a header identifying the MLM that the message > flowed through, and List-Agent seems like a good choice. Are lists the only agents that forward-with-changes? (Obviously MTAs forward, and they do in fact make changes to the headers, but thos

<    5   6   7   8   9   10   11   12   >