Mailman 3 March 2016 - Mailman-Developers

Re: [Mailman-Developers] Basic workflow of the ARC implementation
by Aditya Divekar March 15, 2016

March 15, 2016

Regarding my previous mail, I have implicitly assumed that the testing would involve the use of examples which do not have a pre-existing valid ARC chain in them i.e. the test examples would not be containing mails which have multiple ARC set of headers, and that the ARC chain would be first initiated by Mailman. Such examples cannot be used for testing before all the milestones are completed due to the arc verification test being implemented at the end. We can, however implement such examples in the testing process once the entire code is completed, since then the arc verification will be in place. Also, this can be added as a milestone after all the previously mentioned milestones are complete or can be merged with milestone 8. Thanks. Aditya.

1 0

Re: [Mailman-Developers] INTEREST IN IMPLEMENTING Message queue based email archiver
by Florian Fuchs March 15, 2016

March 15, 2016

On Sat, Mar 12, 2016 at 01:34:34AM -0600, Okusanya Damilola wrote: >Sir, > >My name is Okusanya Oluwadamilola. I am currently enrolled for my Masters >programme at Saint Cloud State University at St.Cloud Minnesota. I played >around with Apache ActiveMQ last semester and have some basic Python >skills. Could you shed some more light about the project? Thanks for your >prompt and favourable response. The idea behind this project is to use Mailman's (Python-based) IArchiver interface to add outgoing posts to a message queue (or pub/sub) system which can be consumed by any number of applications, no matter if they're written in Python or not -- asynchronously, even simultaneously. This would open up Mailman to all kinds of use cases, maybe some of them beyond that of a "traditional" mailing list. One part of the project would be to choose and integrate a small number of backends (ActiveMQ could be one of them, but I think both first-in-first out as well as pub/sub are interesting concepts) to distribute list posts. The other part is to come up with an interesting idea how this could be used and maybe create an implementation of that too (depending on the application's scope): Say, hooking it up to a static web page generator. Or creating a websockets server based on this. (These are just spontaneous ideas -- get creative!). In order to prepare for this it makes sense to study Mailman's IArchiver interface in the core (src/mailman/interfaces/archiver.py) and check out the existing implementations: mhonarc and mailarchive (both in src/mailman/archiving), but especially HyperKitty. Florian > >Sincerely, > >Okusanya OIuwadamilola. >_______________________________________________ >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/f%40florianfuchs… > >Security Policy: http://wiki.list.org/x/QIA9

1 0

Re: [Mailman-Developers] adding to REST
by Simon Hanna March 15, 2016

March 15, 2016

On 03/14/2016 07:25 PM, Dominic Dambrogia wrote: > Hi, My name is Dominic. > I contacted this mailing list last week about list moderation and post > approval. My problem was not being able to set a list password via the REST > api. I need this for nonmember approval of posting to a mailing list via > email in the "Approved: *list password*" style in the first line of the > email like the default request for moderation email suggests. > > I'd like to go ahead and tackle this problem personally. I would appreciate > some insight on where to start looking in the project itself. I've only > installed the bundler and used REST so far, so my knowledge of how the > python code works so far is minimal. > > Any insight is greatly appreciated, thanks. > - Dominic If you want to actually develop mailman, you shouldn't use bundler for that. Check out the following two pages that help you with some git knowledge and setting up your dev environment. http://wiki.list.org/DEV/HowToContributeGit http://wiki.list.org/DEV/SetupDevEnvironment You should create an issue on gitlab https://gitlab.com/mailman/mailman/issues if there isn't one already. This issue can be used to discuss specifics about the implementation. You could try the irc channel #mailman on freenode for help in case you need something. You can of course also post to this list. All the code regarding the rest interface lives in src/mailman/rest I hope this get's you started, Simon

3 4

Re: [Mailman-Developers] Basic workflow of the ARC implementation
by Stephen J. Turnbull March 14, 2016

March 14, 2016

Aditya Divekar writes: > Yes, in that case the arc verification would need to be postponed to after > the entire code for the header generation has been written. I'll need to > rethink the milestones a bit, since this testing part would have to be > added at the end, and things will change quite a bit. That's what I wanted to hear! We're making rapid progress! Let me know your thoughts on milestones. There's no huge hurry, since applications haven't even opened yet. > On a side note, would posting on the arc-discuss list for help in > the above problem of testing be acceptable? Yes, but not yet. I should probably review your first post or two before posting, as well. There are plenty of friendly, helpful people on the IETF lists[1], but the lists themselves are rather different in tone and style from most open-source projects. Footnotes: [1] Technically arc-discuss is hosted by dmarc.org, not the IETF, but it's the same people.

2 1

adding to REST
by Dominic Dambrogia March 14, 2016

March 14, 2016

Hi, My name is Dominic. I contacted this mailing list last week about list moderation and post approval. My problem was not being able to set a list password via the REST api. I need this for nonmember approval of posting to a mailing list via email in the "Approved: *list password*" style in the first line of the email like the default request for moderation email suggests. I'd like to go ahead and tackle this problem personally. I would appreciate some insight on where to start looking in the project itself. I've only installed the bundler and used REST so far, so my knowledge of how the python code works so far is minimal. Any insight is greatly appreciated, thanks. - Dominic

1 0

TLS/SMTP AUTH in MM3? [was: Mailman without localhost ?]
by Stephen J. Turnbull March 14, 2016

March 14, 2016

Redirected from -users. I have nothing to add to what Mark wrote there. Mark Sapiro writes: > These are for outgoing mail from Mailman only. They have nothing to do > with delivery of mail TO mailman. You can tell Mailman to connect to any > SMTP server and port by setting SMTPHOST to the fully qualified name of > the server and/or SMTPPORT to the port. > > If ... you can use an alternate port such as 465 or 587 that may > require TLS and/or authentication, you can set SMTPPORT to that > value, but you (or the host admin) will have to patch Mailman's > SMTPDirect.py module to provide the authentication. You can find a > patch for this at <https://bugs.launchpad.net/mailman/+bug/558281>. Is this in Mailman 3? If not, is it appropriate? I doubt it's a GSoC project in itself, but might be a good prove-yourself task for an advanced applicant. Steve

2 1

GitLab/development tools integration project
by Niko 7 March 14, 2016

March 14, 2016

Greetings, I'm a student from University of Oviedo, Spain, and I was interested in working with aforementioned project. I have decent experience in Python and I've already prepared my environment (forked and cloned the core and the client) and I'm going to look into helping with issues soon enough Where should I start thinking about this project? Like, the code itself, I could use some guidance. Thanks in advance!

2 1

Re: [Mailman-Developers] Basic workflow of the ARC implementation
by Stephen J. Turnbull March 13, 2016

March 13, 2016

Aditya Divekar writes: > > > 4. ARC Authentication Result - arc verification code completed. tests > > > passed. merge request created. > > > > How do you propose to create tests for #4? > > > > > Here, we could consider a few scenarios- > 1. A message is passed to the function which does not have any previous ARC > headers. In this case the verification is not performed. > 2. A message containing a valid ARC chain is passed to the > function. The problem is how do you get such a message? The easiest way is if you have implemented the creation functions for the ARC-* fields. Then you can check that you can roundtrip your own fields (create and verify). Of course you will eventually need to test against other implementations (currently Google and AOL have implementations that I know of), but for now it makes sense to "eat your own dogfood". Regards,

2 1

Re: [Mailman-Developers] Basic workflow of the ARC implementation
by Stephen J. Turnbull March 13, 2016

March 13, 2016

Aditya Divekar writes: > Depending on the message, if it has previous Authentication Results added > as a header, that can be extracted too. The entire message can be parsed, > and then all the possible headers involved in the authentication process, > ie. DKIM signature, Authentication results, ARC headers, can be > extracted. If not found, a suitable flag can be set for them. ie. example > - if no previous arc headers were found, a flag can be set. This can later > be used in deciding the flow of the mail such as the "i" tag value, whether > we need to perform ARC authentication for the previous ARC headers, and > other fields that depend on the occurrences of any previous ARC > set. This is all already in the message or msg_data objects, except for the value of "i" itself. So I'm not sure what you're saying. My point is merely that any header field mentioned in any of the relevant RFCs that can be validated must be validated to conform to ARC. > Okay.! So we need to only include the ARC Headers and forward the > message to the subscribers, and leave it upto their MTAs to do the > needful. Yes. > I have come up with the following probable milestones for the > project. - Looks good. I have a couple of comments. > (The project has been divided into milestones on the basis of the separate > modules that will be created. Each module is a milestone). I'm not sure you will need so many separate modules; each verification depending on existing standard can probably be kept to a single function, unless you can't get all relevant information from the upstream modules. But it doesn't hurt to separate them now, and think about combining them later, if that's convenient for you. > 1. ARC Authentication Result - spf verification code completed. tests > passed. merge request created. > 2. ARC Authentication Result - dkim verification code completed. tests > passed. merge request created. > 3. ARC Authentication Result - dmarc verification code completed. tests > passed. merge request created. > 4. ARC Authentication Result - arc verification code completed. tests > passed. merge request created. How do you propose to create tests for #4? > 5. ARC Authentication Result - generate AAR from the previous milestones > code. tests passed. merge request created. > 6. ARC Message Signature code completed. tests passed. merge request > created. > 7. ARC Seal code completed. tests passed. merge request created. > 8. Generate the ARC set of headers from the previous milestones code, and > prepend them to the message. > tests passed. merge request created. > > *As you mentioned, branch coverage will be the aim behind all the tests for > each module (Branch coverage would mean considering all possible scenarios > of the workflow). > > Notes - > > 1. I've broken down the AAR set into different milestones, since each > method will require the use of different functions and packages. (ie. spf, > dkim, dmarc, arc). > > 2. Regarding milestone 8, separate modules will be responsible for > generating the components of the ARC header set, and these can be combined > at the end for getting the complete ARC set. This will be useful for > testing purposes. > > 3. We need to perform the dmarc testing manually since the gs.dmarc package > only provides the dmarc policy query functionality. The gs.dmarc package > can be used to query the dmarc record of the RFC5322.From domain. Then we > can verify using the aspf and adkim relaxed/strict tag values and the > spf/dkim results whether the dmarc authentication is a pass or fail, as > given in the RFC7489 draft (dmarc draft). Is there a better alternative to > this in your knowledge? No. > I would like your opinion on these milestones, and if possible your > ideas can be merged with these to come up with a better list :) No, your list is workable and basically similar to mine, except for the ordering comment on #4. I think we should develop your ideas first, then compare. Steve

2 1

Gsoc Support for Message queue based email archiver
by Anirudh Dahiya March 13, 2016

March 13, 2016

Hello I am a computer scrience undergrad at IIIT-Hyderabad, India. I was looking through the GSoC 2016 ideas and would like to know more about the project "message queue based email archiver" I have played with codebase of mailman and postorius for some time now and am currently trying to understand how Hyperkitty works. Also, as suggested to other students regarding this project, I have gone through the chapter on mailman in the book The Architecture of Open Source Applications, the pycon talk on mailman by Barry and have also gone through relevant parts of the documentation. Regards Anirudh Dahiya (spark on IRC)

1 0