Mailman 3 July 2013 - Mailman-Developers

Re: [Mailman-Developers] Adding DMARC support for Mailman 3
by Franck Martin 08 Jul '13

08 Jul '13

----- Original Message ----- > From: "Mark Sapiro" <mark(a)msapiro.net> > To: "Franck Martin" <franck(a)peachymango.org> > Sent: Monday, July 8, 2013 10:37:01 AM > Subject: Re: [Mailman-Developers] Adding DMARC support for Mailman 3 > > On 07/08/2013 08:34 AM, Franck Martin wrote: > > > > I suspect this process has been improved in MM3, but I have not had a look > > at the code. The purpose is for mailman to recognize 5.7.x bounces and not > > count them against the recipient (or as soft bounce). Hard bounce is the > > default for any non recognized bounce. > > > MM3 uses flufl.bounce <https://launchpad.net/flufl.bounce> for bounce > processing. The process, algorithms and heuristics are essentially > identical to MM2.1 > > In the case of an RFC 3464 compliant DSN, MM does not look at the Status > field at all. It only looks at the Action field. Actions beginning with > 'fail' result in a 'permanent failure' determination. Actions beginning > with 'delayed' result in a 'temporary failure' determination. All other > actions result in the bounce being ignored. > I see in MM2 that regex are used to classify the bounces: http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/files/head:/Mailman… which is described in broad terms here: http://www.esosoft.com/support/mailinglist/mailman/bounce.html It seems flufl has the same structure http://bazaar.launchpad.net/~mailman-coders/flufl.bounce/trunk/files/head:/… but I just read the code quickly...

2 1

Re: [Mailman-Developers] Adding DMARC support for Mailman 3
by Franck Martin 08 Jul '13

08 Jul '13

----- Original Message ----- > From: "Murray S. Kucherawy" <superuser(a)gmail.com> > To: "Franck Martin" <franck(a)peachymango.org> > Cc: "Stephen J. Turnbull" <stephen(a)xemacs.org>, "Mailman Developers" > <Mailman-Developers(a)python.org> > Sent: Monday, July 8, 2013 6:57:03 AM > Subject: Re: [Mailman-Developers] Adding DMARC support for Mailman 3 > On Mon, Jul 8, 2013 at 12:26 AM, Franck Martin < franck(a)peachymango.org > > wrote: > > 1) may not be necessary, if mailman recognizes the bounce message as in > > section > > http://tools.ietf.org/html/draft-kucherawy-dmarc-base-00#section-15.8 > > > eg "550 5.7.1 Email rejected per DMARC policy for example.com " > > > and does not increase the unsubscribe/bounce counter for the receiving > > email > > address. I suppose MM3 bounce processing is better than with MM2, so this > > may be already addressed. > > > Some people have requested this feature, so it is fair to include it, > > rather > > than them having to tweak the associated MTA (which some do not have > > control). > > I don't think the idea of telling people to include or go look for a > particular substring in the SMTP reply text will ultimately work in a > standards document, which relegates this logic to the realm of heuristics. > We've already seen resistance to that effect on the IETF lists. We'd be > better off trying to register some enhanced status codes and asking the > community to begin using those. Mailman 2 read already the substring, and it is common practices amongst ESP to do that to better classify bounces, at least between soft and hard bounces ( http://www.boogietools.com/Products/Windows/BounceStudioEnterprise/Email-Bo… ) I suspect this process has been improved in MM3, but I have not had a look at the code. The purpose is for mailman to recognize 5.7.x bounces and not count them against the recipient (or as soft bounce). Hard bounce is the default for any non recognized bounce. Finally, yes, DMARC should register X.7.17 on http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-st…

2 1

Re: [Mailman-Developers] Adding DMARC support for Mailman 3
by Stephen J. Turnbull 07 Jul '13

07 Jul '13

Murray S. Kucherawy <superuser(a)gmail.com> writes: Hey, I've been trying to find the superuser at Gmail, and it turns out I've known him all along! Would you please fix the breakage where copies of one's posts aren't delivered to yourself, which is a real PITA when trying to diagnose Gmail problems?<wink/> (BTW, did you try to sign up as root? or Administrator? ;-) > I'm all for experimentation and being adaptive as new things come along, > and I'm obviously supportive of the DMARC effort. That said, I hope that > these are going to be configurable options, defaulted "off" for backward > compatibility. I second your concerns in principle, but I don't think you need to worry about these features being anything but optional. I suspect that a majority of our user don't actually have the fine control over their DNS needed to implement DMARC. > (a) the second bullet above is a significant departure from current > use Violating the RFC by munging From (for heaven's sake! have we learned nothing from the sad history of Reply-To munging?) is simply not acceptable for most purposes, although perfectly acceptable for advertising. ;-) Steve

1 0

Message Handling Workflow
by Stephen J. Turnbull 06 Jul '13

06 Jul '13

VuNghia Truong writes: > Could any one please help me to answers these questions: > - Is the handling workflow b.t version 2 and 3 the same or different? It's different. V2 has a single pipeline that both checks the mail for conformance to list regulations and also cleans up the post (removing forbidden content types) and adds list-specific content (mail headers, leader and trailer parts). V3 has two separate pipelines, one for approving the post (using "chains" of "rules") and one for preparting for distribution (using a "pipeline" of "handlers"). Be carefule because the terminology resembles that used in V2 but the architecture is definitely different. > - How the file system are organized, how these pieces of codes fit > together? The /var hierarchy for Mailman 3 is quite similar to that of Mailman 2. I'm not sure what the installed code looks like; we currently recommend running in a virtualenv, basically everything in the source tree. The source hierarchy is quite different. There are altogether 4 separate source trees: - Mailman 3 core: the post distribution and databases - mailman.client: helper library for accessing database and configuration using the REST (HTTP) interface - Postorius: the web admin interface (including user subscription options), which depends on mailman.client - HyperKitty: the archive management and web access interface. Note that Postorius and HyperKitty are designed to function as independent modules, and are basically independent projects.

1 0

Message Handling Workflow
by VuNghia Truong 05 Jul '13

05 Jul '13

Hi everyone, Could any one please help me to answers these questions: - Is the handling workflow b.t version 2 and 3 the same or different? - How the file system are organized, how these pieces of codes fit together? Thanks! Nghia Truong

1 0

Re: [Mailman-Developers] Mailman search function (was?? Re: Like to participate in GSOC 2013 (GNU Mailman) - Like some ideas proposed in the list (Django, Python))
by Barry Warsaw 01 Jul '13

01 Jul '13

On Jun 29, 2013, at 10:33 PM, Chris Cargile wrote: >FWIW, I'd also like very much if anyone could provide a few lines recap of >the activity on the ModernArchiving topic under "initiatives and proposals" >as I feel my thoughts on searching/archiving tie into the >objectives/requirements listed there: >http://wiki.list.org/display/DEV/ModernArchiving > >More concisely, where I have search capability, my goal of integrating more >'robustly' is I think one that will rely upon a channel of communication >being established with the archiving mechanisms, if I understand the mm 2.0 >codebase well enough. Hi Chris, I really think searching is pretty closely tied to the archiver. While the Mailman core may keep a central message store, it won't be directly tied to archiving or searching. We've tried to keep the connection between Mailman and the archivers loose, certainly much looser than between MM2.1 and Pipermail. There are lots of reasons for that, including the ability to define multiple archivers for a single Mailman instance, and the ability to define remote archivers (e.g. mail-archive.com). This is the primary motivation for the stable URL proposal <http://wiki.list.org/x/yQAM>. As for our eventually hoped-for replacement to Pipermail, Hyperkitty, I think it would be wonderful for it to have a built-in search. -Barry

1 0