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
Postmaster, University of Sussex
+44 (0) 1273 87-3148
* 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.
> 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 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
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
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
>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
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
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.
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
I'll make sure to mark these descriptions as i18n strings.
Are you OK with that? Any trap I'm not seeing?
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?
> 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.
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:
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...
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
M.S Computer Science
Github <http://www.github.com/bhargavgolla> |
| Website <http://www.bhargavgolla.com/>
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.