Re: [Mailman-Developers] Need more information about the GSoC idea 'GitLab/development tools integration'

[Stephen J. Turnbull]

Mark Sapiro writes:

 > The definitive reference on threading is
 > 

There's also RFC 5256, based on Jamie's page, which defines threading
in the context of IMAP, and gives a concise account of the algorithm.
___
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] Patch for HyperArch

[Stephen J. Turnbull]

Mark Sapiro writes:
 > On 03/12/2016 08:23 AM, Stephen J. Turnbull wrote:
 > > Mark Sapiro writes:
 > > 
 > >  > The Received: header check is important. For an "imported" mbox, the
 > >  > From_ separators may reflect when the mbox was exported from it's source
 > >  > rather than the message date. If the messages have Received: headers,
 > >  > the later ones at least tend to have good dates.
 > > 
 > > Overengineering (seems to be becoming a habit?) perhaps, but if you're
 > > going to parse one Received field, why not do them all, sort, and take
 > > the latest reasonable one?  Leaving the sorted list on msg_data might
 > > also be useful to spam filters (although we don't really want to
 > > recommend spam filtering in Mailman...).
 > 
 > 
 > I see your point,

About "overengineering"?  :-)

Gotcha on the rest, but "overengineered, yes" was you needed to say.
(I guess the "header field contents are in a list ordered as you would
expect datum" is generally useful though.  Thanks for explaining that,
even if it's not part of the spec.)

___
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] Need more information about the GSoC idea 'GitLab/development tools integration'

[Richard Damon]

On 3/12/16 4:19 PM, Wasim Thabraze wrote:

Hello everyone,

The GSoC idea states  'a tool that will take a thread from a Mailman
mailing list and..'. I just wanted to know what are the different ways to
extract a thread from a mailing list.

I'm actually trying to understand the idea from a couple of days but in
vain. I couldn't even find documentations related to thread extraction.

Does a thread has any unique id? If yes, how should I extract the thread
using the id?

Any links that would help me in understanding it in a much more better way?



Awaiting reply.


Thank You


Regards,
Wasim
  
The normal definition of the 'Thread' is a chain of message linked by 
In-Reply-To: and References: headers to Reference-Id: headers.


Every email message has a unique Reference-Id: header to identify it.

When a person replies to that message, their email program is supposed 
to add a In-Reply-To: header with the Reference-Id of the message it is 
a reply to, or a References: header with a copy of the References: 
header of the message being replied to with the Reference-Id of the 
replied to message added at the beginning (and possibly ones at the end 
trimmed if the header gets too long). This chain defines a 'Thread'.


One wrinkle is with plain text digest users, they tend to not have the 
Reference-Id of the message they are replying to (one of the limitations 
of the plain text digest) so they tend to break threads. The one big 
issue here is that they also often send a message by replying to the 
digest, so two messages that refer to the same message in In-Reply-To: 
or References: headers might not want to be linked together as a thread 
if the common Message-Id isn't present (it is likely the digest). I 
think this is what the current mailman 2 archives do.

___
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

[Mailman-Developers] Need more information about the GSoC idea 'GitLab/development tools integration'

[Wasim Thabraze]

Hello everyone,

The GSoC idea states  'a tool that will take a thread from a Mailman
mailing list and..'. I just wanted to know what are the different ways to
extract a thread from a mailing list.

I'm actually trying to understand the idea from a couple of days but in
vain. I couldn't even find documentations related to thread extraction.

Does a thread has any unique id? If yes, how should I extract the thread
using the id?

Any links that would help me in understanding it in a much more better way?



Awaiting reply.


Thank You


Regards,
Wasim
___
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] Discussion On Project Idea "Preset List Settings Templates" .

[Harshit Bansal]

Hi,

On 3/12/16, Stephen J. Turnbull  wrote:

>  > Basically, a style will be having three levels of viewability:
>  > 1: System wide : A style having this level of viewability will be
>  > visible to all the domains as well as the lists. It will be available
>  > to all the list owners for copying however the site owners will have
>  > the option to make it either read-only or editable.
>
> I don't see a real advantage to having this editable by list owners,
> since it's copyable.  On the other hand, "styles" are not just
> display, but also include security/privacy features.  Eg, a rogue
> editor could DoS the whole site by adding .* as a ban or discard
> expression in spam filtering.  I think probably it's OK to have styles
> editable only by owner.
>

Yes I also agree with you. I am refining this system as follows:
Suppose there is a style A having a domain level viewability. Then
only site owners and domain owners would be allowed to edit it. The
list owners would have the option to either apply as it is or copy and
modify it.
Basically, a user at the same or upper level would be able to edit the
style. The users at the lower level would have to copy the style if
they want to change it.

>  However, the owner might be a group of users.

Yeah, I am actually assuming them to be a group of users.

> How about inheritability?  The difference between inheritance and
> copying is that if the template changes, with inheritance the derived
> configurations change too, with copying they don't.
>

Sorry, I think I have used wrong terminology here. By 'copying' I
actually meant 'inheriting'.

>  > Also while working out the implementation details, I came across a new
>  > problem which is as follows:
>  > Suppose, we have three style A, B and C. B inherits from A and C
>  > inherits from B. Now, suppose someone decides to delete style B then
>  > how can we deal with this situation.
>
> Persistence across Mailman restarts of course needs to be carefully
> dealt with, but we deal with the basic issue in the usual Unix way: a
> style which is "deleted" just loses its entry in the admin-visible
> directory of styles, but it is not actually deleted from the database
> until all references are gone.
>

Indeed a great idea. The unused styles will garbage collected at
regular intervals.


Also, the way in which we now store and categorise styles has made
them very much analogous to the members of a list. So, should a
"roster" like functionality for searching and retrieving the styles be
implemented just like it is implemented for members?

Thanks,
Harshit Bansal.
___
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] Patch for HyperArch

[Mark Sapiro]

On 03/12/2016 08:23 AM, Stephen J. Turnbull wrote:
> Mark Sapiro writes:
> 
>  > The Received: header check is important. For an "imported" mbox, the
>  > From_ separators may reflect when the mbox was exported from it's source
>  > rather than the message date. If the messages have Received: headers,
>  > the later ones at least tend to have good dates.
> 
> Overengineering (seems to be becoming a habit?) perhaps, but if you're
> going to parse one Received field, why not do them all, sort, and take
> the latest reasonable one?  Leaving the sorted list on msg_data might
> also be useful to spam filters (although we don't really want to
> recommend spam filtering in Mailman...).


I see your point, but my feeling is that bad dates tend to come from the
original poster's machine so that if the Date: header is bad, maybe the
first (bottom-most in the message headers) Received: header also has a
bad date, but subsequent ones are likely good.

I think the likelihood that the last (top-most) Received: date is also
bad but an intermediate one is good is vanishingly small.

I also note that the docs say that in the case of multiple 'Xxx:'
headers, the one returned by email.message.get('xxx') is indeterminate,
but I've looked at the code and in the message object, the header's are
kept in a list (not a dictionary) in the order parsed from the original
text, so get() which returns the first found will reliably return the
top-most one.

Also note that this change really only affects processing of imported
mailboxes with bin/arch. For posts to a list being archived, ArchRunner
has already fixed bad dates and even if it hasn't because the site set
ARCHIVER_CLOBBER_DATE_POLICY = 0, ArchRunner still added an
X-List-Received-Date: header and pipermail._set_date() will look at that
before looking at any Received: headers.

So we're really only dealing with defective messages from imported
mailboxes, and they often won't even have Received: headers.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
___
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

[Mailman-Developers] To GET STARTED

[Pabitra Lenka]

Greetings Developers,
  I am a newbie.I would like to contribute to your
organization.Can anyone get me started.?

-- 
Cheers,
Pabitra Lenka
Department of Information Technology
Class of 2018
IIIT Bhubaneswar
___
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

[Mailman-Developers] INTEREST IN IMPLEMENTING Message queue based email archiver

[Okusanya Damilola]

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.

Sincerely,

Okusanya OIuwadamilola.
___
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

[Stephen J. Turnbull]

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
___
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] Patch for HyperArch

[Stephen J. Turnbull]

Mark Sapiro writes:

 > The Received: header check is important. For an "imported" mbox, the
 > From_ separators may reflect when the mbox was exported from it's source
 > rather than the message date. If the messages have Received: headers,
 > the later ones at least tend to have good dates.

Overengineering (seems to be becoming a habit?) perhaps, but if you're
going to parse one Received field, why not do them all, sort, and take
the latest reasonable one?  Leaving the sorted list on msg_data might
also be useful to spam filters (although we don't really want to
recommend spam filtering in Mailman...).

___
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] Help regarding an error during installation

[Stephen J. Turnbull]

Abhilash Raj writes:
 > On 03/10/2016 07:18 AM, Daman Singh wrote:

 > > When i run buildout command i get an error saying,"no module
 > > named 'zlib'" but on running ipython, when i import zlib it works
 > > all right.
 > 
 > When running buildout in mailman-bundler, it generally creates a
 > virtualenv of its own, which might not have 'zlib not installed in
 > it.

This doesn't make a lot of sense to me, as zlib is in the stdlib, and
therefore should be installed if Python is.  Something weird is going
on here, such as crossing PYTHON_PATHs.

I'm beginning to agree with Simon: unless your project is to *fix
bundler*, developers should avoid bundler for now.

___
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] Discussion On Project Idea "Preset List Settings Templates" .

[Stephen J. Turnbull]

Harshit Bansal writes:

 > Basically, a style will be having three levels of viewability:
 > 1: System wide : A style having this level of viewability will be
 > visible to all the domains as well as the lists. It will be available
 > to all the list owners for copying however the site owners will have
 > the option to make it either read-only or editable.

I don't see a real advantage to having this editable by list owners,
since it's copyable.  On the other hand, "styles" are not just
display, but also include security/privacy features.  Eg, a rogue
editor could DoS the whole site by adding .* as a ban or discard
expression in spam filtering.  I think probably it's OK to have styles
editable only by owner.  However, the owner might be a group of users.

How about inheritability?  The difference between inheritance and
copying is that if the template changes, with inheritance the derived
configurations change too, with copying they don't.

 > 2: Domain Wide : A style having this level of viewability will be
 > visible to all the lists within a specific domain. However, the domain
 > owners would have the option to make it read-only or editable.

Same as above.

 > 3: List Specific : A style having this level of viewability will be
 > visible to a specific list.
 > 
 > Not only this, all stylable attributes will be divided into three categories:
 > 1: Site owner level attributes : Only site owners will have the
 > permissions to edit these attributes.

As above, "owner" should be allowed to be a group.

 > 2: Domain owner level : Site owners as well as domain owners can
 > edit these attributes.

Ditto.

 > 3: List owner level : Site owners as well as domain owners as well as
 > list administrators will have the permissions to edit these
 > attributes.

 > @Steve I think this system also addresses the issues that you pointed
 > as now all the permissions will be enforced in the mailman core
 > instead of Postorius.

Yes.

 > Also while working out the implementation details, I came across a new
 > problem which is as follows:
 > Suppose, we have three style A, B and C. B inherits from A and C
 > inherits from B. Now, suppose someone decides to delete style B then
 > how can we deal with this situation.

Persistence across Mailman restarts of course needs to be carefully
dealt with, but we deal with the basic issue in the usual Unix way: a
style which is "deleted" just loses its entry in the admin-visible
directory of styles, but it is not actually deleted from the database
until all references are gone.

___
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