Re: [Mailman-Developers] adding to REST
treal tv writes: > I hadn't considered this yet. I had planned to help with patches so > yeah, I think i'll be rebuilding from the repo! Thanks, I hadn't > even thought about that yet. I think the way to think about it is that bundler is a system for distributing a "turnkey" Mailman installation (I guess the more modern term is "app" but we're way far from getting there!) If you are interested in contributing to the distribution methods themselves (and that is *very* important, at this point distribution and upgrade from Mailman 2 are probably more important *to our users*[1] than code improvement), install bundler (probably alongside a repo installation, or including a repo installation). Otherwise, bundler itself is still unstable, and will distract you from working on Mailman, Postorius, and/or HyperKitty code. Of course if you just want a working Mailman installation that you can start up, configure, and then ignore, try bundler. It does work for a lot of people at some instants of time. ;-) Footnotes: [1] Remember, we're all volunteers. Users are important to most core contributors "just because we care", but you are a volunteer[2] too. Over time we'll train you to be more user-oriented, but for now, have fun! [2] That's mostly remains true if you are a GSoC intern. ___ 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] adding to REST
I hadn't considered this yet. I had planned to help with patches so yeah, I think i'll be rebuilding from the repo! Thanks, I hadn't even thought about that yet. On 03/14/2016 06:24 PM, Simon Hanna wrote: In case you want to turn in patches (merge requests) then having a repo is a must. And if you don't plan to turn in patches it's still useful. ___ 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] adding to REST
I might be misunderstanding you, Simon, but should I not be using Mailman 3 built with the bundler if I intend to modify/further build on the code? I've been working off one built with the bundler for the last couple months and it's tolerated the mods I made without issue but I'd rather switch to source built sooner rather than later if it's going to matter in the future. On 03/14/2016 03:31 PM, Simon Hanna wrote: 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 ___ 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/trealtv%40yandex.com Security Policy: http://wiki.list.org/x/QIA9 ___ 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] adding to REST
On 03/14/2016 10:34 PM, treal tv wrote: > I might be misunderstanding you, Simon, but should I not be using Mailman 3 > built with the bundler > if I intend to modify/further build on the code? > > I've been working off one built with the bundler for the last couple months > and it's tolerated the > mods I made without issue but I'd rather switch to source built sooner rather > than later if it's > going to matter in the future. I'm unaware of any real downside to using the repo (unless you are a security fanatic and want stuff tested for a couple of years ^^) You can also use bundler with git repos. You'll just have to do run "python setup.py develop" for mailman in the python3 virtualenv that bundler installs. Note you will want to use the other repos as well, as there might be some incompatibilities. Now to why you should be using it: In case you want to turn in patches (merge requests) then having a repo is a must. And if you don't plan to turn in patches it's still useful. You can work on another branch than master and whenever upstream has new commits you can rebase them into your branch. That way you stay up to date without too much maintenance ___ 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] adding to REST
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 ___ 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] Basic workflow of the ARC implementation
Hi Steve, As discussed in our earlier conversation, I went over the milestones again and made some changes. We would need to use the approach of creating our own examples in the milestone for the AS code (milestone 6, for testing) too, since the AS signs over the previous generated set of headers. This will however not be a problem since the AMS and AAR code should be already completed by that point thus enabling the creation of test example. And as said before, the second time this approach would be used in milestone 7. The reordering of the arc verification after the completion of the AMS and the AS should not be a problem since the AMS and AS code do not refer explicitly to the arc verification field in the AAR. Both of them use the AAR in their signing[1] as a whole field and are not concerned with its individual fields, and hence the addition of arc at a later stage should not create any problem. Also the examples used for testing by us in milestone 5 and 6 would not involve the `arc = ` field since the example mail will be consisting of the first instance of the ARC headers i.e. `i = 1`, and hence the arc verification test would not be performed (i.e. no `arc = ` field in the AAR), even after the code for it is inserted in its place, thus keeping the tests in milestones 5 and 6 valid. Milestones - 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 - generate AAR header from the previous milestones code. tests passed. merge request created. 5. ARC Message Signature code completed. tests passed. merge request created. 6. ARC Seal code completed. tests passed. merge request created. 7. ARC Authentication Result - arc verification code completed. tests passed. (The workflow is modified to make the mail pass through this function after milestone 3 [2] ). merge request created. 8. The mail is prepended with the complete set of ARC headers. Tests for checking the entire ARC set of headers passed. merge request created (tests). Comments on testing - 1. For spf testing - The spf library itself provides test examples, and mails can be extracted (i.e. the part before gmail adds its own authentication results) from gmail using the `Show Original` feature. These mails can be used for testing purposes. 2. For dkim testing - The dkim library provides testing examples, and similar to above, mails may be used from gmail. 3. For dmarc testing - The examples for this can be gathered from our gmail account. Any mail sent from yahoo's domain to a gmail account will have dmarc verification performed. A mail extracted so can be used for testing purposes by us. 4. Testing this would require testing of the format of the generated AAR against the official RFC7601 format for authentication results (since the values of the individual fields have already been tested above) i.e. keeping track of the delimiters, white spaces, and the correct prepending. The AAR header generated for an example mail from the above code can be used here, and tested against the format outlined in the ARC draft. 5. ARC Message Signature testing - We can generate the signature for a given example mail from the written code, and generate a signature using the same set of headers from the dkim package (keeping track of the implicit and explicit headers). The crucial part would be matching the signatures, i.e. the "b" tag, and matching the body hash, i.e. the "bh" tag. The "t" tag would differ since it depends on the exact time, and the "i","a","s","d", "h" tags can be checked manually. 6. ARC Seal testing - For this we could use the previously defined AAR and AMS, and the current AS code to generate a mail with the full ARC set of headers (the AS would sign over the AAR and the AMS generated in the previous milestones). An example mail could be then passed through the above code, and then can be used for testing purposes (Here we would need the approach of generating our example from the code as you mentioned). Here too, the "i", "a" , "s" , "d" , "cv " tags can be checked manually and the "t" tag would differ. Hence the crucial tag would be the "b" tag. 7. The code for the arc verification test is completed. We can now perform the arc verification test here. A fully cooked mail with the ARC headers can be prepared from the above code for the `pass` test . For a `fail` test, we can make some manual changes in the AS to invalidate it, and then perform arc verification on it. 8. Here the testing for the complete ARC set of headers would need to be performed. An example mail can be passed through the above entire code, and manually asserted in the test. (Since the individual fields would have already been tested, the main aim here would be testing that the ARC
[Mailman-Developers] adding to REST
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 ___ 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] TLS/SMTP AUTH in MM3? [was: Mailman without localhost ?]
On Mar 14, 2016, at 12:15 PM, Stephen J. Turnbull wrote: >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. Python 3's smtplib supports starttls() so I don't think it would be all that difficult. It doesn't look like the Launchpad bug made it to Gitlab, but I agree with Steve's assessment. Cheers, -Barry ___ 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
