Hi
The community bonding period was well utilized in finalizing design,
besides other things.I also made a prototype
<https://gitlab.com/anirudhdahiya9/message-queues-prototypes> for RabbitMQ
Message Queue during this period, and shared it with Florian(and now with
you :) ) Also, I learnt about tox, unittest, and studied the codebase and
tests for existing archivers and runner.
All the progress and designs made during the community bonding period has
been documented by me in my blog post -
https://codefullofsummer.blogspot.in/
Regards
Anirudh Dahiya
(irc spark_)
Hi,
While categorising the styleable attributes I have come across some
attributes which are defined but never used in the code. Some of these
attributes are:
forward_auto_discard
non_member_rejection_notice
member_rejection_notice
bounce_score_threshold
bounce_notify_owner_on_disable
bounce_notify_owner_on_removal
forward_auto_discards
max_days_to_hold
digest_is_default
mime_is_default_digest
scrub_nondigest
obscure_addresses
Some of the attributes are present only in
src/utilities/tests/test_import.py. A list of such attributes is as follows:
bounce_you_are_disabled_warnings
bounce_info_stale_after
accept_these_nonmembers
discard_these_nonmembers
reject_these_nonmembers
What should be done to these attributes? For now, I have included them in
the model.
Also in src/mailman/styles/base.py line no. 129, we are setting up an
non-existing attribute as follows:
mlist.topics_userinterest = {}
But the IMailinglist doesn't contain any such attribute.
Thanks,
Harshit Bansal
On May 24, 2016, at 11:48 PM, Harshit Bansal wrote:
>I was writing the new 'IStyle' interface and after completing some part of
>it I realised that the code has become a bit repetitive as all the
>styleable attributes which are present in src/interfaces/mailinglist.py are
>to be copied to src/interfaces/styles.py in IStyle interface. For example,
>
>advertised = Attribute(
> """Advertise this mailing list when people ask for an overview of the
>available mailing lists.""")
>
>This piece of code is now present in both src/interfaces/mailinglist.py and
>src/interfaces/styles.py.
This is in some respects a quirk held over from Mailman 2. The MailList class
is a mixin of several other classes which hold both settings and functionality
(methods). During the port to Mailman 3, I essentially collapsed all of that
into a single MailingList class.
Styles are a separate thing bolted onto the side of that, which is why they're
implemented as applying to a mailing list only at creation time. You're right
that a style has many of those attributes, but also keep in mind that a style
can have a *subset* of attributes, as you should be able to see in the
existing style classes. Styles are meant to be composable, so for example,
you could define an "announce-only" style that only modifies some of the
related attributes, but allows others to be defined in other style classes.
MailingList instances OTOH contain all the style related attributes.
>Is there any way to correct it or is it fine? One approach that I am able to
>think of is to write one seperate interface containning all the styleable
>attributes and implement that interface both in src/model/mailinglist.py and
>src/model/styles.py.
I'm not sure. Given that styles can be partial collections of attributes,
maybe it doesn't make sense to name them all in the IStyle interface. Leaving
them only in the IMailingList doesn't have much of a functional effect; in
this case the interface isn't much more than documentation and marker (it
declares the @implementor class as being of that interface so it's easier to
look up).
Cheers,
-Barry
Hi,
I was writing the new 'IStyle' interface and after completing some part of
it I realised that the code has become a bit repetitive as all the
styleable attributes which are present in src/interfaces/mailinglist.py are
to be copied to src/interfaces/styles.py in IStyle interface. For example,
advertised = Attribute(
"""Advertise this mailing list when people ask for an overview of the
available mailing lists.""")
This piece of code is now present in both src/interfaces/mailinglist.py and
src/interfaces/styles.py. Is there any way to correct it or is it fine?
One approach that I am able to think of is to write one seperate interface
containning all the styleable attributes and implement that interface both
in src/model/mailinglist.py and src/model/styles.py.
Thanks,
Harshit Bansal.
Hi Harshit,
Their is no authentication system(OAuth etc.) set up between core and
client for now. The client uses plain HTTP calls to communicate to the
core. So, anyone with the credentials can alter any such permissions in the
core. So, for now core and client should reside on the same host. So, I
guess it would be better to implement the permissions stuff on the
postorius side as others pointed out !
PS : I worked on the Node.js mailman client last year. You can refer it here
<https://gitlab.com/black-perl/mailman-client.js>.
Thanks !
Ankush Sharma
ECE IV
IIT-BHU
Varanasi-221005
http://black-perl.in
Linkedin <https://www.linkedin.com/in/ankushsharma003>
On Sun, May 22, 2016 at 3:20 AM, Harshit Bansal <harshitbansal2015(a)gmail.com
> wrote:
> Hi,
> Earlier, while discussing the permission system for manging styles, it was
> decided that the permissions system should be enforced in the core rather
> than in the postorius since otherwise it can be bypassed(deliberately or
> undeliberately). But one thing that I think I forgot to discuss was that
> currently there is no authorisation system in the core and now I am unable
> to figure out that how could the permissions be enforced in the core
> without an authorisation system.
> Should I workout an authorisation system for the core first or enforce
> permissions in postorius only?
>
> Thanks,
> Harshit Bansal
> _______________________________________________
> 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/ankush.sharma.ec…
>
> Security Policy: http://wiki.list.org/x/QIA9
>
On 05/22/2016 12:08 AM, Harshit Bansal wrote:
> Hi Simon,
> This is the discussion that I was referring to:
>
> Harshit Bansal writes:
>
> > I think the "Permissions Systems" would have nothing to do with the
> > core. It would be related to Postorius. We will have to create a style
> > model separately in Postorius which would store the style name and the
> > user who created it. Then only the user who has created the style
> > would be granted the permission to edit it.
>
> Stephen J. Turnbull wrote:
>
> Then there is no *permissions* system! For example, one project last
> year created a Javascript client -- that would completely bypass the
> "permissions" system as you describe it. You could imagine that style
> changes are a "friendly users" feature, and so the "style owner"
> system would be a *safety* feature of the Postorius UI rather than an
> *authorization* feature of styles. But in an enterprise context (eg,
> a virtual hosting service), I'm sure that users will think of it as an
> authorization system. While at present it seems unlikely that there
> would be multiple interfaces on one hosting service, you never know
> what users will do[1]. Also, it would not be obvious to somebody who
> installed the node.js Mailman client that they are likely bypassing
> "security" as documented in the typical Mailman manuals and tutorials
> that you would find on the web.
>
> Thanks,
> Harshit Bansal
>
>>Hi,
>>Earlier, while discussing the permission system for manging styles, it
>>was
>>decided that the permissions system should be enforced in the core
>>rather
>>than in the postorius since otherwise it can be bypassed(deliberately
>>or
>>undeliberately). But one thing that I think I forgot to discuss was
>>that
>>currently there is no authorisation system in the core and now I am
>>unable
>>to figure out that how could the permissions be enforced in the core
>>without an authorisation system.
>>Should I workout an authorisation system for the core first or enforce
>>permissions in postorius only?
After reading this and your proposal, I'm wondering why you want to add
the permission system in postorius.
You are storing the styles in core, and grant permissions based on
list/domain/site ownerships. All this information is in core.
Currently mailmanclient exposes everything, not caring about
permissions. You have admin rights, whoever uses mailmanclient has to
manage access on their own.
We currently have @list_moderator_required that we use in postorius. We
are not doing anything with domain or site owners, but they should be
pretty easy to implement.
While in theory it would be possible to enforce permissions in core
about who is allowed to call specific rest calls, this would require a
lot of changes. I'm not sure we want to go this way.
There are some things in core, that suggest that this might come
sometime. (Users have passwords and you can authenticate them)
But I guess this is somewhat legacy and will be dropped sometime in the
future.
>Hi,
>Earlier, while discussing the permission system for manging styles, it
>was
>decided that the permissions system should be enforced in the core
>rather
>than in the postorius since otherwise it can be bypassed(deliberately
>or
>undeliberately). But one thing that I think I forgot to discuss was
>that
>currently there is no authorisation system in the core and now I am
>unable
>to figure out that how could the permissions be enforced in the core
>without an authorisation system.
>Should I workout an authorisation system for the core first or enforce
>permissions in postorius only?
Can you elaborate a little more?
What do you want to use the authorization for? Why isn't doing it in postorius safe enough?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Hi,
Earlier, while discussing the permission system for manging styles, it was
decided that the permissions system should be enforced in the core rather
than in the postorius since otherwise it can be bypassed(deliberately or
undeliberately). But one thing that I think I forgot to discuss was that
currently there is no authorisation system in the core and now I am unable
to figure out that how could the permissions be enforced in the core
without an authorisation system.
Should I workout an authorisation system for the core first or enforce
permissions in postorius only?
Thanks,
Harshit Bansal
Hi, all
This IETF work affects us all, so I'm reposting here so those with the
interest can participate.
"Indirect mail flows" includes but is not limited to mailing lists.
"DMARC" is the protocol which Yahoo! and AOL used to unsubscribe
thousands of innocent list members in April 2014. This Internet Draft
is about to be promoted to RFC, so this is really the last chance to
get any changes made. (You can comment on a Request for Comments, but
you'll never get one changed. :-) For our purposes,
"interoperability" means best practices for both email providers and
mailing list operators to avoid reoccurance of that "April Fool's Joke".
If you haven't participated in IETF work before, you might want to run
your comments by us (or me personally, if you prefer) before sending
them off to the IESG. RFC-ese is not really English. ;-) I'll be happy
to provide translation of portions of interest on request.
My personal opinion is that the last draft I looked at (#12) was very
good, but the more eyes the better.
Reply-To set to mailman-users, but personal replies to me also
welcome. Please don't reply-all. Also, there is no chance that DMARC
"p=reject" itself is going away, so let's not rehash that issue.
Standards-geek-ily y'rs,
The IESG writes:
>
> The IESG has received a request from the Domain-based Message
> Authentication, Reporting & Conformance WG (dmarc) to consider the
> following document:
> - 'Interoperability Issues Between DMARC and Indirect Email Flows'
> <draft-ietf-dmarc-interoperability-15.txt> as Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf(a)ietf.org mailing lists by 2016-06-03. Exceptionally, comments may be
> sent to iesg(a)ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
> DMARC introduces a mechanism for expressing domain-level policies and
> preferences for email message validation, disposition, and reporting.
> The DMARC mechanism can encounter interoperability issues when
> messages do not flow directly from the author's administrative domain
> to the final recipients. Collectively these email flows are referred
> to as indirect email flows. This document describes interoperability
> issues between DMARC and indirect email flows. Possible methods for
> addressing interoperability issues are presented.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> _______________________________________________
> dmarc mailing list
> dmarc(a)ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>