Mailman-Developers March 2014

mailman-developers@python.org

27 participants
69 discussions

Re: [Mailman-Developers] Moderation rules priority

by Ian Eiloart

On 18 Mar 2014, at 19:12, Barry Warsaw <barry(a)list.org> wrote: > I see this was a private reply. Feel free to forward this on to the list if > you want. Thanks, Barry. I’ll have a go at that if I get time. For me, the big win for spam prevention with mailing lists is the restriction on posters: it’s what keeps mailing lists relatively spam free. Most sites don’t like to bounce messages that they’ve previously accepted, so that means that the spam gets held for moderation, which creates a lot of work for list owners. If list bound mail can be rejected by the MTA at SMTP time, that would save a lot of work for list owners. > On Mar 18, 2014, at 02:58 PM, Ian Eiloart wrote: > >> That page suggests that Mailman 3 won’t be able to reject, at LMTP time, a >> message based on the sender/recipient information. That means that the MTA >> has to accept a message for delivery, even if Mailman is then going to reject >> it because the sender isn’t permitted to post to the list, or even just >> because the list doesn’t exist. Is that the case? > > At the moment, yes, but if you're interested in working on this, here's a > rough sketch that might work: > > Amend LMTPRunner.process_message() to run the member-moderation and > nonmember-moderation rules. Probably rather than hard coding this, create a > short chain just for LMTP-acceptance processing. This would allow folks to > customize what criteria the LMTP server uses to decide whether to accept the > message or not. > > .process_message() knows the name of the mailing list the message is destined > for (via recipient inspection). It currently doesn't query the db for a > mailing list object because it doesn't need it, but that would be easy to add. > You've already got the message object, so just craft an empty metadata > dictionary for the chain processing. > > Probably make the link action for both rules LinkAction.stop so that the first > one to hit wins. Then check the moderation_action to decide what the > disposition should be. E.g. if Action.reject or Action.discard, you can issue > the appropriate LMTP response code. If it's Action.hold, Action.accept, or > Action.defer, accept the message at LMTP time and enqueue the message for full > processing. > > Cheers, > -Barry -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148

7 years

Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project

by Rajeev S

Hi, Made a minor edit upon Meflin's comment, asking to change project title. http://myfossblog.blogspot.in/2014/03/yet-another-change.html *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk <http://rajeevs.tk>* On Fri, Mar 14, 2014 at 3:50 PM, Rajeev S <rajeevs1992(a)gmail.com> wrote: > Hi, > > I have submitted a proposal for the Mailman CLI project through > melange.You can find it here > > > https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014… > > (Organisation view only) > > I have gone through the suggestions by Stephen as comments to the proposal > and revised the proposal accordingly. > > http://myfossblog.blogspot.in/2014/03/gsoc-proposal-to-gnu-mailman.html > > > > *Regards,Rajeev S* > *Government Engineering College,Thrissur* > *http://rajeevs.tk <http://rajeevs.tk>* >

7 years

Re: [Mailman-Developers] Git mirror for mailman

by Patrick Ben Koetter

* Abhilash Raj <raj.abhilash1(a)gmail.com>: > Hi Patrick, > > I see you haven't updated the git mirror that you put up for mailman. I > also did send you my public key off the list. > Thanks a lot for your help. Terri sent a mail that discourages use of a GIT repo during GSoC. Barry wants a proxy. What I provided is a GIT repo that is not a read-only proxy. It does not fit either of the requirements. I'll see to provide a read-only proxy as soon as my time permits. Thanks a lot for your help. p@rick > > On Sun, Mar 9, 2014 at 1:30 AM, Patrick Ben Koetter <p(a)sys4.de> wrote: > > > * Abhilash Raj <raj.abhilash1(a)gmail.com>: > > > I was in a conversation with Barry yesterday to setup a unofficial git > > > mirror for mailman since there are large number of people who use git as > > > their primary vcs. I think it would encourage more people to contribute > > > to mailman, if not through merge requests on lp, through small patches > > > making of which is quite trivial in git I suppose. > > > > Seems we have an inofficial git repo now. Are there any opinions on who > > should > > be in control of the code, e.g. handle merge requests, etc.? AFAIK Barry > > has > > the last word on what gets to become Mailman 3 at the moment. I'd like to > > move > > on with the repo setup and clarify that. > > > > Thx > > > > p@rick > > > > -- > > [*] sys4 AG > > > > https://sys4.de, +49 (89) 30 90 46 64 > > Franziskanerstraße 15, 81669 München > > > > Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 > > Vorstand: Patrick Ben Koetter, Marc Schiffbauer > > Aufsichtsratsvorsitzender: Florian Kirstein > > > > _______________________________________________ > > Mailman-Developers mailing list > > Mailman-Developers(a)python.org > > https://mail.python.org/mailman/listinfo/mailman-developers > > Mailman FAQ: http://wiki.list.org/x/AgA3 > > Searchable Archives: > > http://www.mail-archive.com/mailman-developers%40python.org/ > > Unsubscribe: > > https://mail.python.org/mailman/options/mailman-developers/raj.abhilash1%40… > > > > Security Policy: http://wiki.list.org/x/QIA9 > > > > > > -- > Abhilash Raj > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers(a)python.org > https://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://wiki.list.org/x/AgA3 > Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/p%40sys4.de > > Security Policy: http://wiki.list.org/x/QIA9 -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein

7 years

Git mirror for mailman

by Abhilash Raj

Hi all, I was in a conversation with Barry yesterday to setup a unofficial git mirror for mailman since there are large number of people who use git as their primary vcs. I think it would encourage more people to contribute to mailman, if not through merge requests on lp, through small patches making of which is quite trivial in git I suppose. I am willing to maintain the mirror but I need I don't have a private server to host it. Anyone has ideas about how to setup? or already has a mirror running? Thanks, Abhilash

7 years

Re: [Mailman-Developers] MM3: message held reason

by Barry Warsaw

On Mar 17, 2014, at 07:59 PM, Aurelien Bompard wrote: >On Mailman3, every "message held" notification has "XXX" as the reason. This >comes from the HoldChain class in mailman/chains/hold.py, where "XXX" is >hardcoded. I'd like to fix that. I think there could be a list in the >message metadata to which each matching rule would add a short description of >why it matched, like we currently have a list of matching rules in the >msgdata['rule_hits'] variable. I'll make sure to mark these descriptions as >i18n strings. > >Are you OK with that? Any trap I'm not seeing? Yes, it would be pretty cool to implement this. The main reason I never did was because I couldn't quite work out a nice way to display multiple reasons given the rules for template interpolation. You'll notice the postheld.txt template has a single *indented* line containing $reason and that has implications for exactly what kind of string can go in there (e.g. if it's multiple lines, who's responsible for getting everything to line up correctly). Maybe that shouldn't be indented, but then the wrapping rules might interfere. If you can work out the display issues, keeping in mind an i18n'd postheld.txt template, and the fact that those templates can be replaced by a site or list admin, then I think your basic plan is on the right track. Cheers, -Barry

7 years

MM3: message held reason

by Aurelien Bompard

Hey! On Mailman3, every "message held" notification has "XXX" as the reason. This comes from the HoldChain class in mailman/chains/hold.py, where "XXX" is hardcoded. I'd like to fix that. I think there could be a list in the message metadata to which each matching rule would add a short description of why it matched, like we currently have a list of matching rules in the msgdata['rule_hits'] variable. I'll make sure to mark these descriptions as i18n strings. Are you OK with that? Any trap I'm not seeing? Aurélien

7 years, 1 month

Moderation rules priority

by Stephen J. Turnbull

Aurelien Bompard writes: > I'd like to discuss what happens when an email is sent by both a > member and a nonmember in Mailman3. How is that possible? Very easy, > here's my use case : I have my own domain, say example.com, and for > convenience and portability I choose to use Gmail as a > server/storage/interface. My main adress is alice(a)example.com and I > redirect it to alice(a)gmail.com, while I set a default identity in > gmail to alice(a)example.com which will set the proper From header. > However, for spam detection and spoofing reasons, gmail adds a Sender > header with alice(a)gmail.com. My outgoing emails thus have both a From > and a Sender header, and in this case email clients only display the > >From header (except Outlook, but eh...) Your outgoing emails also have an envelope sender, which might be different from both of the above. > Mailman now: when I subscribe to a list, I use my regular address, > alice(a)example.com. But the message.senders property will contain both > addresses because of the Sender header. The email goes through the > MemberModeration rule, which finds my subscribed address and, by > default, associates the "defer" action. > The email then goes through the NonMemberModeration rule, which finds > my Gmail address and sets the action to "hold" (it ignores my main > address because it's a member already). > > What do you think about all that? Do you agree there's actually an > issue there? Yes. > Any idea how to solve it? For example, make the NonMember rule exit > if a member is found amongst the senders (which would simply be > equivalent to making it yield to the Member rule). Bad idea? Offhand I'd say that having both a Member rule and a NonMember rule is a bad idea. There should be one conceptual test: can we identify a member as the originator of this post? Having Member and NonMember rules that can both "succeed" is not coherent. I think that what should happen here is that the Member rule should try to identify the originator, and the NonMemberModeration (if in effect) should just check for a "member_identified" property. The member_identified property could be a Boolean or actually contain a list of members (list because it's not obvious what to do if each of From, Sender, and envelope sender corresponds to a different member; that would probably be a policy issue). I don't really see how order dependence can be avoided without violating DRY all over the place. Alternatively, NonMemberModeration might not be a rule, but rather a chain. Perhaps that's the most elegant solution, as order dependence between chains is necessary.

7 years, 1 month

[GSoC 2014] Proposal for Cordova App for GNU Mailman Admin Interface

by Stephen J. Turnbull

Bhargav Golla writes: > Also, I have observed on the PSF GSoC page that it requires students to > submit a patch to the sub-organization. I like this one: https://bugs.launchpad.net/mailman/+bug/881320 Requires knowledge of gettext and the Python facilities for dealing with it (IIRC xgettext knows about Python now). I recommend searching Launchpad for the "mailman3" tag; Mailman 2 bugs are somewhat likely to be harder bugs, and definitely solving Mailman 2 bugs is not as useful for learning Mailman architecture and coding -- not to mention requiring you to check out and find your way around a rather different source tree. HTH, I gotta get back to work...

7 years, 1 month

[GSoC 2014] Proposal for Cordova App for GNU Mailman Admin Interface

by Bhargav Golla

Hello After feedback on the mailing list regarding various doubts and questions I had, I have developed a proposal for Cordova App idea and have attached the same with this mail. I would be very much obliged if someone could share their views about this. Also, I have observed on the PSF GSoC page that it requires students to submit a patch to the sub-organization. I was wondering if I could receive any pointers regarding any issues that were highlighted for GSoC aspirants to solve during application period. If there is such, please provide me the information about it or I would be very much grateful if I could get any information about which issues I can target before the application period ends. Thanks -- Bhargav Golla M.S Computer Science Github <http://www.github.com/bhargavgolla> | LinkedIN<http://www.linkedin.com/in/bhargavgolla> | Website <http://www.bhargavgolla.com/>

7 years, 1 month

Using git for mailman development during GSoC is NOT RECOMMENDED

by Terri Oda

I just added the following note to the wiki and I want to repeat it here: While it is possible to use a git mirror or other tools to use git for Mailman core and Postorius development, we DO NOT RECOMMEND USING GIT for GSoC. Merge requests need to happen on launchpad (that is the one way new code gets accepted into those projects), and previous GSoC students have found that the time required to make it all work is more than they anticipated. (We may one day switch to git, but it won't be happening this summer.) Sorry! I know our official stance for regular contributors is "use whatever as long as you can submit a launchpad merge request" but for GSoC students, you're on a short timeline that's going to be busier at the end than the beginning and experience says it's much safer to learn launchpad and use it from the get-go than risk time-consuming problems later in the process. Terri

7 years, 1 month

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers March 2014