From stephen at xemacs.org Sat Mar 1 08:15:14 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 01 Mar 2008 16:15:14 +0900 Subject: [Mailman-Developers] Fwd: Feedback for mailman developers In-Reply-To: References: <3E27E105-5319-49F0-9554-63BCCA96E0BC@list.org> <87wspggpk2.fsf@uwakimon.sk.tsukuba.ac.jp> <873as2oj5o.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <87y792kj99.fsf@uwakimon.sk.tsukuba.ac.jp> 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, stop looking for reasons why not to do this I'm not a Mailman developer yet, and I was looking for a reason for this to be where I start. I didn't find it in the patch itself, and in the meantime I found something I have a strong personal interest in doing. Sorry; I hope you have better luck with Barry (who's the assigned developer), Mark or Tokio. Steve From dan at thecsl.org Mon Mar 3 00:03:35 2008 From: dan at thecsl.org (Dan MacNeil) Date: Sun, 02 Mar 2008 18:03:35 -0500 Subject: [Mailman-Developers] 1-click unsubscribe In-Reply-To: <87y792kj99.fsf@uwakimon.sk.tsukuba.ac.jp> References: <3E27E105-5319-49F0-9554-63BCCA96E0BC@list.org> <87wspggpk2.fsf@uwakimon.sk.tsukuba.ac.jp> <873as2oj5o.fsf@uwakimon.sk.tsukuba.ac.jp> <87y792kj99.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <47CB3247.2000406@thecsl.org> Stephen J. Turnbull wrote: [snip] >>> 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. Somebody else writes >> Please, stop looking for reasons why not to do this Stephen J. Turnbull: > I'm not a Mailman developer yet, and I was > looking for a reason for this to be where > I start. I didn't find it in the patch itself, > and in the meantime I found something I have > a strong personal interest in doing. I've avoided this thread untill now because I'm not a mailman developer and I didn't want my thoughts mixed in with blovating by the greedy, ignorant and self absorbed. but... Please re-consider working on "1-click" unsubscribe. In my small experience administering lists for tiny non-profit and community groups, Mailman is very often used as a newsletter/announcement list by groups without money or tech to afford something fancy like constant contact. For example, groups like: http://canalwaters.org http://lists.canalwaters.org/pipermail/canal-news/ The subscribers to these lists are generally not very computer friendly. Because the current unsubscribe process take 5 steps: 1) Click 2) enter email 3) click submit 4) read email 5) reply to email ...a lot of subscribers to these lists click the "this is spam" button in hotmail, aol , yahoo, gmail or whatever. Generally, they are aware that they signed up for the list, but don't understand that they asking for the mailman list to be blacklisted. by clicking the spam button. All they know is that they're not getting the thing they don't want anymore. This I know because my group is subscribed to the feedback loops for hotmail & AOL. When somebody clicks a "this is spam" button, we get a copy. If I know the clicker well, I contact them and get their story. I've read the FAQ and know that mailman is focused on discussion lists and for what my opinion is worth, I'm ok with that. It is awfully nice that your solution works for other people, but I don't see any obligation for you to do more than scratch your own itch. However, lots of people use it for newsletters/announcements because it is the tool at hand. Adding things like 1-click unsubscribe will make mailman a better tool for these accidental uses and (as far as I can see) not hurt it for discussion lists. I can't offer a lot more support than testing, spec development and (probably) a couple hundred bucks but I do think this a feature worth considering. --It definitely occupies spots #1 to #5 on my wish list. Hope this helps. From mark at msapiro.net Mon Mar 3 02:31:46 2008 From: mark at msapiro.net (Mark Sapiro) Date: Sun, 2 Mar 2008 17:31:46 -0800 Subject: [Mailman-Developers] 1-click unsubscribe In-Reply-To: <47CB3247.2000406@thecsl.org> Message-ID: Dan MacNeil wrote: > >The subscribers to these lists are generally not very computer >friendly. Because the current unsubscribe process take 5 steps: > > 1) Click > 2) enter email > 3) click submit > 4) read email > 5) reply to email > >...a lot of subscribers to these lists click the "this is spam" >button in hotmail, aol , yahoo, gmail or whatever. I hear what you're saying, and I'm not trying to avoid your request, but I want to point out that if you are willing to set personalize to Yes, which you would have to do anyway for a 1-click unsubscribe, you can collapse steps 1-3 above into 1 with something like Unsubscribe: %(user_optionsurl)s?login-unsub in msg_header or msg_footer, although this may be more confusing than just Unsubscribe: %(user_optionsurl)s because the former takes one to the the same page as the latter, but with the addition of "The confirmation email has been sent." at the top, but it is just one click to get to step 4. The latter collapses steps 1 and 2 into 1 and is what is currently done on this list and I think all the python.org lists, at least for 'message' subscribers (personalization is not currently implemented for digests). So my question is are you a 'message' subscriber, and have you noticed this footer? Then my next question is do you have experience with lists that do implement a 1-click unsubscribe, and do you find it actually works? My experience (see ) is that it doesn't work well, but I'm willing to listen to other input. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From bob at nleaudio.com Mon Mar 3 04:47:49 2008 From: bob at nleaudio.com (Bob Puff) Date: Sun, 2 Mar 2008 22:47:49 -0500 Subject: [Mailman-Developers] 1-click unsubscribe In-Reply-To: References: <47CB3247.2000406@thecsl.org> Message-ID: <20080303034551.M22151@nleaudio.com> > Then my next question is do you have experience with lists that do > implement a 1-click unsubscribe, and do you find it actually works? > My experience (see developers/2005-February/017851.html>) is that it doesn't work well, > but I'm willing to listen to other input. I've implemented a 1-click unsubscribe many years ago for a high-traffic list, and its used constantly.. even by spambots! Although with mine, I assume people know their subscribed email address, which isn't always the case. Having the customized prompt is great. Bob From dan at thecsl.org Mon Mar 3 05:31:03 2008 From: dan at thecsl.org (Dan MacNeil) Date: Sun, 02 Mar 2008 23:31:03 -0500 Subject: [Mailman-Developers] 1-click unsubscribe In-Reply-To: References: Message-ID: <47CB7F07.5050800@thecsl.org> > Dan MacNeil wrote: >> [snip] >> current unsubscribe process take 5 steps: >> >> 1) Click >> 2) enter email >> 3) click submit >> 4) read email >> 5) reply to email [snip] > > I hear what you're saying, and I'm not trying to avoid your request, > but I want to point out that if you are willing to set personalize to > Yes, which you would have to do anyway for a 1-click unsubscribe, you > can collapse steps 1-3 above into 1 with something like > > Unsubscribe: %(user_optionsurl)s?login-unsub > > in msg_header or msg_footer, although this may be more confusing than > just [snip] We do have personalize set to "yes" and we have VERP enabled and configured. We did experiment with including the unsubscribe URL in the footer, but found it hard to explain the process to people that cared to ask. Right our DEFAULT_MSG_FOOTER is: ### To unsubscribe: 1) send blank email to: %(real_name)s-leave@%(host_name)s 2) reply to the confirmation email ### ...as this seems the simplest to explain, step by step, click by click, key-stroke, by key-stroke. > Then my next question is do you have experience with lists that do > implement a 1-click unsubscribe, and do you find it actually works? My > experience (see > ) > is that it doesn't work well, but I'm willing to listen to other input. Thanks to the link to 2005 discussion. On discussion lists when there are replies to mangle and archive, your experience is pretty compelling. I do have direct experience with Constant Contact and yes for their application (newsletter/announcement lists) and their #1 goal (avoid being tarred as a spammer, so mail gets delivered) 1-click works very well.. On announcement/newsletter lists people can't reply and there is relatively little danger of the 1-click footer getting lost in the wild for accidental or malicious clicking by somebody other than the addressee. I agree that for discussion lists, 1-click won't reduce the number of UNSUBSCIBE posts to the list and list-owner's cell phone at dinner time. 1-click might reduce the length of the UNSUBSCRIBE, it might not. IMNSHO, for announcement-only lists, the advantages of 1-click are greater than the disadvantages. Since 2005, things have gotten a bit more ruthless on the anti-spam front, Particularly at the large providers so.... Given my small and narrow experience,(43 lists, 6500 members, 5 years, 30 small organizations), I'm willing to live with collateral damage even on discussion lists. I'd be ok with the certainty of people sometimes being unsubscribed against their will in exchange for even a chance at reducing the number of clicks on the dreaded "This is SPAM" button. http://Dreamhost.com , (70,000 hosted domains ???) feels differently. They encourage their customers to use mailman for discussion lists but FORBID them from using mailman for announcement lists. For announcement lists , they require customers to use (home-brew?) announcement software that handles 1-click and tracks when and how people came on the list. Mailman is ubiquitous. (thank you!) People who use it for newsletters often lack the $240-$360 per year needed for something like Constant Contact and they don't know that there alternatives like http://PhpList.com Again, maybe Mailman shouldn't be all things to all people. That would be nice, but... From jrhett at netconsonance.com Tue Mar 4 21:30:33 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 4 Mar 2008 12:30:33 -0800 Subject: [Mailman-Developers] before next release: disable backscatter in default installation Message-ID: 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. PROBLEM: Mailman comes out of the box ready to backscatter spam people. Yes, it's easy enough to fix. But because it comes stock this way, and is documented to install this way, most people install it to do this. Those of us who work in abuse departments are tired of hearing "well that's how Mailman works". We also object to having to teach people how to fix their mailman installations because it's not documented in the current manual. This is *exactly* like Sendmail 14 years ago. We didn't accept it then, and Sendmail fixed the problem. RESOLUTION: Mailman default installation should not backscatter in a default configuration. 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by default. Nearly everyone uses web based signup. 2. Discard or hold messages from non-subscribers by default. I would think that it would be perfectly reasonable to have documentation on how to enable the 1980s-style -request / -subscribe etc aliases. However this documentation should have a note that this is against the AUP of nearly every network provider, and enabling it will likely cause them to get listed in various blacklists as a backscatter source. FYI: I know that this goes against the instincts of many old-time mailing list advocates here. But after dealing with a 10k/hour backscatter DoS my tolerance for this problem is understandably limited. Yes, it was a sweet day back in the 1980s. I was running a mailing list server and several UUCP gateways at the time, so I remember them well. But those days are past, and we need to deal with the reality of today. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From stephen at xemacs.org Tue Mar 4 23:44:56 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 05 Mar 2008 07:44:56 +0900 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: References: Message-ID: <87lk4yw1lj.fsf@uwakimon.sk.tsukuba.ac.jp> 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 strongly oppose any substantial change in default behavior for the 2.1.10 release. It is way too late for that. From jrhett at netconsonance.com Tue Mar 4 23:49:34 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 4 Mar 2008 14:49:34 -0800 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: <87lk4yw1lj.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87lk4yw1lj.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <17DFE61F-10E8-44CC-B825-771E32A06402@netconsonance.com> > 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. On Mar 4, 2008, at 2:44 PM, Stephen J. Turnbull wrote: > > Which "next release"? 2.1.10, which is deep into beta at this point? > I would strongly oppose any substantial change in default behavior for > the 2.1.10 release. It is way too late for that. This is not substantive, it's trivial. This change has a zero chance of affecting legitimate traffic to existing sites. It would only affect new installations. However, it's significantly relevant to the thousands of people receiving backscatter from mailman hosts every day. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From mark at msapiro.net Wed Mar 5 00:28:22 2008 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 4 Mar 2008 15:28:22 -0800 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: Message-ID: Jo Rhett wrote: > >1. Don't create backscatter aliases for subscribe/unsubscribe/etc by >default. Nearly everyone uses web based signup. Do you have data to back up this assertion? Even if we wanted to do this, it is non-trivial. All confirmation messages and their templates and translations would have to be changed to remove references to confirmation by email. >2. Discard or hold messages from non-subscribers by default. The Defaults.py setting for DEFAULT_GENERIC_NONMEMBER_ACTION has been Hold from the beginning. Perhaps you are thinking of the respond_to_post_requests setting. Do you object to any response at all, or just to responses that include the original message text? If the former, then you must object to DSNs from MTAs as well. If the latter, that is planned to be addressed in Mailman 2.2. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From i at mindlace.net Tue Mar 4 23:57:42 2008 From: i at mindlace.net (Ethan Fremen) Date: Tue, 4 Mar 2008 17:57:42 -0500 Subject: [Mailman-Developers] Web UI redux Message-ID: Hiya! After an embarrassingly long absence, I am going to try again to make some progress on the web ui front. Barry said in an earlier message that there's no web UI for mm3: my first impulse is to start on something there. I was humbled enough by my first experience trying to make progress on this that I will happily start with anything that y'all think is "low hanging fruit" just so I can get something committed that can actually be used. Thanks, ~ethan fremen From jrhett at netconsonance.com Wed Mar 5 02:08:52 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 4 Mar 2008 17:08:52 -0800 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: References: Message-ID: <0C4F5F7D-CB5D-4CE7-8C54-872413A44D36@netconsonance.com> On Mar 4, 2008, at 3:28 PM, Mark Sapiro wrote: >> 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by >> default. Nearly everyone uses web based signup. > > Do you have data to back up this assertion? Sure. I used to work for an ISP with 1400 lists and ~4 million subscribers across them. I disabled all the backscatter aliases 4 years ago, and haven't heard a single complaint. I expected at least one complaint, but never got one. (whining from people who I asked to change their web page about their mailing list, but not a single complaint from an actual user) > Even if we wanted to do this, it is non-trivial. All confirmation > messages and their templates and translations would have to be changed > to remove references to confirmation by email. Text changes are trivial. Code changes require work/testing/etc. >> 2. Discard or hold messages from non-subscribers by default. > > The Defaults.py setting for DEFAULT_GENERIC_NONMEMBER_ACTION has been > Hold from the beginning. > > Perhaps you are thinking of the respond_to_post_requests setting. *shrug* I don't remember the difference offhand. I don't run that mailman instance any more, I just deal with the backscatter abuse reports. > Do you object to any response at all, or just to responses that > include > the original message text? Any response sent to an innocent victim of forgery. > If the former, then you must object to DSNs > from MTAs as well. If the latter, that is planned to be addressed in > Mailman 2.2. Of course we object to DSNs from MTAs. No shipping mailserver currently sends DSNs to accepted mail by default. Most of them haven't for like 10 years. And yes, we absolutely ban qmail from use unless the person patches it to the moon to solve its problems. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From stephen at xemacs.org Wed Mar 5 03:00:39 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 05 Mar 2008 11:00:39 +0900 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: <17DFE61F-10E8-44CC-B825-771E32A06402@netconsonance.com> References: <87lk4yw1lj.fsf@uwakimon.sk.tsukuba.ac.jp> <17DFE61F-10E8-44CC-B825-771E32A06402@netconsonance.com> Message-ID: <87fxv6vsjc.fsf@uwakimon.sk.tsukuba.ac.jp> 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 be trivial. Would you like to provide it, since you evidently know how to make the configuration changes needed? 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 release. Code changes to implement it can, and should, wait for the next release. From cmpalmer at metalab.unc.edu Tue Mar 4 17:15:58 2008 From: cmpalmer at metalab.unc.edu (=?iso-8859-1?Q?Crist=F3bal?= Palmer) Date: Tue, 4 Mar 2008 11:15:58 -0500 Subject: [Mailman-Developers] 1-click unsubscribe In-Reply-To: <47CB7F07.5050800@thecsl.org> References: <47CB7F07.5050800@thecsl.org> Message-ID: <20080304161558.GA5791@garp.metalab.unc.edu> On Sun, Mar 02, 2008 at 11:31:03PM -0500, Dan MacNeil wrote: > Since 2005, things have gotten a bit more ruthless on the > anti-spam front, Particularly at the large providers so.... lists.ibiblio.org currently hosts 566 lists. We are constantly having to deal with mail providers who blacklist us because their users find it easier to tag mailing list posts as spam than follow the unsubscribe process. IMHO, moving the "unsubscribe or edit options" to the top of the listinfo page or making it its own page by default would go a long way towards alleviating this problem. 1-click unsubscribe or some other, more streamlined default would help us quite a bit. Anything to help us reduce abuse reports and improve deliverability. I don't think a potentially-beneficial change should be discarded because it's not a panacea. Mailman hosts will always have to do work educating their list owners and supporting list users who are having trouble. I'm following this thread with interest and look forward to the changes that come out of this discussion. I'd be happy to discuss specific experiences off-list. Cheers, -- Crist?bal Palmer ibiblio.org systems administrator From cmpalmer at metalab.unc.edu Wed Mar 5 02:13:46 2008 From: cmpalmer at metalab.unc.edu (=?iso-8859-1?Q?Crist=F3bal?= Palmer) Date: Tue, 4 Mar 2008 20:13:46 -0500 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: References: Message-ID: <20080305011346.GD5749@garp.metalab.unc.edu> On Tue, Mar 04, 2008 at 03:28:22PM -0800, Mark Sapiro wrote: > > The Defaults.py setting for DEFAULT_GENERIC_NONMEMBER_ACTION has been > Hold from the beginning. We've recently set this to 3 (Discard) for new lists. Please explain the argument for keeping the default as Hold for the long term. I believe it should be Discard, but can think of at least one argument for keeping the current default. I'd like to hear development team's line. > Perhaps you are thinking of the respond_to_post_requests setting. > > Do you object to any response at all, or just to responses that include > the original message text? If the former, then you must object to DSNs > from MTAs as well. If the latter, that is planned to be addressed in > Mailman 2.2. Even without the original message text a response is a problem. In the case of backscatter, the many novice users are still likely to tag the message as spam, which will cause the mailman install to be blacklisted if enough users from the same provider take this action. I'm happy to discuss ibiblio's experiences with being blacklisted off-list. Cheers, -- Crist?bal Palmer ibiblio.org systems administrator From stephen at xemacs.org Wed Mar 5 06:27:06 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 05 Mar 2008 14:27:06 +0900 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <20080305011346.GD5749@garp.metalab.unc.edu> References: <20080305011346.GD5749@garp.metalab.unc.edu> Message-ID: <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> 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 software engineering and hysterical policy. 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 Mailman installations*, not even those that upgrade to 2.1.10. So the right thing to do is to get 2.1.10 out the door as is, and get started on 2.2. Then you can even discuss shutting off the feature in *existing* installations and requiring admins of *existing* installations to reactivate the feature if they want it.[1] That would very likely have noticeable effect *much sooner* than the change proposed for 2.1.10, and would be much less disruptive. Footnotes: [1] Indeed, I think that makes sense, but I have no intention of participating in discussion until after release of 21.1.10. From cmpalmer at metalab.unc.edu Wed Mar 5 06:46:54 2008 From: cmpalmer at metalab.unc.edu (=?iso-8859-1?Q?Crist=F3bal?= Palmer) Date: Wed, 5 Mar 2008 00:46:54 -0500 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20080305054654.GF5749@garp.metalab.unc.edu> On Wed, Mar 05, 2008 at 02:27:06PM +0900, Stephen J. Turnbull wrote: > So the right thing to do is to get 2.1.10 out the door as is, and get > started on 2.2. Agreed. I like the README.backscatter proposal, too. Such a document would (ideally) help us and other admins who want to take action *now* change the right settings even for existing lists. ibiblio and many other sites have a long-term investment in mailman's success as a project, so let's please keep the release manager happy. :) Cheers, -- Crist?bal Palmer ibiblio.org systems administrator From iane at sussex.ac.uk Wed Mar 5 11:33:14 2008 From: iane at sussex.ac.uk (Ian Eiloart) Date: Wed, 05 Mar 2008 10:33:14 +0000 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <0C4F5F7D-CB5D-4CE7-8C54-872413A44D36@netconsonance.com> References: <0C4F5F7D-CB5D-4CE7-8C54-872413A44D36@netconsonance.com> Message-ID: <7AFBB02ED4F7081C33A84D37@lewes.staff.uscs.susx.ac.uk> --On 4 March 2008 17:08:52 -0800 Jo Rhett wrote: > >> If the former, then you must object to DSNs >> from MTAs as well. If the latter, that is planned to be addressed in >> Mailman 2.2. > > Of course we object to DSNs from MTAs. No shipping mailserver > currently sends DSNs to accepted mail by default. Most of them > haven't for like 10 years. And yes, we absolutely ban qmail from use > unless the person patches it to the moon to solve its problems. > +1 The one reason that I'm looking for an alternative to Mailman is the lack of adequate integration with MTAs, which means that there is no sensible thing that I can do with suspected spam. What I need to be able to do is reject it at SMTP time, based on list post permissions and other configuations - I need to be able to query the configuration from my MTA (Exim). Holding for moderation and discarding are not adequate solutions, but holding for moderation by default would be a good intermediate step. -- Ian Eiloart IT Services, University of Sussex x3148 From amk at amk.ca Wed Mar 5 14:36:08 2008 From: amk at amk.ca (A.M. Kuchling) Date: Wed, 5 Mar 2008 08:36:08 -0500 Subject: [Mailman-Developers] Web UI redux In-Reply-To: References: Message-ID: <20080305133608.GA6466@amk-desktop.matrixgroup.net> yOn Tue, Mar 04, 2008 at 05:57:42PM -0500, Ethan Fremen wrote: > Barry said in an earlier message that there's no web UI for mm3: my > first impulse is to start on something there. I'm interested in working on a REST-style interface for controlling Mailman. One thought: should the web UI be written atop such a REST interface? Pro: it would nicely enforce decoupling the UI and the Mailman engine, and be a good test that the REST interface supports enough functionality. Con: adds an extra layer. (A sketch of the REST interface is in the wiki at http://wiki.list.org/display/DEV/REST+Interface . It's written from the 2.1/2.2 point of view; I don't know if mm3 reworks the basic objects so much that the REST interface no longer applies.) --amk From amk at amk.ca Wed Mar 5 20:53:38 2008 From: amk at amk.ca (A.M. Kuchling) Date: Wed, 5 Mar 2008 14:53:38 -0500 Subject: [Mailman-Developers] Documentation status? Message-ID: <20080305195338.GA12322@amk-desktop.matrixgroup.net> What's the status of the Mailman documentation, and where is the master copy now? The LaTeX source for the docs isn't in the Bazaar repository, beyond a copy in the Japanese translation (./messages/ja/doc/mailman-member.tex). The wiki page at http://wiki.list.org/display/DOC/Mailman+2.1+List+Administrators+Manual says "I (Terri) am currently in the process of importing the 2.1 documentation from latex," but there are many missing sections. Is the plan to migrate everything into the wiki? And where does the current LaTeX master live? --amk From terri at zone12.com Wed Mar 5 21:53:21 2008 From: terri at zone12.com (Terri Oda) Date: Wed, 5 Mar 2008 15:53:21 -0500 Subject: [Mailman-Developers] Documentation status? In-Reply-To: <20080305195338.GA12322@amk-desktop.matrixgroup.net> References: <20080305195338.GA12322@amk-desktop.matrixgroup.net> Message-ID: <8D5D8DBD-D3C8-4C52-93E0-94A09226AD7A@zone12.com> On 5-Mar-08, at 2:53 PM, A.M. Kuchling wrote: > What's the status of the Mailman documentation, and where is the > master copy now? The LaTeX source for the docs isn't in the Bazaar > repository, beyond a copy in the Japanese translation > (./messages/ja/doc/mailman-member.tex). The wiki page at > http://wiki.list.org/display/DOC/Mailman+2.1+List+Administrators > +Manual > says "I (Terri) am currently in the process of importing the 2.1 > documentation from latex," but there are many missing sections. > > Is the plan to migrate everything into the wiki? And where does the > current LaTeX master live? The plan is to migrate all of the docs to the wiki, in hopes that someone someday might help me write them. ;) The master latex file is probably the one on my hard drive/checked into source control (uhh, it was in svn, but it might not have made it to bazaar, in which case, that's my bad and I'll see what I can do), but despite the note, I think I have mostly imported it into the wiki so you can take those as final for now. I'll double check when I get home tonight. I should probably finish writing the docs, but I'm currently hampered by a cyst in my right hand that makes it fairly hard to type right now, so it's kinda limited my ability to participate in much online at the moment. I've been thinking about the mailman docs lately, though (because I looked at them after Jennifer's post about dynamic sublists and was depressed to realise that I hadn't written the section she wanted yet). I'm getting adept at typing with a wrist brace on despite the temporary disability, so poke the docs again after this weekend and I may have the admin docs much further along. Really! If I don't get distracted trying to write a new archive system. (no, really, I have notes on that too!) Terri From amk at amk.ca Wed Mar 5 22:11:24 2008 From: amk at amk.ca (A.M. Kuchling) Date: Wed, 5 Mar 2008 16:11:24 -0500 Subject: [Mailman-Developers] Documentation status? In-Reply-To: <8D5D8DBD-D3C8-4C52-93E0-94A09226AD7A@zone12.com> References: <20080305195338.GA12322@amk-desktop.matrixgroup.net> <8D5D8DBD-D3C8-4C52-93E0-94A09226AD7A@zone12.com> Message-ID: <20080305211124.GA14170@amk-desktop.matrixgroup.net> On Wed, Mar 05, 2008 at 03:53:21PM -0500, Terri Oda wrote: > The master latex file is probably the one on my hard drive/checked > into source control (uhh, it was in svn, but it might not have made > it to bazaar, in which case, that's my bad and I'll see what I can > do), ... Thanks! Looking in SVN, the files are in docs/howtos/ (http://mailman.svn.sourceforge.net/viewvc/mailman/trunk/mailman/docs/howtos/), but there's no docs/ subdirectory in the Bazaar repository. > ... but despite the note, I think I have mostly imported it into the > wiki so you can take those as final for now. I'll double check when > I get home tonight. If you haven't imported everything, I'm happy to do the necessary reformatting of LaTeX into Wiki markup. I've done it before, and simple reformatting is easy to do while I watch TV. If that would be useful, please feel free to e-mail me the latest LaTeX versions. --amk From barry at list.org Wed Mar 5 23:22:58 2008 From: barry at list.org (Barry Warsaw) Date: Wed, 5 Mar 2008 17:22:58 -0500 Subject: [Mailman-Developers] Documentation status? In-Reply-To: <20080305195338.GA12322@amk-desktop.matrixgroup.net> References: <20080305195338.GA12322@amk-desktop.matrixgroup.net> Message-ID: <05E767B2-F67F-44B9-BF0A-F2334406FB5A@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 5, 2008, at 2:53 PM, A.M. Kuchling wrote: > What's the status of the Mailman documentation, and where is the > master copy now? Hi Andrew, The masters are in Bazaar but they're not in the main code repository. I split them off, along with the website source and release/admin scripts into this repository: https://code.launchpad.net/~mailman-administrivia/mailman- administrivia/admin Of course, I'm happy to give you and Terri write permission to this repository if you want. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfPHUUACgkQ2YZpQepbvXGd0wCgof+hT1JPyhT+mGSMZa0NObQe kBoAoIhbPxnWjfb32Bjg+xuVqrLnHTXl =UOgw -----END PGP SIGNATURE----- From barry at list.org Wed Mar 5 23:26:18 2008 From: barry at list.org (Barry Warsaw) Date: Wed, 5 Mar 2008 17:26:18 -0500 Subject: [Mailman-Developers] Documentation status? In-Reply-To: <8D5D8DBD-D3C8-4C52-93E0-94A09226AD7A@zone12.com> References: <20080305195338.GA12322@amk-desktop.matrixgroup.net> <8D5D8DBD-D3C8-4C52-93E0-94A09226AD7A@zone12.com> Message-ID: <2CC52649-9F17-4079-8B14-BA54AF2C8DD4@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 5, 2008, at 3:53 PM, Terri Oda wrote: > I should probably finish writing the docs, but I'm currently hampered > by a cyst in my right hand that makes it fairly hard to type right > now, so it's kinda limited my ability to participate in much online > at the moment. I've been thinking about the mailman docs lately, > though (because I looked at them after Jennifer's post about dynamic > sublists and was depressed to realise that I hadn't written the > section she wanted yet). I'm getting adept at typing with a wrist > brace on despite the temporary disability, so poke the docs again > after this weekend and I may have the admin docs much further along. > Really! If I don't get distracted trying to write a new archive > system. (no, really, I have notes on that too!) Terri, sorry to hear about your hand! I hope you recover soon. I like having docs in the wiki because it lets more people contribute. The downside is that you can't reach it when you're offline and it's harder to publish in alternative media. Have you thought at all about how to handle that? - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfPHgoACgkQ2YZpQepbvXFfGQCfdbK1fL7HtgC4Vv6KJ/oWgBxW RyEAoLFed0b+keSzUlGc+rV1RDEOECCc =kvVn -----END PGP SIGNATURE----- From barry at list.org Wed Mar 5 23:32:05 2008 From: barry at list.org (Barry Warsaw) Date: Wed, 5 Mar 2008 17:32:05 -0500 Subject: [Mailman-Developers] Documentation status? In-Reply-To: <20080305211124.GA14170@amk-desktop.matrixgroup.net> References: <20080305195338.GA12322@amk-desktop.matrixgroup.net> <8D5D8DBD-D3C8-4C52-93E0-94A09226AD7A@zone12.com> <20080305211124.GA14170@amk-desktop.matrixgroup.net> Message-ID: <3F1FFC24-56F3-4BF5-9E9C-12611B5977A4@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 5, 2008, at 4:11 PM, A.M. Kuchling wrote: > On Wed, Mar 05, 2008 at 03:53:21PM -0500, Terri Oda wrote: >> The master latex file is probably the one on my hard drive/checked >> into source control (uhh, it was in svn, but it might not have made >> it to bazaar, in which case, that's my bad and I'll see what I can >> do), ... > > Thanks! Looking in SVN, the files are in docs/howtos/ > (http://mailman.svn.sourceforge.net/viewvc/mailman/trunk/mailman/docs/howtos/ > ), > but there's no docs/ subdirectory in the Bazaar repository. > >> ... but despite the note, I think I have mostly imported it into the >> wiki so you can take those as final for now. I'll double check when >> I get home tonight. > > If you haven't imported everything, I'm happy to do the necessary > reformatting of LaTeX into Wiki markup. I've done it before, and > simple reformatting is easy to do while I watch TV. If that would be > useful, please feel free to e-mail me the latest LaTeX versions. Oh, cool Andrew! See my previous post. I've just added amk and terrio as members of the ~mailman- administrivia team on Launchpad, so you should both now be able to get authenticated copies of the branch, and you should also have write permissions to this repository. I'm currently updating the branch to the latest Bazaar repository format, so wait a little bit before you try to do a branch. Let me know if you have any problems. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfPH2oACgkQ2YZpQepbvXHHnACfQ+xekEF1lKsYo4YeM7o2CL2u dXsAn1uWOdeXrV6Scrmib75HRLUScV4H =m4We -----END PGP SIGNATURE----- From barry at list.org Wed Mar 5 23:41:15 2008 From: barry at list.org (Barry Warsaw) Date: Wed, 5 Mar 2008 17:41:15 -0500 Subject: [Mailman-Developers] Web UI redux In-Reply-To: <20080305133608.GA6466@amk-desktop.matrixgroup.net> References: <20080305133608.GA6466@amk-desktop.matrixgroup.net> Message-ID: <4442F769-8E83-4352-922B-A3C6B042D4F4@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 5, 2008, at 8:36 AM, A.M. Kuchling wrote: > On Tue, Mar 04, 2008 at 05:57:42PM -0500, Ethan Fremen wrote: >> Barry said in an earlier message that there's no web UI for mm3: my >> first impulse is to start on something there. > > I'm interested in working on a REST-style interface for controlling > Mailman. One thought: should the web UI be written atop such a REST > interface? Pro: it would nicely enforce decoupling the UI and the > Mailman engine, and be a good test that the REST interface supports > enough functionality. Con: adds an extra layer. I'm really keen on exploring this because I do think the decoupling will be a big win. It'll let us distribute a turnkey, standalone u/i for those who want something working out of the box, but it'll also let integrators use the core Mailman engine in their own sites. And it won't limit you to just Python web frameworks. > (A sketch of the REST interface is in the wiki at > http://wiki.list.org/display/DEV/REST+Interface . It's written from > the 2.1/2.2 point of view; I don't know if mm3 reworks the basic > objects so much that the REST interface no longer applies.) I think if we're careful we can get pretty close. Ideally, we'd have the same REST api for both, which would give us a nice migration path, but I don't yet know if that's feasible. MM3 does have a more elaborate data model than MM2, but OTOH, everything is formally declared in Zope-style interfaces (and thoroughly tested... woohoo!). One thing that we have to figure out is how to represent all the metadata that currently lives in the Mailman.Gui package of 2.1/2.2. I think any web interface acting through the REST api will want that basic information, e.g. the brief and detailed descriptions of the mailing attributes (the VARHELP). I'm sure there's a clear way to publish that through the REST api, but it might have an impact on the format used. I like JSON a lot, but html or xml might be more amenable to that type of data. OTOH, it's all read-only so it might make sense to split it into two trees of information. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfPIY8ACgkQ2YZpQepbvXG3fACdEve/fgFm5D+6b5YNN7kbyezr gOAAoKdZoACLH1Blcz9deQDqso2kTHcl =0Dn9 -----END PGP SIGNATURE----- From barry at list.org Wed Mar 5 23:54:31 2008 From: barry at list.org (Barry Warsaw) Date: Wed, 5 Mar 2008 17:54:31 -0500 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 5, 2008, at 12:27 AM, Stephen J. Turnbull wrote: > 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 software engineering and > hysterical policy. > > 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 Mailman installations*, not even those > that upgrade to 2.1.10. > > So the right thing to do is to get 2.1.10 out the door as is, and get > started on 2.2. Then you can even discuss shutting off the feature > in *existing* installations and requiring admins of *existing* > installations to reactivate the feature if they want it.[1] That > would very likely have noticeable effect *much sooner* than the change > proposed for 2.1.10, and would be much less disruptive. Mark's the release manager for 2.1, but FWIW I completely agree with Stephen about this. What I would suggest though is that this information be put in a prominent place on the wiki. We have a security space with nothing substantial in it, so I suggest we put it here. http://wiki.list.org/display/SEC/Home This will get much more publicity and community input than in a README file. This is something you can do right now . We need to get 2.1.10 out and move on. I hope Jo, Cristobal, Ian and others will help us solve these problems in MM2.2 and 3.0. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfPJKcACgkQ2YZpQepbvXGicQCeMN5dv4sutxfUfzvL1FHNzZp1 McAAoIGPH+NOxU+nzOrlzV4egzw8EYtg =d5ci -----END PGP SIGNATURE----- From barry at list.org Thu Mar 6 00:05:08 2008 From: barry at list.org (Barry Warsaw) Date: Wed, 5 Mar 2008 18:05:08 -0500 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <20080305011346.GD5749@garp.metalab.unc.edu> References: <20080305011346.GD5749@garp.metalab.unc.edu> Message-ID: <4D3C2500-2ADC-4FF8-BCF3-ABEF69F914F7@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 4, 2008, at 8:13 PM, Crist?bal Palmer wrote: > On Tue, Mar 04, 2008 at 03:28:22PM -0800, Mark Sapiro wrote: >> >> The Defaults.py setting for DEFAULT_GENERIC_NONMEMBER_ACTION has been >> Hold from the beginning. > > We've recently set this to 3 (Discard) for new lists. Please explain > the argument for keeping the default as Hold for the long term. I > believe it should be Discard, but can think of at least one argument > for keeping the current default. I'd like to hear development team's > line. More and more lists are requiring membership for posting privileges, so I'm sympathetic to this change (but not for 2.1!). OTOH, I think there are ways that we can do this but still relax the constraint for well-known non-members. For example, in MM3 the data model has been improved so that you have a single user object that ties in all your subscriptions. No more multiple passwords or options (unless you want the latter), no more multiple accounts for each of your email addresses. What if in the future, your site had 1400 lists, the membership databases of which were driven from your site's membership rosters. Now, someone you've never heard of before posts to one of your lists. You probably discard this (although there /are/ arguments to be made for some lists holding these messages instead). But let's say that I join your site and register an email address. Now I post to one of your lists which I haven't explicitly subscribed to. But you know me so do you discard the message, hold it, or let it through? Let's say you hold it, and a list admin approves it, saying "hey this guy looks legit". Let's say you do this 5 times across 3 different lists. I'm probably not a spammer, right? So maybe now I can post to all your lists without being held. Anyway, it's things like this that I think can be used to help reduce spamming on the list while letting legitimate traffic through, without Mailman becoming spamassassin. OTOH, in MM3 it'll be much easier to integrate something like spamassassin than it is in MM2. I'm not saying that's a /good/ thing since spam still is better off getting caught in the MTA, but this kind of thing is possible. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfPJycACgkQ2YZpQepbvXHQ8ACgiMNs46R8OcItJtjoCAbIQHaO a2AAnif160xr7GhjOWWQ6Qvcxle7f70R =TyH6 -----END PGP SIGNATURE----- From barry at list.org Thu Mar 6 00:08:39 2008 From: barry at list.org (Barry Warsaw) Date: Wed, 5 Mar 2008 18:08:39 -0500 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <7AFBB02ED4F7081C33A84D37@lewes.staff.uscs.susx.ac.uk> References: <0C4F5F7D-CB5D-4CE7-8C54-872413A44D36@netconsonance.com> <7AFBB02ED4F7081C33A84D37@lewes.staff.uscs.susx.ac.uk> Message-ID: <09FAB6B0-3474-4DF5-9658-F2FB7BADAB07@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 5, 2008, at 5:33 AM, Ian Eiloart wrote: > The one reason that I'm looking for an alternative to Mailman is the > lack > of adequate integration with MTAs, which means that there is no > sensible > thing that I can do with suspected spam. What I need to be able to > do is > reject it at SMTP time, based on list post permissions and other > configuations - I need to be able to query the configuration from my > MTA > (Exim). Ian, I think that alternative is going to be Mailman 3 :). How do you see Exim asking that question? I can see several ways of doing it in Mailman 3. 1) you could call into a Python library that can answer that question; 2) you could use some kind of RPC such as the REST api that Andrew's been talking about; 3) you could make the appropriate queries directly to the Mailman database, which is based on SQLite currently but can be anything that Storm can talk to. Is that the kind of thing you want to do? - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfPJ/gACgkQ2YZpQepbvXEQNgCfQqZlZIt6kFyb+2MrQcteth1j q/8AnRqG8QjGqwBR0y/IQpFZMxBeiupW =eR4z -----END PGP SIGNATURE----- From barry at list.org Thu Mar 6 00:16:53 2008 From: barry at list.org (Barry Warsaw) Date: Wed, 5 Mar 2008 18:16:53 -0500 Subject: [Mailman-Developers] 1-click unsubscribe In-Reply-To: <47CB3247.2000406@thecsl.org> References: <3E27E105-5319-49F0-9554-63BCCA96E0BC@list.org> <87wspggpk2.fsf@uwakimon.sk.tsukuba.ac.jp> <873as2oj5o.fsf@uwakimon.sk.tsukuba.ac.jp> <87y792kj99.fsf@uwakimon.sk.tsukuba.ac.jp> <47CB3247.2000406@thecsl.org> Message-ID: <2AC8E914-16AE-4D08-A24F-D07DF149E981@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 2, 2008, at 6:03 PM, Dan MacNeil wrote: > However, lots of people use it for newsletters/announcements > because it is the tool at hand. Adding things like 1-click > unsubscribe will make mailman a better tool for these accidental > uses and (as far as I can see) not hurt it for discussion lists. Announce-only lists are common even in the FLOSS world, where I think people are more clueful about mailing lists in general. Certainly Mailman has a history of catering to FLOSS project needs, but I think it is worthwhile to explore the use cases for announce lists, and try to understand how to make their lives easier. I'm all for doing whatever we can to help smaller community organizations get a better tool. With Mailman 3 we'll be able to implement list styles much more easily, not just in the way lists are configured, but throughout the stack, including the pipeline handlers and the posting rules. I think the right way to do this is to have a few canned styles that you can use easily to enable things like 1-click unsubscribes. I generally don't like 1-click unsubs but I recognize that this is an important use case in the real world, and it's probably better to have the risk of people getting unsub'd against their will than to have the entire site get blacklisted from AOL because of a cluser. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfPKeUACgkQ2YZpQepbvXE7JgCdGfnHVtwiifsBiE3kXsG9W4O9 I70An2MhQ5kGLpfsGtys8VVM16n6uuMs =1rCs -----END PGP SIGNATURE----- From barry at list.org Thu Mar 6 00:20:29 2008 From: barry at list.org (Barry Warsaw) Date: Wed, 5 Mar 2008 18:20:29 -0500 Subject: [Mailman-Developers] 1-click unsubscribe In-Reply-To: References: Message-ID: <7A15F782-8FA0-4846-8E26-6037182F25BF@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 2, 2008, at 8:31 PM, Mark Sapiro wrote: > Then my next question is do you have experience with lists that do > implement a 1-click unsubscribe, and do you find it actually works? My > experience (see > >) > is that it doesn't work well, but I'm willing to listen to other > input. Interesting! I'd like to hear other input as well. It may be one of those cases where it works differently depending on the audience, but it's one of those checkboxes you have to tick in order to even get in the door. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfPKr0ACgkQ2YZpQepbvXHjUgCgmnHZ3jYzx4wyD2AzEk3ESBd8 0uAAn3+vPaRRtd1Ft3/bPBMC8dotmqH+ =g71L -----END PGP SIGNATURE----- From barry at list.org Thu Mar 6 00:24:29 2008 From: barry at list.org (Barry Warsaw) Date: Wed, 5 Mar 2008 18:24:29 -0500 Subject: [Mailman-Developers] 1-click unsubscribe In-Reply-To: <20080304161558.GA5791@garp.metalab.unc.edu> References: <47CB7F07.5050800@thecsl.org> <20080304161558.GA5791@garp.metalab.unc.edu> Message-ID: <9041EFAF-D6E7-48BF-A3F6-9C8A7FF6B41A@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 4, 2008, at 11:15 AM, Crist?bal Palmer wrote: > On Sun, Mar 02, 2008 at 11:31:03PM -0500, Dan MacNeil wrote: >> Since 2005, things have gotten a bit more ruthless on the >> anti-spam front, Particularly at the large providers so.... > > lists.ibiblio.org currently hosts 566 lists. We are constantly having > to deal with mail providers who blacklist us because their users find > it easier to tag mailing list posts as spam than follow the > unsubscribe process. One problem is that mail readers often make it much easier to tag something as spam then to use the RFC 2369 header to actually present a button to unsubscribe. If David Ascher is at PyCon, I'm going to bribe him to add this to Thunderbird by default. :) - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfPK60ACgkQ2YZpQepbvXHZ4ACdFHvkne4N32PYodeGTl/fZWwX cocAnip/mx1edhJP7c2BlgVQdyJ/V5z8 =moTw -----END PGP SIGNATURE----- From barry at list.org Thu Mar 6 00:36:54 2008 From: barry at list.org (Barry Warsaw) Date: Wed, 5 Mar 2008 18:36:54 -0500 Subject: [Mailman-Developers] 2008 Pizzigati Prize Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I realize that I've been remiss in announcing this. My apologies. I have been awarded the 2008 Pizzigati Prize for Public Interest Computing for GNU Mailman. http://www.pizzigatiprize.org/ I am deeply honored to win this prize because I believe very strongly in Mailman's role in helping people communicate and organize. I want to thank all of you who have supported me and Mailman over the years, and I want to let you know that I am as excited as ever about where Mailman is going. One of the most satisfying aspects of this project for me has been meeting you, the users, developers and contributors to Mailman, both online and face-to-face. I'm looking forward to meeting the Pizzigati family and having some time to spend with them learning about Anthony's remarkable life, sadly cut too short. So again, thank you all and I'm looking forward to the next 10 years of GNU Mailman! Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfPLpcACgkQ2YZpQepbvXGgwwCbB/PjbX7rSiI0xwKjJ7jPpjgJ kuMAoIfeC0j0+4f8l0GEOp2gYc7a+8MI =Y7nZ -----END PGP SIGNATURE----- From terri at zone12.com Thu Mar 6 04:15:36 2008 From: terri at zone12.com (Terri Oda) Date: Wed, 5 Mar 2008 22:15:36 -0500 Subject: [Mailman-Developers] 1-click unsubscribe In-Reply-To: <20080304161558.GA5791@garp.metalab.unc.edu> References: <47CB7F07.5050800@thecsl.org> <20080304161558.GA5791@garp.metalab.unc.edu> Message-ID: On 4-Mar-08, at 11:15 AM, Crist?bal Palmer wrote: > IMHO, moving the "unsubscribe or edit options" to the top of the > listinfo page or making it its own page by default would go a long way > towards alleviating this problem. +1 Most of my problems went away when I changed it so "unsubscribe" was on the button (it used to be just "edit options" and boy, that was fun), but I'm sure we can make this page more useable. We actually already have a separate page, that's just not linked: try looking at the options page without an email address and it's almost exactly what users would probably want: http://mail.python.org/mailman/options/mailman-developers Maybe we should just advertise that link more heavily somehow? I think that's the page most subscribers *actually* want, so maybe that's the one that should appear in the default footers? I've actually had the weird but insightful opportunity to watch other people use mailman because I'm maintaining an installation at the university, and I've been learning a lot about the web interface that I didn't realise... it's been very interesting, since I had never been anywhere near my subscribers and list admins before. Terri From mark at msapiro.net Thu Mar 6 05:25:49 2008 From: mark at msapiro.net (Mark Sapiro) Date: Wed, 05 Mar 2008 20:25:49 -0800 Subject: [Mailman-Developers] 1-click unsubscribe In-Reply-To: References: <47CB7F07.5050800@thecsl.org> <20080304161558.GA5791@garp.metalab.unc.edu> Message-ID: <47CF724D.3090000@msapiro.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Terri Oda wrote: | We actually | already have a separate page, that's just not linked: try looking at | the options page without an email address and it's almost exactly | what users would probably want: | | http://mail.python.org/mailman/options/mailman-developers Any objections to changing the URL in the RFC 2369 List-Unsubscribe: header to the above - for 2.1.10? I could probably also suppress the "Error: No address given" message unless you came from options login page itself. - -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFHz3JNVVuXXpU7hpMRAgXsAJ4wgNI18bNWPC5fZC+gLml8x5BnzgCg8ZLd 2O9ry0MZtB+MEJg1gvh451Y= =BMHU -----END PGP SIGNATURE----- From barry at list.org Thu Mar 6 05:33:18 2008 From: barry at list.org (Barry Warsaw) Date: Wed, 5 Mar 2008 23:33:18 -0500 Subject: [Mailman-Developers] 1-click unsubscribe In-Reply-To: <47CF724D.3090000@msapiro.net> References: <47CB7F07.5050800@thecsl.org> <20080304161558.GA5791@garp.metalab.unc.edu> <47CF724D.3090000@msapiro.net> Message-ID: <27DD1426-4F83-4724-AA7C-FB3980E4C041@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 5, 2008, at 11:25 PM, Mark Sapiro wrote: > Any objections to changing the URL in the RFC 2369 List-Unsubscribe: > header to the above - for 2.1.10? I could probably also suppress the > "Error: No address given" message unless you came from options login > page itself. I only wonder though if it'll be frustrating or confusing that a user will have to enter their email address in the section above that button? OTOH, this page does make a better landing for the List- Unsubscribe header than the listinfo page. +1 - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfPdA8ACgkQ2YZpQepbvXF1iwCfQBtdnXQ8Fw5hVZ8fvLIke/iY 96MAn07jUbR9QRBQDI/+WnOxBJ4qMr5i =5wzM -----END PGP SIGNATURE----- From terri at zone12.com Thu Mar 6 09:20:29 2008 From: terri at zone12.com (Terri Oda) Date: Thu, 6 Mar 2008 03:20:29 -0500 Subject: [Mailman-Developers] Documentation status? In-Reply-To: <2CC52649-9F17-4079-8B14-BA54AF2C8DD4@list.org> References: <20080305195338.GA12322@amk-desktop.matrixgroup.net> <8D5D8DBD-D3C8-4C52-93E0-94A09226AD7A@zone12.com> <2CC52649-9F17-4079-8B14-BA54AF2C8DD4@list.org> Message-ID: <129A3B16-0505-4A12-A673-87E61CDDD98C@zone12.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5-Mar-08, at 5:26 PM, Barry Warsaw wrote: > I like having docs in the wiki because it lets more people > contribute. The downside is that you can't reach it when you're > offline and it's harder to publish in alternative media. Have you > thought at all about how to handle that? I've actually thought about it a fair bit! I also like the wiki 'cause it's easier for other people to contribute (because I like to believe that I'm not the only person in the world who wants to write extensive Mailman documentation ;) ), and I'm particularly fond of the wiki we're using on wiki.list.org because of the way it outputs. PDF: One of the things I really like about the Confluence wiki software is that it does a pdf export. I was *shocked* by how many people want to print mailman documentation but apparently that pdf appeals to a lot of people (I used to get more mail about that format than any other). I noticed today that the pdf export isn't available if you're not logged in, though. Can we change that? I didn't see it offhand in the settings, but I admit I haven't looked very hard yet. I really think people will use it if they know it's there. HTML: What *is* available even if you're not logged in, though, is a nice printable version of the HTML. We could probably make a plain text version from this, although I'm unconvinced anyone would care except in a theoretical way. ;) Are there other formats that would be useful? When people emailed me and mentioned format, they were almost all using PDF or HTML, so I assume those are the most important ones. Printed hard copies: I've been putting the manuals into big wiki documents rather than splitting them up -- easier for those who want a printout to get it in a go. (The appendices are separate 'cause I didn't think most people would want them, and those who did would probably want them separate.) They can print as pdf or as html, as per their preferences, or import the HTML into something and repaginate however they like. I haven't actually tried this, but it really is nice html output. :) Including the docs with releases?: The HTML output is nice enough that I think we could consider snapshotting the documentation and putting it with each release as HTML. I think the Members Manual is worth including particularly because so many people have it on their sites for their users already. Plus, with a couple of search and replaces, you can customize the whole thing for your site, or even for a specific list, which can be very handy for certain types of users. I'm hoping the List Administrators Manual will be worth including when it's done, too, as well as the as of yet unwritten Site Administrators Manual.... but maybe I'm getting ahead of myself. Still, I think we'd do well to include some of this with the release. I will even volunteer to proofread the wiki output for each release. (I edited a magazine for years, I can probably handle this.) Doc licensing: I periodically get emails asking about the license on the documentation. I kinda assume it's all GPL (I can sign another copyright form for them if you need me to, Barry.), and that makes most sense if we want to include them. If everyone's okay with that, we should maybe put a note to that effect so I don't have to keep telling people "Please, take it and do anything you want with it! I like people using mailman, and if my docs help you do that, use them any way you need to!" Or, hrm, maybe I'll just put that in the docs and it'll get the point across. :) Other docs I want to see in the wiki: In my perfect world, I'd like to see us port all of our FAQ items to the documentation part of the wiki, so all of these things could be found in one place and thus easily searchable in one go. Any volunteers? Easy job, just a bit time-consuming, and a bit of thought needs to be put into how best to organize things. My guess is make them all children of an FAQ page so they're automatically indexed, but keep things one-question-per-page since it's unlikely that anyone'll ever want to print the entire FAQ. Similarly, installation docs, things like the backscatter information... all should be in one place. I was trying to explain to one of my department sysadmins where to find mailman help, and it was *embarrassing* when I started listing off the docs I wrote, the FAQ Wizard, the mailing lists, the help files included with the installation, the FAQ on list.org... really, I'd like to see a one- stop shop for documentation, and I think the wiki is the best choice (because more people can contribute!), with us exporting the bits that are useful to go with each release. I periodically try to coerce my little sister to import everything into the wiki for me, but she is strangely resistant to my offer of cookies in exchange for mind-numbing work. ;) But it is a pretty easy job with a script and some time to sanity-check the results, if anyone's got some time and interest. As added incentive, the offer of fresh cookies is open to anyone, not just my sister. I'll mail them out to any address you like, although obviously I can't guarantee that they'll be quite as fresh by the time you get 'em. ;) Finally: Jeez, what an essay. I could have written something explaining all the general list administration options in the time it took me to type this. Whoops. sorry! Terri -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHz6lNYWvHDqWmQaoRAplHAJ9aJMOxm5HR+nbQOgtrvddzcoeP2wCfUvJK lkwPNP+s0kRm0aHRLgHMTYU= =Bq22 -----END PGP SIGNATURE----- From cmpalmer at metalab.unc.edu Thu Mar 6 17:45:12 2008 From: cmpalmer at metalab.unc.edu (=?iso-8859-1?Q?Crist=F3bal?= Palmer) Date: Thu, 6 Mar 2008 11:45:12 -0500 Subject: [Mailman-Developers] 1-click unsubscribe In-Reply-To: <47CF724D.3090000@msapiro.net> References: <47CB7F07.5050800@thecsl.org> <20080304161558.GA5791@garp.metalab.unc.edu> <47CF724D.3090000@msapiro.net> Message-ID: <20080306164512.GO5749@garp.metalab.unc.edu> On Wed, Mar 05, 2008 at 08:25:49PM -0800, Mark Sapiro wrote: > Any objections to changing the URL in the RFC 2369 List-Unsubscribe: > header to the above - for 2.1.10? I could probably also suppress the > "Error: No address given" message unless you came from options login > page itself. I like this. +1 Cheers, -- Crist?bal Palmer ibiblio.org systems administrator From iane at sussex.ac.uk Thu Mar 6 18:04:00 2008 From: iane at sussex.ac.uk (Ian Eiloart) Date: Thu, 06 Mar 2008 17:04:00 +0000 Subject: [Mailman-Developers] Web UI redux Message-ID: <0B51AED7C4C9B1F3697B05A7@lewes.staff.uscs.susx.ac.uk> --On 4 March 2008 17:57:42 -0500 Ethan Fremen wrote: > Hiya! > > After an embarrassingly long absence, I am going to try again to make > some progress on the web ui front. > > Barry said in an earlier message that there's no web UI for mm3: my > first impulse is to start on something there. > > I was humbled enough by my first experience trying to make progress on > this that I will happily start with anything that y'all think is "low > hanging fruit" just so I can get something committed that can actually > be used. a) There was mention that an archive browser is required. b) An easy way for list members to unsubscribe is a legal requirement here in the UK, so that should should also be a priority. The current mechanism is *way* too complicated (even though it probably looks fairly simple to most of us). It needs (a) a simple form where I can enter my email address, and click unsubscribe so that I'm then emailed a verification link, and (b) a confirmation page as the target of that link, which (a) tells me that I'm unsubscribed, (b) allows me to optionally suspend mailings instead, (c) gives me some way to see what other lists I'm subscribed to, perhaps with the option to apply settings to all of them. It should also be very simple to apply site specific page headers, footers and styles. c) List subscription, with captchas, would be useful. Simple option management would also be good: daily digests, d) Simple list management: perhaps with styles "announcement only", "closed discussion", "open discussion". Subscribe (by invitation, with notification, no notification), and unsubscribe). > Thanks, > > ~ethan fremen > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py > Searchable Archives: > http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: > http://mail.python.org/mailman/options/mailman-developers/iane%40sussex.a > c.uk > > Security Policy: > http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp -- Ian Eiloart IT Services, University of Sussex x3148 From iane at sussex.ac.uk Thu Mar 6 18:30:09 2008 From: iane at sussex.ac.uk (Ian Eiloart) Date: Thu, 06 Mar 2008 17:30:09 +0000 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <09FAB6B0-3474-4DF5-9658-F2FB7BADAB07@list.org> References: <0C4F5F7D-CB5D-4CE7-8C54-872413A44D36@netconsonance.com> <7AFBB02ED4F7081C33A84D37@lewes.staff.uscs.susx.ac.uk> <09FAB6B0-3474-4DF5-9658-F2FB7BADAB07@list.org> Message-ID: --On 5 March 2008 18:08:39 -0500 Barry Warsaw wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mar 5, 2008, at 5:33 AM, Ian Eiloart wrote: > >> The one reason that I'm looking for an alternative to Mailman is the >> lack >> of adequate integration with MTAs, which means that there is no >> sensible >> thing that I can do with suspected spam. What I need to be able to >> do is >> reject it at SMTP time, based on list post permissions and other >> configuations - I need to be able to query the configuration from my >> MTA >> (Exim). > > Ian, I think that alternative is going to be Mailman 3 :). > > How do you see Exim asking that question? I can see several ways of > doing it in Mailman 3. 1) you could call into a Python library that can > answer that question; That's doable, with a perl wrapper around a python script. The question I'd want to ask is "is email address a allowed to post to list b". > 2) you could use some kind of RPC such as the REST > api that Andrew's been talking about; I'm not sure whether I could use that from Exim. > 3) you could make the appropriate > queries directly to the Mailman database, which is based on SQLite > currently but can be anything that Storm can talk to. That's probably the most desirable option from the point of view of efficiency, but I'd need to be querying a database remotely. Preferably one with several replicas. Would LDAP be an option? That's what we currently use for our user authentication. Hmm, doesn't look like it. I guess I could knock up a postgres cluster. The disadvantage of this over (1) is that I'd need to replicate Mailman's logic in the SQL query. > Is that the kind of thing you want to do? The ideal thing would be if Mailman had an LMTP interface to accept postings, and could make decisions about accepting mail after RCTP TO. That way, Exim could make LMTP callouts to Mailman (effectively, the HELO, MAIL FROM and RCPT TO sections of the L/SMTP protocol). If Mailman says, yes I'll accept this message for delivery, then Exim can continue. Mailman might later reject a message based on other information, like attachment size, but at that point I don't mind bouncing the message. In fact, for list members bouncing is better than rejection because I can determine what I'm going to say. > - -Barry > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > > iEYEARECAAYFAkfPJ/gACgkQ2YZpQepbvXEQNgCfQqZlZIt6kFyb+2MrQcteth1j > q/8AnRqG8QjGqwBR0y/IQpFZMxBeiupW > =eR4z > -----END PGP SIGNATURE----- -- Ian Eiloart IT Services, University of Sussex x3148 From iane at sussex.ac.uk Thu Mar 6 18:51:26 2008 From: iane at sussex.ac.uk (Ian Eiloart) Date: Thu, 06 Mar 2008 17:51:26 +0000 Subject: [Mailman-Developers] 1-click unsubscribe In-Reply-To: <2AC8E914-16AE-4D08-A24F-D07DF149E981@list.org> References: <3E27E105-5319-49F0-9554-63BCCA96E0BC@list.org> <87wspggpk2.fsf@uwakimon.sk.tsukuba.ac.jp> <873as2oj5o.fsf@uwakimon.sk.tsukuba.ac.jp> <87y792kj99.fsf@uwakimon.sk.tsukuba.ac.jp> <47CB3247.2000406@thecsl.org> <2AC8E914-16AE-4D08-A24F-D07DF149E981@list.org> Message-ID: <919E8414B34C863C210FE637@lewes.staff.uscs.susx.ac.uk> --On 5 March 2008 18:16:53 -0500 Barry Warsaw wrote: > > I generally don't like 1-click unsubs but I recognize that this is an > important use case in the real world, and it's probably better to have > the risk of people getting unsub'd against their will than to have the > entire site get blacklisted from AOL because of a cluser. So, a 1-click unsub is a link in the message footer which takes you to a page that says something like "You've unsubscribed from our list, sorry to see you go"? Well, if the subscriber accidentally clicked that link, then an "oops" button on the page might get them back in. If someone else clicked the link after the email was forwarded to them, then a farewell email to the subscriber, with a one-click resubscribe might help. A note on unsubscription: I manage a few lists for small voluntary organisations, and for us it is REALLY important to be able to avoid re-subscribing someone who has unsubscribed themselves. Therefore, it would be better to set their preferences to no-mail, rather than simply delete their records. Also useful to record the date and the fact that it was the subscriber who opted out. A note on small organisations: we have members that don't have email. It would be great to be able to record their postal addresses in some form that could easily be printed to envelope labels. Or, their phone numbers. So that they can also be notified of important events. This would be incredibly useful to small community organisations. -- Ian Eiloart IT Services, University of Sussex x3148 From barry at list.org Thu Mar 6 19:02:01 2008 From: barry at list.org (Barry Warsaw) Date: Thu, 6 Mar 2008 13:02:01 -0500 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: References: <0C4F5F7D-CB5D-4CE7-8C54-872413A44D36@netconsonance.com> <7AFBB02ED4F7081C33A84D37@lewes.staff.uscs.susx.ac.uk> <09FAB6B0-3474-4DF5-9658-F2FB7BADAB07@list.org> Message-ID: <0CBDE11E-84B0-47AA-B8FE-E9DF88463BEF@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 6, 2008, at 12:30 PM, Ian Eiloart wrote: > That's probably the most desirable option from the point of view of > efficiency, but I'd need to be querying a database remotely. > Preferably one with several replicas. Would LDAP be an option? > That's what we currently use for our user authentication. Hmm, > doesn't look like it. I guess I could knock up a postgres cluster. Theoretically, you would be able to implement different backends for the appropriate interfaces so that some of the data comes out of LDAP, but I haven't gotten that far yet. > The ideal thing would be if Mailman had an LMTP interface to accept > postings, and could make decisions about accepting mail after RCTP TO. MM3 will have LMTP, perhaps as the preferred way to get messages into the incoming queue. I hadn't thought about doing acceptance testing right there, but it's an interesting idea to think about. Thanks! - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfQMZoACgkQ2YZpQepbvXFQNgCgkdfp1UUwsbIDaOis+CHqGpSB 2qUAoJ54l5pVMlclzAPgX/D0WGOydfK8 =38Lj -----END PGP SIGNATURE----- From ACrosman at afsc.org Thu Mar 6 19:02:00 2008 From: ACrosman at afsc.org (Aaron Crosman) Date: Thu, 6 Mar 2008 13:02:00 -0500 Subject: [Mailman-Developers] 1-click unsubscribe In-Reply-To: <919E8414B34C863C210FE637@lewes.staff.uscs.susx.ac.uk> References: <3E27E105-5319-49F0-9554-63BCCA96E0BC@list.org><87wspggpk2.fsf@uwakimon.sk.tsukuba.ac.jp><873as2oj5o.fsf@uwakimon.sk.tsukuba.ac.jp><87y792kj99.fsf@uwakimon.sk.tsukuba.ac.jp> <47CB3247.2000406@thecsl.org><2AC8E914-16AE-4D08-A24F-D07DF149E981@list.org> <919E8414B34C863C210FE637@lewes.staff.uscs.susx.ac.uk> Message-ID: -----Original Message----- From: mailman-developers-bounces+acrosman=afsc.org at python.org [mailto:mailman-developers-bounces+acrosman=afsc.org at python.org] On Behalf Of Ian Eiloart Sent: Thursday, March 06, 2008 12:51 PM To: Barry Warsaw; Dan MacNeil Cc: Mailman Developers; Stephen J. Turnbull Subject: Re: [Mailman-Developers] 1-click unsubscribe A note on unsubscription: I manage a few lists for small voluntary organisations, and for us it is REALLY important to be able to avoid re-subscribing someone who has unsubscribed themselves. Therefore, it would be better to set their preferences to no-mail, rather than simply delete their records. Also useful to record the date and the fact that it was the subscriber who opted out. A note on small organisations: we have members that don't have email. It would be great to be able to record their postal addresses in some form that could easily be printed to envelope labels. Or, their phone numbers. So that they can also be notified of important events. This would be incredibly useful to small community organisations. 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). I'd like to see Mailman improve support for newsletter style setups, which is sounds like is gaining momentum, but getting into full address information should be left to proper CRM solutions. It would be a long time until Mailman could do the other functions of a CRM well-enough for them to be a good idea for anyone to use. Aaron From mark at msapiro.net Thu Mar 6 19:28:33 2008 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 06 Mar 2008 10:28:33 -0800 Subject: [Mailman-Developers] 2008 Pizzigati Prize In-Reply-To: References: Message-ID: <47D037D1.8030803@msapiro.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Barry Warsaw wrote: | | I have been awarded the 2008 Pizzigati Prize for Public Interest | Computing for GNU Mailman. | | http://www.pizzigatiprize.org/ That's Awesome! I'm extremely happy to be associated with this project. - -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFH0DfRVVuXXpU7hpMRAqXfAJ9Acp63irwuxjheLuvTfQWZD+tqWACdGXs6 fDzTCJL3rFvE1LfvvbhT1KI= =umQE -----END PGP SIGNATURE----- From stephen at xemacs.org Thu Mar 6 20:38:27 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 07 Mar 2008 04:38:27 +0900 Subject: [Mailman-Developers] 1-click unsubscribe In-Reply-To: References: <3E27E105-5319-49F0-9554-63BCCA96E0BC@list.org> <87wspggpk2.fsf@uwakimon.sk.tsukuba.ac.jp> <873as2oj5o.fsf@uwakimon.sk.tsukuba.ac.jp> <87y792kj99.fsf@uwakimon.sk.tsukuba.ac.jp> <47CB3247.2000406@thecsl.org> <2AC8E914-16AE-4D08-A24F-D07DF149E981@list.org> <919E8414B34C863C210FE637@lewes.staff.uscs.susx.ac.uk> Message-ID: <877igfve18.fsf@uwakimon.sk.tsukuba.ac.jp> 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 of one-stop subscription management for multiple-list subscribers. The specific attributes Ian requests leave me cold, too, but I have my own idiosyncratic attributes I'd like to be able to query from the subscriber database. Fortunately, what Barry has proposed is an architecture that makes it easy to do these things. (If Barry chooses to work on Ian's requests in the spirit of a Pizzigati Laureate -- congratulations, Barry! -- that's fine by me; I'm happy to contribute by taking care of my own needs.) > It would be a long time until Mailman could do the other functions > of a CRM well-enough for them to be a good idea for anyone to use. That's not the direction Barry's going AIUI. What would be nice is a way for "CRM solutions" to take care of the subscriber db and contact scheduling while Mailman lives up to its name by taking care of delivery. Then Mailman would provide a default "CRM solution" plug-in which handles *only* the "customer" attributes relevant to subscriptions, ie, name, email, notmetoo, nodupes, nomail, etc. This would provide the same functions that are currently integrated in the Mailman core. See also the posts regarding "RESTful interfaces." In other words, from the CRM point of view there would be a message injection API into Mailman, an optional bidirectional API for Mailman to request and update subscriber information from the CRM, and an optional API for the CRM to handle db updates on behalf of Mailman. I think this is what Barry has in mind, although he probably can explain it better. From shiva at sewingwitch.com Thu Mar 6 20:34:01 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 06 Mar 2008 11:34:01 -0800 Subject: [Mailman-Developers] SEC wiki space (was: before next release: disable backscatter indefault installation) In-Reply-To: References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <149F2B51AFE41E1F9ABB7D31@[10.169.6.155]> On Wednesday, March 05, 2008 5:54 PM -0500 Barry Warsaw wrote: > Mark's the release manager for 2.1, but FWIW I completely agree with > Stephen about this. What I would suggest though is that this > information be put in a prominent place on the wiki. We have a > security space with nothing substantial in it, so I suggest we put it > here. > > http://wiki.list.org/display/SEC/Home This appears to be a read-only space. The add page link on the dashboard is grey and there's no Edit tab on the main page. From shiva at sewingwitch.com Thu Mar 6 20:13:31 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 06 Mar 2008 11:13:31 -0800 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: References: Message-ID: <46943F5EA82CA7EE31E8DEF2@[10.169.6.155]> On Tuesday, March 04, 2008 12:30 PM -0800 Jo Rhett wrote: > 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by > default. Nearly everyone uses web based signup. > > 2. Discard or hold messages from non-subscribers by default. How, exactly, does one do these? In particular, how do you remove the aliases when using mm-handler to process mail from sendmail? (I'd be happy to start the wiki page once I have the information to put there.) From mark at msapiro.net Thu Mar 6 21:47:52 2008 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 6 Mar 2008 12:47:52 -0800 Subject: [Mailman-Developers] SEC wiki space (was: before next release:disable backscatter indefault installation) In-Reply-To: <149F2B51AFE41E1F9ABB7D31@[10.169.6.155]> Message-ID: Kenneth Porter wrote: >On Wednesday, March 05, 2008 5:54 PM -0500 Barry Warsaw >wrote: > >> [...] We have a >> security space with nothing substantial in it, so I suggest we put it >> here. >> >> http://wiki.list.org/display/SEC/Home > >This appears to be a read-only space. The add page link on the dashboard is >grey and there's no Edit tab on the main page. Did you 'Sign Up' and/or 'Log In'? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From nigel.metheringham at dev.intechnology.co.uk Thu Mar 6 20:43:04 2008 From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Thu, 6 Mar 2008 19:43:04 +0000 Subject: [Mailman-Developers] 1-click unsubscribe In-Reply-To: <919E8414B34C863C210FE637@lewes.staff.uscs.susx.ac.uk> References: <3E27E105-5319-49F0-9554-63BCCA96E0BC@list.org> <87wspggpk2.fsf@uwakimon.sk.tsukuba.ac.jp> <873as2oj5o.fsf@uwakimon.sk.tsukuba.ac.jp> <87y792kj99.fsf@uwakimon.sk.tsukuba.ac.jp> <47CB3247.2000406@thecsl.org> <2AC8E914-16AE-4D08-A24F-D07DF149E981@list.org> <919E8414B34C863C210FE637@lewes.staff.uscs.susx.ac.uk> Message-ID: On 6 Mar 2008, at 17:51, Ian Eiloart wrote: > So, a 1-click unsub is a link in the message footer which takes you > to a > page that says something like "You've unsubscribed from our list, > sorry to > see you go"? So its an HTTP GET - which is supposed to be idempotent. I know a while back there was discussion of SpamAssassin modules which evaluated linked webpages for spamminess - presumably that action would clear someone off the list too! Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.com ] [ - Comments in this message are my own and not ITO opinion/policy - ] From shiva at sewingwitch.com Thu Mar 6 22:09:57 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 06 Mar 2008 13:09:57 -0800 Subject: [Mailman-Developers] Per-user subject prefix setting Message-ID: A frequent request on mailing lists without a subject prefix is to add one. This often leads to long debate threads about the utility of the prefix. There seems to be two different styles of processing mail that leads to this conflict. One style (which I use) is to filter mail into many folders, one per list. No tag is needed in this case. The other style is to dump all mail into one or a small number of folders, and in this style one needs to tag to know which list a message belongs to. This has been captured in this feature request: There seems to be limited code for customizing messages per-user, but this setting may want to be treated as some kind of user "class" setting so that messages can still be batched for the no-prefix class and the add-prefix class. Perhaps this could be implemented as two distinct queues, similar to the way digests are treated as a distinct queue. From shiva at sewingwitch.com Thu Mar 6 22:13:21 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 06 Mar 2008 13:13:21 -0800 Subject: [Mailman-Developers] SEC wiki space (was: before next release:disable backscatter indefault installation) In-Reply-To: References: Message-ID: <3B35FA715E7699B318671983@[10.169.6.155]> On Thursday, March 06, 2008 12:47 PM -0800 Mark Sapiro wrote: >>> http://wiki.list.org/display/SEC/Home >> >> This appears to be a read-only space. The add page link on the dashboard >> is grey and there's no Edit tab on the main page. > > > Did you 'Sign Up' and/or 'Log In'? Yep, I created a login and see the Log Out link at top. The COM, DEV, and DOC sections are editable. SEC is not. I expected that the other 3 spaces are only editable when one has a login and thought perhaps SEC had been created with some kind of special group requirement, to keep crackers from seeing exploitable issues before a fix was available. From mark at msapiro.net Thu Mar 6 22:44:06 2008 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 6 Mar 2008 13:44:06 -0800 Subject: [Mailman-Developers] SEC wiki space (was: before nextrelease:disable backscatter indefault installation) In-Reply-To: <3B35FA715E7699B318671983@[10.169.6.155]> Message-ID: Kenneth Porter wrote: > >Yep, I created a login and see the Log Out link at top. The COM, DEV, and >DOC sections are editable. SEC is not. > >I expected that the other 3 spaces are only editable when one has a login >and thought perhaps SEC had been created with some kind of special group >requirement, to keep crackers from seeing exploitable issues before a fix >was available. You are correct. My bad. since I am a member of a special group (not special enough to change Space Permissions though), I created a non-special user to see if it could add/edit pages. Foolishly, I then just went to a few pages to see if I had an edit tab, but I didn't actually go to the SEC page. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From dgc at uchicago.edu Thu Mar 6 23:02:14 2008 From: dgc at uchicago.edu (David Champion) Date: Thu, 6 Mar 2008 16:02:14 -0600 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: <46943F5EA82CA7EE31E8DEF2@[10.169.6.155]> References: <46943F5EA82CA7EE31E8DEF2@[10.169.6.155]> Message-ID: <20080306220214.GH10751@monkey.uchicago.edu> > > 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by > > default. Nearly everyone uses web based signup. > > How, exactly, does one do these? In particular, how do you remove the > aliases when using mm-handler to process mail from sendmail? (I'd be happy > to start the wiki page once I have the information to put there.) This cannot be done simply with the current version of mm-handler in contrib -- it requires several code changes and would affect all actions for . That would have bad effects on VERP bounce handling, for example. Here is an update to mm-handler which might address this adequately. I no longer use mm-handler myself (despite having written it), so I can't test this short of installing a new Mailman instance. Can someone on the list test it? http://home.uchicago.edu/~dgc/sw/mailman/mm-handler/mm-handler-2.10 Since it's contrib and not supported, maybe it would be reasonable to put the update into the 2.1.10 release -- provided someone can declare that it works. :) Otherwise feel free to post it on the wiki. -- -D. dgc at uchicago.edu NSIT University of Chicago From shiva at sewingwitch.com Fri Mar 7 00:35:54 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 06 Mar 2008 15:35:54 -0800 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: <20080306220214.GH10751@monkey.uchicago.edu> References: <46943F5EA82CA7EE31E8DEF2@[10.169.6.155]> <20080306220214.GH10751@monkey.uchicago.edu> Message-ID: <8DE7EFBC3447E09D99A70436@[10.169.6.155]> On Thursday, March 06, 2008 4:02 PM -0600 David Champion wrote: > Here is an update to mm-handler which might address this adequately. I > no longer use mm-handler myself (despite having written it), so I can't > test this short of installing a new Mailman instance. Can someone on > the list test it? > > http://home.uchicago.edu/~dgc/sw/mailman/mm-handler/mm-handler-2.10 > > Since it's contrib and not supported, maybe it would be reasonable to > put the update into the 2.1.10 release -- provided someone can declare > that it works. :) Otherwise feel free to post it on the wiki. I'll give it a shot. Question about the backscatter settings: # Prevent backscatter for unapproved actions? $BounceUnapproved = 0; # Prevent backscatter for undefined lists? $BounceNonlist = 1; The comment seems to be logically backwards from the variable name. Should it really read "allow", not "prevent"? Does 0 or 1 mean backscatter? From dgc at uchicago.edu Fri Mar 7 00:39:54 2008 From: dgc at uchicago.edu (David Champion) Date: Thu, 6 Mar 2008 17:39:54 -0600 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: <8DE7EFBC3447E09D99A70436@[10.169.6.155]> References: <46943F5EA82CA7EE31E8DEF2@[10.169.6.155]> <20080306220214.GH10751@monkey.uchicago.edu> <8DE7EFBC3447E09D99A70436@[10.169.6.155]> Message-ID: <20080306233954.GI10751@monkey.uchicago.edu> > # Prevent backscatter for unapproved actions? > $BounceUnapproved = 0; > > # Prevent backscatter for undefined lists? > $BounceNonlist = 1; > > The comment seems to be logically backwards from the variable name. Should > it really read "allow", not "prevent"? Does 0 or 1 mean backscatter? Good point. 1 means to bou^H^H^Hbackscatter. The comments should be adjusted. -- -D. dgc at uchicago.edu NSIT University of Chicago From barry at list.org Fri Mar 7 03:03:45 2008 From: barry at list.org (Barry Warsaw) Date: Thu, 6 Mar 2008 21:03:45 -0500 Subject: [Mailman-Developers] SEC wiki space (was: before next release: disable backscatter indefault installation) In-Reply-To: <149F2B51AFE41E1F9ABB7D31@[10.169.6.155]> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <149F2B51AFE41E1F9ABB7D31@[10.169.6.155]> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 6, 2008, at 2:34 PM, Kenneth Porter wrote: > On Wednesday, March 05, 2008 5:54 PM -0500 Barry Warsaw > > wrote: > >> Mark's the release manager for 2.1, but FWIW I completely agree with >> Stephen about this. What I would suggest though is that this >> information be put in a prominent place on the wiki. We have a >> security space with nothing substantial in it, so I suggest we put it >> here. >> >> http://wiki.list.org/display/SEC/Home > > This appears to be a read-only space. The add page link on the > dashboard is > grey and there's no Edit tab on the main page. Try it now. At one point I thought the entire space should be write restricted to just the core developers, but I think that's misguided. I've opened up the permissions and we can lock specific pages if/when we find that necessary. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfQooIACgkQ2YZpQepbvXEqKACeN1ZIpkSt3wmRBHwc5AMXbMY8 qnIAoIiUvQl8BbYyq0hxE4j4fbNOs75a =etSR -----END PGP SIGNATURE----- From japruim at raoset.com Thu Mar 6 20:18:07 2008 From: japruim at raoset.com (Jason Pruim) Date: Thu, 6 Mar 2008 14:18:07 -0500 Subject: [Mailman-Developers] Documentation status? In-Reply-To: <129A3B16-0505-4A12-A673-87E61CDDD98C@zone12.com> References: <20080305195338.GA12322@amk-desktop.matrixgroup.net> <8D5D8DBD-D3C8-4C52-93E0-94A09226AD7A@zone12.com> <2CC52649-9F17-4079-8B14-BA54AF2C8DD4@list.org> <129A3B16-0505-4A12-A673-87E61CDDD98C@zone12.com> Message-ID: <4BD7F651-32F0-43DB-872E-F0355FBF82CA@raoset.com> On Mar 6, 2008, at 3:20 AM, Terri Oda wrote: > > > Other docs I want to see in the wiki: > > In my perfect world, I'd like to see us port all of our FAQ items to > the documentation part of the wiki, so all of these things could be > found in one place and thus easily searchable in one go. Any > volunteers? Easy job, just a bit time-consuming, and a bit of > thought needs to be put into how best to organize things. My guess > is make them all children of an FAQ page so they're automatically > indexed, but keep things one-question-per-page since it's unlikely > that anyone'll ever want to print the entire FAQ. > > Similarly, installation docs, things like the backscatter > information... all should be in one place. I was trying to explain > to one of my department sysadmins where to find mailman help, and it > was *embarrassing* when I started listing off the docs I wrote, the > FAQ Wizard, the mailing lists, the help files included with the > installation, the FAQ on list.org... really, I'd like to see a one- > stop shop for documentation, and I think the wiki is the best choice > (because more people can contribute!), with us exporting the bits > that are useful to go with each release. > > I periodically try to coerce my little sister to import everything > into the wiki for me, but she is strangely resistant to my offer of > cookies in exchange for mind-numbing work. ;) But it is a pretty > easy job with a script and some time to sanity-check the results, if > anyone's got some time and interest. As added incentive, the offer > of fresh cookies is open to anyone, not just my sister. I'll mail > them out to any address you like, although obviously I can't > guarantee that they'll be quite as fresh by the time you get 'em. ;) Hi Terri, I've been watching this thread with interest and would like to help where I can... I don't know Python, so I can't exactly help program, but I've been told I can translate technological info into something the normal person could understand. So what do I have to do to start helping? :) I have some nights/weekends free and I usually try and fill those with paying work, but need some good karma to go with my money! :) Besides, I love Mailman... Best mailing list software I've used! So let me know where I can help! Thanks! -- Jason Pruim Raoset Inc. Technology Manager MQC Specialist 3251 132nd ave Holland, MI, 49424-9337 www.raoset.com japruim at raoset.com From shiva at sewingwitch.com Fri Mar 7 14:44:21 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 07 Mar 2008 05:44:21 -0800 Subject: [Mailman-Developers] SEC wiki space, Confluence via Seamonkey In-Reply-To: References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <149F2B51AFE41E1F9ABB7D31@[10.169.6.155]> Message-ID: <3C67139F6D397E827425D4BE@[10.0.0.14]> --On Thursday, March 06, 2008 9:03 PM -0500 Barry Warsaw wrote: > Try it now. At one point I thought the entire space should be write > restricted to just the core developers, but I think that's misguided. > I've opened up the permissions and we can lock specific pages if/when we > find that necessary. I can edit it now. Using Mozilla Seamonkey, the Rich Text tab shows a tiny edit window with what looks like HTML to edit. The Wiki Markup tab gives me a Page Not Found. Does Confluence work well with Firefox? Seamonkey should behave nearly identically but some browser detectors get confused by it. From barry at list.org Fri Mar 7 15:16:54 2008 From: barry at list.org (Barry Warsaw) Date: Fri, 7 Mar 2008 09:16:54 -0500 Subject: [Mailman-Developers] SEC wiki space, Confluence via Seamonkey In-Reply-To: <3C67139F6D397E827425D4BE@[10.0.0.14]> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <149F2B51AFE41E1F9ABB7D31@[10.169.6.155]> <3C67139F6D397E827425D4BE@[10.0.0.14]> Message-ID: <982C5C7E-838F-4CFB-845E-65CD26F85D69@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 7, 2008, at 8:44 AM, Kenneth Porter wrote: > --On Thursday, March 06, 2008 9:03 PM -0500 Barry Warsaw > > wrote: > >> Try it now. At one point I thought the entire space should be write >> restricted to just the core developers, but I think that's misguided. >> I've opened up the permissions and we can lock specific pages if/ >> when we >> find that necessary. > > I can edit it now. > > Using Mozilla Seamonkey, the Rich Text tab shows a tiny edit window > with > what looks like HTML to edit. The Wiki Markup tab gives me a Page Not > Found. Does Confluence work well with Firefox? Seamonkey should behave > nearly identically but some browser detectors get confused by it. It definitely works well with FF2, as I use it on both OS X and Ubuntu all the time. It also works well (for me) in Safari, though you might not care about that. ;) I haven't tried Seamonkey, but just be sure you have JavaScript enabled. You probably already do, but I think that'll make a difference. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfRTlYACgkQ2YZpQepbvXFcbQCggEKbmiFa8JrsI3W2naYnP1U9 8lcAn2MqICv0DhR6teSesvcw8mqQncQ5 =NMnB -----END PGP SIGNATURE----- From shiva at sewingwitch.com Fri Mar 7 16:08:01 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 07 Mar 2008 07:08:01 -0800 Subject: [Mailman-Developers] Confluence via Seamonkey In-Reply-To: <982C5C7E-838F-4CFB-845E-65CD26F85D69@list.org> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <149F2B51AFE41E1F9ABB7D31@[10.169.6.155]> <3C67139F6D397E827425D4BE@[10.0.0.14]> <982C5C7E-838F-4CFB-845E-65CD26F85D69@list.org> Message-ID: <08461F582A1C543B3757E883@[10.0.0.14]> --On Friday, March 07, 2008 9:16 AM -0500 Barry Warsaw wrote: > I haven't tried Seamonkey, but just be sure you have JavaScript enabled. > You probably already do, but I think that'll make a difference. Aha! That was it. I'd allowed it on FF yesterday at the office, but not this morning on Seamonkey from home. (I've got the NoScript addon going.) From barry at list.org Fri Mar 7 16:49:08 2008 From: barry at list.org (Barry Warsaw) Date: Fri, 7 Mar 2008 10:49:08 -0500 Subject: [Mailman-Developers] Documentation status? In-Reply-To: <129A3B16-0505-4A12-A673-87E61CDDD98C@zone12.com> References: <20080305195338.GA12322@amk-desktop.matrixgroup.net> <8D5D8DBD-D3C8-4C52-93E0-94A09226AD7A@zone12.com> <2CC52649-9F17-4079-8B14-BA54AF2C8DD4@list.org> <129A3B16-0505-4A12-A673-87E61CDDD98C@zone12.com> Message-ID: <491FAB96-7CF9-4C2B-956F-9E96CE660000@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 6, 2008, at 3:20 AM, Terri Oda wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 5-Mar-08, at 5:26 PM, Barry Warsaw wrote: >> I like having docs in the wiki because it lets more people >> contribute. The downside is that you can't reach it when you're >> offline and it's harder to publish in alternative media. Have you >> thought at all about how to handle that? > > I've actually thought about it a fair bit! I also like the wiki > 'cause it's easier for other people to contribute (because I like to > believe that I'm not the only person in the world who wants to write > extensive Mailman documentation ;) ), and I'm particularly fond of > the wiki we're using on wiki.list.org because of the way it outputs. > > PDF: > > One of the things I really like about the Confluence wiki software > is that it does a pdf export. Heh, just goes to show you how clueless /I/ am! I'd never played with that before, but, like, WOW. :)n > I was *shocked* by how many people want to print mailman > documentation but apparently that pdf appeals to a lot of people (I > used to get more mail about that format than any other). > > I noticed today that the pdf export isn't available if you're not > logged in, though. Can we change that? I didn't see it offhand in > the settings, but I admit I haven't looked very hard yet. I really > think people will use it if they know it's there. Yep, changed. There are two permissions that control this, one for page exports and one for space exports. I don't see any reason why these shouldn't be enabled for anonymous users, since we already allow viewing for anonymous users. This has to be done on a per-space basis, so I enabled both page and space export for the Development, Documentation, Community, and Security spaces. > HTML: > > What *is* available even if you're not logged in, though, is a nice > printable version of the HTML. We could probably make a plain text > version from this, although I'm unconvinced anyone would care except > in a theoretical way. ;) Are there other formats that would be > useful? When people emailed me and mentioned format, they were > almost all using PDF or HTML, so I assume those are the most > important ones. These days, I think you're right about that. Let's call YAGNI on other formats. > Printed hard copies: > > I've been putting the manuals into big wiki documents rather than > splitting them up -- easier for those who want a printout to get it > in a go. (The appendices are separate 'cause I didn't think most > people would want them, and those who did would probably want them > separate.) They can print as pdf or as html, as per their > preferences, or import the HTML into something and repaginate > however they like. I haven't actually tried this, but it really is > nice html output. :) Cool. > Including the docs with releases?: > > The HTML output is nice enough that I think we could consider > snapshotting the documentation and putting it with each release as > HTML. I think the Members Manual is worth including particularly > because so many people have it on their sites for their users > already. Plus, with a couple of search and replaces, you can > customize the whole thing for your site, or even for a specific > list, which can be very handy for certain types of users. I'm > hoping the List Administrators Manual will be worth including when > it's done, too, as well as the as of yet unwritten Site > Administrators Manual.... but maybe I'm getting ahead of myself. > Still, I think we'd do well to include some of this with the > release. I will even volunteer to proofread the wiki output for > each release. (I edited a magazine for years, I can probably handle > this.) That would be great, very much appreciated! I think it would be fairly easy to get my release script to hit the PDF export links to download the latest copies when we spin the tarballs. > Doc licensing: > > I periodically get emails asking about the license on the > documentation. I kinda assume it's all GPL (I can sign another > copyright form for them if you need me to, Barry.), and that makes > most sense if we want to include them. If everyone's okay with > that, we should maybe put a note to that effect so I don't have to > keep telling people "Please, take it and do anything you want with > it! I like people using mailman, and if my docs help you do that, > use them any way you need to!" Or, hrm, maybe I'll just put that in > the docs and it'll get the point across. :) 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? > Other docs I want to see in the wiki: > > In my perfect world, I'd like to see us port all of our FAQ items to > the documentation part of the wiki, so all of these things could be > found in one place and thus easily searchable in one go. Any > volunteers? Yes! > Easy job, just a bit time-consuming, and a bit of thought needs to > be put into how best to organize things. My guess is make them all > children of an FAQ page so they're automatically indexed, but keep > things one-question-per-page since it's unlikely that anyone'll ever > want to print the entire FAQ. > > Similarly, installation docs, things like the backscatter > information... all should be in one place. I was trying to explain > to one of my department sysadmins where to find mailman help, and it > was *embarrassing* when I started listing off the docs I wrote, the > FAQ Wizard, the mailing lists, the help files included with the > installation, the FAQ on list.org... really, I'd like to see a one- > stop shop for documentation, and I think the wiki is the best choice > (because more people can contribute!), with us exporting the bits > that are useful to go with each release. I agree completely. > I periodically try to coerce my little sister to import everything > into the wiki for me, but she is strangely resistant to my offer of > cookies in exchange for mind-numbing work. ;) :) Maybe I'll have more luck bribing my son with Bionicles. :) > But it is a pretty easy job with a script and some time to sanity- > check the results, if anyone's got some time and interest. As added > incentive, the offer of fresh cookies is open to anyone, not just my > sister. I'll mail them out to any address you like, although > obviously I can't guarantee that they'll be quite as fresh by the > time you get 'em. ;) > > Finally: > > Jeez, what an essay. I could have written something explaining all > the general list administration options in the time it took me to > type this. Whoops. sorry! > > Terri No, that was great Terri, thanks! I think you're definitely on the right track with this and I really appreciate everything you've done to help coordinate the documentation effort. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfRY/cACgkQ2YZpQepbvXEo9ACgh2IVcf5mfkrn5BG5zqRMcYu4 Gx0AmgNzoBk/dJpSsY/3aWGRTMwElBD+ =/fMT -----END PGP SIGNATURE----- From barry at list.org Fri Mar 7 17:05:45 2008 From: barry at list.org (Barry Warsaw) Date: Fri, 7 Mar 2008 11:05:45 -0500 Subject: [Mailman-Developers] Confluence via Seamonkey In-Reply-To: <08461F582A1C543B3757E883@[10.0.0.14]> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <149F2B51AFE41E1F9ABB7D31@[10.169.6.155]> <3C67139F6D397E827425D4BE@[10.0.0.14]> <982C5C7E-838F-4CFB-845E-65CD26F85D69@list.org> <08461F582A1C543B3757E883@[10.0.0.14]> Message-ID: <1C07D368-0C2F-41FF-A781-ECCF1122B67E@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 7, 2008, at 10:08 AM, Kenneth Porter wrote: > --On Friday, March 07, 2008 9:16 AM -0500 Barry Warsaw > > wrote: > >> I haven't tried Seamonkey, but just be sure you have JavaScript >> enabled. >> You probably already do, but I think that'll make a difference. > > Aha! That was it. I'd allowed it on FF yesterday at the office, but > not > this morning on Seamonkey from home. (I've got the NoScript addon > going.) Who doesn't?! :) - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfRZ9kACgkQ2YZpQepbvXFl6ACfX3uT65I4VgjwA4X9aQkLS0nr vrMAoILSmQa8FVbTEFPyk4fU92+CxaJ8 =+UFg -----END PGP SIGNATURE----- From amk at amk.ca Fri Mar 7 19:03:41 2008 From: amk at amk.ca (A.M. Kuchling) Date: Fri, 7 Mar 2008 13:03:41 -0500 Subject: [Mailman-Developers] Documentation status? In-Reply-To: <491FAB96-7CF9-4C2B-956F-9E96CE660000@list.org> References: <20080305195338.GA12322@amk-desktop.matrixgroup.net> <8D5D8DBD-D3C8-4C52-93E0-94A09226AD7A@zone12.com> <2CC52649-9F17-4079-8B14-BA54AF2C8DD4@list.org> <129A3B16-0505-4A12-A673-87E61CDDD98C@zone12.com> <491FAB96-7CF9-4C2B-956F-9E96CE660000@list.org> Message-ID: <20080307180341.GA30669@amk-desktop.matrixgroup.net> On Fri, Mar 07, 2008 at 10:49:08AM -0500, Barry Warsaw wrote: > 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? The major issue with the GFDL is that for a while, Debian considered it to be a non-free license. I think the current status is that Debian now considers GFDL-licensed docs with no unmodifiable sections to be free, so we shouldn't have any such sections. (This is going by http://www.debian.org/vote/2006/vote_001#outcome ; is anyone here a Debian developer and know if that's the latest status?) Terri Oda wrote: > >information... all should be in one place. I was trying to explain > >to one of my department sysadmins where to find mailman help, and it > >was *embarrassing* when I started listing off the docs I wrote, the > >FAQ Wizard, the mailing lists, the help files included with the Yes, we definitely need to clean up on that respect. For example: * Are bugs kept in Jira or on SourceForge? (http://www.list.org/bugs.html says there's a transition going on.) * http://www.list.org/{docs,admins,users,...}.html would need to be updated. * The README says Python 2.1 or later is required, but it looks like Python 2.3 is actually needed these days. I've created a Launchpad branch, small-fixes, with some updates to the docs. This branch could be merged into 2.1 at any time, once someone has proofread my changes. --amk From amk at amk.ca Fri Mar 7 23:17:39 2008 From: amk at amk.ca (A.M. Kuchling) Date: Fri, 7 Mar 2008 17:17:39 -0500 Subject: [Mailman-Developers] Enhancing the bounce log Message-ID: <20080307221739.GA2146@amk-desktop.matrixgroup.net> I'd like to produce improved bounce statistics from Mailman's logs; for example, I'd like to track, per message, how many recipients there were and how many of them bounced. This means the logs need to include the message ID. Most of Mailman's logs (smtp, post, vette) include the ID, but the critical missing piece is the bounce log. To close the loop, I'l need to extract the ID of the message that was bounced. (The message ID of the bounce message itself isn't useful, and may not even exist; qmail's bounces apparently don't have IDs.) How should I write the code to extract the ID? Looking through the bounce test messages, there are various formats so we'll need several functions, similar to how there are several bounced-address parsers in Mailman.Bouncers. Should I: 1) add a extract_message_id() function to all of the modules in Mailman.Bouncers, which currently just have a process() function? 2) have a new package, Mailman.Bouncers.MessageId or whatever, that has several modules, analogous to the existing bounce analysis? 3) have a bunch of analysis functions in one module, and a single master function that tries all of them? I think 3) is the simplest course, but not too simple to be workable. Looking at the test bounces, finding the message ID is much simpler than finding the bounce address; searching for a small number of strings such as 'Original message follows' will often find the original headers. Can anyone see a reason that the more complicated 1) or 2) would be necessary? (I'll start a branch for this too, aimed at getting the change into 2.2.) --amk From shiva at sewingwitch.com Fri Mar 7 23:58:31 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 07 Mar 2008 14:58:31 -0800 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <7902D674628CC82E16CE5010@[10.169.6.155]> On Wednesday, March 05, 2008 5:54 PM -0500 Barry Warsaw wrote: > Mark's the release manager for 2.1, but FWIW I completely agree with > Stephen about this. What I would suggest though is that this > information be put in a prominent place on the wiki. We have a > security space with nothing substantial in it, so I suggest we put it > here. Initial text here: I grabbed some text from Jo Rhett's initial post in this thread and then added what I did to my installation. Those with more of a "big picture" view of the system can refine this. From mark at msapiro.net Sat Mar 8 01:02:12 2008 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 7 Mar 2008 16:02:12 -0800 Subject: [Mailman-Developers] Enhancing the bounce log In-Reply-To: <20080307221739.GA2146@amk-desktop.matrixgroup.net> Message-ID: A.M. Kuchling wrote: > >How should I write the code to extract the ID? Looking through the >bounce test messages, there are various formats so we'll need several >functions, similar to how there are several bounced-address parsers in >Mailman.Bouncers. Should I: I don't think we do. I ran the following import os import re import email hre = re.compile('^>?\s*message-id:\s*(<.*>)', re.IGNORECASE) for f in os.listdir('.'): if not f.endswith('.txt'): continue msg = email.message_from_file(open(f)) messageid = None inheaders = True for line in msg.as_string().splitlines(): if inheaders: if line == '': inheaders = False continue mo = hre.search(line) if mo: messageid = mo.group(1) break print '%s: %s' % (f, messageid) in current Mailman's test/bounces/ directory which contains 86 DSNs. Of those 86, 12 have no message id for the original message. Of the remaining 74, all message ids are found with the above. If the re is changed to hre = re.compile('^message-id:\s*(<.*>)', re.IGNORECASE) 73 of the 74 are found. llnl_01.txt has the 'original message' quoted with '>' characters. A few mesages have the messsage id in a report section with leading whitespace, but they all have it later as well without leading whitespace. In any case, I think the hre = re.compile('^>?\s*message-id:\s*(<.*>)', re.IGNORECASE) re will likely find anything to be found and is unlikely to find false hits. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From mark at msapiro.net Sat Mar 8 01:31:29 2008 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 7 Mar 2008 16:31:29 -0800 Subject: [Mailman-Developers] before nextrelease: disable backscatter indefault installation In-Reply-To: <7902D674628CC82E16CE5010@[10.169.6.155]> Message-ID: Kenneth Porter wrote: > >Initial text here: > > > >I grabbed some text from Jo Rhett's initial post in this thread and then >added what I did to my installation. Those with more of a "big picture" >view of the system can refine this. Thanks Kenneth. I changed the last part. Take a look. Note that sitelist.cfg is irrelevant. It is intended to be used as input to bin/config_list to configure the site list ('mailman' list) more appropriately than the default settings. It has no actual effect on any list unless you run bin/config_list on that list with sitelist.cfg as input. Also, if you're happy with the way the new mm_handler is working, let me know, and I'll get it in the contrib directory for 2.1.10. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From stephen at xemacs.org Sat Mar 8 06:34:21 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 08 Mar 2008 14:34:21 +0900 Subject: [Mailman-Developers] Documentation status? In-Reply-To: <491FAB96-7CF9-4C2B-956F-9E96CE660000@list.org> References: <20080305195338.GA12322@amk-desktop.matrixgroup.net> <8D5D8DBD-D3C8-4C52-93E0-94A09226AD7A@zone12.com> <2CC52649-9F17-4079-8B14-BA54AF2C8DD4@list.org> <129A3B16-0505-4A12-A673-87E61CDDD98C@zone12.com> <491FAB96-7CF9-4C2B-956F-9E96CE660000@list.org> Message-ID: <873ar1g4o2.fsf@uwakimon.sk.tsukuba.ac.jp> 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 it means that documentation and code can't be copied between GPL program and GFDL docs without explicit permission of the authors. This problem can be mostly solved by dual licensing the documentation (including all docstrings) GFDL/GPL, of course, but that doesn't stop downstream from reverting to single licensing. And it can't: requiring dual licensing is an additional restriction prohibited by both licenses. Nor does it help with copying code snippets into the documentation as examples, and dual licensing the code is right out: the GFDL is not a free software license according to the FSF. A possible problem is that any downstream derivative can add a cover text or Invariant Section, and effectively fork the documentation (unless we're willing to go nonfree to incorporate their required texts.) If cPanel/Plesk adds nothing else to Mailman documentation, I bet they'll add cover texts! And putting advertisements for their products in cover texts and Invariant Sections is encouraged by the FSF; that's what those provisions are there for. In practice, these don't seem to be real problems; the FSF has regularly looked the other way from massive unpermitted relicensing (eg, Wikipedia) and while cPanel/Plesk might not permit removal of their cover texts, they're not exactly famous for improving Mailman docs. OTOH, the only real advantage to GFDL is that we can borrow from other GFDLed docs. Do we want to do that? From mark at msapiro.net Sun Mar 9 00:09:13 2008 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 08 Mar 2008 15:09:13 -0800 Subject: [Mailman-Developers] Updated message catalogs needed for Mailman 2.1.10 Message-ID: <47D31C99.10103@msapiro.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If you are a language champion or otherwise responsible for a Mailman translation, please get the updated 2.1.10 message catalog for your language to me as soon as possible. Mailman 2.1.10 has been in beta for 3 months now, and I have received very few updated translations. I am planning to release what I hope will be the final beta release of 2.1.10 in a few days. This would be a release candidate rather than a beta if I had more updated translations. Thank you for your understanding. - -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFH0xyZVVuXXpU7hpMRAo1aAKDYiS/wpexcQJqNPi+d0GLK6o2x0gCfTo/Z 24bhI96yktpfx97nDC3XH48= =PH4r -----END PGP SIGNATURE----- From iane at sussex.ac.uk Mon Mar 10 11:19:09 2008 From: iane at sussex.ac.uk (Ian Eiloart) Date: Mon, 10 Mar 2008 10:19:09 +0000 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <0CBDE11E-84B0-47AA-B8FE-E9DF88463BEF@list.org> References: <0C4F5F7D-CB5D-4CE7-8C54-872413A44D36@netconsonance.com> <7AFBB02ED4F7081C33A84D37@lewes.staff.uscs.susx.ac.uk> <09FAB6B0-3474-4DF5-9658-F2FB7BADAB07@list.org> <0CBDE11E-84B0-47AA-B8FE-E9DF88463BEF@list.org> Message-ID: --On 6 March 2008 13:02:01 -0500 Barry Warsaw wrote: > >> The ideal thing would be if Mailman had an LMTP interface to accept >> postings, and could make decisions about accepting mail after RCTP TO. > > MM3 will have LMTP, perhaps as the preferred way to get messages into the > incoming queue. I hadn't thought about doing acceptance testing right > there, but it's an interesting idea to think about. Yep, it would be the easiest way to integrate acceptance testing with Exim. It's common for sites to put Exim installations in front of Exchange servers (for security reasons), and do SMTP call forwards to test deliverability. > Thanks! -- Ian Eiloart IT Services, University of Sussex x3148 From iane at sussex.ac.uk Mon Mar 10 13:06:22 2008 From: iane at sussex.ac.uk (Ian Eiloart) Date: Mon, 10 Mar 2008 12:06:22 +0000 Subject: [Mailman-Developers] 1-click unsubscribe In-Reply-To: References: <3E27E105-5319-49F0-9554-63BCCA96E0BC@list.org> <87wspggpk2.fsf@uwakimon.sk.tsukuba.ac.jp> <873as2oj5o.fsf@uwakimon.sk.tsukuba.ac.jp> <87y792kj99.fsf@uwakimon.sk.tsukuba.ac.jp> <47CB3247.2000406@thecsl.org> <2AC8E914-16AE-4D08-A24F-D07DF149E981@list.org> <919E8414B34C863C210FE637@lewes.staff.uscs.susx.ac.uk> Message-ID: <8E592366C806C2A59D1AF786@lewes.staff.uscs.susx.ac.uk> --On 6 March 2008 19:43:04 +0000 Nigel Metheringham wrote: > > On 6 Mar 2008, at 17:51, Ian Eiloart wrote: >> So, a 1-click unsub is a link in the message footer which takes you >> to a >> page that says something like "You've unsubscribed from our list, >> sorry to >> see you go"? > > > So its an HTTP GET - which is supposed to be idempotent. I know a > while back there was discussion of SpamAssassin modules which evaluated > linked webpages for spamminess - presumably that action would clear > someone off the list too! > > Nigel. It's an interesting point, but there are plenty of un/subscribe and request verification mechanisms out there which do exactly this. Including in Mailman, I think. -- Ian Eiloart IT Services, University of Sussex x3148 From barry at list.org Mon Mar 10 16:00:06 2008 From: barry at list.org (Barry Warsaw) Date: Mon, 10 Mar 2008 11:00:06 -0400 Subject: [Mailman-Developers] [Mailman-i18n] Updated message catalogs needed for Mailman 2.1.10 In-Reply-To: <47D31C99.10103@msapiro.net> References: <47D31C99.10103@msapiro.net> Message-ID: <435803E2-A7E6-4DA7-ADBC-76887D471356@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 8, 2008, at 6:09 PM, Mark Sapiro wrote: > If you are a language champion or otherwise responsible for a Mailman > translation, please get the updated 2.1.10 message catalog for your > language to me as soon as possible. Mailman 2.1.10 has been in beta > for > 3 months now, and I have received very few updated translations. > > I am planning to release what I hope will be the final beta release of > 2.1.10 in a few days. This would be a release candidate rather than a > beta if I had more updated translations. I think it may be time to once again consider modernizing our i18n workflow, especially for 2.2 and 3.0. Let me state up front that I'm HUGELY grateful for all the excellent work that the i18n volunteers have contributed over the years. Through your work, Mailman was one of the first localized Python projects and we invented a lot of the basic Python machinery for internationalizing applications. Of course, things have come a long way since then, and I think it may be time for us to join a wider translation community. AFAIK, the two leading contenders are running our own Pootle service, or using Launchpad translations. Is there any other viable alternative? I'd like to get some feedback from the current i18n volunteers to see what you think. If you believe that the status quo is best, feel free to say so. I think it's not, but I'm open to opinions. What I'm really looking for is a system and process that makes both the translators lives better, and doesn't put blockages in our workflow for releasing new versions of Mailman. Thanks, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfVTPYACgkQ2YZpQepbvXFi2QCfUXfgKcktYHrtEODoxd07Xsft ZH8AnRvkLxP92KZL24bFja+C96/22FYO =lF7M -----END PGP SIGNATURE----- From barry at list.org Mon Mar 10 16:41:17 2008 From: barry at list.org (Barry Warsaw) Date: Mon, 10 Mar 2008 11:41:17 -0400 Subject: [Mailman-Developers] Documentation status? In-Reply-To: <20080307180341.GA30669@amk-desktop.matrixgroup.net> References: <20080305195338.GA12322@amk-desktop.matrixgroup.net> <8D5D8DBD-D3C8-4C52-93E0-94A09226AD7A@zone12.com> <2CC52649-9F17-4079-8B14-BA54AF2C8DD4@list.org> <129A3B16-0505-4A12-A673-87E61CDDD98C@zone12.com> <491FAB96-7CF9-4C2B-956F-9E96CE660000@list.org> <20080307180341.GA30669@amk-desktop.matrixgroup.net> Message-ID: On Mar 7, 2008, at 1:03 PM, A.M. Kuchling wrote: > On Fri, Mar 07, 2008 at 10:49:08AM -0500, Barry Warsaw wrote: >> 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? > > The major issue with the GFDL is that for a while, Debian considered > it to be a non-free license. I think the current status is that > Debian now considers GFDL-licensed docs with no unmodifiable sections > to be free, so we shouldn't have any such sections. > > (This is going by http://www.debian.org/vote/2006/vote_001#outcome ; > is anyone here a Debian developer and know if that's the latest > status?) I asked an Ubuntu guy at Canonical to see if I can get a definitive answer about this. You're right to point to this vote as the definitive answer, but I was told to look specifically at Amendment A for details and a note on dual-licensing. If Debian is still recommending dual licensing even with GFDL and no unmodifiable sections, then it seems to me not worth the effort. If it makes sense to keep our documentation GPL'd, then let's just do that. > Terri Oda wrote: >>> information... all should be in one place. I was trying to explain >>> to one of my department sysadmins where to find mailman help, and it >>> was *embarrassing* when I started listing off the docs I wrote, the >>> FAQ Wizard, the mailing lists, the help files included with the > > Yes, we definitely need to clean up on that respect. For example: > > * Are bugs kept in Jira or on SourceForge? > (http://www.list.org/bugs.html says there's a transition going > on.) Right now they're still in SF, but I've wanted to move them for a long time. Moving to Jira requires work that someone at Atlassian offered to do once, but neither he nor I have had the time since. We could move to Launchpad's tracker because I believe it supports SF imports. We could try to put up our own Roundup instance, but I'm wary of doing anything that /we/ have to babysit. I'm still open to moving to Jira, but sadly don't have to the time to convert the SF data dump (or even be sure it's finally complete an accurate. :/). > * http://www.list.org/{docs,admins,users,...}.html would need to be > updated. Easy peasy. > * The README says Python 2.1 or later is required, but it looks like > Python 2.3 is actually needed these days. Yep. Mark, correct me if I'm wrong but I don't believe 2.1.10 restores Python 2.1 compatibility. Not that I care! Python 2.3 would be fine as a minimum requirement AFAIC. > I've created a > Launchpad branch, small-fixes, with some updates to the docs. > This branch could be merged into 2.1 at any time, once someone has > proofread my changes. This is the branch, right Andrew? https://code.edge.launchpad.net/~amk/mailman/small-fixes I'll take a look tonight unless Mark beats me to it. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20080310/03860144/attachment.pgp From barry at list.org Mon Mar 10 16:42:45 2008 From: barry at list.org (Barry Warsaw) Date: Mon, 10 Mar 2008 11:42:45 -0400 Subject: [Mailman-Developers] Documentation status? In-Reply-To: <873ar1g4o2.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20080305195338.GA12322@amk-desktop.matrixgroup.net> <8D5D8DBD-D3C8-4C52-93E0-94A09226AD7A@zone12.com> <2CC52649-9F17-4079-8B14-BA54AF2C8DD4@list.org> <129A3B16-0505-4A12-A673-87E61CDDD98C@zone12.com> <491FAB96-7CF9-4C2B-956F-9E96CE660000@list.org> <873ar1g4o2.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 8, 2008, at 12:34 AM, Stephen J. Turnbull wrote: > OTOH, the only real advantage to GFDL is that we can borrow from other > GFDLed docs. Do we want to do that? 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. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfVVvkACgkQ2YZpQepbvXHfdACcDxWo7DEi81UWIGdkml6fB5Eo TIcAn0Js6H35/7PlEe1uEN8pE83p3kMk =S9oC -----END PGP SIGNATURE----- From barry at list.org Mon Mar 10 17:11:29 2008 From: barry at list.org (Barry Warsaw) Date: Mon, 10 Mar 2008 12:11:29 -0400 Subject: [Mailman-Developers] Documentation status? In-Reply-To: References: <20080305195338.GA12322@amk-desktop.matrixgroup.net> <8D5D8DBD-D3C8-4C52-93E0-94A09226AD7A@zone12.com> <2CC52649-9F17-4079-8B14-BA54AF2C8DD4@list.org> <129A3B16-0505-4A12-A673-87E61CDDD98C@zone12.com> <491FAB96-7CF9-4C2B-956F-9E96CE660000@list.org> <20080307180341.GA30669@amk-desktop.matrixgroup.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 10, 2008, at 11:41 AM, Barry Warsaw wrote: > > https://code.edge.launchpad.net/~amk/mailman/small-fixes > > I'll take a look tonight unless Mark beats me to it. Actually, I found a few minutes to review this. The branch looks good, +1 for merging it to 2.1. Thanks! - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfVXbEACgkQ2YZpQepbvXEDCwCgnzGgTade0FoqzpBQz9tLOo74 RtIAoI05MM6rlTT13NgZM6XVRmQqsVCr =GfkU -----END PGP SIGNATURE----- From thijs at debian.org Mon Mar 10 16:53:17 2008 From: thijs at debian.org (Thijs Kinkhorst) Date: Mon, 10 Mar 2008 16:53:17 +0100 Subject: [Mailman-Developers] Documentation status? In-Reply-To: <20080307180341.GA30669@amk-desktop.matrixgroup.net> References: <20080305195338.GA12322@amk-desktop.matrixgroup.net> <491FAB96-7CF9-4C2B-956F-9E96CE660000@list.org> <20080307180341.GA30669@amk-desktop.matrixgroup.net> Message-ID: <200803101653.19326.thijs@debian.org> On Friday 7 March 2008 19:03, A.M. Kuchling wrote: > The major issue with the GFDL is that for a while, Debian considered > it to be a non-free license. ?I think the current status is that > Debian now considers GFDL-licensed docs with no unmodifiable sections > to be free, so we shouldn't have any such sections. ? > > (This is going by http://www.debian.org/vote/2006/vote_001#outcome ; > is anyone here a Debian developer and know if that's the latest status?) Yes, I am and yes, it is the latest status. Basically, GFDL is not a problem to Debian if you don't use cover texts and unmodifiable sections, however it's discouraged because it's yet another licence and texts from e.g. a manual cannot be used in code. Another problem is that your tarball is going to have content licenced under different licences. I think it's preferable to have one licence covering the entire Mailman tarball if that's possible. There doesn't seem a real reason to switch to the GFDL when GPL provides just what you need. If the entire project is already GPL, then let's keep it simple and keep everything under the same licence. Thijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 481 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20080310/c198ec46/attachment.pgp From amk at amk.ca Mon Mar 10 18:03:26 2008 From: amk at amk.ca (A.M. Kuchling) Date: Mon, 10 Mar 2008 13:03:26 -0400 Subject: [Mailman-Developers] Documentation status? In-Reply-To: References: <20080305195338.GA12322@amk-desktop.matrixgroup.net> <8D5D8DBD-D3C8-4C52-93E0-94A09226AD7A@zone12.com> <2CC52649-9F17-4079-8B14-BA54AF2C8DD4@list.org> <129A3B16-0505-4A12-A673-87E61CDDD98C@zone12.com> <491FAB96-7CF9-4C2B-956F-9E96CE660000@list.org> <20080307180341.GA30669@amk-desktop.matrixgroup.net> Message-ID: <20080310170326.GA10563@amk-desktop.matrixgroup.net> On Mon, Mar 10, 2008 at 12:11:29PM -0400, Barry Warsaw wrote: > Actually, I found a few minutes to review this. The branch looks > good, +1 for merging it to 2.1. Should I do a push to the 2.1 branch, or will you or Mark pull it into 2.1? (I think I have commit privileges at this point, but I'm new to both Mailman & Bazaar, and am therefore cautious...) --amk From shiva at sewingwitch.com Mon Mar 10 18:46:39 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 10 Mar 2008 10:46:39 -0700 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: References: <0C4F5F7D-CB5D-4CE7-8C54-872413A44D36@netconsonance.com> <7AFBB02ED4F7081C33A84D37@lewes.staff.uscs.susx.ac.uk> <09FAB6B0-3474-4DF5-9658-F2FB7BADAB07@list.org> <0CBDE11E-84B0-47AA-B8FE-E9DF88463BEF@list.org> Message-ID: --On Monday, March 10, 2008 10:19 AM +0000 Ian Eiloart wrote: > Yep, it would be the easiest way to integrate acceptance testing with > Exim. It's common for sites to put Exim installations in front of > Exchange servers (for security reasons), and do SMTP call forwards to > test deliverability. Another approach is to dump the valid users list periodically using a Windows-based LDAP app and then copy that to the OSS front end MTA for validation. Check the MIMEDefang list archives for howto. From shiva at sewingwitch.com Mon Mar 10 19:22:23 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 10 Mar 2008 11:22:23 -0700 Subject: [Mailman-Developers] before nextrelease: disable backscatter in default installation In-Reply-To: References: Message-ID: --On Friday, March 07, 2008 4:31 PM -0800 Mark Sapiro wrote: > I changed the last part. Take a look. Note that sitelist.cfg is > irrelevant. It is intended to be used as input to bin/config_list to > configure the site list ('mailman' list) more appropriately than the > default settings. It has no actual effect on any list unless you run > bin/config_list on that list with sitelist.cfg as input. The new text says to change generic_nonmember_action but not where to change it. I see it in /var/lib/mailman/data/sitelist.cfg which I believe is site-wide and probably suffers the same issue. I haven't yet found it in the web interface. (It might be nice if the web interface included an "all settings" page, or at least an index of settings so one could then go to the specific page with that setting.) Ideally I should be able to change it in a text file or otherwise with a shell utility, so that I can bulk-change the setting in all lists I manage with a script. From shiva at sewingwitch.com Mon Mar 10 19:29:54 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 10 Mar 2008 11:29:54 -0700 Subject: [Mailman-Developers] anti-backscatter mm-handler (was before next release: disable backscatter in default installation) In-Reply-To: References: Message-ID: <4F0D9B22CFEDE02CE00CAD64@[10.0.0.14]> --On Friday, March 07, 2008 4:31 PM -0800 Mark Sapiro wrote: > Also, if you're happy with the way the new mm_handler is working, let > me know, and I'll get it in the contrib directory for 2.1.10. I'm seeing lines like the following in maillog. How do I trace the source of the error? (I can debug code in an Emacs/shell situation, I just don't know how to debug within the sendmail/mm-handler/mailman environment to isolate the offending module and line.) Mar 10 11:13:30 centos sendmail[26008]: m2749udR026109: to=, delay=3+14:03:32, xdelay=00:00:00, mailer=mailman, pri=7863419, relay=lists.matureasskickers.net, dsn=4.0.0, stat=Operating system error In sendmail.mc: Mmailman, P=/usr/local/sbin/mm-handler, F=rDFMhlqSu, U=mailman:mailman, S=EnvFromL, R=EnvToL/HdrToL, A=mm-handler $h $u My only change to your script was the Perl location in the shebang and these two lines (to match the CentOS RPM file locations): $MMWRAPPER = "/usr/lib/mailman/mail/mailman"; $MMLISTDIR = "/var/lib/mailman/lists"; From amk at amk.ca Mon Mar 10 20:21:25 2008 From: amk at amk.ca (A.M. Kuchling) Date: Mon, 10 Mar 2008 15:21:25 -0400 Subject: [Mailman-Developers] Enhancing the bounce log In-Reply-To: References: <20080307221739.GA2146@amk-desktop.matrixgroup.net> Message-ID: <20080310192125.GA12622@amk-desktop.matrixgroup.net> On Fri, Mar 07, 2008 at 04:02:12PM -0800, Mark Sapiro wrote: > In any case, I think the > > hre = re.compile('^>?\s*message-id:\s*(<.*>)', re.IGNORECASE) > > re will likely find anything to be found and is unlikely to find false > hits. Excellent point! I've written up a patch using the regex: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1911318&group_id=103 One minor test-suite oddity I noticed: about a third of the bounce messages in tests/bounces/ have mbox-style 'From VM Wed Mar 21 22:20:23 2001' header lines. Most of them seem harmless, but the one in hotpop_01.txt breaks the email.Message() parser because the line is ">From daemon Tue Nov 13 13:43:50 2001". Worth fixing? --amk From barry at list.org Mon Mar 10 20:30:33 2008 From: barry at list.org (Barry Warsaw) Date: Mon, 10 Mar 2008 15:30:33 -0400 Subject: [Mailman-Developers] Documentation status? In-Reply-To: <20080310170326.GA10563@amk-desktop.matrixgroup.net> References: <20080305195338.GA12322@amk-desktop.matrixgroup.net> <8D5D8DBD-D3C8-4C52-93E0-94A09226AD7A@zone12.com> <2CC52649-9F17-4079-8B14-BA54AF2C8DD4@list.org> <129A3B16-0505-4A12-A673-87E61CDDD98C@zone12.com> <491FAB96-7CF9-4C2B-956F-9E96CE660000@list.org> <20080307180341.GA30669@amk-desktop.matrixgroup.net> <20080310170326.GA10563@amk-desktop.matrixgroup.net> Message-ID: <856E1AA4-CEA4-4039-B67B-E254F03D409D@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 10, 2008, at 1:03 PM, A.M. Kuchling wrote: > On Mon, Mar 10, 2008 at 12:11:29PM -0400, Barry Warsaw wrote: >> Actually, I found a few minutes to review this. The branch looks >> good, +1 for merging it to 2.1. > > Should I do a push to the 2.1 branch, or will you or Mark pull it into > 2.1? > > (I think I have commit privileges at this point, but I'm new to both > Mailman & Bazaar, and am therefore cautious...) Well, theoretically you can't do much permanent damage right? :) Because this involves the 2.1 branch, I'm going to leave it up to Mark to decide. In general, I'm happy for you to commit to the Mailman branches directly, but with 2.1.10 so close, let's get Mark's okay first for this one. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfVjFkACgkQ2YZpQepbvXGQ/gCgpxyQsp4b8viQNCt3cs7FiAm5 CykAoI+Kt28naVrIedSMHIiYr/ZAojXO =eTW9 -----END PGP SIGNATURE----- From mark at msapiro.net Mon Mar 10 22:24:57 2008 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 10 Mar 2008 14:24:57 -0700 Subject: [Mailman-Developers] Enhancing the bounce log In-Reply-To: <20080310192125.GA12622@amk-desktop.matrixgroup.net> Message-ID: A.M. Kuchling wrote: >On Fri, Mar 07, 2008 at 04:02:12PM -0800, Mark Sapiro wrote: >> In any case, I think the >> >> hre = re.compile('^>?\s*message-id:\s*(<.*>)', re.IGNORECASE) >> >> re will likely find anything to be found and is unlikely to find false >> hits. > >Excellent point! I've written up a patch using the regex: >https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1911318&group_id=103 I've looked at the patch, and I wonder why it doesn't include the '<' and '>' in the log entries. According to RFC 2822, the '<' and '>' are part of the msg-id, and more importantly, all existing bounce, post, smtp and vette log entries with msg-ids include them >One minor test-suite oddity I noticed: about a third of the bounce >messages in tests/bounces/ have mbox-style 'From VM Wed Mar 21 >22:20:23 2001' header lines. Most of them seem harmless, but the one >in hotpop_01.txt breaks the email.Message() parser because the line is >">From daemon Tue Nov 13 13:43:50 2001". Worth fixing? Yes. I'll remove that bogus line from the test message. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From stephen at xemacs.org Mon Mar 10 22:37:48 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 11 Mar 2008 06:37:48 +0900 Subject: [Mailman-Developers] Documentation status? In-Reply-To: References: <20080305195338.GA12322@amk-desktop.matrixgroup.net> <8D5D8DBD-D3C8-4C52-93E0-94A09226AD7A@zone12.com> <2CC52649-9F17-4079-8B14-BA54AF2C8DD4@list.org> <129A3B16-0505-4A12-A673-87E61CDDD98C@zone12.com> <491FAB96-7CF9-4C2B-956F-9E96CE660000@list.org> <873ar1g4o2.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <87zlt6clar.fsf@uwakimon.sk.tsukuba.ac.jp> 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! From mark at msapiro.net Tue Mar 11 02:18:17 2008 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 10 Mar 2008 18:18:17 -0700 Subject: [Mailman-Developers] anti-backscatter mm-handler (was before next release: disablebackscatter in default installation) In-Reply-To: <4F0D9B22CFEDE02CE00CAD64@[10.0.0.14]> Message-ID: Kenneth Porter wrote: >--On Friday, March 07, 2008 4:31 PM -0800 Mark Sapiro >wrote: > >> Also, if you're happy with the way the new mm_handler is working, let >> me know, and I'll get it in the contrib directory for 2.1.10. > >I'm seeing lines like the following in maillog. How do I trace the source >of the error? (I can debug code in an Emacs/shell situation, I just don't >know how to debug within the sendmail/mm-handler/mailman environment to >isolate the offending module and line.) > >Mar 10 11:13:30 centos sendmail[26008]: m2749udR026109: >to=, delay=3+14:03:32, >xdelay=00:00:00, mailer=mailman, pri=7863419, >relay=lists.matureasskickers.net, dsn=4.0.0, stat=Operating system error > >In sendmail.mc: > >Mmailman, P=/usr/local/sbin/mm-handler, F=rDFMhlqSu, >U=mailman:mailman, > S=EnvFromL, R=EnvToL/HdrToL, > A=mm-handler $h $u > > >My only change to your script was the Perl location in the shebang and >these two lines (to match the CentOS RPM file locations): > >$MMWRAPPER = "/usr/lib/mailman/mail/mailman"; >$MMLISTDIR = "/var/lib/mailman/lists"; I am not the author of mm-handler - that's David Champion. I'm just the release manager for the 2.1.10 release. I'm not well versed in either perl or sendmail, but I'm surprised sendmail doesn't log more. In any case, my guess would be a permissions issue or a group mismatch from the mailman wrapper, but if everything is the same as with the previous mm-handler, then that should not be the case. You could try running mm-handler by hand. I think it would be something like /usr/local/sbin/mm-handler your.host.name listname < file_with_raw_msg You might want to uncomment the $DEBUG = 1; line when you do this. If I read your sendmail.mc fragment correctly, you want to do this as user:group mailman:mailman. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From munichlinux at gmail.com Mon Mar 10 14:51:22 2008 From: munichlinux at gmail.com (Prashanth) Date: Mon, 10 Mar 2008 19:21:22 +0530 Subject: [Mailman-Developers] Recipients list in mailman Message-ID: <1f869bdd0803100651i2b4ace12waaccdc3b9a20d364@mail.gmail.com> Hi, I need to change the way mailman creates the list of mail ids to deliver the mail, I tried locating the code which creates the list of mail-id of a mailing list to send message but failed. Is there any function or a code which creates the list of mail-ids to deliver mail, it would be helpful if someone can tell me the exact location where mailman does that. -- regards, Prashanth http://munichlinux.blogspot.com From eino at utu.fi Mon Mar 10 19:21:18 2008 From: eino at utu.fi (Eino Tuominen) Date: Mon, 10 Mar 2008 20:21:18 +0200 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: References: <0C4F5F7D-CB5D-4CE7-8C54-872413A44D36@netconsonance.com> <7AFBB02ED4F7081C33A84D37@lewes.staff.uscs.susx.ac.uk> <09FAB6B0-3474-4DF5-9658-F2FB7BADAB07@list.org> <0CBDE11E-84B0-47AA-B8FE-E9DF88463BEF@list.org> Message-ID: <47D57C1E.9090105@utu.fi> Kenneth Porter wrote: > > Another approach is to dump the valid users list periodically using a > Windows-based LDAP app and then copy that to the OSS front end MTA for > validation. Check the MIMEDefang list archives for howto. A bit off topic, but why not run the LDAP app on the OSS system? Or better yet, have front end MTA to query LDAP (AD) directly. About the original question, +1 for a more thorough LDAP integration and LMTP. BTW, we have written a couple of utilities to integrate Mailman with Sun's Messaging Server. Another is an MTA wrapper (MTA/Ldap.py) to publish mailman aliases in an LDAP directory, and the other one is a channel program for JES to feed appropriate messages to the Mailman wrapper. And we also have UtuMemeberships.py to authenticate users with our email address against LDAP. Is there any public interest for those? -- Eino Tuominen From mark at msapiro.net Tue Mar 11 02:51:34 2008 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 10 Mar 2008 18:51:34 -0700 Subject: [Mailman-Developers] Recipients list in mailman In-Reply-To: <1f869bdd0803100651i2b4ace12waaccdc3b9a20d364@mail.gmail.com> Message-ID: Prashanth wrote: > > I need to change the way mailman creates the list of >mail ids to deliver the mail, I tried locating the code which creates >the list of mail-id of a mailing list to send message but failed. Is >there any function or a code which creates the list of mail-ids to >deliver mail, it would be helpful if someone can tell me the exact >location where mailman does that. Mailman/Handlers/CalcRecips.py -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From brad at shub-internet.org Tue Mar 11 02:41:24 2008 From: brad at shub-internet.org (Brad Knowles) Date: Mon, 10 Mar 2008 20:41:24 -0500 Subject: [Mailman-Developers] [Mailman-Users] [Mailman-Announce] Updated message catalogs needed for Mailman 2.1.10 In-Reply-To: References: <47D31C99.10103@msapiro.net> Message-ID: On 3/10/08, liste yoneticisi wrote: > (An explanation to all: I just asked if there is anyone who > responsible for Turkish translation of Mailman, attended to these lists > from Turkiye.) This is a question that is better asked on the mailman-i18n mailing list. That's where all the Internationalization folks should be hanging out. -- Brad Knowles LinkedIn Profile: From stanabe at uwo.ca Tue Mar 11 04:10:06 2008 From: stanabe at uwo.ca (Satoshi Tanabe) Date: Tue, 11 Mar 2008 12:10:06 +0900 Subject: [Mailman-Developers] GNU Mailman Site Redesign Message-ID: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com> Hello, Currently I'm creating an unofficial site of GNU Mailman. It's not done yet, but the goal is to make the current official site more accessible and usable. The content is almost the same. The unofficial site (since Google Page Creator doesn't support folders, images are not shown and linked docs are not available): http://gnu.mailman.googlepages.com/index.html You can download the source tarball here (with linked docs): Source Tarball (size: 1.1mb) http://gnu.mailman.googlepages.com/Mailman-Site-Redesign.tar.gz This site tries to solve the problems that I listed in the following document: What's wrong with the current Mailman official site? http://gnu.mailman.googlepages.com/wrong.txt I'd love to have your feedback. Also, I listed several questions in the document above, so I'd appreciate if any of you could answer or comment on them (Some questions are not about the official site per se). Best, - Satoshi From shiva at sewingwitch.com Tue Mar 11 05:11:27 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 10 Mar 2008 21:11:27 -0700 Subject: [Mailman-Developers] anti-backscatter mm-handler (was before next release: disablebackscatter in default installation) In-Reply-To: References: Message-ID: <2043056A9AF44CA70F59A180@[10.0.0.14]> --On Monday, March 10, 2008 6:18 PM -0700 Mark Sapiro wrote: > In any case, my guess would be a permissions issue or a group mismatch > from the mailman wrapper, but if everything is the same as with the > previous mm-handler, then that should not be the case. That looks like it. I realized I'd moved the file into place while it was still owned by me, with 744 permissions. Oops. I'll look in the morning to see if that fixes it. From mark at msapiro.net Tue Mar 11 05:38:50 2008 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 10 Mar 2008 21:38:50 -0700 Subject: [Mailman-Developers] Documentation status? In-Reply-To: <20080310170326.GA10563@amk-desktop.matrixgroup.net> Message-ID: A.M. Kuchling wrote: >On Mon, Mar 10, 2008 at 12:11:29PM -0400, Barry Warsaw wrote: >> Actually, I found a few minutes to review this. The branch looks >> good, +1 for merging it to 2.1. > >Should I do a push to the 2.1 branch, or will you or Mark pull it into >2.1? > >(I think I have commit privileges at this point, but I'm new to both >Mailman & Bazaar, and am therefore cautious...) I'm way behind on my emails ... I'll try to take care of this tomorrow/ -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From terri at zone12.com Tue Mar 11 05:44:09 2008 From: terri at zone12.com (Terri Oda) Date: Tue, 11 Mar 2008 00:44:09 -0400 Subject: [Mailman-Developers] Documentation status? In-Reply-To: <4BD7F651-32F0-43DB-872E-F0355FBF82CA@raoset.com> References: <20080305195338.GA12322@amk-desktop.matrixgroup.net> <8D5D8DBD-D3C8-4C52-93E0-94A09226AD7A@zone12.com> <2CC52649-9F17-4079-8B14-BA54AF2C8DD4@list.org> <129A3B16-0505-4A12-A673-87E61CDDD98C@zone12.com> <4BD7F651-32F0-43DB-872E-F0355FBF82CA@raoset.com> Message-ID: On 6-Mar-08, at 2:18 PM, Jason Pruim wrote: > I've been watching this thread with interest and would like to help > where I can... I don't know Python, so I can't exactly help program, > but I've been told I can translate technological info into something > the normal person could understand. So what do I have to do to start > helping? :) Hi Jason! Sorry it took me so long to get back to you -- been a busy week! So, what I'd suggest you do first is hook yourself up with a wiki account, look around at the documentation that's currently on the mailman website, and import all of it into the wiki. Try to figure out what's up to date and what isn't and make it obvious. Try to figure out nice ways to organize it. You know, all that stuff. :) Maybe import all those FAQ entries somehow, or at least lay out a structure so someone else can just cut and paste. This accomplishes two things: (a) we have more nicely organized and linked docs that are easier to edit (I really think this is the most important documentation task on the table at the moment) (b) you will have a good idea of what documentation we have and where the gaps are, so you'll be able to figure out what documents you want to work on writing as a next phase to this! Sound appealing? I'm sure I can come up with other ideas if this isn't up your alley, but if you can translate technical info to humanspeak, you'd probably do a great job organizing stuff in a way that real people can actually find the information they want. :) Terri From mark at msapiro.net Tue Mar 11 06:02:41 2008 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 10 Mar 2008 22:02:41 -0700 Subject: [Mailman-Developers] before nextrelease: disable backscatter indefault installation In-Reply-To: Message-ID: Kenneth Porter wrote: >--On Friday, March 07, 2008 4:31 PM -0800 Mark Sapiro >wrote: > >> I changed the last part. Take a look. Note that sitelist.cfg is >> irrelevant. It is intended to be used as input to bin/config_list to >> configure the site list ('mailman' list) more appropriately than the >> default settings. It has no actual effect on any list unless you run >> bin/config_list on that list with sitelist.cfg as input. > >The new text says to change generic_nonmember_action but not where to >change it. Privacy options -> Sender filters >I see it in /var/lib/mailman/data/sitelist.cfg which I believe >is site-wide and probably suffers the same issue. As I tried to point out in what you quote above, data/sitelist.cfg has absolutely no effect on anything unless you run bin/config_list on a particular list with that file as input. >I haven't yet found it in >the web interface. (It might be nice if the web interface included an "all >settings" page, or at least an index of settings so one could then go to >the specific page with that setting.) Yes, there should be a TOC or index in the docs for all settings, and having it on a page in the web interface is a good idea too. >Ideally I should be able to change it in a text file or otherwise with a >shell utility, so that I can bulk-change the setting in all lists I manage >with a script. You can do the following to set generic_nonmember_action to discard for every list: #!/bin/bash cd /path/to/mailman/bin f=`mktemp` echo generic_nonmember_action = 3 > $f for list in `./list_lists --bare` do ./config-list -i $f $list done rm $f I.e. you can configure a list with text input to config_list containing only those settings you want to change. Maybe you can come up with some good text to add to the wiki page. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From mark at msapiro.net Tue Mar 11 06:37:56 2008 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 10 Mar 2008 22:37:56 -0700 Subject: [Mailman-Developers] Documentation status? In-Reply-To: References: <20080305195338.GA12322@amk-desktop.matrixgroup.net> <8D5D8DBD-D3C8-4C52-93E0-94A09226AD7A@zone12.com> <2CC52649-9F17-4079-8B14-BA54AF2C8DD4@list.org> <129A3B16-0505-4A12-A673-87E61CDDD98C@zone12.com> <491FAB96-7CF9-4C2B-956F-9E96CE660000@list.org> <20080307180341.GA30669@amk-desktop.matrixgroup.net> Message-ID: <47D61AB4.6080309@msapiro.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Barry Warsaw wrote: | On Mar 7, 2008, at 1:03 PM, A.M. Kuchling wrote: | |> * The README says Python 2.1 or later is required, but it looks like |> Python 2.3 is actually needed these days. | | Yep. Mark, correct me if I'm wrong but I don't believe 2.1.10 restores | Python 2.1 compatibility. Not that I care! Python 2.3 would be fine as | a minimum requirement AFAIC. That is correct. There were a few isinstance(something, str) calls in HTMLFormatter.py and htmlformat.py that I added in 2.1.9. They're still there, and I don't know what other things I may have added since that require Python 2.3. The wiki page at is very clear that we require at least Python 2.3 for the 2.1 branch from 2.1.9 forward. - -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFH1hqzVVuXXpU7hpMRAsE1AJ9Xn+T1YKRSmpKwmf/8iMA4rhY29ACgg1v8 Mf7z6gtoXf/ops4TJcSclY0= =Emue -----END PGP SIGNATURE----- From iane at sussex.ac.uk Tue Mar 11 11:34:57 2008 From: iane at sussex.ac.uk (Ian Eiloart) Date: Tue, 11 Mar 2008 10:34:57 +0000 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: References: <0C4F5F7D-CB5D-4CE7-8C54-872413A44D36@netconsonance.com> <7AFBB02ED4F7081C33A84D37@lewes.staff.uscs.susx.ac.uk> <09FAB6B0-3474-4DF5-9658-F2FB7BADAB07@list.org> <0CBDE11E-84B0-47AA-B8FE-E9DF88463BEF@list.org> Message-ID: <81EE07755B430C5B2A6DCE27@lewes.staff.uscs.susx.ac.uk> --On 10 March 2008 10:46:39 -0700 Kenneth Porter wrote: > --On Monday, March 10, 2008 10:19 AM +0000 Ian Eiloart > wrote: > >> Yep, it would be the easiest way to integrate acceptance testing with >> Exim. It's common for sites to put Exim installations in front of >> Exchange servers (for security reasons), and do SMTP call forwards to >> test deliverability. > > Another approach is to dump the valid users list periodically using a > Windows-based LDAP app and then copy that to the OSS front end MTA for > validation. Check the MIMEDefang list archives for howto. That's pointless with Exim. Exim's capable of querying the LDAP server directly to check the existence of a user - so people can use their accounts as soon as they're created. The advantage of a call forward is that it allows for other factors that might determine deliverability, such as quota problems, personal filters or whatever other features the backend might support. Call forwards are definitive, and don't require knowledge of the nature of the backend. -- Ian Eiloart IT Services, University of Sussex x3148 From shiva at sewingwitch.com Tue Mar 11 14:55:48 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Tue, 11 Mar 2008 06:55:48 -0700 Subject: [Mailman-Developers] before nextrelease: disable backscatter indefault installation In-Reply-To: References: Message-ID: <6E146B540F41049B53D82F0D@[10.0.0.14]> --On Monday, March 10, 2008 10:02 PM -0700 Mark Sapiro wrote: > Maybe you can come up with some good text to add to the wiki page. Thanks for the details. Wiki updated. From barry at list.org Tue Mar 11 19:13:39 2008 From: barry at list.org (Barry Warsaw) Date: Tue, 11 Mar 2008 14:13:39 -0400 Subject: [Mailman-Developers] Documentation status? In-Reply-To: <47D61AB4.6080309@msapiro.net> References: <20080305195338.GA12322@amk-desktop.matrixgroup.net> <8D5D8DBD-D3C8-4C52-93E0-94A09226AD7A@zone12.com> <2CC52649-9F17-4079-8B14-BA54AF2C8DD4@list.org> <129A3B16-0505-4A12-A673-87E61CDDD98C@zone12.com> <491FAB96-7CF9-4C2B-956F-9E96CE660000@list.org> <20080307180341.GA30669@amk-desktop.matrixgroup.net> <47D61AB4.6080309@msapiro.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 11, 2008, at 1:37 AM, Mark Sapiro wrote: > That is correct. There were a few isinstance(something, str) calls in > HTMLFormatter.py and htmlformat.py that I added in 2.1.9. They're > still > there, and I don't know what other things I may have added since that > require Python 2.3. > > The wiki page at is > very > clear that we require at least Python 2.3 for the 2.1 branch from > 2.1.9 > forward. Perfect, thanks. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfWy9QACgkQ2YZpQepbvXGbhwCfUs5GeVEeNFVtqSWMBELy36uh B+EAoKIaxccY8MAF2AbXKtSKot0PYflq =wGuE -----END PGP SIGNATURE----- From terri at zone12.com Wed Mar 12 03:44:15 2008 From: terri at zone12.com (Terri Oda) Date: Tue, 11 Mar 2008 22:44:15 -0400 Subject: [Mailman-Developers] GNU Mailman Site Redesign In-Reply-To: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com> References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com> Message-ID: <964B9E4D-758A-4B0C-8691-25744618B55A@zone12.com> On 10-Mar-08, at 11:10 PM, Satoshi Tanabe wrote: > This site tries to solve the problems that I listed in the > following document: > > What's wrong with the current Mailman official site? > http://gnu.mailman.googlepages.com/wrong.txt > > I'd love to have your feedback. Also, I listed several questions in > the document above, so I'd appreciate if any of you could answer or > comment on them (Some questions are not about the official site per > se). I haven't had a chance to seriously look at all the content or your comments and questions, but wow, you do seem to be spot on about simplifying the webpage being an improvement! I'd like to sit down and nitpick some stuff, but I know I won't have time this week, so for now I just want to say that I'm very much in favour of using this as a springboard to redesign the main site. Terri From terri at zone12.com Wed Mar 12 03:59:49 2008 From: terri at zone12.com (Terri Oda) Date: Tue, 11 Mar 2008 22:59:49 -0400 Subject: [Mailman-Developers] Documentation status? In-Reply-To: References: <20080305195338.GA12322@amk-desktop.matrixgroup.net> <8D5D8DBD-D3C8-4C52-93E0-94A09226AD7A@zone12.com> <2CC52649-9F17-4079-8B14-BA54AF2C8DD4@list.org> <129A3B16-0505-4A12-A673-87E61CDDD98C@zone12.com> <4BD7F651-32F0-43DB-872E-F0355FBF82CA@raoset.com> Message-ID: <866A29BB-6AFB-4FA2-AC50-D30B5699825F@zone12.com> On 11-Mar-08, at 11:00 AM, Jason Pruim wrote: > I can work on that... I already have a wiki account, and it looks > like I can edit pages... I would like to get some opinions on how > to do the FAQ's... I have some for my company website (Not related > to mailman) but what I did was a list of all the questions up at > the top of the page with named anchors linking down to the actual > answer... Maybe the best way to describe it would be to show you.. > Sorry if this is bad form... Just trying to help! :) > > http://raoset.com/faqs/faqs.shtml > > Let me know if that looks like a good way for these... I can make > the transfer pretty quickly if this looks like it would be a good > thing. Or if anyone has any better ideas on how to do them, I'm > open to ideas :) I like this style when you have a smaller number of questions, but there are probably over 200 entries in the the Mailman FAQ. I think putting them all on one page is less than ideal: (a) It makes for a big, unpleasant to load page (b) It makes it awkward to print off the answer to a specific question (seriously, people seem to print docs a lot. I don't get it, but I'm learning to expect it) (c) It makes it more difficult to edit (our wiki doesn't seem to let you edit a single section of a document) Even split up by section as we have it now, there are 30+ questions in a lot of the sections, so they'd still be pretty big. I find editing the Members Manual actually kinda annoying because of its size. You have to search through the entire document to find the segment you want. I suspect a lot of people will decide this is just annoying enough that they won't go update an FAQ entry as a result... and this is exactly what we want to avoid! So my gut says a nice index like you've got is terrific, but the answers should probably be one-page-per-answer. You might even be able to get the wiki to make the index for you if you put all the FAQ entries in one section or as children to one page (the index?) or something... Terri From japruim at raoset.com Tue Mar 11 16:00:41 2008 From: japruim at raoset.com (Jason Pruim) Date: Tue, 11 Mar 2008 11:00:41 -0400 Subject: [Mailman-Developers] Documentation status? In-Reply-To: References: <20080305195338.GA12322@amk-desktop.matrixgroup.net> <8D5D8DBD-D3C8-4C52-93E0-94A09226AD7A@zone12.com> <2CC52649-9F17-4079-8B14-BA54AF2C8DD4@list.org> <129A3B16-0505-4A12-A673-87E61CDDD98C@zone12.com> <4BD7F651-32F0-43DB-872E-F0355FBF82CA@raoset.com> Message-ID: On Mar 11, 2008, at 12:44 AM, Terri Oda wrote: > > On 6-Mar-08, at 2:18 PM, Jason Pruim wrote: >> I've been watching this thread with interest and would like to help >> where I can... I don't know Python, so I can't exactly help program, >> but I've been told I can translate technological info into something >> the normal person could understand. So what do I have to do to start >> helping? :) > > Hi Jason! Sorry it took me so long to get back to you -- been a > busy week! > > So, what I'd suggest you do first is hook yourself up with a wiki > account, look around at the documentation that's currently on the > mailman website, and import all of it into the wiki. Try to figure > out what's up to date and what isn't and make it obvious. Try to > figure out nice ways to organize it. You know, all that stuff. :) > Maybe import all those FAQ entries somehow, or at least lay out a > structure so someone else can just cut and paste. > > This accomplishes two things: > > (a) we have more nicely organized and linked docs that are easier to > edit (I really think this is the most important documentation task > on the table at the moment) > > (b) you will have a good idea of what documentation we have and > where the gaps are, so you'll be able to figure out what documents > you want to work on writing as a next phase to this! > > Sound appealing? I'm sure I can come up with other ideas if this > isn't up your alley, but if you can translate technical info to > humanspeak, you'd probably do a great job organizing stuff in a way > that real people can actually find the information they want. :) > > Terri Hi Terri, I can work on that... I already have a wiki account, and it looks like I can edit pages... I would like to get some opinions on how to do the FAQ's... I have some for my company website (Not related to mailman) but what I did was a list of all the questions up at the top of the page with named anchors linking down to the actual answer... Maybe the best way to describe it would be to show you.. Sorry if this is bad form... Just trying to help! :) http://raoset.com/faqs/faqs.shtml Let me know if that looks like a good way for these... I can make the transfer pretty quickly if this looks like it would be a good thing. Or if anyone has any better ideas on how to do them, I'm open to ideas :) -- Jason Pruim Raoset Inc. Technology Manager MQC Specialist 3251 132nd ave Holland, MI, 49424-9337 www.raoset.com japruim at raoset.com From fmouse-mailman at fmp.com Wed Mar 12 07:58:13 2008 From: fmouse-mailman at fmp.com (Lindsay Haisley) Date: Wed, 12 Mar 2008 01:58:13 -0500 Subject: [Mailman-Developers] A couple of possible fixes to Mailman 2.1.9 Message-ID: <1205305093.24885.97.camel@vishnu.fmp.com> These are a few things I found while debugging my Mailman installation after the Gentoo mailman ebuild maintainer brought PREFIX and VAR_PREFIX in line with the Linux standard FSH. The changes are distribution-neutral but fix a couple of issues that crop up when PREFIX != VAR_PREFIX. check_perms_grsecurity.py is a contrib piece, but should be patched as follows: @@ -132,8 +132,8 @@ print file print "\nEnsuring that all config.db/pck files are owned by Mailman" - cdbs = glob.glob(paths.prefix + '/lists/*/config.db*') - cpcks = glob.glob(paths.prefix + '/lists/*/config.pck*') + cdbs = glob.glob(paths.var_prefix + '/lists/*/config.db*') + cpcks = glob.glob(paths.var_prefix + '/lists/*/config.pck*') for file in cdbs + cpcks: stat = os.stat(file) var_prefix isn't defined in paths.py, but probably should be. Adding: var_prefix = 'whatever ...' after line 31 in paths.py takes care of this, and var_prefix can be set by the autoconf/configure process in the install. ~mailman/bin/update may need to be patched as follows: @@ -344,7 +344,7 @@ # a new one there # tmpl_dir = os.path.join(mm_cfg.PREFIX, "templates") - list_dir = os.path.join(mm_cfg.PREFIX, "lists") + list_dir = os.path.join(mm_cfg.VAR_PREFIX, "lists") b4_tmpl_dir = os.path.join(tmpl_dir, mlist._internal_name) new_tmpl_dir = os.path.join(list_dir, mlist._internal_name) if os.path.exists(b4_tmpl_dir): I may be out to lunch on this one, but it got my attention. Does the use of PREFIX for the lists directory here apply to a legacy version of Mailman ("pre-b4")? If so, then perhaps this isn't an error. -- Lindsay Haisley | "Everything works | PGP public key FMP Computer Services | if you let it" | available at 512-259-1190 | (The Roadie) | http://pubkeys.fmp.com http://www.fmp.com | | From mark at msapiro.net Wed Mar 12 15:34:34 2008 From: mark at msapiro.net (Mark Sapiro) Date: Wed, 12 Mar 2008 07:34:34 -0700 Subject: [Mailman-Developers] [Mailman-Users] Mailman topic duplication In-Reply-To: <1f869bdd0803112305m5c85a649v2c787ba21bc09ec4@mail.gmail.com> Message-ID: Prashanth wrote: > > When i add same topic repeatedly it keeps adding (i >could see topic duplications), Is this a bug? If I type the same thing twice If I type the same thing twice and my MUA allows it, is it a bug? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From shiva at sewingwitch.com Wed Mar 12 17:58:25 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 12 Mar 2008 09:58:25 -0700 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: References: Message-ID: <8772784277AC90CB6FD149BA@[10.170.7.6]> --On Tuesday, March 04, 2008 12:30 PM -0800 Jo Rhett wrote: > 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by > default. Nearly everyone uses web based signup. Here's the list of valid actions from mm-handler: @ValidActions = qw(admin bounces confirm join leave owner request subscribe unsubscribe); Which ones should be left enabled? From fmouse-mailman at fmp.com Wed Mar 12 18:04:35 2008 From: fmouse-mailman at fmp.com (Lindsay Haisley) Date: Wed, 12 Mar 2008 12:04:35 -0500 Subject: [Mailman-Developers] Referencing internal list names in TOC templates Message-ID: <1205341475.24885.112.camel@vishnu.fmp.com> I mentioned this before, about a year and a half ago, but I don't know if it ever got any notice, since it's not in the 2.1.9 code. Please excuse me if this is already in the pipeline and scheduled for a future version. I just came on it again after a Gentoo Mailman upgrade which made me rebuild everything. If one is modifying Mailman TOC templates, as is necessary, for instance, when implementing the Namazu search engine or working with PHP code in templates, it can be extremely useful, and sometimes quite necessary to know the "internal" name of a list. This is easily done by adding one line to HyperArch.py: --- HyperArch.py.orig 2006-10-16 20:25:22.000000000 -0500 +++ HyperArch.py 2006-10-16 20:28:35.000000000 -0500 @@ -752,6 +752,7 @@ listname = mlist.internal_name() mbox = os.path.join(mlist.archive_dir()+'.mbox', listname+'.mbox') d = {"listname": mlist.real_name, + "internal": mlist.internal_name(), "listinfo": mlist.GetScriptURL('listinfo', absolute=1), "fullarch": '../%s.mbox/%s.mbox' % (listname, listname), "size": sizeof(mbox, mlist.preferred_language), This allows one to use "%(internal)s" as a replacement token in template code. -- Lindsay Haisley | "In an open world, | PGP public key FMP Computer Services | who needs Windows | available at 512-259-1190 | or Gates" | http://pubkeys.fmp.com http://www.fmp.com | | From amk at amk.ca Thu Mar 13 15:31:08 2008 From: amk at amk.ca (A.M. Kuchling) Date: Thu, 13 Mar 2008 10:31:08 -0400 Subject: [Mailman-Developers] Enhancing the bounce log In-Reply-To: References: <20080310192125.GA12622@amk-desktop.matrixgroup.net> Message-ID: <20080313143108.GB6733@amk-desktop.matrixgroup.net> On Mon, Mar 10, 2008 at 02:24:57PM -0700, Mark Sapiro wrote: > I've looked at the patch, and I wonder why it doesn't include the '<' > and '>' in the log entries. According to RFC 2822, the '<' and '>' are I had a vague wrong impression that Mailman didn't include them in the logs; I've uploaded an updated version of the patch that keeps the angle brackets. --amk From japruim at raoset.com Thu Mar 13 15:38:32 2008 From: japruim at raoset.com (Jason Pruim) Date: Thu, 13 Mar 2008 10:38:32 -0400 Subject: [Mailman-Developers] Documentation status? In-Reply-To: <866A29BB-6AFB-4FA2-AC50-D30B5699825F@zone12.com> References: <20080305195338.GA12322@amk-desktop.matrixgroup.net> <8D5D8DBD-D3C8-4C52-93E0-94A09226AD7A@zone12.com> <2CC52649-9F17-4079-8B14-BA54AF2C8DD4@list.org> <129A3B16-0505-4A12-A673-87E61CDDD98C@zone12.com> <4BD7F651-32F0-43DB-872E-F0355FBF82CA@raoset.com> <866A29BB-6AFB-4FA2-AC50-D30B5699825F@zone12.com> Message-ID: On Mar 11, 2008, at 10:59 PM, Terri Oda wrote: > On 11-Mar-08, at 11:00 AM, Jason Pruim wrote: > > I like this style when you have a smaller number of questions, but > there are probably over 200 entries in the the Mailman FAQ. I think > putting them all on one page is less than ideal: > > (a) It makes for a big, unpleasant to load page > (b) It makes it awkward to print off the answer to a specific > question (seriously, people seem to print docs a lot. I don't get > it, but I'm learning to expect it) > (c) It makes it more difficult to edit (our wiki doesn't seem to let > you edit a single section of a document) > Yeah, I see the issue with that, always scrolling back up to the top to see the index might be a bit of a pain... I'll probably download the text of the questions/answers to my computer this weekend so I can work on organizing them without screwing up what is already there :) > Even split up by section as we have it now, there are 30+ questions > in a lot of the sections, so they'd still be pretty big. I find > editing the Members Manual actually kinda annoying because of its > size. You have to search through the entire document to find the > segment you want. I suspect a lot of people will decide this is > just annoying enough that they won't go update an FAQ entry as a > result... and this is exactly what we want to avoid! > > So my gut says a nice index like you've got is terrific, but the > answers should probably be one-page-per-answer. One page per answer, with links to the previous/next questions as well as the index? So for the people who are reading each one, they would be able to flip between them without going back and then picking the next one... > > > You might even be able to get the wiki to make the index for you if > you put all the FAQ entries in one section or as children to one > page (the index?) or something... I'll play with the wiki, Maybe make a page just to play with... I don't have a TON of experience with wiki's, but I know the basics, If I do make a page just for testing can I transfer that to a different page after it's formatted correctly? -- Jason Pruim Raoset Inc. Technology Manager MQC Specialist 3251 132nd ave Holland, MI, 49424-9337 www.raoset.com japruim at raoset.com From sub2.dev.mailman at msquared.id.au Thu Mar 13 15:12:47 2008 From: sub2.dev.mailman at msquared.id.au (Msquared) Date: Thu, 13 Mar 2008 23:12:47 +0900 Subject: [Mailman-Developers] 1-click unsubscribe In-Reply-To: <8E592366C806C2A59D1AF786@lewes.staff.uscs.susx.ac.uk> References: <87wspggpk2.fsf@uwakimon.sk.tsukuba.ac.jp> <873as2oj5o.fsf@uwakimon.sk.tsukuba.ac.jp> <87y792kj99.fsf@uwakimon.sk.tsukuba.ac.jp> <47CB3247.2000406@thecsl.org> <2AC8E914-16AE-4D08-A24F-D07DF149E981@list.org> <919E8414B34C863C210FE637@lewes.staff.uscs.susx.ac.uk> <8E592366C806C2A59D1AF786@lewes.staff.uscs.susx.ac.uk> Message-ID: <20080313141247.GA19761@sliderule.msquared.net.au> On Mon, Mar 10, 2008 at 12:06:22PM +0000, Ian Eiloart wrote: > > So its an HTTP GET - which is supposed to be idempotent. I know a > > while back there was discussion of SpamAssassin modules which > > evaluated linked webpages for spamminess - presumably that action > > would clear someone off the list too! > > It's an interesting point, but there are plenty of un/subscribe and > request verification mechanisms out there which do exactly this. > Including in Mailman, I think. Just because there are plenty of them out there, doesn't mean they are a good idea... Regards, Msquared... From mark at msapiro.net Fri Mar 14 03:26:54 2008 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 13 Mar 2008 19:26:54 -0700 Subject: [Mailman-Developers] Mailman 2.1.10b4 Released Message-ID: <47D9E26E.4040708@msapiro.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am happy to announce the next beta release of Mailman 2.1.10. This is a security and bug fix release and it is highly recommended that all sites upgrade to this version. Mailman 2.1.10 also adds support for three new language translations, Galician, Hebrew and Slovak and a few new features. Mailman is free software for managing email mailing lists and e- newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, including download links, please see: http://www.list.org http://mailman.sf.net http://www.gnu.org/software/mailman Special thanks are due to Barry Warsaw and Tokio Kikuchi for much coding and support, Moritz Naumann for help with security issues and Jim Tittsler for a significant patch. Here's a list of the major changes. Security - - The 2.1.9 fixes for CVE-2006-3636 were not complete. In particular, some potential cross-site scripting attacks were not detected in editing templates and updating the list's info attribute via the web admin interface. This has been assigned CVE-2008-0564 and has been fixed. Thanks again to Moritz Naumann for assistance with this. New Features - - Changed cmd_who.py to list all members if authorization is with the list's admin or moderator password and to accept the password if the roster is public. Also changed the web roster to show hidden members when authorization is by site or list's admin or moderator password (1587651). - - Added the ability to put a list name in accept_these_nonmembers to accept posts from members of that list (1220144). - - Added a new 'sibling list' feature to exclude members of another list from receiving a post from this list if the other list is in the To: or Cc: of the post or to include members of the other list if that list is not in the To: or Cc: of the post (Patch ID 1347962). - - Added the admin_member_chunksize attribute to the admin General Options interface (Bug 1072002, Partial RFE 782436). Internationalization - - Added the Hebrew translation from Dov Zamir. This includes addition of a direction ('ltr', 'rtl') to the LC_DESCRIPTIONS table. The add_language() function defaults direction to 'ltr' to not break existing mm_cfg.py files. - - Added the Slovak translation from Martin Matuska. - - Added the Galician translation from Frco. Javier Rial Rodr?guez. Changes since 2.1.10b3 include the Galician translation and updates to the French translation (Vietnamese and Danish translations were updated in 2.1.10b3). Other changes since 2.1.10b3 include: - - In 2.1.9, queue runner processing was made ~ more robust by making backups of queue entries when they were dequeued ~ so they could be recovered in the event of a system failure. This ~ opened the possibility that if a message itself caused a runner to ~ crash, a loop could result that would endlessly reprocess the message. ~ This has now been fixed by adding a dequeue count to the entry and ~ moving the entry aside and logging the fact after the third dequeue of ~ the same entry. - - Fixed the command line scripts add_members, sync_members and ~ clone_member to properly handle banned addresses (1904737). - - Fixed bin/newlist to add the list's preferred language to the list's ~ available_languages if it is other than the server's default language ~ (1906368). - - Changed the first URL in the RFC 2369 List-Unsubscribe: header to go ~ to the options login page instead of the listinfo page. - - Changed the options login page to not issue the "No address given" ~ error when coming from the List-Unsubscribe and other direct links. ~ Also changed to remember the user's language selection when ~ redisplaying the page following an error. /Mark Sapiro - -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFH2eJuVVuXXpU7hpMRAihOAJ4zIREWCWCQt7YDDHp3frDHjzwkCQCfdh7J W3UKWsTTfStBE4z64oqa36c= =ZedT -----END PGP SIGNATURE----- From iane at sussex.ac.uk Fri Mar 14 12:30:46 2008 From: iane at sussex.ac.uk (Ian Eiloart) Date: Fri, 14 Mar 2008 11:30:46 +0000 Subject: [Mailman-Developers] [Mailman-Announce] Mailman 2.1.10b4 Released In-Reply-To: <47D9E26E.4040708@msapiro.net> References: <47D9E26E.4040708@msapiro.net> Message-ID: <36898B72F6D4423EF51C29C3@lewes.staff.uscs.susx.ac.uk> --On 13 March 2008 19:26:54 -0700 Mark Sapiro wrote: > > - - Added a new 'sibling list' feature to exclude members of another list > from receiving a post from this list if the other list is in the To: or > Cc: of the post or to include members of the other list if that list is > not in the To: or Cc: of the post (Patch ID 1347962). I don't understand this feature.... Hmm, Tokio Kikuchi asked about the name in 2005. I'm sorry that I didn't comment earlier. Sibling is a *completely* misleading term for this feature, because sibling relationships are necessarily symmetrical: if A is a sibling of B, then B must be a sibling of A. This feature is necessarily anti-symmetrical, more like "child" or "descendent". The term "sibling" will lead people to misconfigure their lists. Question: is the relationship also transitive? IE, if C is a child of B, and B is a child of A, then will postings to A go to members of C? If so, then the relationship should be called "descendent". As far as inclusion is concerned, we then have a partially ordered set of mailing lists under this relationship. If the code handles the (presumably erroneous case) where a list is marked as a "sibling" of itself properly (ie, the listing should be ignored). -- Ian Eiloart IT Services, University of Sussex x3148 From shiva at sewingwitch.com Fri Mar 14 17:10:32 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 14 Mar 2008 09:10:32 -0700 Subject: [Mailman-Developers] anti-backscatter mm-handler (was before next release: disablebackscatter in default installation) In-Reply-To: <2043056A9AF44CA70F59A180@[10.0.0.14]> References: <2043056A9AF44CA70F59A180@[10.0.0.14]> Message-ID: <93BEF122617C33437BE0ED5C@[10.0.0.14]> BTW, the experimental mm-handler isn't currently letting posts through, but I haven't had a chance to debug it. I'll try to look at it this weekend. It no longer reports an error, though, once I fixed the permissions. From lars.reimann at googlemail.com Fri Mar 14 21:02:58 2008 From: lars.reimann at googlemail.com (Lars Reimann) Date: Fri, 14 Mar 2008 21:02:58 +0100 Subject: [Mailman-Developers] Question about specific place of source code Message-ID: <59acdf910803141302u27951ff4n47d7f177b91ec7c4@mail.gmail.com> Hi all, i am using mailman 2.1.9. I am making some customizations, and i have a questions about MIME Content-Type. (I have crawled through the archives...) If I add a message header (msg_header and msg_footer) mailman sets the > Content-Type: text/plain; charset="us-ascii" My Question is, if anyone can please point me to the line of code, where this is added to a message. I already looked in Decorate.py but my alterations (e.g. comment out the header addition) did not make any difference. So the place where i looked might not be correct. I want to see how these are constructed and maybe alter to fit my customization. Any urgent help would be greatly appreciated. Thanks so far, L.R. From mark at msapiro.net Sat Mar 15 15:54:12 2008 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 15 Mar 2008 07:54:12 -0700 Subject: [Mailman-Developers] Question about specific place of source code In-Reply-To: <59acdf910803141302u27951ff4n47d7f177b91ec7c4@mail.gmail.com> Message-ID: Lars Reimann wrote: > >If I add a message header (msg_header and msg_footer) mailman sets the > >> Content-Type: text/plain; charset="us-ascii" > >My Question is, if anyone can please point me to the line of code, >where this is added to a message. I already looked in Decorate.py but >my alterations (e.g. comment out the header addition) did not make any >difference. So the place where i looked might not be correct. > >I want to see how these are constructed and maybe alter to fit my >customization. The addition of headers and footers is done by Decorate.py. When they are added as separate MIME parts, the parts are constructed by email.MIMEText.MIMEText() which is called in four places in Decorate.py. If you are asking about the case where the message is a single text/plain part and the header and/or footer are added to that part. The overall message Content-Type: is set by del msg['content-transfer-encoding'] del msg['content-type'] msg.set_payload(payload, newcset) It is the email.Message.Message.set_payload() method that actually sets the Content-Type: and Content-Transfer-Encoding: appropriate to the payload (message body) being set. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From mark at msapiro.net Tue Mar 18 03:28:41 2008 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 17 Mar 2008 19:28:41 -0700 Subject: [Mailman-Developers] before next release: disable backscatter in default installation References: 0C4F5F7D-CB5D-4CE7-8C54-872413A44D36@netconsonance.com Message-ID: <47DF28D9.4080302@msapiro.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry for not replying to this sooner, but I was busy and then it got buried. Jo Rhett wrote: | On Mar 4, 2008, at 3:28 PM, Mark Sapiro wrote: | |> Even if we wanted to do this, it is non-trivial. All confirmation |> messages and their templates and translations would have to be changed |> to remove references to confirmation by email. | | Text changes are trivial. Code changes require work/testing/etc. Well, yes and no. A code change is work, but I can unit test it, integration test it and expose it by installing it on my production server. I can do this on my own and on my own schedule. A text change breaks 35 existing Mailman translations, and breaks them to the extent that changing a single character in the English text, causes that text to be rendered in English on the translated page. This requires 35 translators or translation teams to update their translations. This is anything but trivial. |> Do you object to any response at all, or just to responses that |> include |> the original message text? | | Any response sent to an innocent victim of forgery. | |> If the former, then you must object to DSNs |> from MTAs as well. If the latter, that is planned to be addressed in |> Mailman 2.2. | | Of course we object to DSNs from MTAs. No shipping mailserver | currently sends DSNs to accepted mail by default. Most of them | haven't for like 10 years. And yes, we absolutely ban qmail from use | unless the person patches it to the moon to solve its problems. I'm not talking about DSNs to non-accepted mail. I'm talking about a message that is accepted by an MX, queued and later rejected by the ultimate destination. When the MX gets the reject from the destination, does it say "oops, I screwed up, I never should have accepted and queued this message" and just drop it, or does it return a DSN. Does this make sense, or am I stuck in the 20th century? - -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFH3yjZVVuXXpU7hpMRAlk/AJ9LxZz66hcGiTqpqUcMuZsgLASr+wCeNVIQ ILs8O7pVmBYux+M6r28X7P8= =qGpO -----END PGP SIGNATURE----- From mark at msapiro.net Tue Mar 18 04:16:42 2008 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 17 Mar 2008 20:16:42 -0700 Subject: [Mailman-Developers] Per-user subject prefix setting In-Reply-To: Message-ID: Kenneth Porter wrote: > > > >There seems to be limited code for customizing messages per-user, but this >setting may want to be treated as some kind of user "class" setting so that >messages can still be batched for the no-prefix class and the add-prefix >class. Perhaps this could be implemented as two distinct queues, similar to >the way digests are treated as a distinct queue. It's probably easier than that. It's more like some digest users getting MIME digests and some getting plain. As I see it, what would need to be done is to remove the prefixing from CookHeaders and have SMTPDirect split the recipient list and make two copies of the message, one which gets prefixed and delivered to the 'prefix' list and the other doesn't get prefixed and gets delivered to the 'no prefix' list. It might be better to have CalcRecips do the list splitting, but the idea is the same. There would have to be some list default which would presumably apply to new members. Recipients who get the post because of 'regular_include_lists' might get the list default or get a prefix based on their 'included list' setting - another argument for splitting the list in CalcRecips. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From t.d.lee at durham.ac.uk Thu Mar 20 11:41:12 2008 From: t.d.lee at durham.ac.uk (David Lee) Date: Thu, 20 Mar 2008 10:41:12 +0000 (GMT) Subject: [Mailman-Developers] Has Mailman lost its way? Message-ID: First there was Majordomo... Once upon a time, Majordomo version one was the leader in its field. So good was it, that ambitious plans were laid for a succeeding generation: version two. And at that point it went off the rails and ended up in a ditch. 'Domo V1 got stuck, because the development went into 'Domo V2. But V2 got stuck because it never got released and never got used. And so the once glorious Majordomo sadly faded into the night-time of obscurity. Move forward a few years... In another place, at a later time, Mailman v2.1 became the leader in its field. So good was it, that ambitious plans were laid, not just for one, but for two, succeeding generations: v2.2 and v3. And at that point... ... well what has happened? Nearly two years ago, the July 5 2006 "What I did on my summer vacation" email and wiki entry (http://wiki.list.org/x/vg) outlined a massive amount of potential progress. But, in reality, what actually have we (the subset of real-world end-users who could assist development) been able to do? Has Mailman lost its way? Could it be drifting to the same obscurity and oblivion as the entire majordomo project? Could I suggest that serious consideration be given to: 1. Freeze 2.1 now. No new features. The only exception would be security bug-fixes. Nothing else. 2. Freeze "new idea" development now. Concentrate solely on bugfixing the already implemented ideas. 3. Decide whether 2.2 or 3.0 is the way of the near future. The reality is that neither of these has delivered anything to the real-world end-user during two or more years. Choose only one. Freeze the other for the time being, until the "chosen one" has been properly post-beta released. 4. Whichever of the above is chosen, aim to start delivering betas fast. Get something out there that you (the main developers) and we (some real-world end-users who can help bug-hunt) can get to work on, knowing that our work will be productive in a foreseeable timescale. Set the goal. Drive towards it, ignoring distractions. 5. For a few months, change the mindset away from development (yes, I know we coders love it) and towards a firm, decisively-directed "release management" (to use ITIL-speak). Mailman used to be a leading product. But it is slipping behind. We, the end-users, need some of that new code that's being lying dormant, and (to an end-user) unuseable, during the last two years or so. Many of us, the enthusiastic real-world end-users, cannot realistically commit to developing something for which there is no clear strategy. Give us a strategy, a roadmap with real, near-future dates on it, then we can at least make local business cases to our local managements for our taking part in beta trials. Let's get some new code out now as beta. There may be a sizeable "TODO"; there may be a sizeable "Known Problems". But let's start releasing betas soon, and concentrate all our limited efforts on that one common task. Otherwise, are we not in danger of following Majordomo into oblivion? (Oh, and #1 on my own list is proper "virtual domains": the Jul/2005 paper mentioned that the code substantially existed. But sadly it's never come anywhere near a release schedule. If we have a realistic beta-release schedule, then I can locally justify actively investing in bug-hunting.) Sorry if that sounds harsh. It is meant to be constructive. (Honest!) Best wishes. -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : UNIX Team Leader Durham University : : South Road : : http://www.dur.ac.uk/t.d.lee/ Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. : From stanabe at uwo.ca Thu Mar 20 22:59:23 2008 From: stanabe at uwo.ca (Satoshi Tanabe) Date: Fri, 21 Mar 2008 06:59:23 +0900 Subject: [Mailman-Developers] GNU Mailman Site Redesign In-Reply-To: <964B9E4D-758A-4B0C-8691-25744618B55A@zone12.com> References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com> <964B9E4D-758A-4B0C-8691-25744618B55A@zone12.com> Message-ID: <42a95f60803201459kfdbcfcfwd23dc2f1308e9f8b@mail.gmail.com> Hi, Terri, thanks for your comments. (More to come later?) Here's another attempt to improve Mailman: Subscription Page Redesign: http://gnu.mailman.googlepages.com/Mailman-Subscription-Page-Redesign.ta.gz Again, feedback is welcome. - Satoshi 2008/3/12, Terri Oda : > > On 10-Mar-08, at 11:10 PM, Satoshi Tanabe wrote: > > This site tries to solve the problems that I listed in the > > following document: > > > > What's wrong with the current Mailman official site? > > http://gnu.mailman.googlepages.com/wrong.txt > > > > I'd love to have your feedback. Also, I listed several questions in > > the document above, so I'd appreciate if any of you could answer or > > comment on them (Some questions are not about the official site per > > se). > > > I haven't had a chance to seriously look at all the content or your > comments and questions, but wow, you do seem to be spot on about > simplifying the webpage being an improvement! > > I'd like to sit down and nitpick some stuff, but I know I won't have > time this week, so for now I just want to say that I'm very much in > favour of using this as a springboard to redesign the main site. > > > Terri > > From jrhett at netconsonance.com Tue Mar 25 02:07:29 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon, 24 Mar 2008 18:07:29 -0700 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: 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 Mailman installations*, not even those > that upgrade to 2.1.10. I understood. I'm trying to stem the flood of new installations that have this feature. > So the right thing to do is to get 2.1.10 out the door as is, and get > started on 2.2. No, it isn't. Based on current pace you're pushing the problem out for 2+ years. > Then you can even discuss shutting off the feature > in *existing* installations and requiring admins of *existing* > installations to reactivate the feature if they want it.[1] That > would very likely have noticeable effect *much sooner* than the change > proposed for 2.1.10, and would be much less disruptive. Huh? How exactly are you going to shut off the feature in an existing installation? Sorry, as stated your proposal sounds either naive or insane. No insult intended. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Tue Mar 25 02:14:38 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon, 24 Mar 2008 18:14:38 -0700 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <4D3C2500-2ADC-4FF8-BCF3-ABEF69F914F7@list.org> References: <20080305011346.GD5749@garp.metalab.unc.edu> <4D3C2500-2ADC-4FF8-BCF3-ABEF69F914F7@list.org> Message-ID: <3F8B7F4A-5093-4A33-8A10-C1A641068803@netconsonance.com> On Mar 5, 2008, at 3:05 PM, Barry Warsaw wrote: > through? Let's say you hold it, and a list admin approves it, saying > "hey this guy looks legit". Let's say you do this 5 times across 3 > different lists. I'm probably not a spammer, right? So maybe now I > can post to all your lists without being held. Nobody in an abuse department receives complaints about mailman servers which are holding their mail. No blacklists exist for mailman servers that hold mail. As long as the server doesn't send back a message about it being Held, doesn't matter in this context. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Tue Mar 25 02:16:31 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon, 24 Mar 2008 18:16:31 -0700 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: <46943F5EA82CA7EE31E8DEF2@[10.169.6.155]> References: <46943F5EA82CA7EE31E8DEF2@[10.169.6.155]> Message-ID: On Mar 6, 2008, at 11:13 AM, Kenneth Porter wrote: > On Tuesday, March 04, 2008 12:30 PM -0800 Jo Rhett > wrote: > >> 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by >> default. Nearly everyone uses web based signup. >> >> 2. Discard or hold messages from non-subscribers by default. > > How, exactly, does one do these? In particular, how do you remove the > aliases when using mm-handler to process mail from sendmail? (I'd > be happy > to start the wiki page once I have the information to put there.) You only need a single handler per list, and one for the server. Default install is like 10 aliases per list. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Tue Mar 25 02:24:19 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon, 24 Mar 2008 18:24:19 -0700 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <7902D674628CC82E16CE5010@[10.169.6.155]> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <7902D674628CC82E16CE5010@[10.169.6.155]> Message-ID: <4B180B15-5A04-40BD-960C-05CE606B7437@netconsonance.com> Thank you, Kenneth. This at least gives us something to point people to. FYI: ".h4 Discard or hold messages" ... On Mar 7, 2008, at 2:58 PM, Kenneth Porter wrote: > Initial text here: > > > > I grabbed some text from Jo Rhett's initial post in this thread and > then > added what I did to my installation. Those with more of a "big > picture" > view of the system can refine this. > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py > Searchable Archives: http://www.mail-archive.com/mailman-developers% > 40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman- > developers/jrhett%40netconsonance.com > > Security Policy: http://www.python.org/cgi-bin/faqw-mm.py? > req=show&file=faq01.027.htp -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Tue Mar 25 02:28:15 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon, 24 Mar 2008 18:28:15 -0700 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: <8772784277AC90CB6FD149BA@[10.170.7.6]> References: <8772784277AC90CB6FD149BA@[10.170.7.6]> Message-ID: > --On Tuesday, March 04, 2008 12:30 PM -0800 Jo Rhett > wrote: > >> 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by >> default. Nearly everyone uses web based signup. On Mar 12, 2008, at 9:58 AM, Kenneth Porter wrote: > Here's the list of valid actions from mm-handler: > > @ValidActions = qw(admin bounces confirm join leave > owner request subscribe unsubscribe); > > Which ones should be left enabled? In my experience, none of them. I've got a 1k+ list server running without any of these actions enabled, and have never had a problem with it. (obviously you also have to patch the headers added to list e-mail to not reference these names) Naturally, if you have someone who really does do list admin by e- mail (very rare) then you could leave one of these enabled for them. As long as an e-mail without any proper actions is dropped. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Tue Mar 25 02:34:41 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon, 24 Mar 2008 18:34:41 -0700 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: <47DF28D9.4080302@msapiro.net> References: 0C4F5F7D-CB5D-4CE7-8C54-872413A44D36@netconsonance.com <47DF28D9.4080302@msapiro.net> Message-ID: On Mar 17, 2008, at 7:28 PM, Mark Sapiro wrote: > A text change breaks 35 existing Mailman translations, and breaks them Sorry, yes you are right I forgot about translations. > I'm not talking about DSNs to non-accepted mail. I'm talking about a > message that is accepted by an MX, queued and later rejected by the > ultimate destination. When the MX gets the reject from the > destination, > does it say "oops, I screwed up, I never should have accepted and > queued > this message" and just drop it, or does it return a DSN. > > Does this make sense, or am I stuck in the 20th century? If you have an MX that queues mail for someone else and isn't configured to properly deal with DSNs, then yes, you are stuck in the 20th century. And yes, if your MX host was on our network (and sending DSNs to forged senders) we'd ask you to shut it down. ("ask" in non-optional sense) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Tue Mar 25 02:37:38 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon, 24 Mar 2008 18:37:38 -0700 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: <87fxv6vsjc.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87lk4yw1lj.fsf@uwakimon.sk.tsukuba.ac.jp> <17DFE61F-10E8-44CC-B825-771E32A06402@netconsonance.com> <87fxv6vsjc.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <5B7E246D-AD01-4F5D-BF49-C9229F434CEC@netconsonance.com> 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 release. Code changes to implement > it can, and should, wait for the next release. What? I'm sorry, but Mailman has been blamed for backscatter for like 3 years going now. This problem has been well known for long before 2.1.10 was even dreamed of. I am asking that the developers start paying attention *NOW*. If the problems aren't going to be solved before 2.2, then we're going to put Mailman in the same bin as qmail and say that using it is a violation of the AUP. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From mark at msapiro.net Tue Mar 25 02:45:22 2008 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 24 Mar 2008 18:45:22 -0700 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: Message-ID: Jo Rhett wrote: > >If you have an MX that queues mail for someone else and isn't >configured to properly deal with DSNs, then yes, you are stuck in the >20th century. 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 piece? That's what it seems to me that you are saying. If that's not what you are saying, then perhaps you can explain under what circumstances a DSN is OK. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From jrhett at netconsonance.com Tue Mar 25 03:03:02 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon, 24 Mar 2008 19:03:02 -0700 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: References: Message-ID: <6C848D55-A86A-4E76-8510-D47CF866CB78@netconsonance.com> 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 > piece? Yes. And not just me, but a dozen different blacklists. RTFM "backscatter" -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From stephen at xemacs.org Tue Mar 25 06:49:47 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 25 Mar 2008 14:49:47 +0900 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: <5B7E246D-AD01-4F5D-BF49-C9229F434CEC@netconsonance.com> References: <87lk4yw1lj.fsf@uwakimon.sk.tsukuba.ac.jp> <17DFE61F-10E8-44CC-B825-771E32A06402@netconsonance.com> <87fxv6vsjc.fsf@uwakimon.sk.tsukuba.ac.jp> <5B7E246D-AD01-4F5D-BF49-C9229F434CEC@netconsonance.com> Message-ID: <87skyfe4jo.fsf@uwakimon.sk.tsukuba.ac.jp> 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 release. Code changes to implement > > it can, and should, wait for the next release. > > What? I'm sorry, but Mailman has been blamed for backscatter for > like 3 years going now. If you say so. I first heard of the issue within the last year, and that in the context of bouncing back whole messages. And it wasn't from you. > This problem has been well known for long before 2.1.10 was even > dreamed of. I am asking that the developers start paying attention > *NOW*. Nobody has said they should ignore the problem, just that *you* are *way* too late in the process to expect them to stop the release of 2.1.10 for this major change in behavior (I almost certainly would stick with 2.1.9 + patches if this goes in hastily; my users do use those features). I don't speak for them; they might decide this *is* a showstopper. However, I have to wonder how your Mailman users will feel if you change your AUP, and they discover that the *only* post you've made (according to archive search) before going into BOFH mode is this one: Fri, 04 May 2007 13:06:34 -0700 I remember a number of threads about backscatter prevention, but I don't remember the result. Perusing the archives isn't much more enlightening. Where are we on this? In particular, other than removing all but one of the aliases, have we made it easier for people to run a backscatter proof list? Meaning that all subscribe, unsubscribe, etc are done on the web ui and nothing in the server automatically responds to e-mail other than legitimate list mail sent by subscribers? I also remember discussions about honoring SpamAssassin headers to detect spam. Status of this? I see no urgency from you there, it got no response from the developers (shame on them, but these things happen), and you dropped the topic for almost a year. From stephen at xemacs.org Tue Mar 25 07:21:19 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 25 Mar 2008 15:21:19 +0900 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <87r6dze334.fsf@uwakimon.sk.tsukuba.ac.jp> 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 Mailman installations*, not even those > > that upgrade to 2.1.10. > > I understood. I'm trying to stem the flood of new installations that > have this feature. Pure bluster. You have no data about "floods of new installations", and the window to a properly-tested 2.1.11 *for this change only* would be about 3-5 months, depending on code and template contributions and how important Mark and Barry think it is, and whether they're willing to push 2.1.11 out with few translations. This window for 2.1.10 is not going to add significantly to the backscatter from existing <2.1.10 installations. > > Then you can even discuss shutting off the feature > > in *existing* installations and requiring admins of *existing* > > installations to reactivate the feature if they want it.[1] > > Huh? How exactly are you going to shut off the feature in an > existing installation? 1. By fiat from the ISP, eg as you threaten to change your AUP. This would be most likely to well-received by ISP clients if combined with: 2. At upgrade time to say 2.1.11, a variable `enable_auto_reply' is added to Defaults.py, and set to false. Since no existing mm_cfg.py will have "enable_auto_reply = True" in it, this (along with the implied changes to the code, of course) would shut off the autoreplies for *every* existing Mailman installation that upgrades. This will not be feasible with your proposed change to 2.1.10. > Sorry, as stated your proposal sounds either naive or insane. No, just radical and unlikely to be implemented. But if implemented it will do one heck of a lot more for the backscatter problem than panicking as you propose we do. From stephen at xemacs.org Tue Mar 25 07:35:16 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 25 Mar 2008 15:35:16 +0900 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: <6C848D55-A86A-4E76-8510-D47CF866CB78@netconsonance.com> References: <6C848D55-A86A-4E76-8510-D47CF866CB78@netconsonance.com> Message-ID: <87prtje2fv.fsf@uwakimon.sk.tsukuba.ac.jp> 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 > > piece? > > Yes. And not just me, but a dozen different blacklists. Unfortunately this attitude does seem to be catching hold. I was told recently that a secondary MX would have to stop functioning as such because his ISP insists that he have an up to the second list of all valid mailboxes at my site; he's not allowed to relay undeliverable mail to me *ever*. So much for the whole concept of a store-and-forward mail system. :-( From mark at msapiro.net Tue Mar 25 17:07:56 2008 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 25 Mar 2008 09:07:56 -0700 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <87prtje2fv.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: Stephen J. Turnbull wrote: >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 > > > piece? > > > > Yes. And not just me, but a dozen different blacklists. > >Unfortunately this attitude does seem to be catching hold. I was told >recently that a secondary MX would have to stop functioning as such >because his ISP insists that he have an up to the second list of all >valid mailboxes at my site; he's not allowed to relay undeliverable >mail to me *ever*. > >So much for the whole concept of a store-and-forward mail system. :-( Well, it does simplify the MTA's job. Instead of all that queueing and retrying and such, you just have during SMTP (hold on a minute while I attempt to deliver this to the next hop and return that result to you)*N, a system that doesn't seem to scale well. Either that or you just forget the concept that the originator of a message can ever be informed of a delivery problem. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From jrhett at netconsonance.com Tue Mar 25 03:03:02 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon, 24 Mar 2008 19:03:02 -0700 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: References: Message-ID: <6C848D55-A86A-4E76-8510-D47CF866CB78@netconsonance.com> 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 > piece? Yes. And not just me, but a dozen different blacklists. RTFM "backscatter" -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From eino at utu.fi Tue Mar 25 18:06:05 2008 From: eino at utu.fi (Eino Tuominen) Date: Tue, 25 Mar 2008 19:06:05 +0200 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: References: Message-ID: <47E930FD.2000800@utu.fi> Mark Sapiro wrote: > > Well, it does simplify the MTA's job. Instead of all that queueing and > retrying and such, you just have during SMTP (hold on a minute while I > attempt to deliver this to the next hop and return that result to > you)*N, a system that doesn't seem to scale well. Either that or you > just forget the concept that the originator of a message can ever be > informed of a delivery problem. 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 outside your domain. -- Eino Tuominen From japruim at raoset.com Tue Mar 25 18:10:58 2008 From: japruim at raoset.com (Jason Pruim) Date: Tue, 25 Mar 2008 13:10:58 -0400 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <47E930FD.2000800@utu.fi> References: <47E930FD.2000800@utu.fi> Message-ID: <9F720A82-848F-4C5D-A158-ED0BB9A4492C@raoset.com> On Mar 25, 2008, at 1:06 PM, Eino Tuominen wrote: > Mark Sapiro wrote: >> >> Well, it does simplify the MTA's job. Instead of all that queueing >> and >> retrying and such, you just have during SMTP (hold on a minute >> while I >> attempt to deliver this to the next hop and return that result to >> you)*N, a system that doesn't seem to scale well. Either that or you >> just forget the concept that the originator of a message can ever be >> informed of a delivery problem. > > 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 outside your > domain. But how would you scale that to the size of say... yahoo? Multiple data centers around the world, all processing mail for different domains under yahoo's control... How would one be able to synchronize all that data from tons of different places like that? > > > -- > Eino Tuominen > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py > Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/japruim%40raoset.com > > Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp > -- Jason Pruim Raoset Inc. Technology Manager MQC Specialist 3251 132nd ave Holland, MI, 49424-9337 www.raoset.com japruim at raoset.com From mark at msapiro.net Tue Mar 25 18:59:19 2008 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 25 Mar 2008 10:59:19 -0700 Subject: [Mailman-Developers] before next release: disable backscatterindefault installation In-Reply-To: <47E930FD.2000800@utu.fi> Message-ID: Eino Tuominen wrote: > >You are missing the point. Of course you can inform of a delivery >problem, but only when you really need to do it. That's not what Jo Rhett seems to be saying at . -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From eino at utu.fi Tue Mar 25 19:13:14 2008 From: eino at utu.fi (Eino Tuominen) Date: Tue, 25 Mar 2008 20:13:14 +0200 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <9F720A82-848F-4C5D-A158-ED0BB9A4492C@raoset.com> References: <47E930FD.2000800@utu.fi> <9F720A82-848F-4C5D-A158-ED0BB9A4492C@raoset.com> Message-ID: <47E940BA.6070903@utu.fi> Jason Pruim wrote: > > But how would you scale that to the size of say... yahoo? Multiple data > centers around the world, all processing mail for different domains > under yahoo's control... How would one be able to synchronize all that > data from tons of different places like that? Well, Scale-out is always hard, and enterprises like Yahoo and such are facing a lot of difficult challenges in their environment, but if I may put my two cents in how about letting gateways query some sort of probabilistic datastructure, e.g. bloom filters, to find if an address is known? You could generate bloom filters from the different directories, and distribute those filters via DNS or LDAP. With a few hundred megabytes of memory you can store millions of entries in the filter with error probability something like under 1/1000. That means you end up sending only under 1/1000th of DSN messages you are sending now. -- Eino Tuominen From stephen at xemacs.org Tue Mar 25 21:18:44 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 26 Mar 2008 05:18:44 +0900 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <47E930FD.2000800@utu.fi> References: <47E930FD.2000800@utu.fi> Message-ID: <87bq52eevv.fsf@uwakimon.sk.tsukuba.ac.jp> 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 outside your domain. Says who? There is nothing in the standards that says so. And if you take that seriously, you have to disable .forward and procmail for individual users, as well as refuse to allow open subscription mailing lists and the like. This may make sense in the U.S. Army and in corporations with a military authority structure, but it does not in most universities, research, or open communities. That is *not* the way Internet mail is designed to work. Mail, like every other application on the Internet, is intended to be decentralized. It is designed to allow load-sharing by use of intermediate and/or secondary MXes to handle primary crashes or overloads. From barry at python.org Tue Mar 25 21:58:17 2008 From: barry at python.org (Barry Warsaw) Date: Tue, 25 Mar 2008 16:58:17 -0400 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: <5B7E246D-AD01-4F5D-BF49-C9229F434CEC@netconsonance.com> References: <87lk4yw1lj.fsf@uwakimon.sk.tsukuba.ac.jp> <17DFE61F-10E8-44CC-B825-771E32A06402@netconsonance.com> <87fxv6vsjc.fsf@uwakimon.sk.tsukuba.ac.jp> <5B7E246D-AD01-4F5D-BF49-C9229F434CEC@netconsonance.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 24, 2008, at 9:37 PM, Jo Rhett wrote: > 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 release. Code changes to implement >> it can, and should, wait for the next release. > > What? I'm sorry, but Mailman has been blamed for backscatter for > like 3 years going now. This problem has been well known for long > before 2.1.10 was even dreamed of. I am asking that the developers > start paying attention *NOW*. > > If the problems aren't going to be solved before 2.2, then we're > going to put Mailman in the same bin as qmail and say that using it > is a violation of the AUP. Now that there's documentation, I don't think you need to be that severe. Not everybody needs or wants this particular behavior. Those that do should now have the information at their fingertips. If downstream distributions want to change the defaults they are free to do so. This simply cannot be changed in Mailman 2.1. For one thing, it's a major feature change, not a security fix. A security problem would be something like a cross-site scripting vulnerability or remote root exploit. For another, pushing back 2.1.10 guarantees that 2.2 will be delayed because of the extra q/a that needs to happen, etc. This isn't a trivial change and we have limited resources. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR+lnaXEjvBPtnXfVAQKXCwQAk6y1e4juyw4DAh6XIoYzKdSFzZ4/2h9U 3Ql6dfeU14niMIpJPYlf3qKTECu5aI21q+yAlT8t4yud48aAAgqTMkGPWMQ93T8A OZ8YWUhxMypzkxYIyR/X/W/n3rhthdPY3Y6a13F5NhlATEPwQXuXaIwxaN/m7FSC HxTNcT69OrU= =aWxK -----END PGP SIGNATURE----- From eino at utu.fi Tue Mar 25 22:51:59 2008 From: eino at utu.fi (Eino Tuominen) Date: Tue, 25 Mar 2008 23:51:59 +0200 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <87bq52eevv.fsf@uwakimon.sk.tsukuba.ac.jp> References: <47E930FD.2000800@utu.fi> <87bq52eevv.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <47E973FF.5090205@utu.fi> Stephen J. Turnbull wrote: > 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 outside your domain. > > Says who? There is nothing in the standards that says so. And if you The times, they are a-changing... We are facing a new world and old habits are not the best ways to do things anymore. I'm certainly not one of those deeming all DSN's as evil, but it really hurts our users when some spammer starts a campaing forging sender addresses to look like ours. All the backscatter that is not absolutely necessary is evil. I know, we are still sending it out, too, but I'm actively working on the issue. -- Eino Tuominen From barry at python.org Tue Mar 25 23:20:29 2008 From: barry at python.org (Barry Warsaw) Date: Tue, 25 Mar 2008 18:20:29 -0400 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: <6C848D55-A86A-4E76-8510-D47CF866CB78@netconsonance.com> References: <6C848D55-A86A-4E76-8510-D47CF866CB78@netconsonance.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 24, 2008, at 10:03 PM, Jo Rhett wrote: > 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 >> piece? > > Yes. And not just me, but a dozen different blacklists. RTFM > "backscatter" I think you will be happier with what is possible in Mailman 3. In mm3 we have a working LMTP server, those it's based on asyncore and its scalability is questionable. Although I have not yet done this, I plan to tie the rule chain checker into LMTP so that if your MTA supports LMTP delivery the following can happen: worldwildwonderland -> SMTP -> MM's LMTP -> rule checks The rule checks then could tell LTMP to reject the message right there, which would return 5xx to SMTP and /it/ would return 5xx to whatever upstream SMTP its talking to. Now, I wouldn't want to do a lot of work at that point, but some simple checks would definitely be possible. You can reject messages as early in the process as possible and do it at the SMTP layer. While I think the LMTP code could be backported to 2.2, the rule chains stuff cannot. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR+l6rXEjvBPtnXfVAQJMEQP/RVWLJNRtQbH3UsWCLLi76ef/fOhCP5h8 /k0V/dkM7gmM2efjnfoK30VR88gxcDAHXCFZ4DxYSFCcPleHRfcp/DTgrnBq3ezv 4eG76PIjXXNfXx+DVHiafORSBWavyYmtIvOjt75tT6VPO99GbO3dA6wwdtWkDDeD oWVR6pkzjSA= =oBVb -----END PGP SIGNATURE----- From barry at list.org Tue Mar 25 23:28:51 2008 From: barry at list.org (Barry Warsaw) Date: Tue, 25 Mar 2008 18:28:51 -0400 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <47E973FF.5090205@utu.fi> References: <47E930FD.2000800@utu.fi> <87bq52eevv.fsf@uwakimon.sk.tsukuba.ac.jp> <47E973FF.5090205@utu.fi> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 25, 2008, at 5:51 PM, Eino Tuominen wrote: > Stephen J. Turnbull wrote: >> 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 outside >>> your domain. >> >> Says who? There is nothing in the standards that says so. And if >> you > > The times, they are a-changing... We are facing a new world and old > habits are not the best ways to do things anymore. I'm certainly not > one > of those deeming all DSN's as evil, but it really hurts our users when > some spammer starts a campaing forging sender addresses to look like > ours. All the backscatter that is not absolutely necessary is evil. I > know, we are still sending it out, too, but I'm actively working on > the > issue. In this regard, I don't view Mailman's job as to change the world. It's job is to adhere to standards, both formal (RFC) and best established practices. That doesn't mean I think Mailman should just spew bounce notices all over the place. I think Mailman should give sites the option to do reasonable bouncing, with rate limits, but also the option to remain totally silent. We should give people the option to keep their email responder addresses open, but also the ability to shut them off. IMO, all those policies are valid and in widespread use. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFH6Xyj2YZpQepbvXERAltmAJ4zYNpDGKuZQmQ4laBRqkE9pR06mgCfW31R rLSzzuk2SdqF/yRTmHvHivk= =EhmY -----END PGP SIGNATURE----- From jrhett at netconsonance.com Wed Mar 26 02:19:11 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 25 Mar 2008 18:19:11 -0700 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: <87skyfe4jo.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87lk4yw1lj.fsf@uwakimon.sk.tsukuba.ac.jp> <17DFE61F-10E8-44CC-B825-771E32A06402@netconsonance.com> <87fxv6vsjc.fsf@uwakimon.sk.tsukuba.ac.jp> <5B7E246D-AD01-4F5D-BF49-C9229F434CEC@netconsonance.com> <87skyfe4jo.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: On Mar 24, 2008, at 10:49 PM, Stephen J. Turnbull wrote: >> What? I'm sorry, but Mailman has been blamed for backscatter for >> like 3 years going now. > > If you say so. I first heard of the issue within the last year, and > that in the context of bouncing back whole messages. And it wasn't > from you. Don't read any spam mailing lists or even Wikipedia much, eh? > However, I have to wonder how your Mailman users will feel if you > change your AUP, and they discover that the *only* post you've made > (according to archive search) before going into BOFH mode is this one: Mailman is currently violating our AUP. I don't have any responsibility for that. In fact, my failure in this has been the amount of lenience I have given Mailman users, hoping that you guys would pay attention to all of the negative press and the fairly constant barrage of people on this list questioning these issues. > I see no urgency from you there, it got no response from the > developers (shame on them, but these things happen), and you dropped > the topic for almost a year. The topic has never been dropped. It has been repeatedly raised by me and others, both on this list and to the developers in person. It has been raised even in the print press. This whole "you didn't make us aware of this problem" approach you are taking here is... got no good words for this without being rude. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Wed Mar 26 02:28:14 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 25 Mar 2008 18:28:14 -0700 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <87r6dze334.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <87r6dze334.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <63F122FC-9CEA-4587-AE86-D393E3B22C75@netconsonance.com> On Mar 24, 2008, at 11:21 PM, Stephen J. Turnbull wrote: > Pure bluster. You have no data about "floods of new installations", We turn up X customers a week. We see X customers a week running into problems and getting blacklisted for backscatter. This is the "flood" I am trying to solve. What is your problem? I'm solving a technical issue. This kind of personal attack is irrelevant, and pointless. I don't care. >>> Huh? How exactly are you going to shut off the feature in an >> existing installation? > > 1. By fiat from the ISP, eg as you threaten to change your AUP. This > would be most likely to well-received by ISP clients if combined with: It's not a change of AUP. Mailman currently violates the AUP. And yes, we can force them to fix their installations with good documentation. We have it, but people protest that you don't support it. That was why I said two things were necessary - a documentation fix and a defaults fix. Read my original posts. > implied changes to the code, of course) would shut off the autoreplies > for *every* existing Mailman installation that upgrades. This will > not be feasible with your proposed change to 2.1.10. I don't care what changes are made. Don't waste time on my proposal, do something better. >> Sorry, as stated your proposal sounds either naive or insane. > > No, just radical and unlikely to be implemented. But if implemented > it will do one heck of a lot more for the backscatter problem than > panicking as you propose we do. Hyperbole like this wastes everyone's time. I don't care what is done. Do something that makes it better. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Wed Mar 26 02:29:45 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 25 Mar 2008 18:29:45 -0700 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: <87prtje2fv.fsf@uwakimon.sk.tsukuba.ac.jp> References: <6C848D55-A86A-4E76-8510-D47CF866CB78@netconsonance.com> <87prtje2fv.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: On Mar 24, 2008, at 11:35 PM, Stephen J. Turnbull wrote: > Unfortunately this attitude does seem to be catching hold. I was told > .... > So much for the whole concept of a store-and-forward mail system. :-( You are stuck in the last century, aren't you? No insult intended, honestly. Nobody I know of has done store and forward since the mid 90s. It defeats most spam control methods. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Wed Mar 26 02:33:08 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 25 Mar 2008 18:33:08 -0700 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <9F720A82-848F-4C5D-A158-ED0BB9A4492C@raoset.com> References: <47E930FD.2000800@utu.fi> <9F720A82-848F-4C5D-A158-ED0BB9A4492C@raoset.com> Message-ID: <7FF06F7B-D198-4A83-BB08-71F3ADAA9997@netconsonance.com> On Mar 25, 2008, at 10:10 AM, Jason Pruim wrote: > But how would you scale that to the size of say... yahoo? Multiple > data centers around the world, all processing mail for different > domains under yahoo's control... How would one be able to synchronize > all that data from tons of different places like that? Your disbelief has no relevance. Yahoo does do it. More to the point, I solved this problem for the Navy. 2.5 MILLION e- mail accounts, and they needed to stop accepting e-mail for accounts which didn't exist. To put this in perspective, I did this on a 386/25 processor with 16 megabytes of main memory in 1992. It's not a hard problem, and *every* modern mail system handles this properly. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Wed Mar 26 02:36:21 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 25 Mar 2008 18:36:21 -0700 Subject: [Mailman-Developers] before next release: disable backscatterindefault installation In-Reply-To: References: Message-ID: <15C0F020-EBC8-4FA1-A8C2-D95184276E7E@netconsonance.com> On Mar 25, 2008, at 10:59 AM, Mark Sapiro wrote: > Eino Tuominen wrote: >> >> You are missing the point. Of course you can inform of a delivery >> problem, but only when you really need to do it. > > > That's not what Jo Rhett seems to be saying at > 019928.html>. If you reject the mail during the SMTP phase, and it came from a legitimate sender, their mail server will return the DSN back to the sender. If it was spam, the spambot will go somewhere else. This is why you reject during SMTP session. Because if you don't, the spambot comes back to your supposed legal recipient and sends a bunch more forged mail. And each of those messages you bounce back to the innocent victim of forgery. Now that basic education is out of the way... -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Wed Mar 26 02:47:32 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 25 Mar 2008 18:47:32 -0700 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <87bq52eevv.fsf@uwakimon.sk.tsukuba.ac.jp> References: <47E930FD.2000800@utu.fi> <87bq52eevv.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <200C977A-AADF-4435-B313-302C22A50770@netconsonance.com> On Mar 25, 2008, at 1:18 PM, Stephen J. Turnbull wrote: >> 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 outside >> your domain. > > Says who? There is nothing in the standards that says so. And if you Again, you are welcome to do this. Please sign your systems up to the appropriate blacklists and save us the time. > That is *not* the way Internet mail is designed to work. Mail, like The Internet of 1990, yes, you're right. I was there. By 1993 everyone was already changing course, and by 1997 the Internet you're talking about didn't exist any more. Move along. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Wed Mar 26 02:50:11 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 25 Mar 2008 18:50:11 -0700 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: References: <87lk4yw1lj.fsf@uwakimon.sk.tsukuba.ac.jp> <17DFE61F-10E8-44CC-B825-771E32A06402@netconsonance.com> <87fxv6vsjc.fsf@uwakimon.sk.tsukuba.ac.jp> <5B7E246D-AD01-4F5D-BF49-C9229F434CEC@netconsonance.com> Message-ID: On Mar 25, 2008, at 1:58 PM, Barry Warsaw wrote: > Now that there's documentation, I don't think you need to be that > severe. The documentation is insufficient as it stands. The mailing list headers would contain addresses which no longer exist. But yes, an "official documentation configuration" from Mailman is enough for me ;-) > This isn't a trivial change and we have limited resources. That's fine, but this isn't the first time you and I have had this conversation, Barry. And there's more than one year between the time we first had this conversation and today. So can we not "forget about it" again? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Wed Mar 26 02:51:29 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 25 Mar 2008 18:51:29 -0700 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <47E973FF.5090205@utu.fi> References: <47E930FD.2000800@utu.fi> <87bq52eevv.fsf@uwakimon.sk.tsukuba.ac.jp> <47E973FF.5090205@utu.fi> Message-ID: On Mar 25, 2008, at 2:51 PM, Eino Tuominen wrote: > The times, they are a-changing... We are facing a new world and old > habits are not the best ways to do things anymore. I'm certainly > not one > of those deeming all DSN's as evil, but it really hurts our users when > some spammer starts a campaing forging sender addresses to look like > ours. All the backscatter that is not absolutely necessary is evil. Not all bounces are backscatter. My servers all deliver DSNs to the sender. My servers don't send backscatter. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Wed Mar 26 02:53:00 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 25 Mar 2008 18:53:00 -0700 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: References: <6C848D55-A86A-4E76-8510-D47CF866CB78@netconsonance.com> Message-ID: <28DD21DE-78C0-4953-9EC5-A60B6B5F09EE@netconsonance.com> On Mar 25, 2008, at 3:20 PM, Barry Warsaw wrote: > I think you will be happier with what is possible in Mailman 3. In > mm3 we have a working LMTP server, those it's based on asyncore and > its scalability is questionable. Although I have not yet done > this, I plan to tie the rule chain checker into LMTP so that if > your MTA supports LMTP delivery the following can happen: > > worldwildwonderland -> SMTP -> MM's LMTP -> rule checks That sounds like exactly the right solution. When do you think MM3 will be reasonable to use in production? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From mark at msapiro.net Wed Mar 26 02:59:16 2008 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 25 Mar 2008 18:59:16 -0700 Subject: [Mailman-Developers] before next release: disable backscatterindefault installation In-Reply-To: Message-ID: Jo Rhett wrote: > >Not all bounces are backscatter. My servers all deliver DSNs to the >sender. My servers don't send backscatter. So now we're back to my original question. Under what circumstances is it acceptable for an MTA to accept a message and then later return an undeliverable DSN? I thought previously you said 'none', but now you say your servers do it, so which is it? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From julian at mehnle.net Tue Mar 25 10:33:09 2008 From: julian at mehnle.net (Julian Mehnle) Date: Tue, 25 Mar 2008 09:33:09 +0000 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: <6C848D55-A86A-4E76-8510-D47CF866CB78@netconsonance.com> References: <6C848D55-A86A-4E76-8510-D47CF866CB78@netconsonance.com> Message-ID: <200803250933.13236.julian@mehnle.net> Jo Rhett wrote: > 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 > > piece? > > Yes. And not just me, but a dozen different blacklists. RTFM > "backscatter" You can however safely send a DSN if an SPF[1] check for the incoming message passes. 1. http://www.openspf.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mail.python.org/pipermail/mailman-developers/attachments/20080325/19844675/attachment.pgp From larsi at gnus.org Tue Mar 25 08:13:49 2008 From: larsi at gnus.org (Lars Magne Ingebrigtsen) Date: Tue, 25 Mar 2008 08:13:49 +0100 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: <87prtje2fv.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Tue, 25 Mar 2008 15:35:16 +0900") References: <6C848D55-A86A-4E76-8510-D47CF866CB78@netconsonance.com> <87prtje2fv.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: "Stephen J. Turnbull" writes: > Unfortunately this attitude does seem to be catching hold. I was told > recently that a secondary MX would have to stop functioning as such > because his ISP insists that he have an up to the second list of all > valid mailboxes at my site; he's not allowed to relay undeliverable > mail to me *ever*. These days, secondary MXs usually do SMTP callouts to verify whether email addresses are valid on the primary mail server. It does, however, make the concept of a "secondary MX" less useful than it used to be. -- (domestic pets only, the antidote for overdose, milk.) larsi at gnus.org * Lars Magne Ingebrigtsen From Dale at Newfield.org Wed Mar 26 05:12:28 2008 From: Dale at Newfield.org (Dale Newfield) Date: Wed, 26 Mar 2008 00:12:28 -0400 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <63F122FC-9CEA-4587-AE86-D393E3B22C75@netconsonance.com> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <87r6dze334.fsf@uwakimon.sk.tsukuba.ac.jp> <63F122FC-9CEA-4587-AE86-D393E3B22C75@netconsonance.com> Message-ID: <47E9CD2C.2060401@Newfield.org> Jo Rhett wrote: > I don't care what is done. Do something that makes it better. This is an open source project. You are welcome to use it as is or modify it to your liking. (I believe--someone confirm, please) you even have the right to distribute your modified version. You're welcome to make whatever changes you'd like for your own use or even offer the patches to this OPEN SOURCE project. Seeing as those running this are volunteers I see no reason they should jump to do your bidding. Seeing your attitude I see no reason they should want to. -Dale From stephen at xemacs.org Wed Mar 26 11:05:42 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 26 Mar 2008 19:05:42 +0900 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <63F122FC-9CEA-4587-AE86-D393E3B22C75@netconsonance.com> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <87r6dze334.fsf@uwakimon.sk.tsukuba.ac.jp> <63F122FC-9CEA-4587-AE86-D393E3B22C75@netconsonance.com> Message-ID: <87zlsler61.fsf@uwakimon.sk.tsukuba.ac.jp> 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's the best policy for Mailman. > I don't care what is done. Do something that makes it better. I'm not in a position to volunteer. It doesn't really sound like anyone else is, either. Have you thought about providing compensation to get this done? From iane at sussex.ac.uk Wed Mar 26 11:07:21 2008 From: iane at sussex.ac.uk (Ian Eiloart) Date: Wed, 26 Mar 2008 10:07:21 +0000 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <46AFF679D4EFB29F57698A4B@lewes.staff.uscs.susx.ac.uk> --On 24 March 2008 18:07:29 -0700 Jo Rhett wrote: > > Sorry, as stated your proposal sounds either naive or insane. No > insult intended. Please, think harder about what you write to the list. If you left an insult in there that you were aware of, then you *are* intentionally insulting people. I'm on your side in theory. I've been asking various mailing list developers to address this problem for years, with no progress anywhere. But, I've lost patience with your apparent aggression here. I'm pleased to see Mailman getting some development attention after what appears to have been quite a long break. I know, though, that the developers have been putting a lot of work in behind the scenes. I do want to see backscatter addressed - if spam and backscatter aren't indicative of security problems then I don't know what would be. I also want to see huge usability improvements. But, to see all of those things, we can't go trying to squeeze big changes into small updates. And I don't think that insulting volunteer developers is going to prove very productive. -- Ian Eiloart IT Services, University of Sussex x3148 From iane at sussex.ac.uk Wed Mar 26 11:54:57 2008 From: iane at sussex.ac.uk (Ian Eiloart) Date: Wed, 26 Mar 2008 10:54:57 +0000 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: References: Message-ID: --On 24 March 2008 18:45:22 -0700 Mark Sapiro wrote: > Jo Rhett wrote: >> >> If you have an MX that queues mail for someone else and isn't >> configured to properly deal with DSNs, then yes, you are stuck in the >> 20th century. > > > 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 > piece? Er, "peace". But yes. That should be the way that email sysadmins are thinking these days. But, it's a "should" not a "must", in the sense of RFC 2821 section 2.3 > > That's what it seems to me that you are saying. If that's not what you > are saying, then perhaps you can explain under what circumstances a > DSN is OK. There are examples: (1) Internal DSNs are OK if you don't accept inbound, unauthenticated mail from your own domain. (Actually, it's your domain so feel free to do what you like internally). For example, we don't accept mail from our own domain unless it's authenticated, or carries a header saying that it's been through our server. Therefore we don't get spam with local SMTP return-paths. So, my mail server can safely bounce email into my domain. In fact, if I'm handling an authenticated message submission, I prefer to bounce than to reject: some MUAs don't handle rejection properly. (2) It should also be acceptable to bounce a message that gets an SPF pass (perhaps not from a +all entry, though), or if it carries a valid DKIM signature. (2a) Given that SPF is available, this could be extended to domains that don't publish SPF records (yes, including us). If they don't care who's using their email addresses, then perhaps we should punish them by drowning them in backscatter! (3) It's probably OK to bounce a message to a list member - perhaps if the message broke some list policy on message content. -- Ian Eiloart IT Services, University of Sussex x3148 From iane at sussex.ac.uk Wed Mar 26 11:58:18 2008 From: iane at sussex.ac.uk (Ian Eiloart) Date: Wed, 26 Mar 2008 10:58:18 +0000 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: References: <6C848D55-A86A-4E76-8510-D47CF866CB78@netconsonance.com> <87prtje2fv.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <1D462170B5DA42D7C8FC334E@lewes.staff.uscs.susx.ac.uk> --On 25 March 2008 08:13:49 +0100 Lars Magne Ingebrigtsen wrote: > > These days, secondary MXs usually do SMTP callouts to verify whether > email addresses are valid on the primary mail server. It does, however, > make the concept of a "secondary MX" less useful than it used to be. Yes. The architecture sucks. We abandoned it about 10 years ago for an LDAP user database that all our SMTP hosts (we have four peers) can access. The database has four mirrors. If the database isn't available (I can't remember the last occasion), we use a 4xx error and ask the sender to hang on to the mail for us. -- Ian Eiloart IT Services, University of Sussex x3148 From iane at sussex.ac.uk Wed Mar 26 12:09:47 2008 From: iane at sussex.ac.uk (Ian Eiloart) Date: Wed, 26 Mar 2008 11:09:47 +0000 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <87bq52eevv.fsf@uwakimon.sk.tsukuba.ac.jp> References: <47E930FD.2000800@utu.fi> <87bq52eevv.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <6409CCAB96BF893D5A596FCA@lewes.staff.uscs.susx.ac.uk> --On 26 March 2008 05:18:44 +0900 "Stephen J. Turnbull" wrote: > 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 outside your > domain. > > Says who? There is nothing in the standards that says so. And if you > take that seriously, you have to disable .forward and procmail for > individual users, as well as refuse to allow open subscription mailing > lists and the like. This may make sense in the U.S. Army and in > corporations with a military authority structure, but it does not in > most universities, research, or open communities. No, that's not true. I have about 10,000 users here. They have access to .forward files, but only a handful have worked out how to use them. Actually, we let them set auto-replies but only after the email has passed a very strict spamassassin threshold, and its rate limited, and its only for personal email (To and CC: recipents, no list headers, etc). We do have open subscription mailing lists. What we don't do is bounce emails with bad recipient addresses. > That is *not* the way Internet mail is designed to work. Mail, like > every other application on the Internet, is intended to be > decentralized. It is designed to allow load-sharing by use of > intermediate and/or secondary MXes to handle primary crashes or > overloads. Yes, but they need to have equal access to user databases. -- Ian Eiloart IT Services, University of Sussex x3148 From iane at sussex.ac.uk Wed Mar 26 12:27:18 2008 From: iane at sussex.ac.uk (Ian Eiloart) Date: Wed, 26 Mar 2008 11:27:18 +0000 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: References: <6C848D55-A86A-4E76-8510-D47CF866CB78@netconsonance.com> Message-ID: <2E24C30EA2CAFD42BCF9DC9A@lewes.staff.uscs.susx.ac.uk> > > I think you will be happier with what is possible in Mailman 3. In > mm3 we have a working LMTP server, those it's based on asyncore and > its scalability is questionable. Although I have not yet done this, I > plan to tie the rule chain checker into LMTP so that if your MTA > supports LMTP delivery the following can happen: > > worldwildwonderland -> SMTP -> MM's LMTP -> rule checks > > The rule checks then could tell LTMP to reject the message right > there, which would return 5xx to SMTP and /it/ would return 5xx to > whatever upstream SMTP its talking to. > > Now, I wouldn't want to do a lot of work at that point, but some > simple checks would definitely be possible. You can reject messages > as early in the process as possible and do it at the SMTP layer. It needs to be done after RCPT TO. LMTP allows you to sensibly do this later, and get return codes for individual recipients. However, it we're doing this with call forwards from an MTA which is receiving email over SMTP, then the MTA will have to check the sender/recipient pair at RCPT TO time. on connect: accept the connection HELO/EHLO: reject if the sending MTA isn't known MAIL FROM: accept (perhaps unless the sender address is forbidden to post to all lists). RCPT TO: accept if the sender has permissions to post to the list, otherwise reject. This is the last chance to give a list specific response to an MTA that is engaged in a callout. DATA: reject null senders here if appropriate. Rejecting a null sender at RCPT TO or earlier might break callouts. ............. . Check the data, reject if inappropriate for a specific list (but this is likely to cause a bounce from our MTA). Because we've decided to trust the sender, we should be OK to bounce a message here, unless the list is an open list. > While I think the LMTP code could be backported to 2.2, the rule > chains stuff cannot. > -- Ian Eiloart IT Services, University of Sussex x3148 From jrhett at netconsonance.com Wed Mar 26 19:58:25 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 26 Mar 2008 11:58:25 -0700 (PDT) Subject: [Mailman-Developers] before next release: disable backscatterindefault installation In-Reply-To: References: Message-ID: <2329.64.13.143.30.1206557905.squirrel@mail.netconsonance.com> > Jo Rhett wrote: >> Not all bounces are backscatter. My servers all deliver DSNs to the >> sender. My servers don't send backscatter. On Tue, March 25, 2008 6:59 pm, Mark Sapiro wrote: > So now we're back to my original question. Under what circumstances is > it acceptable for an MTA to accept a message and then later return an > undeliverable DSN? > > I thought previously you said 'none', but now you say your servers do > it, so which is it? My servers do it for mail accepted locally for relay, which is *only* SSL-encrypted and SMTP-AUTH mail. In short, zero chance of bouncing mail to a forged sender. My server does not accept e-mail from random parties for relay. It either rejects it during the SMTP transaction, or delivers it. -- Jo Rhett Network/Software Engineer Net Consonance From jrhett at netconsonance.com Wed Mar 26 20:02:50 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 26 Mar 2008 12:02:50 -0700 (PDT) Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <47E9CD2C.2060401@Newfield.org> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <87r6dze334.fsf@uwakimon.sk.tsukuba.ac.jp> <63F122FC-9CEA-4587-AE86-D393E3B22C75@netconsonance.com> <47E9CD2C.2060401@Newfield.org> Message-ID: <2928.64.13.143.30.1206558170.squirrel@mail.netconsonance.com> > Jo Rhett wrote: >> I don't care what is done. Do something that makes it better. On Tue, March 25, 2008 9:12 pm, Dale Newfield wrote: > This is an open source project. You are welcome to use it as is or > modify it to your liking. (I believe--someone confirm, please) you even > have the right to distribute your modified version. You're welcome to > make whatever changes you'd like for your own use or even offer the > patches to this OPEN SOURCE project. Seeing as those running this are > volunteers I see no reason they should jump to do your bidding. Seeing > your attitude I see no reason they should want to. You're missing the point. I'm an Abuse Admin. This isn't my problem, nor is it my bidding. If you run Mailman, this is *YOUR* problem. I can, and frankly SHOULD HAVE, banned Mailman from the networks I'm responsible for. I'm here to try and get a more reasonable resolution. And when people like you insult and attack me, all you do is contribute to the ongoing perception that mailman developers don't care about the backscatter problem, which is why a lot of us abuse admins are preparing to disallow Mailman on our networks. Now take your attitude problem and put it somewhere useful. -- Jo Rhett Network/Software Engineer Net Consonance From jrhett at netconsonance.com Wed Mar 26 20:05:33 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 26 Mar 2008 12:05:33 -0700 (PDT) Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: <200803250933.13236.julian@mehnle.net> References: <6C848D55-A86A-4E76-8510-D47CF866CB78@netconsonance.com> <200803250933.13236.julian@mehnle.net> Message-ID: <1081.64.13.143.30.1206558333.squirrel@mail.netconsonance.com> On Tue, March 25, 2008 2:33 am, Julian Mehnle wrote: > You can however safely send a DSN if an SPF[1] check for the incoming > message passes. That's not "safe" but perhaps "safer". But a lot of sites can't use SPF so they either don't use it, or use soft-fail. I would only trust SPF results from explicit matches and PASS. -- Jo Rhett Network/Software Engineer Net Consonance From jrhett at netconsonance.com Wed Mar 26 20:06:56 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 26 Mar 2008 12:06:56 -0700 (PDT) Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <87zlsler61.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <87r6dze334.fsf@uwakimon.sk.tsukuba.ac.jp> <63F122FC-9CEA-4587-AE86-D393E3B22C75@netconsonance.com> <87zlsler61.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <2759.64.13.143.30.1206558416.squirrel@mail.netconsonance.com> On Wed, March 26, 2008 3:05 am, Stephen J. Turnbull wrote: > I'm not in a position to volunteer. It doesn't really sound like > anyone else is, either. Have you thought about providing compensation to > get this done? I'm here out of good will, 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. -- Jo Rhett Network/Software Engineer Net Consonance From jrhett at netconsonance.com Wed Mar 26 20:14:58 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 26 Mar 2008 12:14:58 -0700 (PDT) Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <46AFF679D4EFB29F57698A4B@lewes.staff.uscs.susx.ac.uk> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <46AFF679D4EFB29F57698A4B@lewes.staff.uscs.susx.ac.uk> Message-ID: <1369.64.13.143.30.1206558898.squirrel@mail.netconsonance.com> > --On 24 March 2008 18:07:29 -0700 Jo Rhett >> Sorry, as stated your proposal sounds either naive or insane. No >> insult intended. On Wed, March 26, 2008 3:07 am, Ian Eiloart wrote: > Please, think harder about what you write to the list. If you left an > insult in there that you were aware of, then you *are* intentionally > insulting people. No, I wasn't. But in case someone misread my statement regarding patent facts of already installed software as an insult, I added the disclaimer to make it clear. My remarks were entirely fuctional. Short of writing a worm, you can't fix existing installations after the fact. > I'm on your side in theory. I've been asking various mailing list > developers to address this problem for years, with no progress anywhere. > But, I've lost patience with your apparent aggression here. Why is your patience satiated with Mailman, but lost with me? I think you need to turn those guns around and point them where they belong. I have no aggression. I do have a general desire to see this problem solved, and I'm frustrated by the complete lack of action. I sat through a meeting where every single abuse admin says that they can't get Mailman installations to deal with the problems involved, even when full documentation for how to solve the problem is provided - because Mailman doesn't support the changes. And general agreement that it was perhaps time to close the door. So I'm here, wasting my time, trying to get this solved so that just maybe we won't be forced to all migrate to web forums. Which would suck. -- Jo Rhett Network/Software Engineer Net Consonance From jag at fsf.org Wed Mar 26 20:33:56 2008 From: jag at fsf.org (Joshua 'jag' Ginsberg) Date: Wed, 26 Mar 2008 15:33:56 -0400 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <2928.64.13.143.30.1206558170.squirrel@mail.netconsonance.com> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <87r6dze334.fsf@uwakimon.sk.tsukuba.ac.jp> <63F122FC-9CEA-4587-AE86-D393E3B22C75@netconsonance.com> <47E9CD2C.2060401@Newfield.org> <2928.64.13.143.30.1206558170.squirrel@mail.netconsonance.com> Message-ID: <47EAA524.6010803@fsf.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Seeing as those running this are >> volunteers I see no reason they should jump to do your bidding. Seeing >> your attitude I see no reason they should want to. > > You're missing the point. I'm an Abuse Admin. This isn't my problem, nor > is it my bidding. If you run Mailman, this is *YOUR* problem. Jo -- For what it's worth, you've stated your problem with impeccable clarity. What you haven't done with the same aplomb is acknowledge and respond to the equally legitimate concerns of the developer community here. - - "I am asking that the developers start paying attention *NOW*." - -- Reply: "Nobody has said they should ignore the problem, just that *you* are *way* too late in the process to expect them to stop the release of 2.1.10 for this major change in behavior." - - "This is not substantive, it's trivial." - -- Reply: "From the point of view of the release manager, there are no trivial code changes to a release candidate." - -- Reply: "A text change breaks 35 existing Mailman translations, and breaks them to the extent that changing a single character in the English text, causes that text to be rendered in English on the translated page. This requires 35 translators or translation teams to update their translations. This is anything but trivial." And you're intermixing it with impatience and superciliousness: "You are stuck in the last century, aren't you?" "Now that basic education is out of the way..." "Sorry, as stated your proposal sounds either naive or insane." "Hyperbole like this wastes everyone's time. I don't care what is done. Do something that makes it better." Like it or not, Mailman is a major development project with limited volunteer resources. It has strategically determined its own course -- security fixes and translation updates only for 2.1; new features without major redesign for 2.2; major redesign for 3.0 -- and it has a standard professional release cycle. Like it or not, your complaint of backscatter, while completely accurate and relevant, will not be fixed in the 2.10 timeline. And you need to respect that to keep a stable, reliable product with the limited volunteer resources it has, Mailman must follow these development guidelines. A compromise for 2.1 has been proposed -- a README.backscatter file, better wiki documentation, and getting the information out so that under the 2.1 framework backscatter can be minimized through sysadmin awareness. I encourage you to take the lead in this effort since the issue is clearly important to you. A halfway solution for 2.2 has been proposed -- changing the default behavior -- and I encourage you to provide the developers with strategic advice on how to make your life, the abuse administrator, more manageable. And a good solution for 3.0 has been proposed -- an LMTP transport that can help Mailman do SMTP-time rejections. Mailman is a community project, and you'll find a receptive and helpful audience for your issue when you give the community's concerns the consideration they deserve. - -jag -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH6qUknXt15egVdEoRAl78AKC9LxFMFXMOa7YE7jcvdikADPwQ/QCfTM0T /GeF22cDhlFEhvU5J2HaJtw= =yn2p -----END PGP SIGNATURE----- From wolfgang at sweet-haven.com Wed Mar 26 22:30:44 2008 From: wolfgang at sweet-haven.com (Lew Wolfgang) Date: Wed, 26 Mar 2008 14:30:44 -0700 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <7FF06F7B-D198-4A83-BB08-71F3ADAA9997@netconsonance.com> References: <47E930FD.2000800@utu.fi> <9F720A82-848F-4C5D-A158-ED0BB9A4492C@raoset.com> <7FF06F7B-D198-4A83-BB08-71F3ADAA9997@netconsonance.com> Message-ID: <47EAC084.8050006@sweet-haven.com> Jo Rhett wrote: > More to the point, I solved this problem for the Navy. 2.5 MILLION e- > mail accounts, and they needed to stop accepting e-mail for accounts > which didn't exist. Hi Jo, I assume you're talking NMCI. I just tested this by sending to a bogus NMCI address from .com and .mil (non-NMCI) and in both cases the bogus messages were accepted by NMCI. This has always been a major issue with NMCI and has caused many problems. Good for you if you fixed it, but it still seems to be broken from my end of the Navy. Regards, Lew Wolfgang From julian at mehnle.net Wed Mar 26 23:30:18 2008 From: julian at mehnle.net (Julian Mehnle) Date: Wed, 26 Mar 2008 22:30:18 +0000 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: <1081.64.13.143.30.1206558333.squirrel@mail.netconsonance.com> References: <200803250933.13236.julian@mehnle.net> <1081.64.13.143.30.1206558333.squirrel@mail.netconsonance.com> Message-ID: <200803262230.18612.julian@mehnle.net> Jo Rhett wrote: > On Tue, March 25, 2008 2:33 am, Julian Mehnle wrote: > > You can however safely send a DSN if an SPF[1] check for the incoming > > message passes. > > That's not "safe" but perhaps "safer". But a lot of sites can't use > SPF so they either don't use it, or use soft-fail. I would only trust > SPF results from explicit matches and PASS. There are two parts to SPF: publishing SPF records for one's domains, and checking SPF on incoming messages. Everyone can do the SPF checking part, even if they cannot publish SPF records themselves for whatever reason. SPF's alias-style forwarding issues aside, "Pass" results, when achieved, are perfectly reliable and accurately indicate that the envelope sender address can safely be bounced to. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mail.python.org/pipermail/mailman-developers/attachments/20080326/b7f7a5dd/attachment.pgp From stephen at xemacs.org Thu Mar 27 00:56:54 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 27 Mar 2008 08:56:54 +0900 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <6409CCAB96BF893D5A596FCA@lewes.staff.uscs.susx.ac.uk> References: <47E930FD.2000800@utu.fi> <87bq52eevv.fsf@uwakimon.sk.tsukuba.ac.jp> <6409CCAB96BF893D5A596FCA@lewes.staff.uscs.susx.ac.uk> Message-ID: <87tzitdoop.fsf@uwakimon.sk.tsukuba.ac.jp> 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 work. I know I would do it (but you surely could find somebody cheaper and better-qualified ;-). > > decentralized. It is designed to allow load-sharing by use of > > intermediate and/or secondary MXes to handle primary crashes or > > overloads. > > Yes, but they need to have equal access to user databases. I ask, where are these requirements written? I've been reading the Mailman lists for years. I know that you guys want the autoresponders configurable. However, often enough they've been presented as YAGNI, not a bug, and this is the first time I've heard a demand that they be shut off by default. Obviously you guys hang out together in some Big Site Cabal, but what is common knowledge to you is not necessarily something that volunteer part-time developers are going to have easy access to. BTW, that's not how I understand a secondary as a practical matter. Effectively, that is a distributed primary. (I bet your "secondary" MXes deliver directly to user mailboxes, which are a shared resource like the user database. No?) Among other things, for most small- scale operations, the user database lives on the same host as the primary's MTA. If it is down, then under that requirement so are any secondaries. From jrhett at netconsonance.com Thu Mar 27 00:58:07 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 26 Mar 2008 16:58:07 -0700 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: <200803262230.18612.julian@mehnle.net> References: <200803250933.13236.julian@mehnle.net> <1081.64.13.143.30.1206558333.squirrel@mail.netconsonance.com> <200803262230.18612.julian@mehnle.net> Message-ID: <4F4F0086-B734-4FC3-AE18-FE7881121690@netconsonance.com> On Mar 26, 2008, at 3:30 PM, Julian Mehnle wrote: > There are two parts to SPF: publishing SPF records for one's > domains, and > checking SPF on incoming messages. Everyone can do the SPF checking > part, even if they cannot publish SPF records themselves for whatever > reason. SPF's alias-style forwarding issues aside, "Pass" results, > when > achieved, are perfectly reliable and accurately indicate that the > envelope sender address can safely be bounced to. I was part of the original SPF working group, you're singing to the choir. But for various reasons many organizations publish wide-open SPF records, and right or wrong those people will still report backscatter to the blacklists. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Mar 27 00:59:51 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 26 Mar 2008 16:59:51 -0700 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <47EAC084.8050006@sweet-haven.com> References: <47E930FD.2000800@utu.fi> <9F720A82-848F-4C5D-A158-ED0BB9A4492C@raoset.com> <7FF06F7B-D198-4A83-BB08-71F3ADAA9997@netconsonance.com> <47EAC084.8050006@sweet-haven.com> Message-ID: <6456481F-822E-4C78-8BCA-521A851A41C9@netconsonance.com> On Mar 26, 2008, at 2:30 PM, Lew Wolfgang wrote: > Jo Rhett wrote: >> More to the point, I solved this problem for the Navy. 2.5 >> MILLION e- >> mail accounts, and they needed to stop accepting e-mail for accounts >> which didn't exist. > > I assume you're talking NMCI. I just tested this by sending to a > bogus > NMCI address from .com and .mil (non-NMCI) and in both cases the bogus > messages were accepted by NMCI. This has always been a major issue > with > NMCI and has caused many problems. Good for you if you fixed it, > but it > still seems to be broken from my end of the Navy. I have no idea who NMCI is. They might have changed acronyms. At the time it was Navsea, SEA-05 (and SEA-04 administration). It was also a ccMail gateway. My god, I hope they aren't still using that ;-) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From cmpalmer at metalab.unc.edu Thu Mar 27 01:18:43 2008 From: cmpalmer at metalab.unc.edu (=?iso-8859-1?Q?Crist=F3bal?= Palmer) Date: Wed, 26 Mar 2008 20:18:43 -0400 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <1369.64.13.143.30.1206558898.squirrel@mail.netconsonance.com> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <46AFF679D4EFB29F57698A4B@lewes.staff.uscs.susx.ac.uk> <1369.64.13.143.30.1206558898.squirrel@mail.netconsonance.com> Message-ID: <20080327001842.GN22377@garp.metalab.unc.edu> On Wed, Mar 26, 2008 at 12:14:58PM -0700, Jo Rhett wrote: > > So I'm here, wasting my time, trying to get this solved so that just maybe > we won't be forced to all migrate to web forums. Which would suck. Yes, that would suck. I encourage you to please continue engaging this list and the developers, but would caution you that you've already caused at least three people to think you're being overly antagonistic. So far I see documentation and some good scripts for fixing problems on existing systems coming out of this conversation. Please let's make improving that documentation and making 2.2 and 3.0 good by your standards a priority. Jo, would you please be willing to take the lead in improving this wiki page: http://wiki.list.org/display/SEC/Controlling+spam since it looks rather stubbish? If you're willing to lead by example on the documentation and 2.2, your argument would likely come off a bit better. Now, if your goal is a public telling-off of the mailman team, I think you've already made that clear enough. Can we move on? At ibiblio we host 500+ lists, including 41 cc- (creative commons) lists. Jumping from mailman to something else would be incredibly painful. We run on donations and we host sites like etree, groklaw, gutenberg... we could use your help if we're going to continue to do what we do. This open source world is a group effort that runs largely on good will and sharing. Your currency here often isn't valid if it doesn't come with a smile. So please, I *very* much respect what you're trying to do. Your contributions so far have been incredibly valuable. Point your guns at the wiki and 2.2 now, eh? That said, if 2.2 doesn't make progress on the backscatter front, ibiblio will have to re-evaluate its options. Specifically, I'd love to see the aliases and List- headers dealt with, both in terms of the defaults and in terms of providing documentation/tools for helping existing installations get up to snuff. Cheers, -- Crist?bal Palmer ibiblio.org systems administrator From stephen at xemacs.org Thu Mar 27 01:58:02 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 27 Mar 2008 09:58:02 +0900 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <2759.64.13.143.30.1206558416.squirrel@mail.netconsonance.com> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <87r6dze334.fsf@uwakimon.sk.tsukuba.ac.jp> <63F122FC-9CEA-4587-AE86-D393E3B22C75@netconsonance.com> <87zlsler61.fsf@uwakimon.sk.tsukuba.ac.jp> <2759.64.13.143.30.1206558416.squirrel@mail.netconsonance.com> Message-ID: <87skyddlut.fsf@uwakimon.sk.tsukuba.ac.jp> 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. The resources to do what you say is necessary are not currently available. As you've remarked yourself, 2.2 is dead in the water and 3.0 is a long time away. 2.1 gets a new release every so often with a few bug fixes, and this is only really possible because it's in pure maintenance mode -- feature changes are mostly rejected out of hand. Those aren't symptoms of a project flush with resources. The technical problem of backscatter has been acknowledged. From the posts to this thread, I conclude the Mailman community *at large* is at present unaware of the threat of banning. I gather that includes Mark but perhaps not Barry. On the other side, there are very few resources available, and for this kind of change there is special pressure on the translators; no one of us can do it alone. The question is where to get the resources. While it's not your responsibility to do it, it isn't anybody else's, either. Regards, From barry at list.org Thu Mar 27 03:53:12 2008 From: barry at list.org (Barry Warsaw) Date: Wed, 26 Mar 2008 22:53:12 -0400 Subject: [Mailman-Developers] Sibling list terminology (was Re: Mailman 2.1.10b4 Released) In-Reply-To: <36898B72F6D4423EF51C29C3@lewes.staff.uscs.susx.ac.uk> References: <47D9E26E.4040708@msapiro.net> <36898B72F6D4423EF51C29C3@lewes.staff.uscs.susx.ac.uk> Message-ID: <7FE7A0C5-4EDF-441F-B01E-5F286A74BAEA@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 14, 2008, at 7:30 AM, Ian Eiloart wrote: > > > --On 13 March 2008 19:26:54 -0700 Mark Sapiro > wrote: > >> >> - - Added a new 'sibling list' feature to exclude members of >> another list >> from receiving a post from this list if the other list is in the >> To: or >> Cc: of the post or to include members of the other list if that >> list is >> not in the To: or Cc: of the post (Patch ID 1347962). > > I don't understand this feature.... Hmm, Tokio Kikuchi asked about > the name > in 2005. I'm sorry that I didn't comment earlier. > > > > > Sibling is a *completely* misleading term for this feature, because > sibling > relationships are necessarily symmetrical: if A is a sibling of B, > then B > must be a sibling of A. This feature is necessarily anti- > symmetrical, more > like "child" or "descendent". The term "sibling" will lead people to > misconfigure their lists. > > > > > Question: is the relationship also transitive? IE, if C is a child > of B, > and B is a child of A, then will postings to A go to members of C? > If so, > then the relationship should be called "descendent". > > > > As far as inclusion is concerned, we then have a partially ordered > set of > mailing lists under this relationship. If the code handles the > (presumably > erroneous case) where a list is marked as a "sibling" of itself > properly > (ie, the listing should be ignored). > > I didn't see any follow up on this, but perhaps I missed it while I was at Pycon. Tokio can correct me, but I do not believe this feature is transitive. There is a strictly one-level inclusion or exclusion of regular delivery addresses. I see what you're saying about the term "sibling" lists being misleading. But what's a good term? I can't think of anything that encompasses both the inclusion and exclusion lists. "Related" is about as close as I could come, but that's pretty uninformative. It also might be too late to change for 2.1.10, especially if the u/i strings have already been translated. Ultimately, it's Mark's decision, and changing it would be predicated on finding a good alternative. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfrDBoACgkQ2YZpQepbvXHm1QCbBE8LCvrIqcidwogr//L5zz9H bSYAn2vgW62BRAktJ+IEf4VVPY1vpdNA =/j/C -----END PGP SIGNATURE----- From julian at mehnle.net Thu Mar 27 10:27:54 2008 From: julian at mehnle.net (Julian Mehnle) Date: Thu, 27 Mar 2008 09:27:54 +0000 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: <4F4F0086-B734-4FC3-AE18-FE7881121690@netconsonance.com> References: <200803262230.18612.julian@mehnle.net> <4F4F0086-B734-4FC3-AE18-FE7881121690@netconsonance.com> Message-ID: <200803270927.58196.julian@mehnle.net> Jo Rhett wrote: > But for various reasons many organizations publish wide-open SPF > records, and right or wrong those people will still report > backscatter to the blacklists. This is the first time I hear of this being a widespread problem. Can you please contact me off-list and give me some details on which organiza- tions do that? Perhaps the SPF project has to take them aside and have a friendly word or two with them. In any case, this can be considered an abuse of the blacklists being reported to. For example, the SpamCop blacklist explicitly asks spam submitters to publish SPF records if they receive backscatter, so it is obvious that they aren't supposed to submit bounces as spam that are "legitimate" according to a published SPF record of theirs. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mail.python.org/pipermail/mailman-developers/attachments/20080327/a2916ed9/attachment.pgp From iane at sussex.ac.uk Thu Mar 27 12:53:15 2008 From: iane at sussex.ac.uk (Ian Eiloart) Date: Thu, 27 Mar 2008 11:53:15 +0000 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <1369.64.13.143.30.1206558898.squirrel@mail.netconsonance.com> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <46AFF679D4EFB29F57698A4B@lewes.staff.uscs.susx.ac.uk> <1369.64.13.143.30.1206558898.squirrel@mail.netconsonance.com> Message-ID: --On 26 March 2008 12:14:58 -0700 Jo Rhett wrote: > >> --On 24 March 2008 18:07:29 -0700 Jo Rhett >>> Sorry, as stated your proposal sounds either naive or insane. No >>> insult intended. > > On Wed, March 26, 2008 3:07 am, Ian Eiloart wrote: >> Please, think harder about what you write to the list. If you left an >> insult in there that you were aware of, then you *are* intentionally >> insulting people. > > No, I wasn't. But in case someone misread my statement regarding patent > facts of already installed software as an insult, I added the disclaimer > to make it clear. My remarks were entirely fuctional. Short of writing a > worm, you can't fix existing installations after the fact. So, which of "naive" or "insane" requires misreading to be insulting? Neither word has a complementary definition that I'm aware of. > Why is your patience satiated with Mailman, but lost with me? I think you > need to turn those guns around and point them where they belong. My point is that guns are not required. -- Ian Eiloart IT Services, University of Sussex x3148 From iane at sussex.ac.uk Thu Mar 27 13:16:42 2008 From: iane at sussex.ac.uk (Ian Eiloart) Date: Thu, 27 Mar 2008 12:16:42 +0000 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <87tzitdoop.fsf@uwakimon.sk.tsukuba.ac.jp> References: <47E930FD.2000800@utu.fi> <87bq52eevv.fsf@uwakimon.sk.tsukuba.ac.jp> <6409CCAB96BF893D5A596FCA@lewes.staff.uscs.susx.ac.uk> <87tzitdoop.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20A8FB7AF06FCD481A760372@lewes.staff.uscs.susx.ac.uk> --On 27 March 2008 08:56:54 +0900 "Stephen J. Turnbull" wrote: > 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 work. I know I would do it (but you surely could find > somebody cheaper and better-qualified ;-). At a penny per user, I could raise ?100. That wouldn't do the job. Unfortunately, UK academic institutions are cash strapped. We (Sussex) have contributed to UoW and Cyrus IMAP servers code, and to some other projects. Cambridge (somewhat less cash strapped) contributed almost all of the Exim MTA. > > > decentralized. It is designed to allow load-sharing by use of > > > intermediate and/or secondary MXes to handle primary crashes or > > > overloads. > > > > Yes, but they need to have equal access to user databases. > > I ask, where are these requirements written? You mean the requirement that the mail system be able to reject email from non-members at SMTP time? under "spam defenses". Third paragraph. It was there on July 21 last year, when the page was created from the Mailman 2.2 wish list. > I've been reading the > Mailman lists for years. I know that you guys want the autoresponders > configurable. However, often enough they've been presented as YAGNI, Er. I guess that depends on what you mean by "need". Clearly nobody has died because we haven't got this feature. However, very many people have been inconvenienced. It's possible that Mailman bounces contributed to our site being blacklisted by AOL and Yahoo for short periods. It's certain that I've had to spend time helping list managers understand how to choose between the inadequate choices that they have for bad lists. > not a bug, and this is the first time I've heard a demand that they be > shut off by default. Obviously you guys hang out together in some Big > Site Cabal, No... I spend more time on the Exim mailing list, but all the conversations that I've ever had about Mailman are on this list. If you read the thread carefully, you'll find that my position is that this feature is a requirement, but not for 2.1, and maybe not even for 2.2. I just want it to happen eventually. > but what is common knowledge to you is not necessarily > something that volunteer part-time developers are going to have easy > access to. That's why I post to the list. > BTW, that's not how I understand a secondary as a practical matter. > Effectively, that is a distributed primary. Yes. When I said the architecture is broken I meant the entire concept of the secondary. It's best to have a distributed primary, and not hard to implement with LDAP. Failing that, you have to choose between relying on third parties to queue your mail for later delivery or on queuing tons of spam on your secondary. I'd prefer to simply not have a secondary if it can't be of equal quality to the primary. > (I bet your "secondary" > MXes deliver directly to user mailboxes, which are a shared resource > like the user database. No?) Among other things, for most small- > scale operations, the user database lives on the same host as the > primary's MTA. If it is down, then under that requirement so are any > secondaries. > -- Ian Eiloart IT Services, University of Sussex x3148 From iane at sussex.ac.uk Thu Mar 27 13:22:15 2008 From: iane at sussex.ac.uk (Ian Eiloart) Date: Thu, 27 Mar 2008 12:22:15 +0000 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <2928.64.13.143.30.1206558170.squirrel@mail.netconsonance.com> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <87r6dze334.fsf@uwakimon.sk.tsukuba.ac.jp> <63F122FC-9CEA-4587-AE86-D393E3B22C75@netconsonance.com> <47E9CD2C.2060401@Newfield.org> <2928.64.13.143.30.1206558170.squirrel@mail.netconsonance.com> Message-ID: --On 26 March 2008 12:02:50 -0700 Jo Rhett wrote: > > You're missing the point. I'm an Abuse Admin. This isn't my problem, nor > is it my bidding. If you run Mailman, this is *YOUR* problem. > Ah, now I see what's going on. His usual abuse sink is malfunctioning, so he's routed all his incoming abuse to this list. Sorry, just kidding, no insult intended ;) -- Ian Eiloart IT Services, University of Sussex x3148 From timowi.lists at gmx.de Thu Mar 27 16:26:29 2008 From: timowi.lists at gmx.de (Timo Wingender) Date: Thu, 27 Mar 2008 16:26:29 +0100 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense Message-ID: <47EBBCA5.1000305@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I like to participate in Google Summer of Code this year. One possible Project for me is to implement some Spam Defense in Mailman. I think development for Mailman should be possible through Python Software Foundation. Am I right with this? I administrate a Mailman installation with about 100 lists and thousands of users and I moderate most of the Lists. I think the biggest Problem of Mailman is the lack in spam defense. Discard messages from nonmembers is no option on most lists. Some time ago I began some modification of Mailman. But I never finished it. The first action is to integrate support for SpamAssassin in Mailman. Therefor I wrote a python class spamc which connects to spamd. This gives the possibility to scan all incoming Mail. Further ideas for spam defense are: - - Add the possibility to scan all messages form nonmembers half an hour later again before mark them as hold. This is because most of the mails which are not recognized as spam are to new. The servers are not in any blacklist at time of incoming. - - Train the bayes filter from Mailman. Forward all accepted Messages to SpamAssassin to learn them as ham. The autolearn feature of SA doesn't work for me. It learns to much false negatives. 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? Best Wishes Timo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH67yiakDbqHKnrh8RAhxoAKDYWguLeFxuSAy18sSCXdwWONmdiwCg2YwO W60FvGTr79tAAXZEndPSFSk= =iutB -----END PGP SIGNATURE----- From jrhett at netconsonance.com Thu Mar 27 17:22:48 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 27 Mar 2008 09:22:48 -0700 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <20080327001842.GN22377@garp.metalab.unc.edu> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <46AFF679D4EFB29F57698A4B@lewes.staff.uscs.susx.ac.uk> <1369.64.13.143.30.1206558898.squirrel@mail.netconsonance.com> <20080327001842.GN22377@garp.metalab.unc.edu> Message-ID: <47EBC9D8.3000403@netconsonance.com> Crist?bal Palmer wrote: > So far I see documentation and some good scripts for fixing problems > on existing systems coming out of this conversation. As per my original statement, that would be great. > Please let's make > improving that documentation and making 2.2 and 3.0 good by your > standards a priority. None of these are "my standards". The standards expoused by the leading anti-spam groups are what we are talking about. > Jo, would you please be willing to take the lead in improving this > wiki page: > > http://wiki.list.org/display/SEC/Controlling+spam > > since it looks rather stubbish? If you're willing to lead by example > on the documentation and 2.2, your argument would likely come off a > bit better. I've written some points about what is not covered in that to the list. The problem is that what I did on the mailman install I was responsible for was fairly hackish. I can program in almost anything, but Python is not my strong point and the Python.org style used in Mailman even less so. This makes my patches fairly hackish and probably not the best way to do things. (more on this below) > Now, if your goal is a public telling-off of the mailman > team, I think you've already made that clear enough. Can we move on? Never did, never was. Have repeatedly asked that we move on ;-) > This open source world is a group effort that runs largely > on good will and sharing. Your currency here often isn't valid if it > doesn't come with a smile. For projects where I am asking something of them, my approach generally comes with a smile and a patch. In fact, if you look at the sourceforge patch repository you'll find that my functionality requests *did* come with patches. This situation is different, because the request is going the other way. Mailman sites have been asking abuse departments to ignore the backscatter and smile for far too many years. The smiles have long since faded and most of us are frustrated with the situation. I took on role of trying to push the developers to put something in place before we simply banned mailman within our networks. There is nothing personal here. It is entirely technical, and entirely goal oriented. The difficult part is that none of us at that meeting or in any of the conversations I'd had with others since then are strong Python developers. And in fact, if you look back at my submitted patches and comments on this list -- I have in all cases asked what changes would make the patch workable and acceptable for inclusion into the codebase, and received no responses to that. So we have fairly apparent opinion that my patches aren't stylistically worth considering. I'm not surprised, given that I don't personally grok the Python.org style. I'm not offended, just aware that my patches are unlikely to be useful in this effort. -- Jo Rhett Net Consonance ... net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Mar 27 17:29:21 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 27 Mar 2008 09:29:21 -0700 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: <47EBBCA5.1000305@gmx.de> References: <47EBBCA5.1000305@gmx.de> Message-ID: <47EBCB61.30702@netconsonance.com> Timo Wingender wrote: > Discard messages from nonmembers is no option on most lists. AFAIK it is an option, but not the default and defaults are rarely changed in my experience. > The first action is to integrate support for SpamAssassin in > Mailman. Therefor I wrote a python class spamc which connects to spamd. > This gives the possibility to scan all incoming Mail. Entirely my opinion, but I suspect that this will be harder to do and less portable than having a mailman front-end that recognizes the headers inserted by the major spam gateways. For example, the sites I am aware of run amavisd+SA in front of mailman. They aren't going to disable amavis to have mailman run SA directly. Nor are sites with barrucudas likely to do so, etc etc. My opinion entirely, but I think it would be better to make mailman aware of the headers inserted by these solutions. Again, just my opinion. -- Jo Rhett Net Consonance ... net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Mar 27 17:49:46 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 27 Mar 2008 09:49:46 -0700 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <47EAA524.6010803@fsf.org> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <87r6dze334.fsf@uwakimon.sk.tsukuba.ac.jp> <63F122FC-9CEA-4587-AE86-D393E3B22C75@netconsonance.com> <47E9CD2C.2060401@Newfield.org> <2928.64.13.143.30.1206558170.squirrel@mail.netconsonance.com> <47EAA524.6010803@fsf.org> Message-ID: <47EBD02A.10309@netconsonance.com> Joshua 'jag' Ginsberg wrote: > For what it's worth, you've stated your problem with impeccable clarity. > What you haven't done with the same aplomb is acknowledge and respond to > the equally legitimate concerns of the developer community here. I have tried to. I've even wasted time responding to people who don't seem to understand the issues involved at all. > - - "I am asking that the developers start paying attention *NOW*." > - -- Reply: "Nobody has said they should ignore the problem, just that > *you* are *way* too late in the process to expect them to stop the > release of 2.1.10 for this major change in behavior." Invalid in that this issue has been known since long before 2.1.10 or honestly even 2.1.6 was thought of. It's the same excuse with every release. > - - "This is not substantive, it's trivial." > - -- Reply: "From the point of view of the release manager, there are no > trivial code changes to a release candidate." > - -- Reply: "A text change breaks 35 existing Mailman translations, and This I did acknowledge. Check the mail archive. > And you're intermixing it with impatience and superciliousness: If you look, I only responded in that manner to people who insulted or attacked me first. *And* in most cases I responded thoughtfully and dry to apparent insults to first, second... sometimes third time. But I'm human. A better question is why are people with zero apparent experience on this matter responding to me with insults and attacks? My posts were entirely technical, and their inexperierence is apparent. Their inability to work on the code base themselves is also apparent. All this does is make me regret attempting to intervene in this matter in the first place. > Like it or not, Mailman is a major development project with limited > volunteer resources. It has strategically determined its own course -- > security fixes and translation updates only for 2.1; new features > without major redesign for 2.2; major redesign for 3.0 -- and it has a > standard professional release cycle. > ... And you need to respect that to keep a stable, reliable product with > the limited volunteer resources it has, Mailman must follow these > development guidelines. No I don't. My job is to enforce our AUP. My job is not to come onto mailing lists with perfectly valid issues that are so very well known they are reported in the non-technical news media, and get abused for bringing them up. > A compromise for 2.1 has been proposed -- a README.backscatter file, > better wiki documentation, and getting the information out so that under > the 2.1 framework backscatter can be minimized through sysadmin > awareness. I encourage you to take the lead in this effort since the > issue is clearly important to you. No, this issue isn't "important to me". Doing my job is important to me. Preventing the next backscatter DoS against our mailservers (which was 60% mailman traffic) is important to me. Since everyone already thinks that I'm a jerk, let's go all the way. Shutting down Mailman permanently, throughout the 'Net, *SHOULD* be important to me. It's the best possible fix for the problem at hand. Why I chose to try and work with the developers to get a fix into place is a curious thing, because it certainly won't solve the problem today and it's clearly been a waste of time. > Mailman is a community project, and you'll find a receptive and helpful > audience for your issue when you give the community's concerns the > consideration they deserve. I think you need to go back and look at my original posts, and the abuse and derision and insults I received. The problem is not that I failed to give the community's concerns respect. You'll find, if you look honestly, that the problem went entirely the other way. There wasn't a single response within a week of my original post that had anything verging on respect for the very well known issue in it. Anyway, I'm done. -- Jo Rhett Net Consonance ... net philanthropy, open source and other randomness From japruim at raoset.com Thu Mar 27 17:35:25 2008 From: japruim at raoset.com (Jason Pruim) Date: Thu, 27 Mar 2008 12:35:25 -0400 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: <47EBCB61.30702@netconsonance.com> References: <47EBBCA5.1000305@gmx.de> <47EBCB61.30702@netconsonance.com> Message-ID: On Mar 27, 2008, at 12:29 PM, Jo Rhett wrote: > Timo Wingender wrote: >> Discard messages from nonmembers is no option on most lists. > > AFAIK it is an option, but not the default and defaults are rarely > changed in my experience. > >> The first action is to integrate support for SpamAssassin in >> Mailman. Therefor I wrote a python class spamc which connects to >> spamd. >> This gives the possibility to scan all incoming Mail. > > Entirely my opinion, but I suspect that this will be harder to do and > less portable than having a mailman front-end that recognizes the > headers inserted by the major spam gateways. > > For example, the sites I am aware of run amavisd+SA in front of > mailman. > They aren't going to disable amavis to have mailman run SA directly. > Nor are sites with barrucudas likely to do so, etc etc. My opinion > entirely, but I think it would be better to make mailman aware of the > headers inserted by these solutions. > One thing that I've been thinking about in regards to this... Is this job the responsibility of mailman? To scan for spam and other such things? I do all of my scanning at the front end, all e-mail gets run through ASSP to scan blacklists, grey list, etc. etc. then it goes to the MTA, which in my case just verifies the account exists (Or an alias for it does) and then is delivered to mailman for delivery... Why not run something like that instead of checking for all that stuff just before the delivery? > Again, just my opinion. > > -- > Jo Rhett > Net Consonance ... net philanthropy, open source and other randomness > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py > Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/japruim%40raoset.com > > Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp > -- Jason Pruim Raoset Inc. Technology Manager MQC Specialist 3251 132nd ave Holland, MI, 49424-9337 www.raoset.com japruim at raoset.com From mark at msapiro.net Thu Mar 27 17:47:48 2008 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 27 Mar 2008 09:47:48 -0700 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: <47EBCB61.30702@netconsonance.com> Message-ID: Jo Rhett wrote: >Timo Wingender wrote: >> Discard messages from nonmembers is no option on most lists. > >AFAIK it is an option, but not the default and defaults are rarely >changed in my experience. I think that Timo is saying that for his purposes on his lists it is not viable for him to automatically discard messages from nonmembers, not that the option doesn't exist in Mailman. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From terri at zone12.com Thu Mar 27 17:59:48 2008 From: terri at zone12.com (Terri Oda) Date: Thu, 27 Mar 2008 12:59:48 -0400 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: References: <47EBBCA5.1000305@gmx.de> <47EBCB61.30702@netconsonance.com> Message-ID: <53240295-0A86-4940-91C5-29FD85FBFE52@zone12.com> On 27-Mar-08, at 12:35 PM, Jason Pruim wrote: > One thing that I've been thinking about in regards to this... Is this > job the responsibility of mailman? To scan for spam and other such > things? > > I do all of my scanning at the front end, all e-mail gets run through > ASSP to scan blacklists, grey list, etc. etc. then it goes to the MTA, > which in my case just verifies the account exists (Or an alias for it > does) and then is delivered to mailman for delivery... > > Why not run something like that instead of checking for all that stuff > just before the delivery? Even if it's not Mailman's responsibility to do the scanning, it can be incredibly helpful to make the mailman interface aware of and able to interact with scanning technologies. ie - using messages discarded as spam for retraining the system, letting list admins customize the behaviour for some lists (or -owner addresses) based on lower or higher threshold values than the server itself uses, maybe having a way to "discard this spam for all lists" or "flag this as spam for other list admins" in the case of messages being sent to multiple lists at once... Terri From timowi.lists at gmx.de Thu Mar 27 17:59:42 2008 From: timowi.lists at gmx.de (Timo Wingender) Date: Thu, 27 Mar 2008 17:59:42 +0100 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: References: Message-ID: <47EBD27E.1050206@gmx.de> Mark Sapiro schrieb: > Jo Rhett wrote: > > >> Timo Wingender wrote: >> >>> Discard messages from nonmembers is no option on most lists. >>> >> AFAIK it is an option, but not the default and defaults are rarely >> changed in my experience. >> > > > I think that Timo is saying that for his purposes on his lists it is > not viable for him to automatically discard messages from nonmembers, > not that the option doesn't exist in Mailman. > > I know how to discard messages automatically. But on most lists the default is to hold them. The question is how mailman is used. If the list are there for communication only with list members then it's an option to discard messages. But if you use a list as an official contact you cannot simply discard all messages from nonmembers. Sometimes people send mails to a list from an alternative address or someone not on the list wants to contact the list. If this is an intended use of a list then discard by default is no option. From jrhett at netconsonance.com Thu Mar 27 18:12:31 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 27 Mar 2008 10:12:31 -0700 Subject: [Mailman-Developers] Done. Message-ID: <47EBD57F.3070204@netconsonance.com> I've been incredibly tolerant of being abused on this issue for 3 weeks now, but the now-constant flood of people coming forward to say that I'm not respecting the mailman community is too funny. It breaks the bounds of reality. *I* did one thing. I pointed out an issue that *EVERYONE* knows about, even the non-technical news media. I asked that something be done soon. I wrote my post clearly and politely. http://mail.python.org/pipermail/mailman-developers/2008-March/019804.html Did I receive a respectful response addressing these issues from anyone who writes code for the project? Yes: Mark Sapiro wrote me a respectful reply on March 5. http://mail.python.org/pipermail/mailman-developers/2008-March/019807.html But that reply only negated my suggestions, with no solutions proposed. I attempted to respond to the insults and derision I received in most of the replies with honest, straightforward answers. Even when the questions were hopelessly supercilious and rude. At this time there has been more effort spent writing me back saying that I'm not respecting the community than it would have taken to write patches to fix the problem. I've certainly wasted more time here than I did writing my patches and testing them in the first place. I respected the community by coming here and trying to address the issue, rather than simply blacklisting Mailman sites. I respected the community by replying to everyone who replied to me, rather than ignoring the posts filled with derision or technical nonsense. Perhaps that was a mistake. I had a nice dinner with a number of people last night on this topic, and not a single person (all of whom witnessed this thread) felt that trying to address this issue here was producing any results. So I am done. Keep your derision to yourself, and keep wasting time telling people how they should respect you rather than solve the problem. I am right now updating our AUP documentation to mention that Mailman is explicitly banned unless the person provides documentation of the configuration/patches they have applied to prevent backscatter. I am notifying the known mailman sites within our network. We are done with this issue. -- Jo Rhett Net Consonance ... net philanthropy, open source and other randomness From timowi.lists at gmx.de Thu Mar 27 18:10:30 2008 From: timowi.lists at gmx.de (Timo Wingender) Date: Thu, 27 Mar 2008 18:10:30 +0100 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: <47EBCB61.30702@netconsonance.com> References: <47EBBCA5.1000305@gmx.de> <47EBCB61.30702@netconsonance.com> Message-ID: <47EBD506.3030009@gmx.de> Jo Rhett schrieb: > Timo Wingender wrote: >> Discard messages from nonmembers is no option on most lists. > > AFAIK it is an option, but not the default and defaults are rarely > changed in my experience. > >> The first action is to integrate support for SpamAssassin in Mailman. >> Therefor I wrote a python class spamc which connects to spamd. This >> gives the possibility to scan all incoming Mail. > > Entirely my opinion, but I suspect that this will be harder to do and > less portable than having a mailman front-end that recognizes the > headers inserted by the major spam gateways. > > For example, the sites I am aware of run amavisd+SA in front of > mailman. They aren't going to disable amavis to have mailman run SA > directly. Nor are sites with barrucudas likely to do so, etc etc. My > opinion entirely, but I think it would be better to make mailman aware > of the headers inserted by these solutions. Yes, most sites run an SA in front of mailman. But SA doesn't mark all spam. For me it finds over 90% but enough spam mails are not found. Most of the are simply to new. Scan them again later identifies them as spam. Scanning incoming mail with SA is much easier then the interaction with SA in the later process. E.g. rescanning or train bayes filter. > > Again, just my opinion. > From timowi.lists at gmx.de Thu Mar 27 18:18:40 2008 From: timowi.lists at gmx.de (Timo Wingender) Date: Thu, 27 Mar 2008 18:18:40 +0100 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: References: <47EBBCA5.1000305@gmx.de> <47EBCB61.30702@netconsonance.com> Message-ID: <47EBD6F0.3030906@gmx.de> Jason Pruim schrieb: > > On Mar 27, 2008, at 12:29 PM, Jo Rhett wrote: >> Timo Wingender wrote: >>> Discard messages from nonmembers is no option on most lists. >> >> AFAIK it is an option, but not the default and defaults are rarely >> changed in my experience. >> >>> The first action is to integrate support for SpamAssassin in >>> Mailman. Therefor I wrote a python class spamc which connects to spamd. >>> This gives the possibility to scan all incoming Mail. >> >> Entirely my opinion, but I suspect that this will be harder to do and >> less portable than having a mailman front-end that recognizes the >> headers inserted by the major spam gateways. >> >> For example, the sites I am aware of run amavisd+SA in front of mailman. >> They aren't going to disable amavis to have mailman run SA directly. >> Nor are sites with barrucudas likely to do so, etc etc. My opinion >> entirely, but I think it would be better to make mailman aware of the >> headers inserted by these solutions. >> > > One thing that I've been thinking about in regards to this... Is this > job the responsibility of mailman? To scan for spam and other such > things? Of course this is not the primary job of mailman. But it can help to reduce the effort to moderate lists. If you have an moderator for each list it's no problem if a few spam messages per day are hold. But if you don't it's much effort to sort out all the spam. > > I do all of my scanning at the front end, all e-mail gets run through > ASSP to scan blacklists, grey list, etc. etc. then it goes to the MTA, > which in my case just verifies the account exists (Or an alias for it > does) and then is delivered to mailman for delivery... Not every site runs ASSP and I am not a fan of greylisting. It delays mails of legitimate users and once most sites use is spammers will get around it. > > Why not run something like that instead of checking for all that stuff > just before the delivery? > > >> Again, just my opinion. >> >> -- >> Jo Rhett >> Net Consonance ... net philanthropy, open source and other randomness >> _______________________________________________ >> Mailman-Developers mailing list >> Mailman-Developers at python.org >> http://mail.python.org/mailman/listinfo/mailman-developers >> Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py >> Searchable Archives: >> http://www.mail-archive.com/mailman-developers%40python.org/ >> Unsubscribe: >> http://mail.python.org/mailman/options/mailman-developers/japruim%40raoset.com >> >> >> Security Policy: >> http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp >> > > -- > > Jason Pruim > Raoset Inc. > Technology Manager > MQC Specialist > 3251 132nd ave > Holland, MI, 49424-9337 > www.raoset.com > japruim at raoset.com > > > From japruim at raoset.com Thu Mar 27 18:34:39 2008 From: japruim at raoset.com (Jason Pruim) Date: Thu, 27 Mar 2008 13:34:39 -0400 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: <47EBD6F0.3030906@gmx.de> References: <47EBBCA5.1000305@gmx.de> <47EBCB61.30702@netconsonance.com> <47EBD6F0.3030906@gmx.de> Message-ID: <067F5B74-C336-4EC8-97D5-E73545BA0CAA@raoset.com> On Mar 27, 2008, at 1:18 PM, Timo Wingender wrote: > Jason Pruim schrieb: >> >>> >> >> One thing that I've been thinking about in regards to this... Is >> this job the responsibility of mailman? To scan for spam and other >> such things? > Of course this is not the primary job of mailman. But it can help to > reduce the effort to moderate lists. > > If you have an moderator for each list it's no problem if a few spam > messages per day are hold. But if you don't it's much effort to sort > out all the spam. I see what you're getting at.. I've never looked at it from that stand point before so it didn't make sense to me. I use mailman primarily for internal communication for my company, the ability to send a file to art at mydomain.com and it goes to who ever is in the art department that day has been great! > >> >> I do all of my scanning at the front end, all e-mail gets run >> through ASSP to scan blacklists, grey list, etc. etc. then it goes >> to the MTA, which in my case just verifies the account exists (Or >> an alias for it does) and then is delivered to mailman for >> delivery... > Not every site runs ASSP and I am not a fan of greylisting. It > delays mails of legitimate users and once most sites use is spammers > will get around it. I completely agree... Greylisting isn't the best way to use it. I should say though that I might be in a different configuration then you... Most of the people who e-mail my domain are our customers and have their own domain. So I can white list all of our customers since the chance of spam is very low from their company mail servers. Greylisting also helped me get my feet wet with spam related issues since I wasn't ready to start blocking based on content. But now we get too much spam making it around the greylisting so I need to get back into the fight against spam! :) > >> >> Why not run something like that instead of checking for all that >> stuff just before the delivery? >> >>> Again, just my opinion. >>> >>> -- >>> Jo Rhett >>> Net Consonance ... net philanthropy, open source and other >>> randomness >>> _______________________________________________ >>> Mailman-Developers mailing list >>> Mailman-Developers at python.org >>> http://mail.python.org/mailman/listinfo/mailman-developers >>> Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py >>> Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ >>> Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/japruim%40raoset.com >>> >>> Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp >>> >> >> -- >> >> Jason Pruim >> Raoset Inc. >> Technology Manager >> MQC Specialist >> 3251 132nd ave >> Holland, MI, 49424-9337 >> www.raoset.com >> japruim at raoset.com >> >> >> > -- Jason Pruim Raoset Inc. Technology Manager MQC Specialist 3251 132nd ave Holland, MI, 49424-9337 www.raoset.com japruim at raoset.com From timowi.lists at gmx.de Thu Mar 27 18:34:41 2008 From: timowi.lists at gmx.de (Timo Wingender) Date: Thu, 27 Mar 2008 18:34:41 +0100 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: <53240295-0A86-4940-91C5-29FD85FBFE52@zone12.com> References: <47EBBCA5.1000305@gmx.de> <47EBCB61.30702@netconsonance.com> <53240295-0A86-4940-91C5-29FD85FBFE52@zone12.com> Message-ID: <47EBDAB1.3070904@gmx.de> Terri Oda schrieb: > On 27-Mar-08, at 12:35 PM, Jason Pruim wrote: > >> One thing that I've been thinking about in regards to this... Is this >> job the responsibility of mailman? To scan for spam and other such >> things? >> >> I do all of my scanning at the front end, all e-mail gets run through >> ASSP to scan blacklists, grey list, etc. etc. then it goes to the MTA, >> which in my case just verifies the account exists (Or an alias for it >> does) and then is delivered to mailman for delivery... >> >> Why not run something like that instead of checking for all that stuff >> just before the delivery? >> > > Even if it's not Mailman's responsibility to do the scanning, it can > be incredibly helpful to make the mailman interface aware of and able > to interact with scanning technologies. ie - using messages > discarded as spam for retraining the system, letting list admins > customize the behaviour for some lists (or -owner addresses) based on > lower or higher threshold values than the server itself uses, maybe > having a way to "discard this spam for all lists" or "flag this as > spam for other list admins" in the case of messages being sent to > multiple lists at once... > That's exactly my intention. interaction between list is an good idea. But I think relative difficult to implement. > Terri > > > From thijs at debian.org Thu Mar 27 18:44:18 2008 From: thijs at debian.org (Thijs Kinkhorst) Date: Thu, 27 Mar 2008 18:44:18 +0100 Subject: [Mailman-Developers] Done. In-Reply-To: <47EBD57F.3070204@netconsonance.com> References: <47EBD57F.3070204@netconsonance.com> Message-ID: <200803271844.20977.thijs@debian.org> On Thursday 27 March 2008 18:12, Jo Rhett wrote: > I respected the community by coming here and trying to address the > issue, rather than simply blacklisting Mailman sites. ?I respected the > community by replying to everyone who replied to me, rather than > ignoring the posts filled with derision or technical nonsense. ?Perhaps > that was a mistake. I very much support your point of trying to get Mailman into even better defaults. I do also support the people that you come across in a negative, agressive way. It's a pity that you do not see how your tone and way of responding can come across agressive and demanding, and how that makes your actual point fade to the background. Even how much I support your point I got quickly fed up with your conversation style when I received 14 (!) messages by you in just one day on this topic. Some restraint and reflection would be welcome, I guess... bye, Thijs Kinkhorst Debian Mailman Maintainer -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 481 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20080327/03aa13b8/attachment.pgp From mark at msapiro.net Thu Mar 27 20:10:36 2008 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 27 Mar 2008 12:10:36 -0700 Subject: [Mailman-Developers] Done. In-Reply-To: <47EBD57F.3070204@netconsonance.com> Message-ID: Jo Rhett wrote: > >At this time there has been more effort spent writing me back saying >that I'm not respecting the community than it would have taken to write >patches to fix the problem. I've certainly wasted more time here than I >did writing my patches and testing them in the first place. Are you aware that not once in the "before next release:" thread is there any mention that you have patches? Perhaps this has been mentioned before, and I missed it, but I would be interested in seeing them. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From mark at msapiro.net Thu Mar 27 20:47:26 2008 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 27 Mar 2008 12:47:26 -0700 Subject: [Mailman-Developers] Done. In-Reply-To: <47EBF3A6.5080001@netconsonance.com> Message-ID: Jo Rhett wrote: >Mark Sapiro wrote: >> Are you aware that not once in the "before next release:" thread is >> there any mention that you have patches? Perhaps this has been >> mentioned before, and I missed it, but I would be interested in seeing >> them. > >I'm not on the mailing list any more. But not only did I say this >multiple times, but I said this directly in a reply to you: > >http://mail.python.org/pipermail/mailman-developers/2008-March/019809.html What you said in that reply was "I disabled all the backscatter aliases 4 years ago, and haven't heard a single complaint." You also acknowledged in a subsequent post that "obviously you also have to patch the headers added to list e-mail to not reference these names" This is to me at least, not the same thing as saying you have actual patches. Close perhaps, but not the same. >The patches I did were brute-force patches for 2.1.4 or maybe even >earlier. Any competent programmer could do the same patches in about 15 >minutes. Maybe so, and maybe even I could, but even a checklist such as the following, presumably tested, list is of interest. >* Create only a single alias per list (remove 11-12 lines from the output) > >* Change the default to D_DISCARD in two places > >* Remove the option to reject message (leave accept/discard) in moderation > >* Change the headers to give only http addresses for subscribe/unsubscribe. > >I kid you not, it's less text than this message. It's also very >brute-force and I can understand why people would want something >supported by the Mailman developers. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From mark at msapiro.net Thu Mar 27 21:09:03 2008 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 27 Mar 2008 13:09:03 -0700 Subject: [Mailman-Developers] Sibling list terminology (was Re: Mailman 2.1.10b4 Released) In-Reply-To: <7FE7A0C5-4EDF-441F-B01E-5F286A74BAEA@list.org> References: <47D9E26E.4040708@msapiro.net> <36898B72F6D4423EF51C29C3@lewes.staff.uscs.susx.ac.uk> <7FE7A0C5-4EDF-441F-B01E-5F286A74BAEA@list.org> Message-ID: <47EBFEDF.2070805@msapiro.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Barry Warsaw wrote: | On Mar 14, 2008, at 7:30 AM, Ian Eiloart wrote: | |> --On 13 March 2008 19:26:54 -0700 Mark Sapiro |> wrote: | |>> - - Added a new 'sibling list' feature to exclude members of |>> another list |>> from receiving a post from this list if the other list is in the |>> To: or |>> Cc: of the post or to include members of the other list if that |>> list is |>> not in the To: or Cc: of the post (Patch ID 1347962). |> I don't understand this feature.... Hmm, Tokio Kikuchi asked about |> the name |> in 2005. I'm sorry that I didn't comment earlier. | |> Sibling is a *completely* misleading term for this feature, because |> sibling |> relationships are necessarily symmetrical: if A is a sibling of B, |> then B |> must be a sibling of A. This feature is necessarily anti- |> symmetrical, more |> like "child" or "descendent". The term "sibling" will lead people to |> misconfigure their lists. | |> |> | |> Question: is the relationship also transitive? IE, if C is a child |> of B, |> and B is a child of A, then will postings to A go to members of C? |> If so, |> then the relationship should be called "descendent". | |> | |> As far as inclusion is concerned, we then have a partially ordered |> set of |> mailing lists under this relationship. If the code handles the |> (presumably |> erroneous case) where a list is marked as a "sibling" of itself |> properly |> (ie, the listing should be ignored). | |> | | I didn't see any follow up on this, but perhaps I missed it while I | was at Pycon. There wasn't any. At one point, I was going to reply, but I got distracted. | Tokio can correct me, but I do not believe this feature is | transitive. There is a strictly one-level inclusion or exclusion of | regular delivery addresses. That is correct. | I see what you're saying about the term "sibling" lists being | misleading. But what's a good term? I can't think of anything that | encompasses both the inclusion and exclusion lists. "Related" is | about as close as I could come, but that's pretty uninformative. Related (or Relative) was the alternative idea that occurred to me as well, but as you say, it isn't very informative. | It | also might be too late to change for 2.1.10, especially if the u/i | strings have already been translated. Ultimately, it's Mark's | decision, and changing it would be predicated on finding a good | alternative. The actual word "sibling" appears in a few places. It is in the title of the subsection for configuring regular_(in|ex)clude_lists, and is mentioned in the detailed help for these settings in the phrase "site administrator may prohibit cross domain siblings". It is also in the configuration variable ALLOW_CROSS_DOMAIN_SIBLING. I would be reluctant to change this for 2.1.10 because the existing strings have been translated in a few updates, and I have been actively trying to keep from making any further changes to i18n strings. As far as whether the 'sibling' relationship is symmetric or antisymmetric, this is a question that can only be answered if the definition of the relationship is precise enough. There are at least two possible definitions that make sense to me. 1) List A is a sibling of list B iff list A appears in one of list B's regular_(in|ex)clude_lists attributes. 2) List A is a sibling of List B iff list A appears in one of list B's regular_(in|ex)clude_lists attributes or list B appears in one of list A's regular_(in|ex)clude_lists attributes. Under definition 1), the 'sibling' relationship is neither symmetric nor antisymmetric. Under definition 2), the 'sibling' relationship is symmetric and not antisymmetric. As far as a list being in it's own regular_(in|ex)clude_lists, as a result of Ian's original post, I changed the GUI to not allow it and changed the handler to ignore it, but log it. - -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFH6/7fVVuXXpU7hpMRAg3OAJ93X8ZrNEnRPTJlJSVVSrjUACXdjQCgvHkS JEQvKrmvbL2obz4ybyrX728= =Fqg8 -----END PGP SIGNATURE----- From mark at msapiro.net Thu Mar 27 22:21:04 2008 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 27 Mar 2008 14:21:04 -0700 Subject: [Mailman-Developers] Done. In-Reply-To: Message-ID: Mark Sapiro wrote: >Jo Rhett wrote: > >>Mark Sapiro wrote: >>> Are you aware that not once in the "before next release:" thread is >>> there any mention that you have patches? Perhaps this has been >>> mentioned before, and I missed it, but I would be interested in seeing >>> them. I apologize. When I wrote the above and the reply below, I had not seen the post from earlier today at . >>I'm not on the mailing list any more. But not only did I say this >>multiple times, but I said this directly in a reply to you: >> >>http://mail.python.org/pipermail/mailman-developers/2008-March/019809.html > > >What you said in that reply was "I disabled all the backscatter aliases >4 years ago, and haven't heard a single complaint." > >You also acknowledged in a subsequent post that "obviously you also >have to patch the headers added to list e-mail to not reference these >names" > >This is to me at least, not the same thing as saying you have actual >patches. Close perhaps, but not the same. > > >>The patches I did were brute-force patches for 2.1.4 or maybe even >>earlier. Any competent programmer could do the same patches in about 15 >>minutes. > > >Maybe so, and maybe even I could, but even a checklist such as the >following, presumably tested, list is of interest. > > >>* Create only a single alias per list (remove 11-12 lines from the output) >> >>* Change the default to D_DISCARD in two places >> >>* Remove the option to reject message (leave accept/discard) in moderation >> >>* Change the headers to give only http addresses for subscribe/unsubscribe. >> -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From shiva at sewingwitch.com Fri Mar 28 03:36:20 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 27 Mar 2008 19:36:20 -0700 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <20080327001842.GN22377@garp.metalab.unc.edu> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <46AFF679D4EFB29F57698A4B@lewes.staff.uscs.susx.ac.uk> <1369.64.13.143.30.1206558898.squirrel@mail.netconsonance.com> <20080327001842.GN22377@garp.metalab.unc.edu> Message-ID: <51562E4E6BE7FC75C5D4522E@[10.169.6.155]> On Wednesday, March 26, 2008 8:18 PM -0400 Crist?balPalmer wrote: > Jo, would you please be willing to take the lead in improving this > wiki page: > > http://wiki.list.org/display/SEC/Controlling+spam > > since it looks rather stubbish? Agreed. I grabbed text from Jo's original post to get it started, added some of my own supposition, and Mark Sapiro corrected my mistakes. I'd love to see others with experience take it out of stub-hood. From lists at mschuette.name Thu Mar 27 19:37:29 2008 From: lists at mschuette.name (=?ISO-8859-1?Q?Martin_Sch=FCtte?=) Date: Thu, 27 Mar 2008 19:37:29 +0100 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: <53240295-0A86-4940-91C5-29FD85FBFE52@zone12.com> References: <47EBBCA5.1000305@gmx.de> <47EBCB61.30702@netconsonance.com> <53240295-0A86-4940-91C5-29FD85FBFE52@zone12.com> Message-ID: <47EBE969.4000108@mschuette.name> Terri Oda schrieb: > Even if it's not Mailman's responsibility to do the scanning, it can > be incredibly helpful to make the mailman interface aware of and able > to interact with scanning technologies. I would suggest to be more specific: which functions do we wish to have, what is necessary to implement them, and is the effort worth it? - run Spamassassin (or another classification) on all messages: IMHO this is the MTA's job, so let's assume it already happens - hold or discard Messages marked as spam: Set up Spam-Filter rules with "X-Spam-Flag: YES", "X-Spam-Level: \*\*\*\*\*\*\*", or whatever. It is not the most user friendly interface, but certainly the most configurable and flexible one. - give feedback to train a classifier: The admindb interface already has a checkbox to save spam. IMHO it should be given a better label (cf. http://sourceforge.net/tracker/index.php?func=detail&aid=1910552&group_id=103&atid=300103) but it exists and the site administrator only has to train the saved messages regularly. (On my site I deliver them into a shared IMAP spam-folder for review and training.) - reclassify mails in the hold-queue: This sounds quite promising (I know some people do this successfully with IMAP inboxes). But as already mentioned this requires additional effort from the site admins, which probably will not change a working Amavis setup for this. P.S.: I hope this mail did not become too negative. I am always in favour of better and more user friendly spam filters. But there are quite a lot of spam-related patches already and any new approach should be clearly better than the already existing hooks and functions. Otherwise it is just a waste of time which should be used for other problems (MM3 comes to mind). -- Martin From terri at zone12.com Fri Mar 28 04:19:27 2008 From: terri at zone12.com (Terri Oda) Date: Thu, 27 Mar 2008 23:19:27 -0400 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: <47EBE969.4000108@mschuette.name> References: <47EBBCA5.1000305@gmx.de> <47EBCB61.30702@netconsonance.com> <53240295-0A86-4940-91C5-29FD85FBFE52@zone12.com> <47EBE969.4000108@mschuette.name> Message-ID: On 27-Mar-08, at 2:37 PM, Martin Sch?tte wrote: > P.S.: I hope this mail did not become too negative. I am always in > favour of better and more user friendly spam filters. But there are > quite a lot of spam-related patches already and any new approach > should > be clearly better than the already existing hooks and functions. > Otherwise it is just a waste of time which should be used for other > problems (MM3 comes to mind). Choosing the best of from existing spam-related packages and integrating them into the main development tree actually sounds about perfect for a Google summer of code project, IMO. As does taking all the existing methods for handling things (as you described) and putting a good interface on them that makes it easier for people to use and realise that these things can be done. It's easy for *us* to say "well, of course, you can already do that!" but many list admins and even site admins are not aware that these things can be done, and perhaps wouldn't even think to do them. If there was a big "spam management" section in the admin interface, it'd make a lot of people happy. Even just a simple "discard as spam" option which (a) discarded the message (b) saved it somewhere, ran a trainer on it, then deleted it (or not, but these things pile up) would be a useful change to many people. I don't think it's a waste of time at all to make it easier for people to use existing hooks and functions. And I think a lot of the reason we haven't integrated the existing spam-related patches is just that no one's had the time to look through them all and figure out which ones are the best and/or what elements we want from each of them. Again, I think doing so would be quite the worthwhile endeavour. Not all development has to be innovative research! :) Terri From stephen at xemacs.org Fri Mar 28 08:14:09 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 28 Mar 2008 16:14:09 +0900 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <20A8FB7AF06FCD481A760372@lewes.staff.uscs.susx.ac.uk> References: <47E930FD.2000800@utu.fi> <87bq52eevv.fsf@uwakimon.sk.tsukuba.ac.jp> <6409CCAB96BF893D5A596FCA@lewes.staff.uscs.susx.ac.uk> <87tzitdoop.fsf@uwakimon.sk.tsukuba.ac.jp> <20A8FB7AF06FCD481A760372@lewes.staff.uscs.susx.ac.uk> Message-ID: <87abkjtj5q.fsf@uwakimon.sk.tsukuba.ac.jp> 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 imagine what we could do with a month of Barry's undivided attention? Or how about a month of Mark's time (problem with Mark is I don't know if his boss is as sympathetic as Barry's boss is likely to be ...)? > > I ask, where are these requirements written? > > You mean the requirement that the mail system be able to reject email from > non-members at SMTP time? I mean the document that says that backscatter is a mortal sin, not the document that says various people hold the personal opinion that it would be nice if Mailman would to stop all backscatter. > If you read the thread carefully, you'll find that my position is that this > feature is a requirement, but not for 2.1, and maybe not even for 2.2. I > just want it to happen eventually. I'm aware of that. Jo Rhett lacks that kind of patience, and more important, claims to be one of "dozens" similarly impatient I really think this should happen for 2.2, though, and that 2.2 (or something) should happen quite soon. I plan to fix up my secondary MX situation shortly, but not everybody in my situation can do that. > [This stuff isn't written anywhere more reliable than Wikipedia, > and that is] why I post to the list. That's what I was afraid of. From stephen at xemacs.org Fri Mar 28 09:27:05 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 28 Mar 2008 17:27:05 +0900 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <47EBC9D8.3000403@netconsonance.com> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <46AFF679D4EFB29F57698A4B@lewes.staff.uscs.susx.ac.uk> <1369.64.13.143.30.1206558898.squirrel@mail.netconsonance.com> <20080327001842.GN22377@garp.metalab.unc.edu> <47EBC9D8.3000403@netconsonance.com> Message-ID: <878x03tfs6.fsf@uwakimon.sk.tsukuba.ac.jp> 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 Wikipedia, please; Wikipedia does not pretend to publish standards. From stephen at xemacs.org Fri Mar 28 09:51:38 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 28 Mar 2008 17:51:38 +0900 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: <47EBBCA5.1000305@gmx.de> References: <47EBBCA5.1000305@gmx.de> Message-ID: <877ifnten9.fsf@uwakimon.sk.tsukuba.ac.jp> 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 going to reject or discard a post, you really want to reject it in the SMTP transaction that submits it to your external MX, not in Mailman. This implies - Since SpamAssassin (SpamBayes, etc) are easily integrated into MTAs, it's of secondary value to have them run from Mailman. There are also already such patches, so I don't think those would really qualify for GSoC by themselves. - The big hole in the current architecture is that there is no way for spam filters in the MTA to get information from Mailman's member lists. That seems to be the crucial defect at present. - You should get in touch with Brad Knowles who currently isn't subscribed to this list AFAIK, but is the resident anti-spam guru on Mailman-Users. He might be a good GSoc mentor if he's willing, although he's not a code jockey AFAIK. - Peripherally related, but also very important, is work on the backscatter problem. See the ongoing "before next release: disable backscatter in default installation" thread on this list. However, Jo Rhett has sketched out what basically is needed. It's not big enough to qualify for GSoC ;-) The remaining work, however, is substantial, but may not really be on-topic for GSoC: updating the templates, working with the translators to get the new templates translated, and testing the result. - (I do not speak for Barry or Mark, but FWIW) As I read Barry's statements, this kind of thing would not be appropriate for 2.1. - It is definitely appropriate for 2.2 IMO. That would need Mark's cooperation, of course. - Barry has already started work on 3.0 with the intent of realizing some of the ideas summarized above by allowing callbacks into Mailman to be subscriber info for the use of the MTA, including spam fighting. Probably the architectures of a 2.2 implementation and a 3.0 implementation would be quite different. HTH From julian at mehnle.net Fri Mar 28 10:31:59 2008 From: julian at mehnle.net (Julian Mehnle) Date: Fri, 28 Mar 2008 09:31:59 +0000 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <87abkjtj5q.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20A8FB7AF06FCD481A760372@lewes.staff.uscs.susx.ac.uk> <87abkjtj5q.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <200803280932.03268.julian@mehnle.net> Stephen J. Turnbull wrote: > Ian Eiloart writes: > > > I ask, where are these requirements written? > > > > You mean the requirement that the mail system be able to reject > > email from non-members at SMTP time? > > I mean the document that says that backscatter is a mortal sin, not > the document that says various people hold the personal opinion that > it would be nice if Mailman would to stop all backscatter. There is no such document. However you know that it's a mortal sin when you end up on several blacklists (and rightly so!) for having sent backscatter to innocent bystanders. Not all questions of morality have to be formed into laws (nor can they). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mail.python.org/pipermail/mailman-developers/attachments/20080328/d877533d/attachment.pgp From iane at sussex.ac.uk Fri Mar 28 13:09:51 2008 From: iane at sussex.ac.uk (Ian Eiloart) Date: Fri, 28 Mar 2008 12:09:51 +0000 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <878x03tfs6.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <46AFF679D4EFB29F57698A4B@lewes.staff.uscs.susx.ac.uk> <1369.64.13.143.30.1206558898.squirrel@mail.netconsonance.com> <20080327001842.GN22377@garp.metalab.unc.edu> <47EBC9D8.3000403@netconsonance.com> <878x03tfs6.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <5FB84C0DFC17D736C4D7E6B1@lewes.staff.uscs.susx.ac.uk> --On 28 March 2008 17:27:05 +0900 "Stephen J. Turnbull" wrote: > 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 Wikipedia, please; > Wikipedia does not pretend to publish standards. > Here's a page on the Exim wiki: How To Do Autoreplies Without The World Hating You UK Joint Academic Network provides network connectivity and services for UK HE institutions, here's their guidance to victims of backscatter: A talk given at a UK Unix User Group meeting. Look for the 5th abstract on this page: The inevitable "...considered harmful" article: -- Ian Eiloart IT Services, University of Sussex x3148 From iane at sussex.ac.uk Fri Mar 28 13:11:28 2008 From: iane at sussex.ac.uk (Ian Eiloart) Date: Fri, 28 Mar 2008 12:11:28 +0000 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: <47EBCB61.30702@netconsonance.com> References: <47EBBCA5.1000305@gmx.de> <47EBCB61.30702@netconsonance.com> Message-ID: <21AEA9C43E6DB2C33F329819@lewes.staff.uscs.susx.ac.uk> --On 27 March 2008 09:29:21 -0700 Jo Rhett wrote: > Timo Wingender wrote: >> Discard messages from nonmembers is no option on most lists. > > AFAIK it is an option, but not the default and defaults are rarely > changed in my experience. I think he means it's not an acceptable option. -- Ian Eiloart IT Services, University of Sussex x3148 From iane at sussex.ac.uk Fri Mar 28 13:36:47 2008 From: iane at sussex.ac.uk (Ian Eiloart) Date: Fri, 28 Mar 2008 12:36:47 +0000 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <87abkjtj5q.fsf@uwakimon.sk.tsukuba.ac.jp> References: <47E930FD.2000800@utu.fi> <87bq52eevv.fsf@uwakimon.sk.tsukuba.ac.jp> <6409CCAB96BF893D5A596FCA@lewes.staff.uscs.susx.ac.uk> <87tzitdoop.fsf@uwakimon.sk.tsukuba.ac.jp> <20A8FB7AF06FCD481A760372@lewes.staff.uscs.susx.ac.uk> <87abkjtj5q.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <6448A7726836C8302EE824C3@lewes.staff.uscs.susx.ac.uk> > I really think this should happen for 2.2, though, and that 2.2 (or > something) should happen quite soon. I plan to fix up my secondary MX > situation shortly, but not everybody in my situation can do that. > > > [This stuff isn't written anywhere more reliable than Wikipedia, > > and that is] why I post to the list. > > That's what I was afraid of. > 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 return-path. That's what SPF and DKIM are intended to help with. There's friction in their adoption because certain features of email (notably mail forwarding, but also some others) have no regard for these features. Until no email service provider accepts message submissions outside of their own domains, all email providers offer message submission on port 587, all message submissions are autheticated, and mail forwarders accept responsibility for the email that they forward, it's not safe to bounce email. -- Ian Eiloart IT Services, University of Sussex x3148 From julian at mehnle.net Fri Mar 28 13:47:48 2008 From: julian at mehnle.net (Julian Mehnle) Date: Fri, 28 Mar 2008 12:47:48 +0000 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <6448A7726836C8302EE824C3@lewes.staff.uscs.susx.ac.uk> References: <87abkjtj5q.fsf@uwakimon.sk.tsukuba.ac.jp> <6448A7726836C8302EE824C3@lewes.staff.uscs.susx.ac.uk> Message-ID: <200803281247.51493.julian@mehnle.net> Ian Eiloart wrote: > 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 return-path. > > That's what SPF and DKIM are intended to help with. There's friction in > their adoption because certain features of email (notably mail > forwarding, but also some others) have no regard for these features. So far, so good. > Until no email service provider accepts message submissions outside of > their own domains, all email providers offer message submission on port > 587, all message submissions are autheticated, and mail forwarders > accept responsibility for the email that they forward, it's not safe to > bounce email. This, however, is simply untrue. Of course what you said is desirable, but SPF can help with safely bouncing e-mail _today_. SPF may sometimes give an unexpected "Fail" result due to alias-style forwarding or other problematic cases, but when it gives a "Pass" result, it is always safe, i.e., the return path can be assumed to be authentic and bounces may be sent. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mail.python.org/pipermail/mailman-developers/attachments/20080328/26c86636/attachment.pgp From cmpalmer at metalab.unc.edu Fri Mar 28 17:14:01 2008 From: cmpalmer at metalab.unc.edu (=?iso-8859-1?Q?Crist=F3bal?= Palmer) Date: Fri, 28 Mar 2008 12:14:01 -0400 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: <47EBE969.4000108@mschuette.name> References: <47EBBCA5.1000305@gmx.de> <47EBCB61.30702@netconsonance.com> <53240295-0A86-4940-91C5-29FD85FBFE52@zone12.com> <47EBE969.4000108@mschuette.name> Message-ID: <20080328161401.GF22290@garp.metalab.unc.edu> On Thu, Mar 27, 2008 at 07:37:29PM +0100, Martin Sch?tte wrote: > > - hold or discard Messages marked as spam: > Set up Spam-Filter rules with "X-Spam-Flag: YES", "X-Spam-Level: > \*\*\*\*\*\*\*", or whatever. It is not the most user friendly > interface, but certainly the most configurable and flexible one. 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 imposed that filtering on all lists because we have been blacklisted by spamcop yet again. The message we were blacklisted for had been tagged as spam by SA on the list server, but still got bounced out to an innocent 3rd party (who then reported us). Anything that makes spam filtering smarter and better-integrated in mailman is a Good Thing (tm). Providing the *option* to have good and sane filtering integration is definitely not enough. Even with hand-holding and encouragement, the vast majority of our list admins are not going to do nearly as good a job as mailman can do if it accepts this GSOC project. I'll be happy to provide whatever feedback or support I can in making that happen. For the curious, the script I ran was based closely on what's in the wiki for changing generic_nonmember_action: #!/bin/bash cd /usr/local/mailman/bin f=`mktemp` echo "header_filter_rules = [('^X-Spam-Status: Yes', 3, 0)]" > $f for list in `cat /root/no-filter-rules.txt` do ./config_list -i $f $list done rm $f where "/root/no-filter-rules.txt" is a list of lists that had not heeded my advice. Cheers, -- Crist?bal Palmer ibiblio.org systems administrator From timowi.lists at gmx.de Fri Mar 28 18:20:20 2008 From: timowi.lists at gmx.de (Timo Wingender) Date: Fri, 28 Mar 2008 18:20:20 +0100 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: <877ifnten9.fsf@uwakimon.sk.tsukuba.ac.jp> References: <47EBBCA5.1000305@gmx.de> <877ifnten9.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <47ED28D4.6020809@gmx.de> Stephen J. Turnbull schrieb: > 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 going to reject or discard a post, you really want to > reject it in the SMTP transaction that submits it to your external > MX, not in Mailman. This implies > If you don't discard all messages from nonmembers then this is not possible. Of course everything which is obviously spam or produce an error in mailman should be rejected in the smtp transaction. But the must be discarded in mailman > - Since SpamAssassin (SpamBayes, etc) are easily integrated into MTAs, > it's of secondary value to have them run from Mailman. There are > also already such patches, so I don't think those would really > qualify for GSoC by themselves. > - The big hole in the current architecture is that there is no way for > spam filters in the MTA to get information from Mailman's member > lists. That seems to be the crucial defect at present. > That's a good point for lists which discards all messages from non-members. But I think it doesn't affect lists which holds messages from nonmembers by default. > - You should get in touch with Brad Knowles who currently isn't > subscribed to this list AFAIK, but is the resident anti-spam guru on > Mailman-Users. He might be a good GSoc mentor if he's willing, > although he's not a code jockey AFAIK. > > - Peripherally related, but also very important, is work on the > backscatter problem. See the ongoing "before next release: disable > backscatter in default installation" thread on this list. However, > Jo Rhett has sketched out what basically is needed. It's not big > enough to qualify for GSoC ;-) The remaining work, however, is > substantial, but may not really be on-topic for GSoC: updating the > templates, working with the translators to get the new templates > translated, and testing the result. > I read parts of this thread. It's a very long discussion. Adding configuration options to mailman to disable some of the aliases and only answer requests if they seem to contain a command, could be a part of my application. > - (I do not speak for Barry or Mark, but FWIW) As I read Barry's > statements, this kind of thing would not be appropriate for 2.1. > - It is definitely appropriate for 2.2 IMO. That would need Mark's > cooperation, of course. > - Barry has already started work on 3.0 with the intent of realizing > some of the ideas summarized above by allowing callbacks into > Mailman to be subscriber info for the use of the MTA, including spam > fighting. Probably the architectures of a 2.2 implementation and a > 3.0 implementation would be quite different. > I thought of 2.2 too. 2.1 would be nicer because 2.2 and 3.0 seems too far away. I wrote to this list to get some information which spam features are acceptable by the mailman developers and to get some more specific ideas. From timowi.lists at gmx.de Fri Mar 28 18:40:37 2008 From: timowi.lists at gmx.de (Timo Wingender) Date: Fri, 28 Mar 2008 18:40:37 +0100 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: <47EBE969.4000108@mschuette.name> References: <47EBBCA5.1000305@gmx.de> <47EBCB61.30702@netconsonance.com> <53240295-0A86-4940-91C5-29FD85FBFE52@zone12.com> <47EBE969.4000108@mschuette.name> Message-ID: <47ED2D95.1060205@gmx.de> Martin Sch?tte schrieb: > Terri Oda schrieb: > > Even if it's not Mailman's responsibility to do the scanning, it can > > be incredibly helpful to make the mailman interface aware of and able > > to interact with scanning technologies. > > I would suggest to be more specific: which functions do we wish to have, > what is necessary to implement them, and is the effort worth it? > > - run Spamassassin (or another classification) on all messages: > IMHO this is the MTA's job, so let's assume it already happens > > - hold or discard Messages marked as spam: > Set up Spam-Filter rules with "X-Spam-Flag: YES", "X-Spam-Level: > \*\*\*\*\*\*\*", or whatever. It is not the most user friendly > interface, but certainly the most configurable and flexible one. > > - give feedback to train a classifier: > The admindb interface already has a checkbox to save spam. > IMHO it should be given a better label (cf. > http://sourceforge.net/tracker/index.php?func=detail&aid=1910552&group_id=103&atid=300103) > but it exists and the site administrator only has to train the saved > messages regularly. (On my site I deliver them into a shared IMAP > spam-folder for review and training.) This is a begin. But train a statistical filter is more than feeding it with spam. Feeding it with ham messages just as important. > > - reclassify mails in the hold-queue: > This sounds quite promising (I know some people do this successfully > with IMAP inboxes). > But as already mentioned this requires additional effort from the site > admins, which probably will not change a working Amavis setup for this. What has this to do with the amavis setup? SpamAssassin should be installed on every site. And then it can be called to reclassify messages and to learn them as spam or ham. Yes, most of this can be done with mailman in some way already. But therefor you have to know much about mailman and the mail system. This requires changes of the system and sometimes patching of mailman. I this it's an good idea to have this features in mailman, so everyone can simply use it. Even if they don't have access to the system. From mark at msapiro.net Fri Mar 28 19:14:46 2008 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 28 Mar 2008 11:14:46 -0700 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: <47ED28D4.6020809@gmx.de> Message-ID: Timo Wingender wrote: >Stephen J. Turnbull schrieb: >> >> - Peripherally related, but also very important, is work on the >> backscatter problem. See the ongoing "before next release: disable >> backscatter in default installation" thread on this list. However, >> Jo Rhett has sketched out what basically is needed. It's not big >> enough to qualify for GSoC ;-) The remaining work, however, is >> substantial, but may not really be on-topic for GSoC: updating the >> templates, working with the translators to get the new templates >> translated, and testing the result. >> >I read parts of this thread. It's a very long discussion. >Adding configuration options to mailman to disable some of the aliases >and only answer requests if they seem to contain a command, could be a >part of my application. This would be useful. I *might* even be able to mentor this (or even a larger) part of the project, but I'm not able to commit to that at this time. >> - (I do not speak for Barry or Mark, but FWIW) As I read Barry's >> statements, this kind of thing would not be appropriate for 2.1. >> - It is definitely appropriate for 2.2 IMO. That would need Mark's >> cooperation, of course. >> - Barry has already started work on 3.0 with the intent of realizing >> some of the ideas summarized above by allowing callbacks into >> Mailman to be subscriber info for the use of the MTA, including spam >> fighting. Probably the architectures of a 2.2 implementation and a >> 3.0 implementation would be quite different. >> >I thought of 2.2 too. 2.1 would be nicer because 2.2 and 3.0 seems too >far away. As far as I'm concerned, nothing should be done in 2.1 at this point. All development of anything other than bug and security related fixes going forward should be on the 2.2 or 3.0 branches (I know some consider backscatter to be a security issue, but that is not the sense I mean when I say 'security related'). I would like 2.2.0 to be the next release after 2.1.10. I have some small changes to go into it now, and I think addressing backscatter should be high on the list. We also thought initially that getting some GUI improvements would be the primary focus of 2.2, but if that work (which wasn't being done by me) is not forthcoming soon, I would consider making 2.2 relatively short lived and deferring the GUI improvements to a potential 2.3 release. >I wrote to this list to get some information which spam features are >acceptable by the mailman developers and to get some more specific ideas. My view on spam is that as much as possible, it should be dealt with in the MTA and Mailman should never see it. I know that this is not possible in all situations because critera for non-acceptance or discard of a message may be different for Mailman lists than for other mail. I personally have recently started using MailScanner on the server that I admin. It is actually very flexible in allowing different critera and rules based on sender or recipient or whatever. The one thing I don't like is that it interfaces with Postfix (and other MTAs too) in a way that doesn't allow rejecting the mail at incoming SMTP time. Of course I don't accept mail for recipients I don't know, and I greylist everything else, but after that, I have to just store or discard the mail I don't want to deliver as it's too late to not accept it. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From shiva at sewingwitch.com Fri Mar 28 22:57:11 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 28 Mar 2008 14:57:11 -0700 Subject: [Mailman-Developers] mm-handler 2.1.10 (was: before next release: disable backscatter in default installation) In-Reply-To: <20080306220214.GH10751@monkey.uchicago.edu> References: <46943F5EA82CA7EE31E8DEF2@[10.169.6.155]> <20080306220214.GH10751@monkey.uchicago.edu> Message-ID: --On Thursday, March 06, 2008 4:02 PM -0600 David Champion wrote: > Here is an update to mm-handler which might address this adequately. I > no longer use mm-handler myself (despite having written it), so I can't > test this short of installing a new Mailman instance. Can someone on > the list test it? > > http://home.uchicago.edu/~dgc/sw/mailman/mm-handler/mm-handler-2.10 > > Since it's contrib and not supported, maybe it would be reasonable to > put the update into the 2.1.10 release -- provided someone can declare > that it works. :) Otherwise feel free to post it on the wiki. I made some tweaks and discovered it won't work with a list with a dash in the name, due to the regex used to extract the action suffix. Can someone more nimble with regex let me know how to adjust it? I also changed the "printf STDERR" to syslog to my maillog. Here's the before/after regex: < if ($addr =~ /(.*)-(.*)\+.*$/) { --- > if ($addr =~ /(.*)-([^-]+)\+.*$/) { From mark at msapiro.net Fri Mar 28 23:53:38 2008 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 28 Mar 2008 15:53:38 -0700 Subject: [Mailman-Developers] mm-handler 2.1.10 (was: before next release:disable backscatter in default installation) In-Reply-To: Message-ID: Kenneth Porter wrote: > >I made some tweaks and discovered it won't work with a list with a dash in >the name, due to the regex used to extract the action suffix. Can someone >more nimble with regex let me know how to adjust it? > > > >I also changed the "printf STDERR" to syslog to my maillog. > >Here's the before/after regex: > >< if ($addr =~ /(.*)-(.*)\+.*$/) { >--- >> if ($addr =~ /(.*)-([^-]+)\+.*$/) { Actually, all the regexps are 'wrong' in that they will parse a local_part such as my-list into a listname of 'my' and a suffix of 'list' ($list and $cmd in the terminology of the module). The original contrib/mm_handler recovered from that by saying if the suffix didn't match something in the @validfields array, then the listname was the whole thing and the command was 'post' The revised version appears to do a similar thing, so I'm not sure what the problem is. Can you be more specific about the list name and the failure? I.e., what is the local_part of the address that fails and what does split_addr(local_part) return (or what error is logged)? BTW, the old regexps from contrib/mm-handler /(.*)-(.*)\+.*$/ and /(.*)-(.*)$/ and the new regexps /(.*)-([^-]+)\+.*$/ and /(.*)-([^-]+)$/ are virtually equivalent. The only difference is they require at least one character in the second group. The fact that they don't allow a '-' in the second group is irrelevant since the first group is greedy and will eat up all but the last '-' anyway. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From shiva at sewingwitch.com Sat Mar 29 00:03:25 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 28 Mar 2008 16:03:25 -0700 Subject: [Mailman-Developers] mm-handler 2.1.10 (was: before next release:disable backscatter in default installation) In-Reply-To: References: Message-ID: <6DC867EF5FB4C5D3B6B51C8A@[10.0.0.14]> I should have read the error reply more closely. It gave me back this: Your mail for tribes2-pickups at lists.matureasskickers.net could not be sent: no list named "tribes2-pickups-pickups" is known by lists.matureasskickers.net That should be easy to chase down. Since I patched the script to syslog I think I now have enough functionality that I can debug this printf-style. From mark at msapiro.net Sat Mar 29 00:29:24 2008 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 28 Mar 2008 16:29:24 -0700 Subject: [Mailman-Developers] mm-handler 2.1.10 (was: before nextrelease:disable backscatter in default installation) In-Reply-To: <6DC867EF5FB4C5D3B6B51C8A@[10.0.0.14]> Message-ID: Kenneth Porter wrote: >I should have read the error reply more closely. It gave me back this: > >Your mail for tribes2-pickups at lists.matureasskickers.net could not be sent: > no list named "tribes2-pickups-pickups" is known by >lists.matureasskickers.net > >That should be easy to chase down. In case you haven't got it already, the bug is that } elsif (! grep /^$cmd$/, @ValidActions) { # If an undefined action, restore list name $list = "$addr-$cmd"; $cmd = "post"; should be either } elsif (! grep /^$cmd$/, @ValidActions) { # If an undefined action, restore list name $list = "$list-$cmd"; $cmd = "post"; or } elsif (! grep /^$cmd$/, @ValidActions) { # If an undefined action, restore list name $list = $addr; $cmd = "post"; -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From shiva at sewingwitch.com Sat Mar 29 00:39:43 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 28 Mar 2008 16:39:43 -0700 Subject: [Mailman-Developers] mm-handler 2.1.10 (was: before nextrelease:disable backscatter in default installation) In-Reply-To: References: Message-ID: --On Friday, March 28, 2008 4:29 PM -0700 Mark Sapiro wrote: > In case you haven't got it already Thanks, just found it myself. ;) I'll put an updated copy on my website shortly. (Will also have fixed comments.) From stephen at xemacs.org Sat Mar 29 00:58:26 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 29 Mar 2008 08:58:26 +0900 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <200803280932.03268.julian@mehnle.net> References: <20A8FB7AF06FCD481A760372@lewes.staff.uscs.susx.ac.uk> <87abkjtj5q.fsf@uwakimon.sk.tsukuba.ac.jp> <200803280932.03268.julian@mehnle.net> Message-ID: <87skyaqu3h.fsf@uwakimon.sk.tsukuba.ac.jp> 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 sure: Ian Eiloart demonstrated a lot of goodwill toward Mailman when he provided about a half-dozen URLs. Can you justify (to yourself!) doing less? > However you know that it's a mortal sin when you end up on several > blacklists (and rightly so!) for having sent backscatter to > innocent bystanders. Oh, brother! Look up "vigilante", and meditate on the definition until you realize that those are the words of a vigilante. The point is that there's a big difference between blacklisting somebody like me, who has participated in this thread and followed past discussions of backscatter, and blacklisting some poor Ubuntu user, who just installs Mailman and creates a few lists because it says on the homepage that it tries to conform to the RFCs on mailing lists and provides some antispam features, and expects that it will therefore DTRT. The first is both necessary (hypothetically) and right (if necessary), but while the second may be necessary, there's no way it's right. Footnotes: [1] http://www.trumanlibrary.org/buckstop.htm From stephen at xemacs.org Sat Mar 29 01:09:30 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 29 Mar 2008 09:09:30 +0900 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <6448A7726836C8302EE824C3@lewes.staff.uscs.susx.ac.uk> References: <47E930FD.2000800@utu.fi> <87bq52eevv.fsf@uwakimon.sk.tsukuba.ac.jp> <6409CCAB96BF893D5A596FCA@lewes.staff.uscs.susx.ac.uk> <87tzitdoop.fsf@uwakimon.sk.tsukuba.ac.jp> <20A8FB7AF06FCD481A760372@lewes.staff.uscs.susx.ac.uk> <87abkjtj5q.fsf@uwakimon.sk.tsukuba.ac.jp> <6448A7726836C8302EE824C3@lewes.staff.uscs.susx.ac.uk> Message-ID: <87r6duqtl1.fsf@uwakimon.sk.tsukuba.ac.jp> 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 return-path. > > That's what SPF and DKIM are intended to help with. Aha, good point. OK, then the draft standards/RFCs for those qualify as far as I'm concerned. Note, I didn't mean that there must be an RFC saying "no backscatter", although you could read my words that way (and I certainly do demand it before I will consider this a purely technical problem). That would make things easy, of course, but those drafts/RFCs will most likely contain rationale for why we would like to outright ban backscatter, but can't quite go so far yet. > There's friction in their adoption because certain features of > email (notably mail forwarding, but also some others) have no > regard for these features. By which you mean that SPF and DKIM in some configurations are as big a threat to Mailman as blacklisting for backscatter is, right? From shiva at sewingwitch.com Sat Mar 29 01:22:21 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 28 Mar 2008 17:22:21 -0700 Subject: [Mailman-Developers] mm-handler 2.1.10 (was: before nextrelease:disable backscatter in default installation) In-Reply-To: References: Message-ID: --On Friday, March 28, 2008 4:39 PM -0700 Kenneth Porter wrote: > I'll put an updated copy on my website shortly. (Will also have fixed > comments.) Updated version: Changes from David's code: This is running on a CentOS 5 system, which may affect the paths used and the Perl packages available. From shiva at sewingwitch.com Sat Mar 29 01:33:39 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 28 Mar 2008 17:33:39 -0700 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <87skyaqu3h.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20A8FB7AF06FCD481A760372@lewes.staff.uscs.susx.ac.uk> <87abkjtj5q.fsf@uwakimon.sk.tsukuba.ac.jp> <200803280932.03268.julian@mehnle.net> <87skyaqu3h.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <2451B5B22475E784F7A8DAA3@[10.0.0.14]> --On Saturday, March 29, 2008 8:58 AM +0900 "Stephen J. Turnbull" wrote: > > However you know that it's a mortal sin when you end up on several > > blacklists (and rightly so!) for having sent backscatter to > > innocent bystanders. > > Oh, brother! Look up "vigilante", and meditate on the definition > until you realize that those are the words of a vigilante. Is Wikipedia's definition acceptable? > 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. Note that black lists don't block anything. They just report. It's like a web page that lists some group that the author thinks meets some criteria. Others can then use the black lists they trust to block unwanted traffic. I hardly consider either action to be unreasonable. > [...] blacklisting some poor Ubuntu user, who just installs Mailman and > creates a few lists because it says on the homepage that it tries to > conform to the RFCs on mailing lists and provides some antispam features, > and expects that it will therefore DTRT. [...] may be necessary, there's > no way it's right. Is it wrong for me to choose to not accept his traffic? Does the hypothetical "poor Ubuntu user" have a right to set policy on my server? From dgc at uchicago.edu Sat Mar 29 01:51:53 2008 From: dgc at uchicago.edu (David Champion) Date: Fri, 28 Mar 2008 19:51:53 -0500 Subject: [Mailman-Developers] mm-handler 2.1.10 (was: before nextrelease:disable backscatter in default installation) In-Reply-To: References: Message-ID: <20080329005153.GT10751@monkey.uchicago.edu> > Sorry for the bugs and such, and thanks for working it out. I feel bad about posting and abandoning, but I actually have no infrastructure to test this anymore. When I first contributed that script I only knew enough Python to debug Mailman, and was pretty comfortable with Perl. Now that I <3 Python and really can't stand Perl, I would like one day to redo the thing in Python. But I'm going to make it a little more "drivery", in that it'll handle Mailman or Sympa (our management's choice to replace Mailman) or anything else you plug in a ListManager subclass for. I'll probably try to use it for driving RT, for example. I'll post again when I've had a chance to make progress. -- -D. dgc at uchicago.edu NSIT University of Chicago From mark at msapiro.net Sat Mar 29 01:57:07 2008 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 28 Mar 2008 17:57:07 -0700 Subject: [Mailman-Developers] before next release: disable backscatterindefault installation In-Reply-To: <2451B5B22475E784F7A8DAA3@[10.0.0.14]> Message-ID: Kenneth Porter wrote: > >Note that black lists don't block anything. They just report. It's like a >web page that lists some group that the author thinks meets some criteria. > >Others can then use the black lists they trust to block unwanted traffic. I >hardly consider either action to be unreasonable. That's what the maintainers of black lists say, but in fact, the popular black lists are almost universally used by people who consider them a response to the spam problem without considering that the critera for being blacklisted and for being removed from blacklists are under control of the operators of the lists who guarantee no due process and are accountable to no one. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From julian at mehnle.net Sat Mar 29 02:06:42 2008 From: julian at mehnle.net (Julian Mehnle) Date: Sat, 29 Mar 2008 01:06:42 +0000 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <87skyaqu3h.fsf@uwakimon.sk.tsukuba.ac.jp> References: <200803280932.03268.julian@mehnle.net> <87skyaqu3h.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <200803290107.02030.julian@mehnle.net> Stephen J. Turnbull wrote: > 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 sure: Ian Eiloart demonstrated a lot of > goodwill toward Mailman when he provided about a half-dozen URLs. Can > you justify (to yourself!) doing less? You expect me to provide URLs showing what? That there is no standards document saying that backscatter is a mortal sin, in metaphoric sense or not? You must be kidding. > > However you know that it's a mortal sin when you end up on several > > blacklists (and rightly so!) for having sent backscatter to > > innocent bystanders. > > Oh, brother! Look up "vigilante", and meditate on the definition > until you realize that those are the words of a vigilante. > > The point is that there's a big difference between blacklisting > somebody like me, who has participated in this thread and followed > past discussions of backscatter, and blacklisting some poor Ubuntu > user, who just installs Mailman and creates a few lists because it > says on the homepage that it tries to conform to the RFCs on mailing > lists and provides some antispam features, and expects that it will > therefore DTRT. > > The first is both necessary (hypothetically) and right (if necessary), > but while the second may be necessary, there's no way it's right. You seem to be missing that the e-mail system is essentially an anarchy. If there were authorities that could be trusted to maintain order, there might not be any need for blacklists. As things are, however, it seems perfectly legitimate to reject mail from sources that are exhibiting antisocial behavior such as hitting unrelated people with backscatter. Of course we all don't want Mailman installations to systematically end up on blacklists for sending backscatter. That's why I suggested the use of SPF as a method to determine when bounces can be sent safely and when not. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mail.python.org/pipermail/mailman-developers/attachments/20080329/c9fb0691/attachment.pgp From julian at mehnle.net Sat Mar 29 02:18:17 2008 From: julian at mehnle.net (Julian Mehnle) Date: Sat, 29 Mar 2008 01:18:17 +0000 Subject: [Mailman-Developers] before next release: disable backscatterindefault installation In-Reply-To: References: Message-ID: <200803290118.17426.julian@mehnle.net> Mark Sapiro wrote: > Kenneth Porter wrote: > > Note that black lists don't block anything. They just report. It's > > like a web page that lists some group that the author thinks meets > > some criteria. > > > > Others can then use the black lists they trust to block unwanted > > traffic. I hardly consider either action to be unreasonable. > > That's what the maintainers of black lists say, but in fact, the > popular black lists are almost universally used by people who consider > them a response to the spam problem without considering that the > critera for being blacklisted and for being removed from blacklists > are under control of the operators of the lists who guarantee no due > process and are accountable to no one. Who says that benevolent-dictator blacklists cannot be an effective response to the spam prolem? And of course it is untrue that these benevolent dictators are accountable to no one. They are accountable to the users of their blacklists. If users learn that a blacklist is becoming too inaccurate, they will stop using it, or they would be shooting themselves in the foot by rejecting mail from innocent sources. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mail.python.org/pipermail/mailman-developers/attachments/20080329/e92a4e6a/attachment.pgp From mark at msapiro.net Sat Mar 29 03:08:51 2008 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 28 Mar 2008 19:08:51 -0700 Subject: [Mailman-Developers] mm-handler 2.1.10 (was: beforenextrelease:disable backscatter in default installation) In-Reply-To: Message-ID: Kenneth Porter wrote: > >Updated version: > > Kenneth, I would like to get this in the contrib directory for Mailman 2.1.10. I can do this in several ways. One would just be to replace the existing mm-handler and update the README.mm-handler as needed. That might be the cleanest. A second approach would be to update the README.mm-handler to indicate there are two versions and include your version as either a separate file or as a link to your web site. Do you (or does anyone else) have any thoughts on this? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From mark at msapiro.net Sat Mar 29 02:58:01 2008 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 28 Mar 2008 18:58:01 -0700 Subject: [Mailman-Developers] before next release: disablebackscatterindefault installation In-Reply-To: <200803290118.17426.julian@mehnle.net> Message-ID: Julian Mehnle wrote: > >Who says that benevolent-dictator blacklists cannot be an effective >response to the spam prolem? Few if any people. That's my point. >And of course it is untrue that these benevolent dictators are accountable >to no one. They are accountable to the users of their blacklists. If >users learn that a blacklist is becoming too inaccurate, they will stop >using it, or they would be shooting themselves in the foot by rejecting >mail from innocent sources. As long as the "collateral damage" is small compared to the reduction in spam, ISPs will continue to use the lists and it will be up to the "innocent sources" to try to get themselves off. Yes, there is some accountability in the sense you describe, but it is still vigilantism, not due process. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From fmouse-mailman at fmp.com Sat Mar 29 03:23:11 2008 From: fmouse-mailman at fmp.com (Lindsay Haisley) Date: Fri, 28 Mar 2008 21:23:11 -0500 Subject: [Mailman-Developers] before next release: disable backscatterindefault installation In-Reply-To: <200803290118.17426.julian@mehnle.net> References: <200803290118.17426.julian@mehnle.net> Message-ID: <1206757391.7766.13.camel@localhost.localdomain> On Sat, 2008-03-29 at 01:18 +0000, Julian Mehnle wrote: > > blacklists > > are under control of the operators of the lists who guarantee no due > > process and are accountable to no one. > > Who says that benevolent-dictator blacklists cannot be an effective > response to the spam prolem? > > And of course it is untrue that these benevolent dictators are accountable > to no one. They are accountable to the users of their blacklists. Absolutely! I use a mix of 6 advisroy blacklists on my mail server. For my personal account, these stop about 80% of the spam sent to me, and probably a similar percentage for my customers and my mailing lists. I haven't had a complaint about a false positive from these blacklists in well over a year. The last time I got such a report was on an IP address blocked because it was listed by Spamcop - one of several false positives from this source. I dropped Spamcop from the mix and have had no such problems since then. -- Lindsay Haisley | "In an open world, | PGP public key FMP Computer Services | who needs Windows | available at 512-259-1190 | or Gates" | http://pubkeys.fmp.com http://www.fmp.com | | From stephen at xemacs.org Sat Mar 29 05:08:14 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 29 Mar 2008 13:08:14 +0900 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: <20080328161401.GF22290@garp.metalab.unc.edu> References: <47EBBCA5.1000305@gmx.de> <47EBCB61.30702@netconsonance.com> <53240295-0A86-4940-91C5-29FD85FBFE52@zone12.com> <47EBE969.4000108@mschuette.name> <20080328161401.GF22290@garp.metalab.unc.edu> Message-ID: <87od8yqij5.fsf@uwakimon.sk.tsukuba.ac.jp> 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 imposed that filtering on all > lists because we have been blacklisted by spamcop yet again. The > message we were blacklisted for had been tagged as spam by SA on the > list server, but still got bounced out to an innocent 3rd party (who > then reported us). Why not just enforce this in SpamAssassin? If you've got lists that require special treatment and have trustworthy admins, get a plan from them and then add a rule that gives them a -5 or -10 bonus so that only really egregious spam gets automatically discarded, and the rest gets handled by the list- specific mechanism. You could also enable the per-address configs in SA itself. I don't see anything in this story that couldn't be done just as well with central control via SA at the MTA. From stephen at xemacs.org Sat Mar 29 05:31:47 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 29 Mar 2008 13:31:47 +0900 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <5FB84C0DFC17D736C4D7E6B1@lewes.staff.uscs.susx.ac.uk> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <46AFF679D4EFB29F57698A4B@lewes.staff.uscs.susx.ac.uk> <1369.64.13.143.30.1206558898.squirrel@mail.netconsonance.com> <20080327001842.GN22377@garp.metalab.unc.edu> <47EBC9D8.3000403@netconsonance.com> <878x03tfs6.fsf@uwakimon.sk.tsukuba.ac.jp> <5FB84C0DFC17D736C4D7E6B1@lewes.staff.uscs.susx.ac.uk> Message-ID: <87myoiqhfw.fsf@uwakimon.sk.tsukuba.ac.jp> 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. > This has zillions of links. Looks valuable, but it's not the place to start. I haven't looked closely at any of them yet, but I did think it was worth making those two observations. From stephen at xemacs.org Sat Mar 29 07:51:40 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 29 Mar 2008 15:51:40 +0900 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <2451B5B22475E784F7A8DAA3@[10.0.0.14]> References: <20A8FB7AF06FCD481A760372@lewes.staff.uscs.susx.ac.uk> <87abkjtj5q.fsf@uwakimon.sk.tsukuba.ac.jp> <200803280932.03268.julian@mehnle.net> <87skyaqu3h.fsf@uwakimon.sk.tsukuba.ac.jp> <2451B5B22475E784F7A8DAA3@[10.0.0.14]> Message-ID: <87lk42qayr.fsf@uwakimon.sk.tsukuba.ac.jp> 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. If you equate self-defense with justice, you are wrong. Vigilantes go beyond self-defense, and that's where they go wrong. > > [...] blacklisting some poor Ubuntu user, who just installs Mailman and > > creates a few lists because it says on the homepage that it tries to > > conform to the RFCs on mailing lists and provides some antispam features, > > and expects that it will therefore DTRT. [...] may be necessary, there's > > no way it's right. > > Is it wrong for me to choose to not accept his traffic? Of course not. Where has anybody suggested otherwise? What I object to is the notion that blacklisting is "right". That is vigilante thinking. Blacklisting is morally neither right nor wrong, not even in the context of spam received. It is a tool that can be used and abused. > Does the hypothetical "poor Ubuntu user" have a right to set policy > on my server? No, but he's going to do it anyway. The policy you want (unless you've got something personal against him) is to never see spam and backscatter, and to receive the valid mails that pass through his server. You can't have that if you blacklist him. You can't have that if you don't. From stephen at xemacs.org Sat Mar 29 08:22:17 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 29 Mar 2008 16:22:17 +0900 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <200803290107.02030.julian@mehnle.net> References: <200803280932.03268.julian@mehnle.net> <87skyaqu3h.fsf@uwakimon.sk.tsukuba.ac.jp> <200803290107.02030.julian@mehnle.net> Message-ID: <87k5jmq9jq.fsf@uwakimon.sk.tsukuba.ac.jp> 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 "antisocial behavior" to what is at worst incompetence. In fact, I object to them, in large part because they are so often associated with turning a blind eye to the collateral damage done by many anti- spam measures, in particular blacklists. From shiva at sewingwitch.com Sat Mar 29 09:16:07 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sat, 29 Mar 2008 01:16:07 -0700 Subject: [Mailman-Developers] mm-handler 2.1.10 (was: beforenextrelease:disable backscatter in default installation) In-Reply-To: References: Message-ID: <729790FACB4D85F25DCAF2A5@[10.0.0.14]> --On Friday, March 28, 2008 7:08 PM -0700 Mark Sapiro wrote: > I would like to get this in the contrib directory for Mailman 2.1.10. I > can do this in several ways. One would just be to replace the existing > mm-handler and update the README.mm-handler as needed. That might be > the cleanest. > > A second approach would be to update the README.mm-handler to indicate > there are two versions and include your version as either a separate > file or as a link to your web site. > > Do you (or does anyone else) have any thoughts on this? I don't have any preference. My version does depend on the presence of the syslog module, and I don't know how commonly-installed that is. But I don't know under what systems the debugging to stderr is supposed to work. Is that a Sun thing? From shiva at sewingwitch.com Sat Mar 29 09:22:31 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sat, 29 Mar 2008 01:22:31 -0700 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <87lk42qayr.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20A8FB7AF06FCD481A760372@lewes.staff.uscs.susx.ac.uk> <87abkjtj5q.fsf@uwakimon.sk.tsukuba.ac.jp> <200803280932.03268.julian@mehnle.net> <87skyaqu3h.fsf@uwakimon.sk.tsukuba.ac.jp> <2451B5B22475E784F7A8DAA3@[10.0.0.14]> <87lk42qayr.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <89F22996103D74A249DA37B1@[10.0.0.14]> --On Saturday, March 29, 2008 3:51 PM +0900 "Stephen J. Turnbull" wrote: > If you equate self-defense with justice, you are wrong. Vigilantes go > beyond self-defense, and that's where they go wrong. We're quibbling over definitions. It's impossible to find agreement under such circumstances. > No, but he's going to do it anyway. The policy you want (unless > you've got something personal against him) is to never see spam and > backscatter, and to receive the valid mails that pass through his > server. You can't have that if you blacklist him. You can't have > that if you don't. FWIW, I use blacklists via SpamAssassin, invoked from a Sendmail milter, so it's not a black and white decision that relies on a single such list. A degree of consensus is required. It might be straightforward to cook up some SA rules that recognize mailman backscatter and drop it, at the risk of dropping legitimate bounce notices. From dgc at uchicago.edu Sat Mar 29 17:28:42 2008 From: dgc at uchicago.edu (David Champion) Date: Sat, 29 Mar 2008 11:28:42 -0500 Subject: [Mailman-Developers] mm-handler 2.1.10 (was: beforenextrelease:disable backscatter in default installation) In-Reply-To: <729790FACB4D85F25DCAF2A5@[10.0.0.14]> References: <729790FACB4D85F25DCAF2A5@[10.0.0.14]> Message-ID: <20080329162842.GU10751@monkey.uchicago.edu> > I don't have any preference. My version does depend on the presence of the > syslog module, and I don't know how commonly-installed that is. But I don't > know under what systems the debugging to stderr is supposed to work. Is > that a Sun thing? IIRC stderr is captured by sendmail and logged in the bounce message, but admittedly if you're not bouncing that's a problem. I'd case out the syslog dependency, and use it only when available. Last I looked, Perl's syslog module was... limited. It doesn't even work at all on some platforms -- something about trying to UDP to the local syslogd instead of using syslog(3) through libc. So it's more portable to system out a call to logger(1) if you need syslogging and can afford a fork/exec. -- -D. dgc at uchicago.edu NSIT University of Chicago From mark at msapiro.net Sat Mar 29 17:37:38 2008 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 29 Mar 2008 09:37:38 -0700 Subject: [Mailman-Developers] mm-handler 2.1.10 (was:beforenextrelease:disable backscatter in default installation) In-Reply-To: <729790FACB4D85F25DCAF2A5@[10.0.0.14]> Message-ID: Kenneth Porter wrote: > >I don't have any preference. My version does depend on the presence of the >syslog module, and I don't know how commonly-installed that is. But I don't >know under what systems the debugging to stderr is supposed to work. Is >that a Sun thing? I just checked, and my CentOS 5 system only has Sys::Syslog and not Unix::Syslog. It might be worthwhile to provide your version plus a patch to go back to the old DEBUG w/o logging. OTOH, Unix::Syslog is available from CPAN, DAG, etc., so I don't think it's unreasonable to expect people to be able to get it. As I understand it (possibly wrong), the way this if ($DEBUG) { $to = join(',', @to); print STDERR "to: $to\n"; print STDERR "sender: $sender\n"; print STDERR "server: $server\n"; exit(-1); } works is it exits with an error, so sendmail returns an undeliverable status/notice containing the script output. Obviously, your logging is much nicer. I have another question since I don't know sendmail. Does sendmail execute mm-handler at incoming SMTP time, and if so, does an error exit from mm-handler result in an SMTP failure status being returned to the sending MTA? If so, it seems that rather than just dropping a 'bad' message as mm-handler seems to do when $BounceUnapproved = 0; and $BounceNonlist = 0;, wouldn't it be better to exit with a failure status. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From cmpalmer at metalab.unc.edu Sat Mar 29 18:50:11 2008 From: cmpalmer at metalab.unc.edu (=?iso-8859-1?Q?Crist=F3bal?= Palmer) Date: Sat, 29 Mar 2008 13:50:11 -0400 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: <87od8yqij5.fsf@uwakimon.sk.tsukuba.ac.jp> References: <47EBBCA5.1000305@gmx.de> <47EBCB61.30702@netconsonance.com> <53240295-0A86-4940-91C5-29FD85FBFE52@zone12.com> <47EBE969.4000108@mschuette.name> <20080328161401.GF22290@garp.metalab.unc.edu> <87od8yqij5.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20080329175011.GO22290@garp.metalab.unc.edu> On Sat, Mar 29, 2008 at 01:08:14PM +0900, Stephen J. Turnbull wrote: > > I don't see anything in this story that couldn't be done just as well > with central control via SA at the MTA. 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. Personally, I think it's the MTA's job to reject malformed (eg. bad HELO) mail, it's SA's job to *tag* mail, and whatever the MTA hands off to should make the decision about whether to drop, quarantine, or deliver. That's a philosophical stance, and if it's impractical and I shouldn't think that way, then so be it. I'd like to hear some arguments before I change that view, though. My current solution has the advantage that for any complaining list admin, I can point that administrator to her/his own admin panel and say, "Play with these settings." >From a sysadmin perspective, I currently have three SA installs that have nearly-identical configs and one repeatedly-tweaked and well-documented mailman install. I'd rather not make one of my SA instances an oddball and drop that on my successor. In an ideal world there'd be only one SA instance, but we're not there yet. If you'd like to donate hardware to ibiblio so we can do that, let me know.... So basically what I'm saying is that my selfish POV makes me want a mailman that has nice anti-spam policies out of the box. If it requires an admin making decisions about which addresses to protect or whether to do it from within SA, mailman, or something else, then there's a problem. I'm still scratching my head on how this bounced its way into my inbox, for example: http://garp.metalab.unc.edu/backscatter-example.txt How/where do I stop that? Cheers, -- Crist?bal Palmer ibiblio.org systems administrator From cmpalmer at metalab.unc.edu Sat Mar 29 19:37:36 2008 From: cmpalmer at metalab.unc.edu (=?iso-8859-1?Q?Crist=F3bal?= Palmer) Date: Sat, 29 Mar 2008 14:37:36 -0400 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: <9E722503-2294-4CBB-8154-BF1B47CD1ECE@yakshavers.com> References: <47EBBCA5.1000305@gmx.de> <47EBCB61.30702@netconsonance.com> <53240295-0A86-4940-91C5-29FD85FBFE52@zone12.com> <47EBE969.4000108@mschuette.name> <20080328161401.GF22290@garp.metalab.unc.edu> <87od8yqij5.fsf@uwakimon.sk.tsukuba.ac.jp> <20080329175011.GO22290@garp.metalab.unc.edu> <9E722503-2294-4CBB-8154-BF1B47CD1ECE@yakshavers.com> Message-ID: <20080329183736.GU22290@garp.metalab.unc.edu> On Sat, Mar 29, 2008 at 01:12:59PM -0500, Robby Griffin wrote: >> How/where do I stop that? > > How is that backscatter? Looks like plain old spam to me (addressed > to a -owner address, which forwarded to postmaster But it shouldn't go to postmaster! /usr/local/mailman/bin/list_owners cc-co shows me three addresses, all of which are @gmail.com addresses. > , which forwarded to you), postmaster does forward to me, yes. > and your (three!) SpamAssassins two. One on malecky (the list machine), and one on garp. The third machine doesn't come into play here. > let it through. Though one > of them did score it high enough to be marked as spam, you don't > seem to have anything between the world and your inbox that actually > blocks spam... Not true. Mail to lists (but apparently not owners) now gets discarded if it has been tagged as spam. Furthermore, I have procmail rules in place in two places that drop mail above a certain threshold and quarantine a middle batch. > If it helps, I have one setup where I have to discard high-scoring > spam with procmail on its way into my inbox, and another where I > modified SA to add a user-configurable threshold for tagging > "extreme" spam so I could discard it within the MTA. I don't discard anything at the MTA, but otherwise you've got close to what I've got. What I'm missing here is the step where the mail went from going to one of the three list admins (again, all at gmail) to going to me. Where was the forgery? How did mailman (or was it postfix?) get duped? Cheers, -- Crist?bal Palmer ibiblio.org systems administrator From cmpalmer at metalab.unc.edu Sat Mar 29 19:49:25 2008 From: cmpalmer at metalab.unc.edu (=?iso-8859-1?Q?Crist=F3bal?= Palmer) Date: Sat, 29 Mar 2008 14:49:25 -0400 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: <20080329183736.GU22290@garp.metalab.unc.edu> References: <47EBBCA5.1000305@gmx.de> <47EBCB61.30702@netconsonance.com> <53240295-0A86-4940-91C5-29FD85FBFE52@zone12.com> <47EBE969.4000108@mschuette.name> <20080328161401.GF22290@garp.metalab.unc.edu> <87od8yqij5.fsf@uwakimon.sk.tsukuba.ac.jp> <20080329175011.GO22290@garp.metalab.unc.edu> <9E722503-2294-4CBB-8154-BF1B47CD1ECE@yakshavers.com> <20080329183736.GU22290@garp.metalab.unc.edu> Message-ID: <20080329184925.GV22290@garp.metalab.unc.edu> On Sat, Mar 29, 2008 at 02:37:36PM -0400, Crist?bal Palmer wrote: > Where was the forgery? How did mailman (or was it > postfix?) get duped? Given an off-list response I got, I should clarify further. An important detail that I left out was that I never got mail like what I linked to before I put SA on the mailing list server. Once I added that, I started seeing mails like this at a rate of two or three per day. Cheers, -- Crist?bal Palmer ibiblio.org systems administrator From mark at msapiro.net Sat Mar 29 19:53:22 2008 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 29 Mar 2008 11:53:22 -0700 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: <20080329175011.GO22290@garp.metalab.unc.edu> Message-ID: Crist?bal Palmer wrote: > >I'm still scratching my head on how this bounced its way into my >inbox, for example: > > http://garp.metalab.unc.edu/backscatter-example.txt > >How/where do I stop that? It doesn't look to me like backscatter at all. It looks like spam sent to cc-co-owner at lists.ibiblio.org which went to MailScanner on "malecky" which replaced the original message with a message consisting of the "notice" with the original attached. That message then continued through delivery chain to cc-co-owner at lists.ibiblio.org which was redirected to postmaster at lists.ibiblio.org and then to admin at ibiblio.org by lists.ibiblio.org. It was then relayed to metalab.unc.edu (a bit of a puzzle as the MX for ibiblio.org is mail.metalab.unc.edu, but perhaps these are really the same machine) which redirected admin at ibiblio.org to cmpalmer at ibiblio.org which ultimately got delivered to cmpalmer at garp.metalab.unc.edu. It also appears that the cmpalmer at ibiblio.org to cmpalmer at garp.metalab.unc.edu step involved a resend which rewrote the envelope sender to cmpalmer at metalab.unc.edu. I don't know what there is to stop here. I may be completely wrong, but it looks like this was just mail sent to cc-co-owner at lists.ibiblio.org delivered through the chain that would apply to all such mail. OK, I've just seen your reply to Robby Griffin's off-list message so the question is "why did cc-co-owner at lists.ibiblio.org" go to postmaster at lists.ibiblio.org. You say "What I'm missing here is the step where the mail went from going to one of the three list admins (again, all at gmail) to going to me. Where was the forgery? How did mailman (or was it postfix?) get duped?" There is no evidence in the Received: chain that this copy was sent to any of the three list admins. What does /usr/local/mailman/bin/list_owners -m cc-co show you? Assuming that doesn't list postmaster, what is in the MTA logs on lists.ibiblio.org regarding this message, and what's in Mailman's smtp log regarding this message? There's actually no indication that this ever went to Mailman. How is list mail delivered to Mailman on this machine? Is it possible that cc-co-owner at lists.ibiblio.org is mis-interpreted as trying to deliver to the 'co-owner' address of the cc list and this mis-delivery goes to postmaster? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From mark at msapiro.net Sat Mar 29 19:59:39 2008 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 29 Mar 2008 11:59:39 -0700 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: <20080329184925.GV22290@garp.metalab.unc.edu> Message-ID: Crist?bal Palmer wrote: > >An important detail that I left out was that I never got mail like >what I linked to before I put SA on the mailing list server. Once I >added that, I started seeing mails like this at a rate of two or three >per day. It appears it's not just SpamAssassin, but MailScanner. Is it possible that somehow this managed to mess up the cc-co-owner address? Are there any regexps that might split cc-co-owner into cc and co-owner instead of cc-co and owner? You still need to look at the maillog on lists.ibiblio.org. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From dgc at uchicago.edu Sat Mar 29 20:49:35 2008 From: dgc at uchicago.edu (David Champion) Date: Sat, 29 Mar 2008 14:49:35 -0500 Subject: [Mailman-Developers] mm-handler 2.1.10 (was:beforenextrelease:disable backscatter in default installation) In-Reply-To: References: <729790FACB4D85F25DCAF2A5@[10.0.0.14]> Message-ID: <20080329194935.GV10751@monkey.uchicago.edu> > As I understand it (possibly wrong), the way this > > if ($DEBUG) { > $to = join(',', @to); > print STDERR "to: $to\n"; > print STDERR "sender: $sender\n"; > print STDERR "server: $server\n"; > exit(-1); > } > > works is it exits with an error, so sendmail returns an undeliverable > status/notice containing the script output. > > Obviously, your logging is much nicer. Correct. But as previously noted, syslog might not log anything at all on some systems -- that's why mm-handler didn't use it originally. And this is debugging code, not meant for live environments.... > I have another question since I don't know sendmail. Does sendmail > execute mm-handler at incoming SMTP time, and if so, does an error > exit from mm-handler result in an SMTP failure status being returned > to the sending MTA? Yes. It's a local delivery agent mapped to your mailing lists' virtual domain, and it's the final step in an SMTP transaction. In a production environment it should exit with one of the statuses from . That will trigger an SMTP failure to the sending MTA with a message appropriate to that exit status. > If so, it seems that rather than just dropping a 'bad' message as > mm-handler seems to do when $BounceUnapproved = 0; and $BounceNonlist > = 0;, wouldn't it be better to exit with a failure status. FWIW, I agree. -- -D. dgc at uchicago.edu NSIT University of Chicago From shiva at sewingwitch.com Sat Mar 29 21:18:37 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sat, 29 Mar 2008 13:18:37 -0700 Subject: [Mailman-Developers] mm-handler 2.1.10 (was:beforenextrelease:disable backscatter in default installation) In-Reply-To: References: Message-ID: --On Saturday, March 29, 2008 9:37 AM -0700 Mark Sapiro wrote: > I just checked, and my CentOS 5 system only has Sys::Syslog and not > Unix::Syslog. It might be worthwhile to provide your version plus a > patch to go back to the old DEBUG w/o logging. OTOH, Unix::Syslog is > available from CPAN, DAG, etc., so I don't think it's unreasonable to > expect people to be able to get it. I've got perl-Unix-Syslog-1.0-1.el5.rf installed from RPMForge. There's a page in the CentOS wiki that explains how to enable this yum/RPM repository. > I have another question since I don't know sendmail. Does sendmail > execute mm-handler at incoming SMTP time, and if so, does an error > exit from mm-handler result in an SMTP failure status being returned > to the sending MTA? Correct. mm-handler is a "mailer" which is invoked upon receipt by sendmail, which typically happens via SMTP. (Sendmail can also accept mail via local socket, or by direct invocation.) It's expected to return a value from /usr/include/sysexits.h. Most Red Hat, Fedora and CentOS users know the procmail mailer, as it's used for local delivery. Based on properties of a message, another mailer may be chosen, either from the config file or from the mailertable map file. The mm-handler README explains how to set up a match on the domain name. > If so, it seems that rather than just dropping a 'bad' message as > mm-handler seems to do when $BounceUnapproved = 0; and $BounceNonlist > = 0;, wouldn't it be better to exit with a failure status. Good idea. EX_NOUSER (67) would be a good code to return. Does Perl have a module that defines these codes symbolically? I didn't see anything at CPAN, but I found one here: From shiva at sewingwitch.com Sat Mar 29 21:27:06 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sat, 29 Mar 2008 13:27:06 -0700 Subject: [Mailman-Developers] mm-handler 2.1.10 (was:beforenextrelease:disable backscatter in default installation) In-Reply-To: References: Message-ID: New bug: The script is wrongly case-sensitive on the list name. A user just tried to send to "Tribes2-pickups" instead of "tribe2-pickups" and it dropped with a log message of "no such list". From mark at msapiro.net Sat Mar 29 21:30:32 2008 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 29 Mar 2008 13:30:32 -0700 Subject: [Mailman-Developers] mm-handler 2.1.10(was:beforenextrelease:disable backscatter in default installation) In-Reply-To: <20080329194935.GV10751@monkey.uchicago.edu> Message-ID: David Champion wrote: > >Correct. But as previously noted, syslog might not log anything at all >on some systems -- that's why mm-handler didn't use it originally. And >this is debugging code, not meant for live environments.... True, but Kenneth added additional logging beyond the debuging code. Also, There are two perl modules, Sys::Syslog and Unix::Syslog. I'm not very familiar with perl and it's various modules, so I may be wrong, but I think that Sys::Syslog is the more common, but Kenneth is using Unix::Syslog. According to the FAQ at , Unix::Syslog requires syslogd to be running on the local host, but given that, it doesn't communicate with syslogd through a network connection so it is not subject to the problems with that. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From mark at msapiro.net Sat Mar 29 21:34:51 2008 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 29 Mar 2008 13:34:51 -0700 Subject: [Mailman-Developers] mm-handler 2.1.10(was:beforenextrelease:disable backscatter in default installation) In-Reply-To: Message-ID: Kenneth Porter wrote: >--On Saturday, March 29, 2008 9:37 AM -0700 Mark Sapiro >wrote: > >> If so, it seems that rather than just dropping a 'bad' message as >> mm-handler seems to do when $BounceUnapproved = 0; and $BounceNonlist >> = 0;, wouldn't it be better to exit with a failure status. > >Good idea. EX_NOUSER (67) would be a good code to return. Does Perl have a >module that defines these codes symbolically? I didn't see anything at >CPAN, but I found one here: > > The two exit codes that seem to make sense are EX_NOUSER (67) and EX_UNAVAILABLE (69). Perhaps EX_NOUSER for a non-existent list and EX_UNAVAILABLE for a non accepted suffix. I don't think perl defines these symbolically anywhere. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From mark at msapiro.net Sat Mar 29 22:23:29 2008 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 29 Mar 2008 14:23:29 -0700 Subject: [Mailman-Developers] mm-handler2.1.10(was:beforenextrelease:disable backscatter in defaultinstallation) In-Reply-To: Message-ID: Mark Sapiro wrote: >Kenneth Porter wrote: > >>--On Saturday, March 29, 2008 9:37 AM -0700 Mark Sapiro >>wrote: >> >>> If so, it seems that rather than just dropping a 'bad' message as >>> mm-handler seems to do when $BounceUnapproved = 0; and $BounceNonlist >>> = 0;, wouldn't it be better to exit with a failure status. >> >>Good idea. EX_NOUSER (67) would be a good code to return. Does Perl have a >>module that defines these codes symbolically? I didn't see anything at >>CPAN, but I found one here: >> >> > > >The two exit codes that seem to make sense are EX_NOUSER (67) and >EX_UNAVAILABLE (69). Perhaps EX_NOUSER for a non-existent list and >EX_UNAVAILABLE for a non accepted suffix. > >I don't think perl defines these symbolically anywhere. There is a potential problem with this, and I don't know enough about the actual sendmail -> mm-handler interface to know if it is a problem or not. mm-handler parses its arguments from sendmail and builds a list of recipients and then processes that list in a loop. If it is really the case that a message addressed to, e.g., more than one list will be passed from sendmail to mm-handler as one invocation with multiple recipients, then the problem is you can only return one exit status, and the desposition might not be the same for all recipients. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From dgc at uchicago.edu Sat Mar 29 22:47:41 2008 From: dgc at uchicago.edu (David Champion) Date: Sat, 29 Mar 2008 16:47:41 -0500 Subject: [Mailman-Developers] mm-handler2.1.10(was:beforenextrelease:disable backscatter in defaultinstallation) In-Reply-To: References: Message-ID: <20080329214741.GW10751@monkey.uchicago.edu> > mm-handler parses its arguments from sendmail and builds a list of > recipients and then processes that list in a loop. If it is really the > case that a message addressed to, e.g., more than one list will be > passed from sendmail to mm-handler as one invocation with multiple > recipients, then the problem is you can only return one exit status, > and the desposition might not be the same for all recipients. The mailman.mc file (cited in README.mm-handler) mentions this vaguely. If the "m" flag is not present in the mailer definition (the "M" line) in sendmail.cf, then mm-handler will be run once per recipient. It's important NOT to have an "m" flag, but just in case you forget that, mm-handler tries to handle multiple recipients a little. -- -D. dgc at uchicago.edu NSIT University of Chicago From shiva at sewingwitch.com Sun Mar 30 01:19:31 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sat, 29 Mar 2008 17:19:31 -0700 Subject: [Mailman-Developers] mm-handler2.1.10(was:beforenextrelease:disable backscatter in defaultinstallation) In-Reply-To: References: Message-ID: <617303E3398A148AB5E6970F@[10.0.0.14]> --On Saturday, March 29, 2008 2:23 PM -0700 Mark Sapiro wrote: > mm-handler parses its arguments from sendmail and builds a list of > recipients and then processes that list in a loop. If it is really the > case that a message addressed to, e.g., more than one list will be > passed from sendmail to mm-handler as one invocation with multiple > recipients, then the problem is you can only return one exit status, > and the desposition might not be the same for all recipients. I saw that. Perhaps a question to comp.mail.sendmail is in order. (I have an appointment to get to as I type this. Can you post it?) From mark at msapiro.net Sun Mar 30 01:43:21 2008 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 29 Mar 2008 17:43:21 -0700 Subject: [Mailman-Developers] mm-handler2.1.10(was:beforenextrelease:disable backscatter indefaultinstallation) In-Reply-To: <617303E3398A148AB5E6970F@[10.0.0.14]> Message-ID: Kenneth Porter wrote: >--On Saturday, March 29, 2008 2:23 PM -0700 Mark Sapiro >wrote: > >> mm-handler parses its arguments from sendmail and builds a list of >> recipients and then processes that list in a loop. If it is really the >> case that a message addressed to, e.g., more than one list will be >> passed from sendmail to mm-handler as one invocation with multiple >> recipients, then the problem is you can only return one exit status, >> and the desposition might not be the same for all recipients. > >I saw that. Perhaps a question to comp.mail.sendmail is in order. (I have >an appointment to get to as I type this. Can you post it?) I think David Champion's reply at answers it adequately. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From stephen at xemacs.org Sun Mar 30 05:17:04 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sun, 30 Mar 2008 12:17:04 +0900 Subject: [Mailman-Developers] Google Summer of Code - Spam Defense In-Reply-To: <20080329175011.GO22290@garp.metalab.unc.edu> References: <47EBBCA5.1000305@gmx.de> <47EBCB61.30702@netconsonance.com> <53240295-0A86-4940-91C5-29FD85FBFE52@zone12.com> <47EBE969.4000108@mschuette.name> <20080328161401.GF22290@garp.metalab.unc.edu> <87od8yqij5.fsf@uwakimon.sk.tsukuba.ac.jp> <20080329175011.GO22290@garp.metalab.unc.edu> Message-ID: <87bq4wrjdb.fsf@uwakimon.sk.tsukuba.ac.jp> 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." > Personally, I think it's the MTA's job to reject malformed (eg. bad > HELO) mail, it's SA's job to *tag* mail, and whatever the MTA hands > off to should make the decision about whether to drop, quarantine, or > deliver. That's a philosophical stance, and if it's impractical and I > shouldn't think that way, then so be it. That is the stance I take personally. It's also the one described here: http://mayfirst.org/?q=node/180 (this URL is from Ian Eiloart, but I don't know if he endorses the stance himself). I know no other list-admins (not Mailman site admins or postmasters, list-admins) who take that stance. They simply want as little in their moderation queues as possible, and many ignore those until somebody complains. Don't you get the "I have 1000 spams in my queue and need to find one held message that's a real post, but lists.ibiblio.org times out and the page never gets done" FAQ from some of your admins? I haven't heard it from other list admins at my site, but I know two have 500 and 1200 pending in the mod queue! They certainly won't care if my site goes to a "shoot first, moderate later" policy. There is a technical problem with our stance, which is that there is a difference between an SMTP reject (permanent failure status) and a bounce message. The SMTP reject *will* be heard by the spammer, and it is in his interest to prune such addresses from the list, at least the one he uses personally. (Not all are smart enough to recognize that, of course.) Bounce messages, if sent, will almost certainly go to a forged address as backscatter :-(, and will not be heard by the spammer. In fact, since the spam was accepted, he is likely to consider the address to have been validated, whether you try to send a bounce or not. 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 milter. > I'd like to hear some arguments before I change that view, > though. My current solution has the advantage that for any > complaining list admin, I can point that administrator to her/his > own admin panel and say, "Play with these settings." Unfortunately, tuning list settings that have to do with filtering is not and never really was something that you want people who have never even set up an MTA to do. Understanding what happens is quite complex. > >From a sysadmin perspective, I currently have three SA installs that > have nearly-identical configs and one repeatedly-tweaked and > well-documented mailman install. I'd rather not make one of my SA > instances an oddball and drop that on my successor. I don't see why that would be needed. If you have list-specific tweaks, then either all the SAs are feeding Mailman, or the ones that aren't won't care. I do this all the time. From shiva at sewingwitch.com Sun Mar 30 07:17:12 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sat, 29 Mar 2008 22:17:12 -0700 Subject: [Mailman-Developers] mm-handler 2.1.10(was:beforenextrelease:disable backscatter in default installation) In-Reply-To: References: Message-ID: <01624C817C8C4D6A18490A08@[10.0.0.14]> --On Saturday, March 29, 2008 1:30 PM -0700 Mark Sapiro wrote: > True, but Kenneth added additional logging beyond the debuging code. The additional stuff was just printf-debugging to figure out what was going wrong earlier. It can be excised or wrapped in if($Debug). > Also, There are two perl modules, Sys::Syslog and Unix::Syslog. I'm not > very familiar with perl and it's various modules, so I may be wrong, > but I think that Sys::Syslog is the more common, but Kenneth is using > Unix::Syslog. According to the FAQ at > , > Unix::Syslog requires syslogd to be running on the local host, but > given that, it doesn't communicate with syslogd through a network > connection so it is not subject to the problems with that. I have no preference, as long as I can get an RPM/SRPM for it. CPAN qualifies, as there's a utility to encapsulate a CPAN module in an RPM. My concern is that I be able to see the output even if no mail is sent, so syslog is a natural solution. From shiva at sewingwitch.com Sun Mar 30 07:19:12 2008 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sat, 29 Mar 2008 22:19:12 -0700 Subject: [Mailman-Developers] mm-handler 2.1.10 In-Reply-To: <20080329214741.GW10751@monkey.uchicago.edu> References: <20080329214741.GW10751@monkey.uchicago.edu> Message-ID: <1E03ECBC8D52A646BAD515D3@[10.0.0.14]> --On Saturday, March 29, 2008 4:47 PM -0500 David Champion wrote: > It's important NOT to have an "m" flag, but just in case you forget > that, mm-handler tries to handle multiple recipients a little. How about checking for multiple recipients, logging a line explaining to remove the "m", and erroring out? From mark at msapiro.net Sun Mar 30 22:17:08 2008 From: mark at msapiro.net (Mark Sapiro) Date: Sun, 30 Mar 2008 13:17:08 -0700 Subject: [Mailman-Developers] mm-handler 2.1.10 In-Reply-To: <1E03ECBC8D52A646BAD515D3@[10.0.0.14]> Message-ID: Kenneth Porter wrote: >--On Saturday, March 29, 2008 4:47 PM -0500 David Champion > wrote: > >> It's important NOT to have an "m" flag, but just in case you forget >> that, mm-handler tries to handle multiple recipients a little. > >How about checking for multiple recipients, logging a line explaining to >remove the "m", and erroring out? That seems to me to be the right approach. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From iane at sussex.ac.uk Mon Mar 31 12:15:07 2008 From: iane at sussex.ac.uk (Ian Eiloart) Date: Mon, 31 Mar 2008 10:15:07 +0000 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <87r6duqtl1.fsf@uwakimon.sk.tsukuba.ac.jp> References: <47E930FD.2000800@utu.fi> <87bq52eevv.fsf@uwakimon.sk.tsukuba.ac.jp> <6409CCAB96BF893D5A596FCA@lewes.staff.uscs.susx.ac.uk> <87tzitdoop.fsf@uwakimon.sk.tsukuba.ac.jp> <20A8FB7AF06FCD481A760372@lewes.staff.uscs.susx.ac.uk> <87abkjtj5q.fsf@uwakimon.sk.tsukuba.ac.jp> <6448A7726836C8302EE824C3@lewes.staff.uscs.susx.ac.uk> <87r6duqtl1.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: --On 29 March 2008 09:09:30 +0900 "Stephen J. Turnbull" wrote: > > > There's friction in their [SPF and DKIM] adoption because certain features of > > email (notably mail forwarding, but also some others) have no > > regard for these features. > > By which you mean that SPF and DKIM in some configurations are as big > a threat to Mailman as blacklisting for backscatter is, right? Maybe, but it's a question of configuration, not principle. SPF is no particular problem, because emails passing through Mailman get new return paths. If your Mailman domain has good SPF records, then the only problem that could occur is with recipients having forwarding set up. Actually, Mailman should be a winner here, because the list member can change their entry in the list much more easily than they can do so in their friends' address books. As far as DKIM is concerned, I think Mailman already can re-sign messages. I don't remember the details, though. Anyway, I think re-signing is the correct thing for a list to do. Again, Mailman is a winner here because it's capable of doing such things. As far as configuration is concerned, of course if you misconfigure either of these things, you're screwed. But, the reasons that SPF and DKIM aren't universal yet are not specific to Mailman. -- Ian Eiloart IT Services, University of Sussex x3148 From iane at sussex.ac.uk Mon Mar 31 12:18:59 2008 From: iane at sussex.ac.uk (Ian Eiloart) Date: Mon, 31 Mar 2008 10:18:59 +0000 Subject: [Mailman-Developers] before next release: disable backscatter indefault installation In-Reply-To: <87myoiqhfw.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20080305011346.GD5749@garp.metalab.unc.edu> <87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp> <46AFF679D4EFB29F57698A4B@lewes.staff.uscs.susx.ac.uk> <1369.64.13.143.30.1206558898.squirrel@mail.netconsonance.com> <20080327001842.GN22377@garp.metalab.unc.edu> <47EBC9D8.3000403@netconsonance.com> <878x03tfs6.fsf@uwakimon.sk.tsukuba.ac.jp> <5FB84C0DFC17D736C4D7E6B1@lewes.staff.uscs.susx.ac.uk> <87myoiqhfw.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <676DC2F6D4834E4CBE1D1BC3@lewes.staff.uscs.susx.ac.uk> --On 29 March 2008 13:31:47 +0900 "Stephen J. Turnbull" wrote: > Thank you, Ian! > Oh, one more link: >From JANET again: Spam Bounces Considered Harmful Their advice is plain: "Reject, Don't Bounce The standards provide for a mail server to 'reject' a message by refusing its transfer, rather than accepting it and risking future problems." -- Ian Eiloart IT Services, University of Sussex x3148 From iane at sussex.ac.uk Mon Mar 31 12:36:52 2008 From: iane at sussex.ac.uk (Ian Eiloart) Date: Mon, 31 Mar 2008 10:36:52 +0000 Subject: [Mailman-Developers] before next release: disable backscatterin default installation In-Reply-To: <200803281247.51493.julian@mehnle.net> References: <87abkjtj5q.fsf@uwakimon.sk.tsukuba.ac.jp> <6448A7726836C8302EE824C3@lewes.staff.uscs.susx.ac.uk> <200803281247.51493.julian@mehnle.net> Message-ID: --On 28 March 2008 12:47:48 +0000 Julian Mehnle wrote: >> Until no email service provider accepts message submissions outside of >> their own domains, all email providers offer message submission on port >> 587, all message submissions are autheticated, and mail forwarders >> accept responsibility for the email that they forward, it's not safe to >> bounce email. > > This, however, is simply untrue. Of course what you said is desirable, > but SPF can help with safely bouncing e-mail _today_. Only for the minority of domains that publish SPF records. My intention was to convey that SPF will be the solution once adopted. > SPF may sometimes > give an unexpected "Fail" result due to alias-style forwarding or other > problematic cases, but when it gives a "Pass" result, it is always safe, > i.e., the return path can be assumed to be authentic and bounces may be > sent. -- Ian Eiloart IT Services, University of Sussex x3148 From mark at msapiro.net Mon Mar 31 18:26:08 2008 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 31 Mar 2008 09:26:08 -0700 Subject: [Mailman-Developers] before next release: disable backscatter in default installation In-Reply-To: <676DC2F6D4834E4CBE1D1BC3@lewes.staff.uscs.susx.ac.uk> Message-ID: Ian Eiloart wrote: > >Their advice is plain: "Reject, Don't Bounce >The standards provide for a mail server to 'reject' a message by refusing >its transfer, rather than accepting it and risking future problems." Although this thread long ago went somewhat off topic for Mailman, I think it's valuable, and there's been a lot of good information here, but I still have a question that I would like information on. I 'get it' that non-acceptance at SMTP time is good and accepting and bouncing is bad. This was not news to me, I've known it for some time, but here's my situation. I run a server that supports a few domains. By far, the bulk of the mail is Mailman and other mail associated with my cycling club. There are several generic forwarding addresses such as 'president', 'vicepresident', 'board', 'membership', etc. in the club's domain. These are aliased to the appropriate current recipients. Of course, all these recipient addresses are valid and deliverable. Any mail I receive for an unknown recipient is rejected at SMTP time, the rest is greylisted and a lot of that never returns. That which passes greylisting is run through MailScanner/ClamAV/SpamAssassin, and sometimes discarded or quarrantined, but nothing is ever returned to the sender. So far, so good. Here's the problem. I receive a message for board at example.net which is aliased to a few other addresses including user at example.com. The MTA (Postfix in my case) accepts the message to board and resends it to the aliased recipients. example.com has a very agressive content filter which rejects messages after receiving the DATA. so Postfix's delivery to user at example.com is sometimes not accepted by example.com so Postfix returns a DSN. Sometimes the sender was legitimate, sometimes (probably more often) not. So what do I do practically in this case. Calling out to verify the recipient won't help because the recipient is valid. I can arrange for the DSN to pass through MailScanner on the way out and possibly create rules to conditionally drop it, but what should the rules be, and is it really a problem at all? Note for example, that yesterday I did not accept 29985 messages for unknown users and greylisted 5684 more and sent no DSNs. This is somewhat typical except I probably average 2 or 3 DSNs per day. Should I be worried? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan