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

> "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

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

> "J" == J C Lawrence 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 arc

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

> "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 me

Re: [Mailman-Developers] incorrect generated HTML

> "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 http://t

Re: [Mailman-Developers] Unified Moderator Interface

> "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 rou

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

> "Tokio" == Tokio Kikuchi <[EMAIL PROTECTED]> writes: Tokio> Consider mailman get a spam from a foreign country and Tokio> caused an error. Mailman may complain UnicodeDecodeError Tokio> and spew an excerpt containing unknown charset string. This really should not happen. Mailma

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

> "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 m

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

> "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. T

Re: [Mailman-Developers] Sender field

> "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 b

Re: [Mailman-Developers] Sender field

> "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 ag

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

> "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 i

Re: [Mailman-Developers] Sender field

> "BAW" == Barry Warsaw <[EMAIL PROTECTED]> writes: * You could still add a handler to the global pipeline, but have it do a test of the listname or domain first, and if it doesn't match, do a quick return. You pay the cost of the handler for every mailing list,

Re: [Mailman-Developers] dkim-signature headers

Michael Thomas writes: > Just to be clear, there are hacks that we do with the length such > that mailing lists that insert trailers into mime structured posts > still verify. This is done by not signing the trailing -- and/or > . This works pretty well. Obviously any wholesale > conversions

Re: [Mailman-Developers] dkim-signature headers

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

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. M

Re: [Mailman-Developers] dkim-signature headers

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. Th

Re: [Mailman-Developers] dkim-signature headers

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 differe

Re: [Mailman-Developers] dkim-signature headers

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

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

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 r

Re: [Mailman-Developers] dkim-signature headers

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 th

Re: [Mailman-Developers] dkim-signature headers

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 speci

Re: [Mailman-Developers] dkim-signature headers

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 n

Re: [Mailman-Developers] dkim-signature headers

Stephen J. Turnbull writes: > 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

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

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

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

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 lat

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

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 ra

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

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 bette

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

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

[Mailman-Developers] Advanced Reply-To-Munging

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. There is nothing that says the MUA can't offer other choices; just the that MUA should offer the address list in Reply-To to the user

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

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

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

Sven Anderson writes: > All my proposal is about, is bringing the reply-to-munging closer to the > RFC _and_ usability than it is now. Well, there is a difference of opinion about this, but my opinion is that Reply-To munging is absolutely broken vis-a-vis the RFC: it's an originator header, an

Re: [Mailman-Developers] Templating the interface

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 li

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

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 distr

[Mailman-Developers] Should we move to Bazaar?

Barry Warsaw writes: > think this is a good time to ask whether we should move from > Subversion to Bazaar 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 hom

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

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 prope

[Mailman-Developers] Styling patch

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?

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'

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

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?

Barry Warsaw writes: > On May 3, 2007, at 11:50 AM, Jon Scott Stevens wrote: > > #1. *everyone* knows how to use it and almost all OSS software > > projects use it. You could say the same for Microsoft Windows. But not for svk. svk apparently uses an idiosyncratic notation, not horrible or

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

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?

[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 > > XEmac

Re: [Mailman-Developers] Styling patch

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-limi

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

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

Re: [Mailman-Developers] Styling patch

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. W

Re: [Mailman-Developers] Improving the archives

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, wo

Re: [Mailman-Developers] Improving the archives

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

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 t

Re: [Mailman-Developers] Improving the archives

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* Mailman-specif

Re: [Mailman-Developers] Improving the archives

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

Re: [Mailman-Developers] Improving the archives

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 obser

Re: [Mailman-Developers] Improving the archives

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

Re: [Mailman-Developers] Improving the archives

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 > s

Re: [Mailman-Developers] Improving the archives

Barry Warsaw writes: > I agree, I just don't think message-ids are user friendly enough to > be this canonical url. Especially in this context, which is exactly > where urls are thrown in users faces. An archiving service is > exactly the right place for redirecting human readable urls

Re: [Mailman-Developers] Improving the archives

Barry Warsaw writes: > Yes, definitely. What do you think of the base32 examples I have on > the wiki page? They're somewhat better than Message-IDs for readability, but they're not user-friendly. > On Jul 24, 2007, at 1:11 PM, Terri Oda wrote: > > > It seems silly to generate nice shor

Re: [Mailman-Developers] lowercase in mailman create function

Mark Sapiro writes: > Thanks for the report. I don't think it's necessary to open a bug. I'll > fix it without a bug in the tracker, Up to you, but it is useful to people with lower versions to be able to see that the bug has been reported, and what progress is being made, in the tracker. > b

Re: [Mailman-Developers] Improving the archives

Craig Loomis writes: >Globally unique IDs, hashed IDs, etc., are very appealing from > various CS-y and techie points of view, but are simply not memorable > to humans or knowable by dumb external programs. I think as much, or > more, effort should be put into delivering a straightfo

[Mailman-Developers] Patches for true Virtual Hosting -- download site?

[EMAIL PROTECTED] writes: > As another aside, as noted in entry 4.47 in the Mailman FAQ ( > http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.047.htp ) > CPanel apparently has patched this functionality into Mailman, but decline > to give back their changes. Given that Mailman is no

Re: [Mailman-Developers] [Mailman-Users] Efficient handling of cross-posting

Moving to Mailman-Developers: > > It should go without saying that it's very interesting; this is a FAQ [...] > Woo-hoo. That's encouraging. Well, if the only thing, that prevented the > feature from appearing by now, is lack of development resources, then I'll > get right on it. Thanks, W

[Mailman-Developers] Feedback for mailman developers

Adrian Bye writes: > I felt at the time it was an important project. I was told it was > not, so I made it myself. And, it was refused to be added to the > main fork of mailman which was quite frustrating. Actually, in the thread in the archives you were not told it was "unimportant", you we

[Mailman-Developers] Fwd: Feedback for mailman developers

Barry Warsaw writes: > Begin forwarded message: > > From: "Adrian Bye" <[EMAIL PROTECTED]> > > We found our mail was directly going into the trash when it > > included mailman headers. When we modified mailman to send but > > hide the mailman headers, we got directly into the inbox. What do

Re: [Mailman-Developers] Fwd: Feedback for mailman developers

Adrian Bye writes: > I don't know the specifics. I just told the developer to remove > all headers which identified mailman as mailman. Well, could you ask him which they were? It matters. BTW, a look at the patch suggests it's incomplete; I couldn't find any templates for headers and footer

[Mailman-Developers] Logging lossage

Moved from mailman-users. Mark Sapiro writes: > If this is the case, there will be 'Message discarded' entries in > Mailman's vette log, but they will only tell you the message was > discarded, not why. I've long thought that this is a design bug. This is one nice thing about SpamAssassin: i

Re: [Mailman-Developers] [Mailman-Users] RFC: X-Archive header fields

Moving to Mailman-Developers per BAW. CC to -Users; Reply-To set to -Developers only. Barry Warsaw writes: > Hi Richard, > > Please see RFC 5064: http://www.ietf.org/rfc/rfc5064.txt Argh. You'd think they'd get in touch with the maintainers and users of the most popular mailing list softwa

[Mailman-Developers] [Bug] 2x decode_header? [was: No subscription is made ...]

Moving to -developers, reply-to set. Please keep Henrik in the loop. Seems to be the same as http://sourceforge.net/tracker/index.php?func=detail&aid=1186819&group_id=103&atid=100103 Henrik Rasmussen writes: > Stephen J. Turnbull wrote: > > Henrik Rasmussen writes

[Mailman-Developers] Mailboxes of various sorts (archive subthread)

Barry Warsaw writes: > The archives is an entirely different subsystem, and without a > volunteer stepping forward (for which I've been practically begging > for years ;), Are you able and willing to mentor said volunteer? > That's the unfortunate reality, but I do have thoughts about ou

Re: [Mailman-Developers] Fwd: Feedback for mailman developers

Adrian Bye writes: > Is the code incomplete? Yes, as far as I can tell. As I wrote before: > > BTW, a look at the patch suggests it's incomplete; I couldn't find any > > templates for headers and footers, nor documentation for how to > > generate the 1-click unsubscribe button. > Please,

[Mailman-Developers] before next release: disable backscatter in default installation

Jo Rhett writes: > Hi. There's a fairly simple problem here that needs to be > addressed. And it's mostly a documentation/install problem. I'm > hoping we can get this resolved before the next release. Which "next release"? 2.1.10, which is deep into beta at this point? I would strongl

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

Jo Rhett writes: > This is not substantive, it's trivial. *sigh* From the point of view of the release manager, there are no trivial code changes to a release candidate. You are handicapping your advocacy by failing to acknowledge the potential for trouble. Adding a README.backscatter would b

Re: [Mailman-Developers] before next release: disable backscatter indefault installation

Cristóbal Palmer writes: > Even without the original message text a response is a problem. I agree -- the addresses are too easy to compute and do end up in lists that are sold -- and would support consideration of changing the defaults as proposed. But not for 2.1.10. Changing 2.1.10 is dumb

Re: [Mailman-Developers] 1-click unsubscribe

Aaron Crosman writes: > Sounds like what you're describing is a more complete CRM. Personally, > I don't think Mailman should head in that direction, there are perfectly > good CRM's for NPO's out there (like CiviCRM). He is talking about a more complete CRM, but we need that anyway because o

Re: [Mailman-Developers] Documentation status?

Barry Warsaw writes: > I think the GFDL would probably be more appropriate: > > http://www.gnu.org/licenses/licenses.html#FDL > > I'm not as well versed on this license; what do people think about that? "Gratuitous license proliferation" about sums it up. The big problem with GFDL is that

Re: [Mailman-Developers] Documentation status?

Barry Warsaw writes: > YAGNI. Since our docs are already GPL'd, unless there's a reason to > switch or dual license that overrides the hassle, let's just stick to > GPL. Yay! Another victory for the Sanity in Free Software movement! ___ Mailma

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

Jo Rhett writes: > On Mar 4, 2008, at 6:00 PM, Stephen J. Turnbull wrote: > > In any case, it's hard to sympathize with your claim of urgency. > > Mark's intention to release 2.1.10 has been known for many months. > > This proposal comes on the eve of rele

Re: [Mailman-Developers] before next release: disable backscatter indefault installation

Jo Rhett writes: > On Mar 4, 2008, at 9:27 PM, Stephen J. Turnbull wrote: > > You see, as Jo Rhett points out (apparently without understanding), it > > will have *no noticable effect* in the short run because *the proposed > > change won't affect existing Mailma

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

Jo Rhett writes: > On Mar 24, 2008, at 6:45 PM, Mark Sapiro wrote: > > I still don't get what you mean by "properly deal with DSNs". Are you > > saying that an MTA should never return a DSN? It should either reject > > the mail during the incoming SMTP transaction or forever hold its > > piec

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

Eino Tuominen writes: > You are missing the point. Of course you can inform of a delivery > problem, but only when you really need to do it. Every organisation > should know of every recipient within their authority. You should know > the recipient if you accept a message for delivery from

Re: [Mailman-Developers] before next release: disable backscatter indefault installation

Jo Rhett writes: > What is your problem? But that's the whole point. I don't have a problem, although you have made me aware that I may have one in the future. Still, it's not pressing. So I want 2.1.10 released ASAP, which means as is, and I can wait for 2.1.11. I also honestly believe that

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

Ian Eiloart writes: > No, that's not true. I have about 10,000 users here. Interesting. I bet we're talking hundreds of thousands of users, just with the three or four of you medium-to-large-site admins that have posted so far. At a penny per user, I'm sure you could find somebody to do this w

Re: [Mailman-Developers] before next release: disable backscatter indefault installation

Jo Rhett writes: > I'm here out of good will, I believe you, but your posting style provides zero evidence for it. > trying to avoid the banning of Mailman from dozens of large ISPs. > This kind of response just makes me think I'm wasting my time. Well, yes, that's what we've been saying. T

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

Ian Eiloart writes: > At a penny per user, I could raise £100. That wouldn't do the job. No, but if you can find 9 more like you, it would. We heard from one current Navy personnel, according to Jo Rhett that's a cool $25,000. Hey, that could probably buy a month of Barry's time ... can you im

Re: [Mailman-Developers] before next release: disable backscatter indefault installation

Jo Rhett writes: > The standards expoused by the leading anti-spam groups are what we > are talking about. URLs to (some of) these standards, s'il vous plait. RFCs (including BCPs) or Internet-drafts preferred, of course, but web pages of similar quality, intended as BCPs, would do. No Wikipe

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

Timo Wingender writes: > This are my ideas so far. Is this welcome in Mailman and is it enough > for an GSoC Project? Where would it be best? 2.1.11? 2.2.0? 3.0.0? I don't speak for the core developers, but to summarize what several others have said and add a couple of points: - If you are go

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

Julian Mehnle writes: > There is no such document. Jo Rhett keeps talking about "technical problems". Well, conformance to a published standard is a technical problem. Deciding what to do in the absence of such a standard is not, and you tell us there isn't one. But I can tell you this for su

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

Ian Eiloart writes: > I think the reason that backscatter isn't subject to any RFC is that the > real problem is the lack of authentication and accountability for > return-paths in the original messages. Bouncing would be fine if you know > that the email really came from the owner of the r

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

Cristóbal Palmer writes: > Back in January I told our 500+ list admins that they could do this: > > > http://lists.ibiblio.org/pipermail/ibiblio-announce/2008-January/000210.html > > And as of yesterday (27 of March) fewer than 20 had done > anything. Yesterday I ran a script that impo

Re: [Mailman-Developers] before next release: disable backscatter indefault installation

Thank you, Ian! A couple comments: Ian Eiloart writes: > A talk given at a UK Unix User Group meeting. Look for the 5th abstract on > this page: > Actually, it's the 6th abstract, I think. >

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

<    4   5   6   7   8   9   10   11   12   >