Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project
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 rajeevs1...@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/rajeevs1992/5629499534213120 (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* ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Moderation rules priority
On Mar 20, 2014, at 01:17 PM, Ian Eiloart wrote: 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. Agreed! I think it would be a great feature for MM3, and it's one of the many reasons why I think the LMTP delivery mechanism is better overall. -Barry signature.asc Description: PGP signature ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Moderation rules priority
On 18 Mar 2014, at 19:12, Barry Warsaw ba...@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 ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Moderation rules priority
On Thu, Mar 20, 2014 at 9:17 AM, Ian Eiloart i...@sussex.ac.uk wrote: 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. Sorry, haven't been following along... I discussed this several months back on the main list. https://mail.python.org/pipermail/mailman-users/2013-August/075523.html Basically I hacked a copy of find_member into scripts/check_subscriber: (http://paste.debian.net/hidden/c36ff81c/ ) check_subscriber is called by multiple postfix tcp_tables (one per list post addr in master.cf), such that incoming emails are checked against the membership list, and smtp rejected if not subscribed. Let me know if you want more details. -Jim P. ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Moderation rules priority
On Thu, Mar 20, 2014 at 1:10 PM, Jim Popovitch jim...@gmail.com wrote: On Thu, Mar 20, 2014 at 9:17 AM, Ian Eiloart i...@sussex.ac.uk wrote: 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. Sorry, haven't been following along... I discussed this several months back on the main list. https://mail.python.org/pipermail/mailman-users/2013-August/075523.html Basically I hacked a copy of find_member into scripts/check_subscriber: (http://paste.debian.net/hidden/c36ff81c/ ) check_subscriber is called by multiple postfix tcp_tables (one per list post addr in master.cf), such that incoming emails are checked against the membership list, and smtp rejected if not subscribed. Let me know if you want more details. fyi.. I've pushed this to launchpad (2.1), and included a README (yea!!) http://bazaar.launchpad.net/~jimpop/mailman/check_subscriber/revision/1451 -Jim P. ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
