From rajeevs1992 at gmail.com  Sun Jun  1 16:58:25 2014
From: rajeevs1992 at gmail.com (Rajeev S)
Date: Sun, 01 Jun 2014 20:28:25 +0530
Subject: [Mailman-Developers] [CLI Project] Introduced Unit tests to CLI
Message-ID: <538B3F91.9070902@gmail.com>

Hi,

As per Abhilash's comment to follow the TDD, I have covered
the test cases for the `domain` scope.

I know that TDD requires to write tests before implementation.
However, I believe that it's not a good idea to postpone test cases for the
existing units further.

Also, I would like to thank Abhilash for the comment, before its too late
to begin writing the tests.

I have pushed the r56 that includes the test scripts.

I have also done some significant refactoring on the code this weekend, to
facilitate easy usage with the unittest package and to make the code 
more cleaner.
The refactoring mainly includes imposing the of DRY principle -- moving 
repetitive code
to the lib/* directory.

As an end note, this is a hefty revision. :)

http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/56

Thank You!

From raj.abhilash1 at gmail.com  Mon Jun  2 08:23:00 2014
From: raj.abhilash1 at gmail.com (Abhilash Raj)
Date: Mon, 2 Jun 2014 11:53:00 +0530
Subject: [Mailman-Developers] [CLI Project] Introduced Unit tests to CLI
In-Reply-To: <538B3F91.9070902@gmail.com>
References: <538B3F91.9070902@gmail.com>
Message-ID: <20140602115300.12ef08a2@angel>

Hi Rajeev,

Rajeev S <rajeevs1992 at gmail.com> wrote:

> Hi,
> 
> As per Abhilash's comment to follow the TDD, I have covered
> the test cases for the `domain` scope.

Thanks for considering my suggestion. I think you don't need to create
a sub-module for each scope inside `tests` module. It should be simpler
like `/tests/test_domain.py` and all the tests related to domains
should reside inside that. You can add multiple test-cases for Domain
like add, delete or whatever inside that single test_domain.py.

> I know that TDD requires to write tests before implementation.
> However, I believe that it's not a good idea to postpone test cases for the
> existing units further.
> 
> Also, I would like to thank Abhilash for the comment, before its too late
> to begin writing the tests.

Glad I could help :)

> I have pushed the r56 that includes the test scripts.
> 
> I have also done some significant refactoring on the code this weekend, to
> facilitate easy usage with the unittest package and to make the code 
> more cleaner.
> The refactoring mainly includes imposing the of DRY principle -- moving 
> repetitive code
> to the lib/* directory.
> 
> As an end note, this is a hefty revision. :)
> 
> http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/56

I see that you parsing the configuration to return a
`mailmanclient.Client()` object twice, once in cmdparser.py and second
time in`/lib/mailman_utils.py`. I don't understand why? Can
cmdparser.py not use the `MailmanUtils.connect()` method?

Here :/src/mailmanclient/cli/core/domains.py#L32 docstrings should be
immediately after the `def` line, there should not be a empty-line in
between them. 

Here: /src/mailmanclient/cli/core/users.py#L41 you can use upto 80chars
in docstrings too before introducing a line break.

Also if you are following the convention of specifying the parameter of
a function in docstring, add a `:type param: foo` for each parameter
too. It helps sphinx in generating better documentation. 
See this: 
  https://pythonhosted.org/an_example_pypi_project/sphinx.html

Everything else looks nice.

-- 
thanks,
Abhilash Raj

From rajeevs1992 at gmail.com  Mon Jun  2 09:26:59 2014
From: rajeevs1992 at gmail.com (Rajeev S)
Date: Mon, 2 Jun 2014 12:56:59 +0530
Subject: [Mailman-Developers] [CLI Project] Introduced Unit tests to CLI
In-Reply-To: <20140602115300.12ef08a2@angel>
References: <538B3F91.9070902@gmail.com> <20140602115300.12ef08a2@angel>
Message-ID: <CAPq4ZOJB_jahQWhHamJm=Z-Q0fmAru_pPieBC9XDJnGoLWyUxA@mail.gmail.com>

On Mon, Jun 2, 2014 at 11:53 AM, Abhilash Raj <raj.abhilash1 at gmail.com>
wrote:

> Hi Rajeev,
>
> Rajeev S <rajeevs1992 at gmail.com> wrote:
>
> Thanks for considering my suggestion. I think you don't need to create
> a sub-module for each scope inside `tests` module. It should be simpler
> like `/tests/test_domain.py` and all the tests related to domains
> should reside inside that. You can add multiple test-cases for Domain
> like add, delete or whatever inside that single test_domain.py.
>
>

I was in an idea to follow "the one class per file" style, especially when
the classes
tend to grow large in size as in the tests.(It was mentioned in the Barry's
style guide, and so is a common coding guideline.)

Should I change that?



>
> I see that you parsing the configuration to return a
> `mailmanclient.Client()` object twice, once in cmdparser.py and second
> time in`/lib/mailman_utils.py`. I don't understand why? Can
> cmdparser.py not use the `MailmanUtils.connect()` method?
>
>

cmdparser.py takes the login credentials from the command line, and not
the config.ini. config.ini, as of now, is just for the testing stuff.



Here :/src/mailmanclient/cli/core/domains.py#L32 docstrings should be
> immediately after the `def` line, there should not be a empty-line in
> between them.
>
> Here: /src/mailmanclient/cli/core/users.py#L41 you can use upto 80chars
> in docstrings too before introducing a line break.


>
Also if you are following the convention of specifying the parameter of
> a function in docstring, add a `:type param: foo` for each parameter
> too. It helps sphinx in generating better documentation.
> See this:
>   https://pythonhosted.org/an_example_pypi_project/sphinx.html




Fine.Will fix with the next revision.




> Everything else looks nice.
>
>

Thank you!

From aurelien at bompard.org  Mon Jun  2 11:26:22 2014
From: aurelien at bompard.org (Aurelien Bompard)
Date: Mon, 2 Jun 2014 11:26:22 +0200
Subject: [Mailman-Developers] Moderating subscriptions
Message-ID: <CAHmoxtWfSSt9wwbSK703w3=ce4FRQsUok4kJdQGRSomCApw7dg@mail.gmail.com>

Hey y'all,

In Mailman 3, I'm trying to create a list that would require its
moderators to approve subscriptions. In the Mailman doc, this is
commonly referred to as a "closed" list. However, I can't find a way
to create such a list, nor the database field which would mark it as
such.
I've also seen the hold_subscription() function in app.moderator which
seems to handle subscriptions that require moderation, but this
function does not seem to be used anywhere.
It feels like I'm missing a piece of the puzzle here, could somebody
point me to it?
Thanks!

Aur?lien

From barry at list.org  Mon Jun  2 15:12:20 2014
From: barry at list.org (Barry Warsaw)
Date: Mon, 2 Jun 2014 09:12:20 -0400
Subject: [Mailman-Developers] [CLI Project] Introduced Unit tests to CLI
In-Reply-To: <CAPq4ZOJB_jahQWhHamJm=Z-Q0fmAru_pPieBC9XDJnGoLWyUxA@mail.gmail.com>
References: <538B3F91.9070902@gmail.com> <20140602115300.12ef08a2@angel>
 <CAPq4ZOJB_jahQWhHamJm=Z-Q0fmAru_pPieBC9XDJnGoLWyUxA@mail.gmail.com>
Message-ID: <20140602091220.1597fe40@limelight.wooz.org>

On Jun 02, 2014, at 12:56 PM, Rajeev S wrote:

>I was in an idea to follow "the one class per file" style, especially when
>the classes tend to grow large in size as in the tests.(It was mentioned in
>the Barry's style guide, and so is a common coding guideline.)
>
>Should I change that?

I intend to relax this constraint, whenever I get back to updating the style
guide.  In the meantime, don't consider the one-class-per-module a hard and
fast rule, especially for test modules.  Use your best judgment and when in
doubt, defer to readability, navigation, and discoverability.

Cheers,
-Barry

From superuser at gmail.com  Tue Jun  3 00:43:31 2014
From: superuser at gmail.com (Murray S. Kucherawy)
Date: Mon, 2 Jun 2014 15:43:31 -0700
Subject: [Mailman-Developers] Thinking about list footers
In-Reply-To: <87tx865gol.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CAL0qLwa-6+5KbGtNuH768k7=J1WTfmtY=hZBOyp0RQOe85YqXA@mail.gmail.com>
 <87tx865gol.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <CAL0qLwYS6GteRDb1N3cLNEu7Xcnvp16XLK6F-Jf2CoFpwXQisQ@mail.gmail.com>

On Sat, May 31, 2014 at 4:30 AM, Stephen J. Turnbull <stephen at xemacs.org>
wrote:

> Also, the last time partial signatures came up, it was pointed out
> that there are *no* MUAs that differentiate between signed parts and
> unsigned parts.  You don't get a warning when your eyes move from a
> signed part to an unsigned part or vice-versa the way you do when
> following a link from an HTTP URL to an HTTPS URL in a browser.  The
> DKIM advocates have not liked the idea of signatures that don't apply
> to the whole message at all.
>

All true, but that's mostly specific to MUAs.  There's nothing saying a
filter of some kind could do something special with appended content when
it senses a message that's bigger than what was signed.  The library in
OpenDKIM does make it easy to spot these, for example, and can tell you
stuff like which header fields were added or modified and in what way, or
how much of the content was signed and how much wasn't.

We didn't intend for this to be used by MUAs, however, so to some degree
they're doing what we expected.

The reason I asked is that there's a proposal for a DKIM canonicalization
that could survive modifications if the modifications are entirely in new
MIME parts.  Thus, if an MLM altered the message strictly by adding parts,
the added parts could be easily isolated by this method, and the remainder
verified against an author signature that should still validate (modulo
Subject field changes).  So you'd have a DKIM signature from the author
domain that validates on the original author content (the final content
minus the added part), and a DKIM signature from the list domain that
validates on the modified content.  I'm trying to figure out if that would
be useful at all, but it sounds like MUAs are the showstopper there.

-MSK

From stephen at xemacs.org  Wed Jun  4 10:23:14 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 04 Jun 2014 17:23:14 +0900
Subject: [Mailman-Developers] Thinking about list footers
In-Reply-To: <CAL0qLwYS6GteRDb1N3cLNEu7Xcnvp16XLK6F-Jf2CoFpwXQisQ@mail.gmail.com>
References: <CAL0qLwa-6+5KbGtNuH768k7=J1WTfmtY=hZBOyp0RQOe85YqXA@mail.gmail.com>
 <87tx865gol.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAL0qLwYS6GteRDb1N3cLNEu7Xcnvp16XLK6F-Jf2CoFpwXQisQ@mail.gmail.com>
Message-ID: <87iooh3wy5.fsf@uwakimon.sk.tsukuba.ac.jp>

Murray S. Kucherawy writes:

 > We didn't intend for this to be used by MUAs, however, so to some degree
 > they're doing what we expected.

I know, but I think it's time for the IETF to recognize that email
fraud cannot be fought if the receiving end of "end-to-end" doesn't go
all the way through the eyeballs, optic nerve, and into the wetware.
(Maybe we need an April 1 RFC for neural transport of IP packets
first?)

 > I'm trying to figure out if that would be useful at all, but it
 > sounds like MUAs are the showstopper there.

I sure don't want to give up!  Some huge fraction of users must use
GMail, Yahoo! mail, AOL, Hotmail, or Outlook for their MUAs.  And that
should cover the vast majority of "Most Likely to Fall for a Phishing
Attack" users.  Not that "vast majority" is anything to write home to
mother about, but it's a very good start.  With Comcast and a couple
of others taking potshots at Yahoo!, I'd think the big ESPs are
probably ready to take MUA improvement seriously.  (Starting with
protecting addressbooks, of course, but HCI stuff too I hope.)

Where is Dave Hayes when we so desperately need his AI newsreader?

Steve


From Richard at Damon-Family.org  Wed Jun  4 14:11:52 2014
From: Richard at Damon-Family.org (Richard Damon)
Date: Wed, 04 Jun 2014 08:11:52 -0400
Subject: [Mailman-Developers] Thinking about list footers
In-Reply-To: <87iooh3wy5.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CAL0qLwa-6+5KbGtNuH768k7=J1WTfmtY=hZBOyp0RQOe85YqXA@mail.gmail.com>
 <87tx865gol.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAL0qLwYS6GteRDb1N3cLNEu7Xcnvp16XLK6F-Jf2CoFpwXQisQ@mail.gmail.com>
 <87iooh3wy5.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <538F0D08.7090308@Damon-Family.org>

On 6/4/14, 4:23 AM, Stephen J. Turnbull wrote:
> Murray S. Kucherawy writes:
>
>  > We didn't intend for this to be used by MUAs, however, so to some degree
>  > they're doing what we expected.
>
> I know, but I think it's time for the IETF to recognize that email
> fraud cannot be fought if the receiving end of "end-to-end" doesn't go
> all the way through the eyeballs, optic nerve, and into the wetware.
> (Maybe we need an April 1 RFC for neural transport of IP packets
> first?)
Yes, the only way to truly fight phish is to at least somewhat
standardize parts of how a MUA displays some stuff to the user.

There are some domains (like banks but NOT Yahoo and AOL) whose email is
important to verify identity of sender, who should have some form of
certificate that shows they have been verified by a trusted 3rd party
(like Https certs). The 3rd party verification keeps phishers from using
minor misspellings to fake these domains.

For other domains, perhaps an SPF like method on a per mailbox basis
(this could be used by Yahoo and the like). A person joins a mailing
list, the list send a request to a mailbox indicated to get added as an
authorized sender, (which then somehow verifies with the user). Receiver
gets an email from an unspecified source, mark it as suspicious or block
it totally. This would impact programs like mailman, as if the user
domain uses such a protection, another step needs to be added to the
subscription process to get the user authorized to send to the list.

This should pretty much get rid of most phish type messages, except
those sent by a user compromised machine, and that is something that the
email standards really can't help with (how can you expect an email
standard to distinguish between email from a program on my machine that
I told it to send, and email from possibly the same program that some
attacking program told it to send.)
>
>  > I'm trying to figure out if that would be useful at all, but it
>  > sounds like MUAs are the showstopper there.
>
> I sure don't want to give up!  Some huge fraction of users must use
> GMail, Yahoo! mail, AOL, Hotmail, or Outlook for their MUAs.  And that
> should cover the vast majority of "Most Likely to Fall for a Phishing
> Attack" users.  Not that "vast majority" is anything to write home to
> mother about, but it's a very good start.  With Comcast and a couple
> of others taking potshots at Yahoo!, I'd think the big ESPs are
> probably ready to take MUA improvement seriously.  (Starting with
> protecting addressbooks, of course, but HCI stuff too I hope.)
>
> Where is Dave Hayes when we so desperately need his AI newsreader?
>
> Steve
>


-- 
Richard Damon


From stephen at xemacs.org  Wed Jun  4 17:39:14 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 05 Jun 2014 00:39:14 +0900
Subject: [Mailman-Developers] Thinking about list footers
In-Reply-To: <538F0D08.7090308@Damon-Family.org>
References: <CAL0qLwa-6+5KbGtNuH768k7=J1WTfmtY=hZBOyp0RQOe85YqXA@mail.gmail.com>
 <87tx865gol.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAL0qLwYS6GteRDb1N3cLNEu7Xcnvp16XLK6F-Jf2CoFpwXQisQ@mail.gmail.com>
 <87iooh3wy5.fsf@uwakimon.sk.tsukuba.ac.jp>
 <538F0D08.7090308@Damon-Family.org>
Message-ID: <871tv44rbx.fsf@uwakimon.sk.tsukuba.ac.jp>

Richard Damon writes:

 > There are some domains (like banks but NOT Yahoo and AOL) whose email is
 > important to verify identity of sender, who should have some form of
 > certificate that shows they have been verified by a trusted 3rd party
 > (like Https certs). The 3rd party verification keeps phishers from using
 > minor misspellings to fake these domains.

This is what some banks do, already (poor man's version).  They send
you mail, you click on a link that takes you to the bank's secure site
which authenticates itself to you (usually via some secret you have
chosen for your account, as well as verifying the site via X.500
certificate over HTTPS).  Having confirmed it is your bank's site, you
log in.

 > For other domains, perhaps an SPF like method on a per mailbox basis
 > (this could be used by Yahoo and the like). A person joins a mailing
 > list, the list send a request to a mailbox indicated to get added as an
 > authorized sender, (which then somehow verifies with the user). Receiver
 > gets an email from an unspecified source, mark it as suspicious or block
 > it totally. This would impact programs like mailman, as if the user
 > domain uses such a protection, another step needs to be added to the
 > subscription process to get the user authorized to send to the
 > list.

If I understand you correctly, we actually already have the mechanics
for this in place.  Most sites like Yahoo! allow you to whitelist a
sender.  This could be extended to allow whitelisting based on the RFC
2369 List-Post field (simple to implement but requires subscriber
action if the List-Post address changes) or the RFC 2919 List-Id field
(complicated because it doesn't correspond directly to any domain,
you'd need some kind of DNS support which would be a bad idea to
special case lists).

Then just DKIM sign, and have the destination check for List-Post (not
from) identity alignment.  Not as much trouble as you suggest.

Murray, is there something here?


From Richard at Damon-Family.org  Thu Jun  5 13:10:31 2014
From: Richard at Damon-Family.org (Richard Damon)
Date: Thu, 05 Jun 2014 07:10:31 -0400
Subject: [Mailman-Developers] Thinking about list footers
In-Reply-To: <871tv44rbx.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CAL0qLwa-6+5KbGtNuH768k7=J1WTfmtY=hZBOyp0RQOe85YqXA@mail.gmail.com>	<87tx865gol.fsf@uwakimon.sk.tsukuba.ac.jp>	<CAL0qLwYS6GteRDb1N3cLNEu7Xcnvp16XLK6F-Jf2CoFpwXQisQ@mail.gmail.com>	<87iooh3wy5.fsf@uwakimon.sk.tsukuba.ac.jp>	<538F0D08.7090308@Damon-Family.org>
 <871tv44rbx.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <53905027.2030503@Damon-Family.org>

On 6/4/14, 11:39 AM, Stephen J. Turnbull wrote:
> Richard Damon writes:
>
>  > There are some domains (like banks but NOT Yahoo and AOL) whose email is
>  > important to verify identity of sender, who should have some form of
>  > certificate that shows they have been verified by a trusted 3rd party
>  > (like Https certs). The 3rd party verification keeps phishers from using
>  > minor misspellings to fake these domains.
>
> This is what some banks do, already (poor man's version).  They send
> you mail, you click on a link that takes you to the bank's secure site
> which authenticates itself to you (usually via some secret you have
> chosen for your account, as well as verifying the site via X.500
> certificate over HTTPS).  Having confirmed it is your bank's site, you
> log in.
Hopefully most don't put a real link, but just instructions to go to the
web site (with maybe the domain which is the name of the bank). Training
people to click on links here is EXACTLY the wrong thing to do here,
that is the foothold that the phisher wants. The key to this proposal is
that something shows in an obvious manner in the mail client to say that
this email has a verified sender. If the certificates have some cost,
and  the issuers are held accountable for having verifiable id of the
sender before issuing the certificate, you remove the a lot of the
things that allow phish to work.
>
>  > For other domains, perhaps an SPF like method on a per mailbox basis
>  > (this could be used by Yahoo and the like). A person joins a mailing
>  > list, the list send a request to a mailbox indicated to get added as an
>  > authorized sender, (which then somehow verifies with the user). Receiver
>  > gets an email from an unspecified source, mark it as suspicious or block
>  > it totally. This would impact programs like mailman, as if the user
>  > domain uses such a protection, another step needs to be added to the
>  > subscription process to get the user authorized to send to the
>  > list.
>
> If I understand you correctly, we actually already have the mechanics
> for this in place.  Most sites like Yahoo! allow you to whitelist a
> sender.  This could be extended to allow whitelisting based on the RFC
> 2369 List-Post field (simple to implement but requires subscriber
> action if the List-Post address changes) or the RFC 2919 List-Id field
> (complicated because it doesn't correspond directly to any domain,
> you'd need some kind of DNS support which would be a bad idea to
> special case lists).
>
> Then just DKIM sign, and have the destination check for List-Post (not
> from) identity alignment.  Not as much trouble as you suggest.
>
> Murray, is there something here?
>
This isn't anything like a whitelist, but more like SPF, but for the
email address, not the whole domain (and keyed to the From instead of
the Sender). This way Yahoo could setup a default setting of just being
able to come from yahoo servers, but when a user signs up for a mailing
list, THAT address (and just that addresses) adds as an authorized
sending domain, the domain for the mailing list. The receiving mail
system can then check that the email came from a valid source, still
allowing the blocking of much of the forged email that is floating
around. The one problem with this is that is does provide a way a
spammer could possibly verify that at least some email addresses are
valid targets (having non-default SPF records), but maybe that could
also be used to setup honeypots.

-- 
Richard Damon


From rajeevs1992 at gmail.com  Fri Jun  6 12:24:03 2014
From: rajeevs1992 at gmail.com (Rajeev S)
Date: Fri, 6 Jun 2014 15:54:03 +0530
Subject: [Mailman-Developers] [Mailman CLI Project] Subscription and
	Membership related Actions
Message-ID: <CAPq4ZOKUFWvpkaftyGi94nt5agZhNWuREEgcEyNs-7dMdScc6A@mail.gmail.com>

Hi,

 The next set of tasks for the coming weeks, before the mid term
evaluation, are mostly subscription and membership related actions for the
CLI.


 The various actions that are to be implemented are



   1.

   Show members of a list

 The `list members of a list` feature is currently available as a part of
the users module, that takes list name as an argument.


  show user ?list list at domain.org


   This does not print the names of the list owners and moderators who are
not members of the list by default. They can be added to the list by
appending the `list.owners` and `list.moderators` to the member list. Is
there a necessity of a new command under the `list` scope that does the
same function?


 show-members list list at domain.org



   1.

   Subscribe/Unsubscribe users from a list

 The commands suitably belongs to the user scope


 subscribe user foo at bar.com ?list list at domain.org

unsubscribe user foo at bar.com ?list list at domain.org


   1.

   Add/remove owners/moderators

 These commands come under the list scope


 add-owner list list at domain.org ?user a at b.com

remove-owner list list at domain.org ?user a at b.com


 add-moderator list list at domain.org ?user a at b.com

remove-moderator list list at domain.org ?user a at b. <a at b.com>com


 and a pair of commands to list the owners and moderators


 show-moderators list list at domain.org

show-owners list list at domain.org



   1.

   Edit/Set list settings

 List preferences can be set or modified using


 edit list list at domain.org ?key KEY ?value VALUE



   1.

   Setting membership preferences

 set preference ?key KEY ?value VALUE

Discussions on placing a `domain` attribute to this command have been done,
but I doubt whether a decision was made. I list below a possible usage


 set preference ?key KEY --value VALUE [--global/--user USER /--address
ADDRESS]



   1.

   Describe instance

 Describe instance can be used to display the details of an instance, like
settings and preferences. This can be achieved by extending the `show`
command of each instance, by passing a key to the specific instance, like


 show list list at domain.org

show user foo at bar.com

show domain domain.org

 The details available for the object `user`

addresses

created_on

display_name

preferences

self_link

subscribed lists, with role

user id


 Details available for domain

base_url

contact_address

description

show lists

mail_host

url_host


 Details available for object list


 list_id

list_name

mail host

members

moderators

owners

pending requests

settings


 The above details can be displayed in groups, with appropriate group
headings.


 BTW,I have pushed the r57 that adds the unit tests for the `lists`. The
unit tests for the `users` will be a part of the next revision, r58. Apart
from that, I would like to add the `describe instance`,
`subscribe/unsubscribe' features for the r58.

From raj.abhilash1 at gmail.com  Fri Jun  6 13:49:56 2014
From: raj.abhilash1 at gmail.com (Abhilash Raj)
Date: Fri, 6 Jun 2014 17:19:56 +0530
Subject: [Mailman-Developers] [Mailman CLI Project] Subscription and
 Membership related Actions
In-Reply-To: <CAPq4ZOKUFWvpkaftyGi94nt5agZhNWuREEgcEyNs-7dMdScc6A@mail.gmail.com>
References: <CAPq4ZOKUFWvpkaftyGi94nt5agZhNWuREEgcEyNs-7dMdScc6A@mail.gmail.com>
Message-ID: <20140606171956.59636c83@angel>

Hi Rajeev,
On Fri, 6 Jun 2014 15:54:03 +0530
Rajeev S <rajeevs1992 at gmail.com> wrote:
>  The `list members of a list` feature is currently available as a part of
> the users module, that takes list name as an argument.
> 
> 
>   show user ?list list at domain.org
> 
> 
>    This does not print the names of the list owners and moderators who are
> not members of the list by default. They can be added to the list by
> appending the `list.owners` and `list.moderators` to the member list. Is
> there a necessity of a new command under the `list` scope that does the
> same function?
> 
> 
>  show-members list list at domain.org

I think it would be more intuitive to have this command in list scope
rather than user scope. And anyway list scope must have a command to
list all subscribers.

>    1.
> 
>    Subscribe/Unsubscribe users from a list
> 
>  The commands suitably belongs to the user scope
> 
> 
>  subscribe user foo at bar.com ?list list at domain.org
> 
> unsubscribe user foo at bar.com ?list list at domain.org

Could it be used somehow to subscribe or unsubscribe more than one
user? If it was like 

`subscribe list list at domain.org --user/users user1/user1,user2,user3`.

Or maybe some other way to do it in user scope itself?

-- 
thanks,
Abhilash Raj

From rajeevs1992 at gmail.com  Mon Jun  9 08:32:53 2014
From: rajeevs1992 at gmail.com (Rajeev S)
Date: Mon, 9 Jun 2014 12:02:53 +0530
Subject: [Mailman-Developers] [Mailman CLI Project] Subscription and
 Membership related Actions
In-Reply-To: <20140606171956.59636c83@angel>
References: <CAPq4ZOKUFWvpkaftyGi94nt5agZhNWuREEgcEyNs-7dMdScc6A@mail.gmail.com>
 <20140606171956.59636c83@angel>
Message-ID: <CAPq4ZOJfZB8yOS03FN7ZCa+ktHLHf7QBKSiA0Jy0Nmms=3h_zA@mail.gmail.com>

On Fri, Jun 6, 2014 at 5:19 PM, Abhilash Raj <raj.abhilash1 at gmail.com>
wrote:

>
>
> I think it would be more intuitive to have this command in list scope
> rather than user scope. And anyway list scope must have a command to
> list all subscribers.
>
>
> Could it be used somehow to subscribe or unsubscribe more than one
> user? If it was like
>
> `subscribe list list at domain.org --user/users user1/user1,user2,user3`.
>
> Or maybe some other way to do it in user scope itself?
>
>

This is always possible

subscribe users user1 at foo.com user2 at bar.com user3 at bar.com --list
list at domain.org

From superuser at gmail.com  Mon Jun  9 20:08:36 2014
From: superuser at gmail.com (Murray S. Kucherawy)
Date: Mon, 9 Jun 2014 11:08:36 -0700
Subject: [Mailman-Developers] Thinking about list footers
In-Reply-To: <871tv44rbx.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CAL0qLwa-6+5KbGtNuH768k7=J1WTfmtY=hZBOyp0RQOe85YqXA@mail.gmail.com>
 <87tx865gol.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAL0qLwYS6GteRDb1N3cLNEu7Xcnvp16XLK6F-Jf2CoFpwXQisQ@mail.gmail.com>
 <87iooh3wy5.fsf@uwakimon.sk.tsukuba.ac.jp>
 <538F0D08.7090308@Damon-Family.org>
 <871tv44rbx.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <CAL0qLwaUUZ0tz=RF6X0GgRrhS_ib1yNF=qHDZO=+jSdd2-70Ww@mail.gmail.com>

On Wed, Jun 4, 2014 at 8:39 AM, Stephen J. Turnbull <stephen at xemacs.org>
wrote:

> If I understand you correctly, we actually already have the mechanics
> for this in place.  Most sites like Yahoo! allow you to whitelist a
> sender.  This could be extended to allow whitelisting based on the RFC
> 2369 List-Post field (simple to implement but requires subscriber
> action if the List-Post address changes) or the RFC 2919 List-Id field
> (complicated because it doesn't correspond directly to any domain,
> you'd need some kind of DNS support which would be a bad idea to
> special case lists).
>
> Then just DKIM sign, and have the destination check for List-Post (not
> from) identity alignment.  Not as much trouble as you suggest.
>
> Murray, is there something here?
>

Unless I'm missing something (which is likely given how little caffeine has
hit my system so far this morning), this reduces to whitelisting the DKIM
signing domain which in this case would be the list operator's domain,
correct?

If that's the case, you still have the scaling problem of populating the
whitelist.  How would Yahoo! go about doing that, for example?  They claim
at least 30,000 such cases that ideally would land in that list
automatically somehow.

-MSK

From stephen at xemacs.org  Tue Jun 10 04:55:34 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 10 Jun 2014 11:55:34 +0900
Subject: [Mailman-Developers] Thinking about list footers
In-Reply-To: <CAL0qLwaUUZ0tz=RF6X0GgRrhS_ib1yNF=qHDZO=+jSdd2-70Ww@mail.gmail.com>
References: <CAL0qLwa-6+5KbGtNuH768k7=J1WTfmtY=hZBOyp0RQOe85YqXA@mail.gmail.com>
 <87tx865gol.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAL0qLwYS6GteRDb1N3cLNEu7Xcnvp16XLK6F-Jf2CoFpwXQisQ@mail.gmail.com>
 <87iooh3wy5.fsf@uwakimon.sk.tsukuba.ac.jp>
 <538F0D08.7090308@Damon-Family.org>
 <871tv44rbx.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAL0qLwaUUZ0tz=RF6X0GgRrhS_ib1yNF=qHDZO=+jSdd2-70Ww@mail.gmail.com>
Message-ID: <87k38ppj6h.fsf@uwakimon.sk.tsukuba.ac.jp>

Murray S. Kucherawy writes:
 > On Wed, Jun 4, 2014 at 8:39 AM, Stephen J. Turnbull <stephen at xemacs.org>
 > wrote:
 > 
 > > If I understand you correctly, we actually already have the mechanics
 > > for this in place.  Most sites like Yahoo! allow you to whitelist a
 > > sender.

"You" here is the individual Yahoo! user.  The whitelists are per-user.
 
 > If that's the case, you still have the scaling problem of populating the
 > whitelist.  How would Yahoo! go about doing that, for example?  They claim
 > at least 30,000 such cases that ideally would land in that list
 > automatically somehow.

It's not "the" whitelist, it's all the users' personal whitelists.

I don't know if Yahoo! offers such whitelist capability, or if they
simply use some heuristic based on the users' contact list, or what.

From visser at terena.org  Tue Jun 10 16:56:32 2014
From: visser at terena.org (Dick Visser)
Date: Tue, 10 Jun 2014 16:56:32 +0200
Subject: [Mailman-Developers] Users in MM3
Message-ID: <CAEQQDN=82t0YDVDJfsdTDMgz7d5jxdnf=i7wQ9BFJp0CEB8MXA@mail.gmail.com>

Hi

I'm looking for a new mailing list manager, and one of the
requirements is that it has a web interface, and that it can use SAML
authentication.
Looking at MM3, I see that there are several options for running the
web interface, one of them is Apache & mod_proxy.
We already have had positive experiences with mod_mellon (which adds
SAML authentication), and another web application (Atlassian
Confluence), which sounds like a similar set-up, so I think this could
be made to work with MM3 as well.
The only issue I'm having is that our current IDM system is build
around the concept of identifying users by ID, in our case an integer.
My Python knowledge is pretty basic, but from
src/mailman/model/user.py it looks like MM3 users are also identified
by an id.
That would be great, because then Apache with mod_mellon could
authenticate a user and populate HTTP headers with the user id, and
then MM3 could pick that up.

Am I assuming the right things?

PS, I'm asking because I've looked at another mailing list manager as
well, but that seemed to using the e-mail address as the user
identifier, which rendered it useless for us...

Thanks!!!



-- 
Dick Visser
System & Networking Engineer
TERENA Secretariat
Singel 468 D, 1017 AW Amsterdam
The Netherlands

From rajeevs1992 at gmail.com  Wed Jun 11 07:37:55 2014
From: rajeevs1992 at gmail.com (Rajeev S)
Date: Wed, 11 Jun 2014 11:07:55 +0530
Subject: [Mailman-Developers] [Mailman CLI Project] Subscription and
 Membership related Actions
In-Reply-To: <CAPq4ZOJfZB8yOS03FN7ZCa+ktHLHf7QBKSiA0Jy0Nmms=3h_zA@mail.gmail.com>
References: <CAPq4ZOKUFWvpkaftyGi94nt5agZhNWuREEgcEyNs-7dMdScc6A@mail.gmail.com>
 <20140606171956.59636c83@angel>
 <CAPq4ZOJfZB8yOS03FN7ZCa+ktHLHf7QBKSiA0Jy0Nmms=3h_zA@mail.gmail.com>
Message-ID: <CAPq4ZOKF_J9jhsZbGJ_crdZe_bKnc+pznb+44GAkw2M3mE_MCA@mail.gmail.com>

>
>
> This is always possible
>
> subscribe users user1 at foo.com user2 at bar.com user3 at bar.com --list
> list at domain.org
>
>

Hi,

I have built to features, subscribe and unsubscribe users, as described
above

*subscribe users user1 at foo.com user2 at bar.com user3 at bar.com --list
list at domain.org*

and

*unsubscribe users user1 at foo.com user2 at bar.com user3 at bar.com --list
list at domain.org*


The command prints a success message on successful completion of action
else prints an error
message and continues execution. These feedback messages can be suppressed
by using a
`--quiet` switch.

subscribe users user1 at foo.com user2 at bar.com user3 at bar.com --list
list at domain.org
user1 at foo.com subscribed to list at domain.org
user2 at foo.com subscribed to list at domain.org
user3 at foo.com subscribed to list at domain.org

The commands accept one or more user emails as arguments.

From johnl at taugh.com  Thu Jun 12 16:18:24 2014
From: johnl at taugh.com (John Levine)
Date: 12 Jun 2014 14:18:24 -0000
Subject: [Mailman-Developers] Two more DMARC mitigations
Message-ID: <20140612141824.5730.qmail@joyce.lan>

* Forwarding signature

The IETF DMARC list is discussing a mutant weak DKIM signature from a
sending system (e.g. Yahoo and AOL) that would survive forwarding, but
contains a list of forwarding target domains.  It's only considered
valid if it's with a signature from the forwarding domain, i.e., the
list.

This is nice for list operators, since it requires nothing beyond
not stripping the signature header, and signing on the way out.

* Submit and sign

When a user at a p=reject signs up for a list, you demand an OAUTH API
token if the the provider supports it, otherwise their host system
password.  You can check it on the spot and skip the challenge email
to confirm opt-in.

When the user sends mail to the list, the list makes whatever changes
it's going to make (subject tag, footers, whatever) and then uses the
API or SUBMIT to resend it through the host system.  When it arrives
back at the list, it has the host system's DKIM signature and the list
can resend it to the subscribers with the valid signature.

It also has to checks DMARC on incoming messages, and if the policy
has changed, holds onto the message and send a notice saying go back
to the web site and give us your credentials to stay on the list.

This is less nice, it's a lot of software development.  Collecting
credentials gives the mail operators heartburn, but as I told them at
a meeting today, if you want all mail to be authenticated, that's what
you asked for.

There is definite interest at large mail providers at least for the
first one.  Dunno if they're interested in the second, but since it
uses features they already have, it matters less.

R's,
John

From jimpop at gmail.com  Thu Jun 12 20:25:06 2014
From: jimpop at gmail.com (Jim Popovitch)
Date: Thu, 12 Jun 2014 14:25:06 -0400
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <20140612141824.5730.qmail@joyce.lan>
References: <20140612141824.5730.qmail@joyce.lan>
Message-ID: <CAGfsgR0vr_DZKjVJYuPUADrR47OYWqJjP+Wpom7mQAuj7HNfQg@mail.gmail.com>

On Thu, Jun 12, 2014 at 10:18 AM, John Levine <johnl at taugh.com> wrote:

> * Forwarding signature
>

It seems to me that a non-DMARC subdomain, for users, would be easier and
better for all..



> * Submit and sign
>

Oh god, NO!



-Jim P.

From stephen at xemacs.org  Thu Jun 12 23:42:08 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 13 Jun 2014 06:42:08 +0900
Subject: [Mailman-Developers]  Two more DMARC mitigations
In-Reply-To: <20140612141824.5730.qmail@joyce.lan>
References: <20140612141824.5730.qmail@joyce.lan>
Message-ID: <874mzppzyn.fsf@uwakimon.sk.tsukuba.ac.jp>

John Levine writes:

 > * Forwarding signature

Thanks, I was about to write something like this!

 > * Submit and sign
 > 
 > When a user at a p=reject signs up for a list, you demand an OAUTH API
 > token if the the provider supports it, otherwise their host system
 > password.

-1 on the password thing.  It's too close to phishing, imposes serious
privacy issues on Mailman hosts, and makes them targets for attack.
This is too dangerous to be even an optional feature.  Third party
patches are OK, of course, but stock Mailman shouldn't do this.

I'm fine with annoying the hell out of Yahoo! and AOL users with an
OAuth request on every post.

 > This is less nice, it's a lot of software development.

I don't think prototyping this is all that hard.  We already have
logic for checking DMARC thanks to dmarc_moderation_action.  We just
add the OAuth check to that, and if it fails, proceed to
dmarc_moderation_action.


From stephen at xemacs.org  Fri Jun 13 00:02:09 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 13 Jun 2014 07:02:09 +0900
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <CAGfsgR0vr_DZKjVJYuPUADrR47OYWqJjP+Wpom7mQAuj7HNfQg@mail.gmail.com>
References: <20140612141824.5730.qmail@joyce.lan>
 <CAGfsgR0vr_DZKjVJYuPUADrR47OYWqJjP+Wpom7mQAuj7HNfQg@mail.gmail.com>
Message-ID: <8738f9pz1a.fsf@uwakimon.sk.tsukuba.ac.jp>

Jim Popovitch writes:
 > On Thu, Jun 12, 2014 at 10:18 AM, John Levine <johnl at taugh.com> wrote:
 > 
 > > * Forwarding signature
 > 
 > It seems to me that a non-DMARC subdomain, for users, would be easier and
 > better for all..

No, the mailbox providers already can do that and it's not because
they were caught with their shorts down that they didn't.  They really
really mean "p=reject" for users.  A senior admin at Yahoo! was very
clear on damrc at ietf that they want their vanilla users covered by
"p=reject" because the threat model (which is not phishing, it's
"recommended by friend" spam) involves user mailboxes.

She also said that (as of a week ago) the attack based on stolen
contact lists was continuing to flood their incoming MXes, despite
over a month of "p=reject" (contrary to AOL's claims that "p=reject"
stopped the attack).  No explanation has been given why the spammers
are continuing to spend their resources on the attack.

 > > * Submit and sign
 > >
 > 
 > Oh god, NO!

Oh, c'mon, Jim.  This is just the evil kind of thing we *want* to do
to AOL!


From johnl at taugh.com  Fri Jun 13 00:11:43 2014
From: johnl at taugh.com (John R Levine)
Date: 13 Jun 2014 00:11:43 +0200
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <874mzppzyn.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <20140612141824.5730.qmail@joyce.lan>
 <874mzppzyn.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <alpine.BSF.2.00.1406130008460.8152@joyce.lan>

> > When a user at a p=reject signs up for a list, you demand an OAUTH API
> > token if the the provider supports it, otherwise their host system
> > password.
>
> -1 on the password thing.  It's too close to phishing, imposes serious
> privacy issues on Mailman hosts, and makes them targets for attack.

Honestly, Tough Noogies.  Let list managers make their own security 
decisions.  AOL and Yahoo want all mail from their users to be 
authenticated.  Well, OK, this will do it.

> I'm fine with annoying the hell out of Yahoo! and AOL users with an
> OAuth request on every post.

My Yahoo contact tells me they eventually plan to do OAuth submission 
which should have long lived tokens.  But in the meantime, the submit hack 
should work everywhere.

Regards,
John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

From jimpop at gmail.com  Fri Jun 13 00:22:13 2014
From: jimpop at gmail.com (Jim Popovitch)
Date: Thu, 12 Jun 2014 18:22:13 -0400
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <8738f9pz1a.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <20140612141824.5730.qmail@joyce.lan>
 <CAGfsgR0vr_DZKjVJYuPUADrR47OYWqJjP+Wpom7mQAuj7HNfQg@mail.gmail.com>
 <8738f9pz1a.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <CAGfsgR0BR9CAkWgPKLp5yFLs0q=2RwS7uSrOaBX0fYbXnF3o0w@mail.gmail.com>

On Thu, Jun 12, 2014 at 6:02 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
>
>  A senior admin at Yahoo! was very clear on damrc at ietf that they want
> their vanilla users covered by "p=reject" because the threat model
> (which is not phishing, it's "recommended by friend" spam) involves user
> mailboxes.

Yeah, I follow that.  BUT... a very senior architect of DMARC
established the DMARC spec for non-user mail and specifically
recommended that user mail be moved to a non-DMARC signed
domain/subdomain.   AND THEN, a (that very same senior admin?) Yahoo!
employee got involved in the DMARC spec and it became the bastardized
DMARC spec.   I relish in pointing this out from time to time, thank
you for the oppty to do it again.  ;-)

-Jim P.

From stephen at xemacs.org  Fri Jun 13 03:34:06 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 13 Jun 2014 10:34:06 +0900
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <8738f9pz1a.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <20140612141824.5730.qmail@joyce.lan>
 <CAGfsgR0vr_DZKjVJYuPUADrR47OYWqJjP+Wpom7mQAuj7HNfQg@mail.gmail.com>
 <8738f9pz1a.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <87oaxxoanl.fsf@uwakimon.sk.tsukuba.ac.jp>

Stephen J. Turnbull writes:

 > She also said that (as of a week ago) the attack based on stolen
 > contact lists was continuing to flood their incoming MXes,

This statement turns out to be inoperative.  Elizabeth now plausibly
denies this, claiming that she never said they were still conducting a
massive spam attack.[1]  What's happening is that the spammers are
sending a small number of probes to check whether Yahoo! (and
presumably AOL as well) retracts "p=reject".


Footnotes: 
[1]  This is true.  She said they "never stopped", without specifying
what they hadn't stopped.




From stephen at xemacs.org  Fri Jun 13 03:59:49 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 13 Jun 2014 10:59:49 +0900
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <CAGfsgR0BR9CAkWgPKLp5yFLs0q=2RwS7uSrOaBX0fYbXnF3o0w@mail.gmail.com>
References: <20140612141824.5730.qmail@joyce.lan>
 <CAGfsgR0vr_DZKjVJYuPUADrR47OYWqJjP+Wpom7mQAuj7HNfQg@mail.gmail.com>
 <8738f9pz1a.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAGfsgR0BR9CAkWgPKLp5yFLs0q=2RwS7uSrOaBX0fYbXnF3o0w@mail.gmail.com>
Message-ID: <87mwdho9gq.fsf@uwakimon.sk.tsukuba.ac.jp>

Jim Popovitch writes:

 > AND THEN, a (that very same senior admin?)

All are the same person I suppose, Elizabeth Zwicky.

 > Yahoo!  employee got involved in the DMARC spec and it became the
 > bastardized DMARC spec.

Do you have specific complaints?

I like the DMARC spec as it stands.  Yahoo! and AOL are abusing it, in
exactly the same way that spammers abuse specs like RFCs 5321 and
5322.  And with the same rationale: "because you can't stop us".

But that doesn't make it useless, any more than spammers make the
fundamental standards for email useless.  The informational parts of
the protocol are a minor privacy invasion, I guess, but produce very
useful data.  Even the policy part is useful IMO.  You just have to
interpret it properly.  "p=quarantine" == "p=we-have-a-security-
problem-so-don't-trust-unauthenticated-mail-from-our-domain", and
"p=reject" == "p=we-have-a-very-serious-security-problem-so-
unauthenticated-mail-from-our-domain-is-almost-certainly-a-scam".

So tell your Yahoo! users that their mailbox provider has a very
serious security problem, and labelled their posts as "almost certain
scams."[1] :-)

Note that "security problem" here doesn't necessarily mean "security
breached".  It can also mean "we are a prominent target", as banks and
other financial institutions are.

Footnotes: 
[1]  I wouldn't be surprised if for those users whose contact lists
were stolen 99% of the mail sent under their mailbox is from the
spammers. ;-)


From stephen at xemacs.org  Fri Jun 13 04:07:21 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 13 Jun 2014 11:07:21 +0900
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <alpine.BSF.2.00.1406130008460.8152@joyce.lan>
References: <20140612141824.5730.qmail@joyce.lan>
 <874mzppzyn.fsf@uwakimon.sk.tsukuba.ac.jp>
 <alpine.BSF.2.00.1406130008460.8152@joyce.lan>
Message-ID: <87lht1o946.fsf@uwakimon.sk.tsukuba.ac.jp>

John R Levine writes:

 > Honestly, Tough Noogies.  Let list managers make their own security 
 > decisions.

Revealing a user password is not a list security decision, it's a user
security decision.  Asking users for their passwords is evil, period.

I mentioned the impact on lists (becoming targets) as additional
reasons not to do this in Mailman.


From jimpop at gmail.com  Fri Jun 13 04:04:55 2014
From: jimpop at gmail.com (Jim Popovitch)
Date: Thu, 12 Jun 2014 22:04:55 -0400
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <87mwdho9gq.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <20140612141824.5730.qmail@joyce.lan>
 <CAGfsgR0vr_DZKjVJYuPUADrR47OYWqJjP+Wpom7mQAuj7HNfQg@mail.gmail.com>
 <8738f9pz1a.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAGfsgR0BR9CAkWgPKLp5yFLs0q=2RwS7uSrOaBX0fYbXnF3o0w@mail.gmail.com>
 <87mwdho9gq.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <CAGfsgR0q-tZiuOOHMNd8wijp5LDg7yVL1e23p8BPcbnfmJo0jw@mail.gmail.com>

On Thu, Jun 12, 2014 at 9:59 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Jim Popovitch writes:
>
>  > AND THEN, a (that very same senior admin?)
>
> All are the same person I suppose, Elizabeth Zwicky.
>
>  > Yahoo!  employee got involved in the DMARC spec and it became the
>  > bastardized DMARC spec.
>
> Do you have specific complaints?

Yes.  Unless it's not already understood... the original idea behind
DMARC centered around non-human transactional emails (Banking
notifications, Facebook status updates, etc.).   Elizabeth got
involved and the spec was morphed (i say bastardized) to become what
it is today, and how it is being used today.

-Jim P.

From jimpop at gmail.com  Fri Jun 13 04:16:03 2014
From: jimpop at gmail.com (Jim Popovitch)
Date: Thu, 12 Jun 2014 22:16:03 -0400
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <87lht1o946.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <20140612141824.5730.qmail@joyce.lan>
 <874mzppzyn.fsf@uwakimon.sk.tsukuba.ac.jp>
 <alpine.BSF.2.00.1406130008460.8152@joyce.lan>
 <87lht1o946.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <CAGfsgR3stHRvyyhVb5suw1yrOhU7TN4c9wBNVEcdJ57GknBBjw@mail.gmail.com>

On Thu, Jun 12, 2014 at 10:07 PM, Stephen J. Turnbull
<stephen at xemacs.org> wrote:
> John R Levine writes:
>
>  > Honestly, Tough Noogies.  Let list managers make their own security
>  > decisions.
>
> Revealing a user password is not a list security decision, it's a user
> security decision.  Asking users for their passwords is evil, period.

Unless I am mistaking things, the sheer irony here is that Yahoo's
bastardized version of DMARC, which is necessary to stave off
collateral damage from their past security breach(es?), needs to be
further augmented with even less user security in order to be secure.
O.o  Man that boggles the mind.

-Jim P.

From rajeevs1992 at gmail.com  Fri Jun 13 06:10:15 2014
From: rajeevs1992 at gmail.com (Rajeev S)
Date: Fri, 13 Jun 2014 09:40:15 +0530
Subject: [Mailman-Developers] [CLI Project]Developed the describe instance
	feature
Message-ID: <539A79A7.30005@gmail.com>

Hi,

I have completed the `describe instance` feature for the list object. I 
herewith attach the sample output of the command.

https://gist.github.com/rajeevs1992/3ca077fd7d1a5a1d5729

The describe feature is triggered when the `show` action is supplied a 
object name of the corresponding domain.

./mmclient show list list1 at domain.org

Further, the CLI can easily be extended to support an independent sub 
command `describe` to perform the same
action, *if necessary*.

./mmclient describe list list1 at domain.org

The describe feature is intended just for getting a snapshot of the 
object, in one shot.

I will be completing the same for rest of the objects and pushing the 
next revision by 17/06/2014,Tuesday, as I will be away
from computer this weekend.

From stephen at xemacs.org  Fri Jun 13 06:39:25 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 13 Jun 2014 13:39:25 +0900
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <CAGfsgR0q-tZiuOOHMNd8wijp5LDg7yVL1e23p8BPcbnfmJo0jw@mail.gmail.com>
References: <20140612141824.5730.qmail@joyce.lan>
 <CAGfsgR0vr_DZKjVJYuPUADrR47OYWqJjP+Wpom7mQAuj7HNfQg@mail.gmail.com>
 <8738f9pz1a.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAGfsgR0BR9CAkWgPKLp5yFLs0q=2RwS7uSrOaBX0fYbXnF3o0w@mail.gmail.com>
 <87mwdho9gq.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAGfsgR0q-tZiuOOHMNd8wijp5LDg7yVL1e23p8BPcbnfmJo0jw@mail.gmail.com>
Message-ID: <87ioo5o22q.fsf@uwakimon.sk.tsukuba.ac.jp>

Jim Popovitch writes:

 > > Do you have specific complaints?
 > 
 > Yes.  Unless it's not already understood... the original idea
 > behind DMARC centered around non-human transactional emails
 > (Banking notifications, Facebook status updates, etc.).

This was understood, and is why I call what Yahoo! and AOL are doing
"abuse".

But what is wrong with the spec itself, besides the potential for
abuse?

 > Elizabeth got involved and the spec was morphed (i say bastardized)

What changed that you object to?

I'm not just nagging, I really want to know.  I've been over the spec
a couple of times, in a fair amount of detail, and I don't see it.
But if there are specific aspects to it that are broken when used as
designed, I (and John) may have some input into getting it changed.

Murray Kucherawy (the other author of the current Internet-Draft) and
Dave Crocker (who's authored more RFCs than the average bear) seem far
more on our side than on Yahoo!'s, and there are a couple of other
people who have posted intelligent comments (and of course, the usual
complement of Net.Kooks without which no standardization effort is
complete).  Even Elizabeth seems quite reasonable, modulo her job
description.

John and I are somewhat more likely to have input into auxiliary
protocols (such as the DKIM-Delegate protocol that John mentioned)
which might make Yahoo!'s use of "p=reject" somewhat more palatable.

Steve

From stephen at xemacs.org  Fri Jun 13 06:46:17 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 13 Jun 2014 13:46:17 +0900
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <CAGfsgR3stHRvyyhVb5suw1yrOhU7TN4c9wBNVEcdJ57GknBBjw@mail.gmail.com>
References: <20140612141824.5730.qmail@joyce.lan>
 <874mzppzyn.fsf@uwakimon.sk.tsukuba.ac.jp>
 <alpine.BSF.2.00.1406130008460.8152@joyce.lan>
 <87lht1o946.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAGfsgR3stHRvyyhVb5suw1yrOhU7TN4c9wBNVEcdJ57GknBBjw@mail.gmail.com>
Message-ID: <87ha3po1ra.fsf@uwakimon.sk.tsukuba.ac.jp>

Jim Popovitch writes:

 > Unless I am mistaking things, the sheer irony here is that Yahoo's
 > bastardized version of DMARC, which is necessary to stave off
 > collateral damage from their past security breach(es?), needs to be
 > further augmented with even less user security in order to be secure.

I don't see why the OAuth version of John's proposal would be less
secure.

If you want real irony, look no farther than Yahoo! Groups' From:
header field.  Yahoo! is using DMARC to get "yahoo.com" out of the
From: field in list traffic, and Groups is putting it right back in.


From jimpop at gmail.com  Fri Jun 13 07:21:37 2014
From: jimpop at gmail.com (Jim Popovitch)
Date: Fri, 13 Jun 2014 01:21:37 -0400
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <87ioo5o22q.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <20140612141824.5730.qmail@joyce.lan>
 <CAGfsgR0vr_DZKjVJYuPUADrR47OYWqJjP+Wpom7mQAuj7HNfQg@mail.gmail.com>
 <8738f9pz1a.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAGfsgR0BR9CAkWgPKLp5yFLs0q=2RwS7uSrOaBX0fYbXnF3o0w@mail.gmail.com>
 <87mwdho9gq.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAGfsgR0q-tZiuOOHMNd8wijp5LDg7yVL1e23p8BPcbnfmJo0jw@mail.gmail.com>
 <87ioo5o22q.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <CAGfsgR0j9pzem9yO=XFcGDxLvpHV7YYzWySO00v2hj+-cUtVrQ@mail.gmail.com>

On Fri, Jun 13, 2014 at 12:39 AM, Stephen J. Turnbull
<stephen at xemacs.org> wrote:
> Jim Popovitch writes:
>
>  > > Do you have specific complaints?
>  >
>  > Yes.  Unless it's not already understood... the original idea
>  > behind DMARC centered around non-human transactional emails
>  > (Banking notifications, Facebook status updates, etc.).
>
> This was understood, and is why I call what Yahoo! and AOL are doing
> "abuse".
>
> But what is wrong with the spec itself, besides the potential for
> abuse?
>
>  > Elizabeth got involved and the spec was morphed (i say bastardized)
>
> What changed that you object to?

One of the original __High-Level Goals__ was:

   DMARC is intended to reduce the success of attackers sending mail
   pretending to be from a domain they do not control, with minimal
   changes to existing mail handling at both senders and receivers.  It
   is particularly intended to protect transactional email, as opposed
   to mail between individuals.


If you go here:
https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ you can
see the early versions of the spec (under "History") contained the
word "transactional".

Also notice that the "diff from previous" comparisons, esp between
rev02 and rev01, seems to be missing several instances of the word
"transactional" (i.e. if the word was removed it should still be
visible on the left-hand side of the diff)

-Jim P.

From stephen at xemacs.org  Fri Jun 13 09:04:07 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 13 Jun 2014 16:04:07 +0900
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <CAGfsgR0j9pzem9yO=XFcGDxLvpHV7YYzWySO00v2hj+-cUtVrQ@mail.gmail.com>
References: <20140612141824.5730.qmail@joyce.lan>
 <CAGfsgR0vr_DZKjVJYuPUADrR47OYWqJjP+Wpom7mQAuj7HNfQg@mail.gmail.com>
 <8738f9pz1a.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAGfsgR0BR9CAkWgPKLp5yFLs0q=2RwS7uSrOaBX0fYbXnF3o0w@mail.gmail.com>
 <87mwdho9gq.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAGfsgR0q-tZiuOOHMNd8wijp5LDg7yVL1e23p8BPcbnfmJo0jw@mail.gmail.com>
 <87ioo5o22q.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAGfsgR0j9pzem9yO=XFcGDxLvpHV7YYzWySO00v2hj+-cUtVrQ@mail.gmail.com>
Message-ID: <87egytnvdk.fsf@uwakimon.sk.tsukuba.ac.jp>

Jim Popovitch writes:

 > > What changed that you object to?
 > 
 > One of the original __High-Level Goals__ was:
 > 
 >    DMARC is intended to reduce the success of attackers sending
 >    mail pretending to be from a domain they do not control, with
 >    minimal changes to existing mail handling at both senders and
 >    receivers.  It is particularly intended to protect transactional
 >    email, as opposed to mail between individuals.

Actually, that word wasn't present in Murray's original -00 draft, and
was added in two places (along with a definition in terms of "business
transactions") in the -01 draft at the same time Ms Zwicky was added
as editor, in July '13.  :-P  According to Chrome's search function,
all three uses are still present in the current (April '14) draft (in
section 1.2 "Anti-Phishing" and section 2.1 "High-Level Goals" (which
contains exactly the text quoted above).

Based on what I've seen on dmarc@, the word "transactional" has
controversial connotations besides ruling out Yahoo!'s use case.  The
problem is that Yahoo!'s problem ("acquaintance-recommended spam") is
a genuine problem, and could be addressed by DMARC "p=reject" if only
Yahoo! users would stop posting to mailing lists. :-)  It's not just
business uses.

Although Elizabeth and I aren't on good terms at the moment because of
difference of opinion about Yahoo!'s behavior, I haven't seen anything
from her that would indicate that she thinks "p=reject" is a *good*
idea ... except that at the moment it's their *only* idea. :-(

Steve

From barry at list.org  Fri Jun 13 16:05:31 2014
From: barry at list.org (Barry Warsaw)
Date: Fri, 13 Jun 2014 10:05:31 -0400
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <20140612141824.5730.qmail@joyce.lan>
References: <20140612141824.5730.qmail@joyce.lan>
Message-ID: <20140613100531.28a07a2d@anarchist.wooz.org>

On Jun 12, 2014, at 02:18 PM, John Levine wrote:

>* Forwarding signature
>
>The IETF DMARC list is discussing a mutant weak DKIM signature from a
>sending system (e.g. Yahoo and AOL) that would survive forwarding, but
>contains a list of forwarding target domains.  It's only considered
>valid if it's with a signature from the forwarding domain, i.e., the
>list.
>
>This is nice for list operators, since it requires nothing beyond
>not stripping the signature header, and signing on the way out.

How does this list of forwarding target domains get specified?  Is this
something the user has to do when they're sending the message?  Do they have
to adjust this when they send a message for the first time to a new mailing
list on a new domain?

Modulo details, +1

>* Submit and sign
>
>When a user at a p=reject signs up for a list, you demand an OAUTH API
>token if the the provider supports it, otherwise their host system
>password.  You can check it on the spot and skip the challenge email
>to confirm opt-in.
>
>When the user sends mail to the list, the list makes whatever changes
>it's going to make (subject tag, footers, whatever) and then uses the
>API or SUBMIT to resend it through the host system.  When it arrives
>back at the list, it has the host system's DKIM signature and the list
>can resend it to the subscribers with the valid signature.
>
>It also has to checks DMARC on incoming messages, and if the policy
>has changed, holds onto the message and send a notice saying go back
>to the web site and give us your credentials to stay on the list.
>
>This is less nice, it's a lot of software development.

*A lot* less nice.  It means new databases to keep the mapping of posting
domains to DMARC policies, and for mapping the OAUTH token (or password!) for
every user at that site.  It means the normal message acceptance and deliery
machinery must be diverted for these special users.  I'm not even sure how
this would work with full personalization, since the final message content
might not be constructed until it's on its way to the outgoing MTA.

Let's say Alice posts from site A, which publishes p=reject.  The message is
going to be personalized and sent to Bob and Claire.  Bob's site honors
Alice's p=reject, but Claire's does not.  Full personalization is turned on,
so some bits of the final message aren't even fully stitched together until
the message is delivered to the outgoing MTA, destined for Bob.  Does that
mean Alice and Bob's message both have to be re-delivered through site A?  How
do I know that Bob is honoring site A's p=reject, and if I can't know that, do
I have to send all personalized messages through site A?  How happy is site A
going to be about that?  Also, how does site A not become the vector for
forwarding attacks?  IOW, how does site A trust that the list's modifications
to Alice's original message is worthy of resigning and sending, and not just a
message subverted to spam?

-1

-Barry

From barry at list.org  Fri Jun 13 16:21:45 2014
From: barry at list.org (Barry Warsaw)
Date: Fri, 13 Jun 2014 10:21:45 -0400
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <alpine.BSF.2.00.1406130008460.8152@joyce.lan>
References: <20140612141824.5730.qmail@joyce.lan>
 <874mzppzyn.fsf@uwakimon.sk.tsukuba.ac.jp>
 <alpine.BSF.2.00.1406130008460.8152@joyce.lan>
Message-ID: <20140613102145.72b78b0c@anarchist.wooz.org>

On Jun 13, 2014, at 12:11 AM, John R Levine wrote:

>> > When a user at a p=reject signs up for a list, you demand an OAUTH API
>> > token if the the provider supports it, otherwise their host system
>> > password.
>>
>> -1 on the password thing.  It's too close to phishing, imposes serious
>> privacy issues on Mailman hosts, and makes them targets for attack.
>
>Honestly, Tough Noogies.  Let list managers make their own security
>decisions.  AOL and Yahoo want all mail from their users to be authenticated.
>Well, OK, this will do it.

This is a really bad idea.  In MM3, we've already eliminated the need for
keeping clear text passwords, and almost gotten rid of any user passwords at
all.  OAUTH tokens are a little better, but no way do I want to hold a clear
text password for users.

-Barry

From barry at list.org  Fri Jun 13 16:24:50 2014
From: barry at list.org (Barry Warsaw)
Date: Fri, 13 Jun 2014 10:24:50 -0400
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <87ha3po1ra.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <20140612141824.5730.qmail@joyce.lan>
 <874mzppzyn.fsf@uwakimon.sk.tsukuba.ac.jp>
 <alpine.BSF.2.00.1406130008460.8152@joyce.lan>
 <87lht1o946.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAGfsgR3stHRvyyhVb5suw1yrOhU7TN4c9wBNVEcdJ57GknBBjw@mail.gmail.com>
 <87ha3po1ra.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20140613102450.1821ea09@anarchist.wooz.org>

On Jun 13, 2014, at 01:46 PM, Stephen J. Turnbull wrote:

>If you want real irony, look no farther than Yahoo! Groups' From:
>header field.  Yahoo! is using DMARC to get "yahoo.com" out of the
>From: field in list traffic, and Groups is putting it right back in.

I'm on a few Yahoo! Groups and the From munging that they're doing is really
just horrible.

-Barry

From barry at list.org  Fri Jun 13 16:26:54 2014
From: barry at list.org (Barry Warsaw)
Date: Fri, 13 Jun 2014 10:26:54 -0400
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <8738f9pz1a.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <20140612141824.5730.qmail@joyce.lan>
 <CAGfsgR0vr_DZKjVJYuPUADrR47OYWqJjP+Wpom7mQAuj7HNfQg@mail.gmail.com>
 <8738f9pz1a.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20140613102654.1b10c423@anarchist.wooz.org>

On Jun 13, 2014, at 07:02 AM, Stephen J. Turnbull wrote:

>This is just the evil kind of thing we *want* to do to AOL!

That's not the evil thing I *really* want to do.  I want to just reject all
posts from p=reject sites.  But I know we can't get away with that.

-Barry

From stf.list.mailman.dev at eisenbits.com  Fri Jun 13 09:33:25 2014
From: stf.list.mailman.dev at eisenbits.com (=?UTF-8?B?U3RhbmlzxYJhdyBGaW5kZWlzZW4=?=)
Date: Fri, 13 Jun 2014 09:33:25 +0200
Subject: [Mailman-Developers] GnuPG support
Message-ID: <539AA945.9060207@eisenbits.com>

This thread is a continuation of this one:
https://mail.python.org/pipermail/mailman-developers/2011-May/021377.html .

Hi

What is the current status of this issue? Is there going to be GnuPG
support in Mailman 3?

-- 
http://people.eisenbits.com/~stf/
http://www.eisenbits.com/

OpenPGP: 80FC 1824 2EA4 9223 A986  DB4E 934E FEA0 F492 A63B

From stephen at xemacs.org  Sat Jun 14 13:05:14 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 14 Jun 2014 20:05:14 +0900
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <20140613100531.28a07a2d@anarchist.wooz.org>
References: <20140612141824.5730.qmail@joyce.lan>
 <20140613100531.28a07a2d@anarchist.wooz.org>
Message-ID: <87a99foiol.fsf@uwakimon.sk.tsukuba.ac.jp>

Barry Warsaw writes:
 > On Jun 12, 2014, at 02:18 PM, John Levine wrote:

 > >* Forwarding signature

 > How does this list of forwarding target domains get specified?

It can be specified explicitly (to add domains that are in Bcc or to
restrict the domains allowed), but it defaults to the list of visible
addressees (To and Cc).

 > Do they have to adjust this when they send a message for the first
 > time to a new mailing list on a new domain?

No, there's nothing that needs to be done per mailing list; it's per
message.  It only needs to be done for users at "p=reject" domains.

A host or an MUA (think Gnus or VM) *could* adjust the DKIM-Delegate
header based on user request or user history (eg, the set of List-Post
headers seen in mail delivered to that user), but the default is
probably good enough in general.

 > >* Submit and sign

 > *A lot* less nice.  It means new databases to keep the mapping of posting
 > domains to DMARC policies, and for mapping the OAUTH token (or password!) for
 > every user at that site.

I don't think so.  DMARC policies are looked up for each message, and
the OAuth token will typically be one time, so users posting from
"p=reject" domains will have to reauthenticate for every post.
Long-lived tokens are possible, but I don't know if anyone implements
them.

I don't think I'd want to deal with passwords at all, and I certainly
wouldn't want to keep a database of them.  I would recommend if you're
going to use the password auth do it for every message separately and
wipe the memory as soon as you're done.

 > It means the normal message acceptance and deliery machinery must
 > be diverted for these special users.

Yes.

 > I'm not even sure how this would work with full personalization,
 > since the final message content might not be constructed until it's
 > on its way to the outgoing MTA.

It would go into a "pending authorization" (from the Author Domain
publishing "p=reject" queue).  Although you'd need a separate queue, I
don't see why this would be particularly problematic.

 > Let's say Alice posts from site A, which publishes p=reject.  The message is
 > going to be personalized and sent to Bob and Claire.  Bob's site honors
 > Alice's p=reject, but Claire's does not.

Why would one care?  You submit the message to site A for all users.

 > How do I know that Bob is honoring site A's p=reject

You can't.  Bob may be silently discarding, in which case you'll only
find out if Bob notices and reports.

 > IOW, how does site A trust that the list's modifications to Alice's
 > original message is worthy of resigning and sending, and not just a
 > message subverted to spam?

That's always site A's problem, any time they authorize their users to
post to third parties.  It's site A that published the "p=reject", and
provides OAuth(*).  But effectively it comes down to trusting their
user (who explicitly authorizes the posts).

(*) Password auth, OTOH, can be "grabbed" by the user, and for that
reason I really don't want Mailman to provide it.


From stephen at xemacs.org  Sat Jun 14 13:09:21 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 14 Jun 2014 20:09:21 +0900
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <20140613102654.1b10c423@anarchist.wooz.org>
References: <20140612141824.5730.qmail@joyce.lan>
 <CAGfsgR0vr_DZKjVJYuPUADrR47OYWqJjP+Wpom7mQAuj7HNfQg@mail.gmail.com>
 <8738f9pz1a.fsf@uwakimon.sk.tsukuba.ac.jp>
 <20140613102654.1b10c423@anarchist.wooz.org>
Message-ID: <878uozoihq.fsf@uwakimon.sk.tsukuba.ac.jp>

Barry Warsaw writes:

 > I want to just reject all posts from p=reject sites.  But I know we
 > can't get away with that.

*We* (= mailman-developers) probably can.  And Mailman 2.1.18-1
already has a facility to allow per-list decisions to do so.  I know
how you feel :-), but I think that's good enough.


From stephen at xemacs.org  Sat Jun 14 13:11:18 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 14 Jun 2014 20:11:18 +0900
Subject: [Mailman-Developers]  GnuPG support
In-Reply-To: <539AA945.9060207@eisenbits.com>
References: <539AA945.9060207@eisenbits.com>
Message-ID: <877g4joieh.fsf@uwakimon.sk.tsukuba.ac.jp>

Stanis?aw Findeisen writes:

 > What is the current status of this issue? Is there going to be GnuPG
 > support in Mailman 3?

Some work was done on it in last year's GSoC, but it's not ready for
integration yet, and I doubt it will be in the first 3.0 release.


From stf.list.mailman.dev at eisenbits.com  Sat Jun 14 14:57:59 2014
From: stf.list.mailman.dev at eisenbits.com (=?UTF-8?B?U3RhbmlzxYJhdyBGaW5kZWlzZW4=?=)
Date: Sat, 14 Jun 2014 14:57:59 +0200
Subject: [Mailman-Developers] GnuPG support
In-Reply-To: <877g4joieh.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <539AA945.9060207@eisenbits.com>
 <877g4joieh.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <539C46D7.7040701@eisenbits.com>

On 2014-06-14 13:11, Stephen J. Turnbull wrote:
> Stanis?aw Findeisen writes:
> 
>  > What is the current status of this issue? Is there going to be GnuPG
>  > support in Mailman 3?
> 
> Some work was done on it in last year's GSoC, but it's not ready for
> integration yet, and I doubt it will be in the first 3.0 release.
> 

What needs to be done? Where is the code?

-- 
http://people.eisenbits.com/~stf/
http://www.eisenbits.com/

OpenPGP: 80FC 1824 2EA4 9223 A986  DB4E 934E FEA0 F492 A63B

From sylvain at opensource-expert.com  Sat Jun 14 10:47:16 2014
From: sylvain at opensource-expert.com (Sylvain Viart)
Date: Sat, 14 Jun 2014 10:47:16 +0200
Subject: [Mailman-Developers] GnuPG support
In-Reply-To: <539AA945.9060207@eisenbits.com>
References: <539AA945.9060207@eisenbits.com>
Message-ID: <539C0C14.5000603@opensource-expert.com>

Hi,

On 13/06/2014 09:33, Stanis?aw Findeisen wrote:
> This thread is a continuation of this one:
> https://mail.python.org/pipermail/mailman-developers/2011-May/021377.html .

I found this page yesterday, as we were doing a key signing party?

http://security.stackexchange.com/questions/26544/gpg-encrypted-mailing-list-and-other-approaches-to-safe-communication

Your are speaking about "2. Do a relay.", right?

Regards,
Sylvain.

From stf.list.mailman.dev at eisenbits.com  Sat Jun 14 19:49:38 2014
From: stf.list.mailman.dev at eisenbits.com (=?UTF-8?B?U3RhbmlzxYJhdyBGaW5kZWlzZW4=?=)
Date: Sat, 14 Jun 2014 19:49:38 +0200
Subject: [Mailman-Developers] GnuPG support
In-Reply-To: <539C0C14.5000603@opensource-expert.com>
References: <539AA945.9060207@eisenbits.com>
 <539C0C14.5000603@opensource-expert.com>
Message-ID: <539C8B32.8050301@eisenbits.com>

On 2014-06-14 10:47, Sylvain Viart wrote:
>> This thread is a continuation of this one:
>> https://mail.python.org/pipermail/mailman-developers/2011-May/021377.html .
> 
> I found this page yesterday, as we were doing a key signing party?
> 
> http://security.stackexchange.com/questions/26544/gpg-encrypted-mailing-list-and-other-approaches-to-safe-communication
> 
> Your are speaking about "2. Do a relay.", right?

Yes, except we don't want to use the mailing list maintainer keys, or
make him manually decrypt/encrypt every message.
This should be done automatically by Mailman, and we want to use the
mailing list keypair.

This could be customized. For example, see "new list settings" here:
https://bugs.launchpad.net/mailman/+bug/558189  .
This scheme could be made quite flexible. For example sending messages
encrypted with some people keys (but not the list key) could also be
allowed, thus alleviating the problem of the list maintainer being able
to inspect (and possibly block) every message.

Anyway it is crucial that the original signatures are retained, IMHO.
Not sure what would be the problems with double-signed messages, but
ideally the Mailman would add its own signature, too.

Also, the technical messages to/from Mailman (like the monthly ML
password, or ML commands) should also be encrypted and/or signed.

-- 
http://people.eisenbits.com/~stf/
http://www.eisenbits.com/

OpenPGP: 80FC 1824 2EA4 9223 A986  DB4E 934E FEA0 F492 A63B

From johnl at taugh.com  Sun Jun 15 00:15:37 2014
From: johnl at taugh.com (John Levine)
Date: 14 Jun 2014 22:15:37 -0000
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <20140613102145.72b78b0c@anarchist.wooz.org>
Message-ID: <20140614221537.5071.qmail@joyce.lan>

>>Honestly, Tough Noogies.  Let list managers make their own security
>>decisions.  AOL and Yahoo want all mail from their users to be authenticated.
>>Well, OK, this will do it.
>
>This is a really bad idea.  In MM3, we've already eliminated the need for
>keeping clear text passwords, and almost gotten rid of any user passwords at
>all.  OAUTH tokens are a little better, but no way do I want to hold a clear
>text password for users.

I agree it's a horrible idea.  But at the moment it's the only
horrible idea I'm aware of that will let lists keep operating in the
way the managers and users want, with no From: munging and no bounces,
using existing facilities from the mail providers.

AOL and Yahoo both have OAUTH APIs, but they are not the same, and I
see no likelihood that the APIs will converge, or that the next large
webmail provider to DMARC us will be compatible with either.  But
everyone has a SUBMIT server.

At least one of the large providers has told me they plan to do OAUTH
submission, presumably with long lived tokens, which would greatly
mitigate the security issues.  It is my impression that if word got
back that lists were considering doing the submit trick, it would
motivate them to get OAUTH submission working sooner.

R's,
John

From johnl at taugh.com  Sun Jun 15 00:21:06 2014
From: johnl at taugh.com (John Levine)
Date: 14 Jun 2014 22:21:06 -0000
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <20140613100531.28a07a2d@anarchist.wooz.org>
Message-ID: <20140614222106.5095.qmail@joyce.lan>

>>* Forwarding signature
>>
>>The IETF DMARC list is discussing a mutant weak DKIM signature from a
>>sending system (e.g. Yahoo and AOL) that would survive forwarding, but
>>contains a list of forwarding target domains.  It's only considered
>>valid if it's with a signature from the forwarding domain, i.e., the
>>list.
>>
>>This is nice for list operators, since it requires nothing beyond
>>not stripping the signature header, and signing on the way out.
>
>How does this list of forwarding target domains get specified?  Is this
>something the user has to do when they're sending the message?

It'd typically be the list domain, on the theory that lists will sign
their outgoing mail with their own domain.  If lists aren't signed
with the list domain, some kludge would be required at the sending
end, but it's intended to be fully automated.

It is my impression, having talked to tech managers at several large
web mail providers this week, that if they could do something like this
without a huge amount of effort, they probably would.  They'd probably
only add it on mail going to legitimate forwarders (for some
definitions of legitimate and forwarders) but the large web mail
providers already have a pretty good idea who those are.

R's,
John



From stephen at xemacs.org  Sun Jun 15 02:13:16 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 15 Jun 2014 09:13:16 +0900
Subject: [Mailman-Developers] GnuPG support
In-Reply-To: <539C46D7.7040701@eisenbits.com>
References: <539AA945.9060207@eisenbits.com>
 <877g4joieh.fsf@uwakimon.sk.tsukuba.ac.jp>
 <539C46D7.7040701@eisenbits.com>
Message-ID: <87y4wzm3mr.fsf@uwakimon.sk.tsukuba.ac.jp>

Stanis?aw Findeisen writes:

 > What needs to be done? Where is the code?

Pretty much everything.  In particular, key management is not at all
useful last I heard, you need to load the keys by hand into a file on
the server or something like that.  It wasn't integrated into the
account management interface.

The most recent code is presumably in Abilash's repo on Launchpad.
I'll find it for you later (have an appointment right now), but you
can look in the list of branches for the Mailman project on
launchpad.net.


From stephen at xemacs.org  Sun Jun 15 09:01:25 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 15 Jun 2014 16:01:25 +0900
Subject: [Mailman-Developers] GnuPG support
In-Reply-To: <87y4wzm3mr.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <539AA945.9060207@eisenbits.com>
 <877g4joieh.fsf@uwakimon.sk.tsukuba.ac.jp>
 <539C46D7.7040701@eisenbits.com>
 <87y4wzm3mr.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <87r42qmzay.fsf@uwakimon.sk.tsukuba.ac.jp>

Stephen J. Turnbull writes:

 > The most recent code is presumably in Abilash's repo on Launchpad.
 > I'll find it for you later (have an appointment right now), but you
 > can look in the list of branches for the Mailman project on
 > launchpad.net.

I think it's lp:~raj-abhilash1/mailman.client/gsoc.


From sylvain at opensource-expert.com  Sun Jun 15 09:42:42 2014
From: sylvain at opensource-expert.com (Sylvain Viart)
Date: Sun, 15 Jun 2014 09:42:42 +0200
Subject: [Mailman-Developers] GnuPG support - PGP - GPG encrypted
 mailing list
In-Reply-To: <539C8B32.8050301@eisenbits.com>
References: <539AA945.9060207@eisenbits.com>
 <539C0C14.5000603@opensource-expert.com> <539C8B32.8050301@eisenbits.com>
Message-ID: <539D4E72.50009@opensource-expert.com>

Le 14/06/2014 19:49, Stanis?aw Findeisen a ?crit :
> http://security.stackexchange.com/questions/26544/gpg-encrypted-mailing-list-and-other-approaches-to-safe-communication
>
> "2. Do a relay."
> Yes, except we don't want to use the mailing list maintainer keys, or
> make him manually decrypt/encrypt every message.

Sorry, of course it should be done by the list engine.
Only the concept of relaying?
 
This question of distributing encrypted email to an unknown number of
subscribers is quite interesting/dangerous in the point of view of
securing the information. Do you agree? Not saying it couldn't be
accomplished of course.

The reply of the question linked above said:

"When a secret is known by more than two or three people, it is no
longer a secret, merely /discreet/. Any recipient of the mailing-list,
by definition, can read all messages, hence he is *trusted* (in the
sense of: he has the power to betray you). "

Could you describe the goal to achieve?
It seems really interesting, but I've the feeling that keeping the
encryption chain will be quite difficult.

And you probably know that the encryption is as strong as it weakest
point in the chain.

Also I noticed that despite we are in 2014, using GPG is still quite
"repulsing" for basic user?

Sylvain.

From stephen at xemacs.org  Sun Jun 15 11:18:16 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 15 Jun 2014 18:18:16 +0900
Subject: [Mailman-Developers] GnuPG support - PGP - GPG encrypted
 mailing list
In-Reply-To: <539D4E72.50009@opensource-expert.com>
References: <539AA945.9060207@eisenbits.com>
 <539C0C14.5000603@opensource-expert.com>
 <539C8B32.8050301@eisenbits.com>
 <539D4E72.50009@opensource-expert.com>
Message-ID: <87ppiamsyv.fsf@uwakimon.sk.tsukuba.ac.jp>

Sylvain Viart writes:

 > This question of distributing encrypted email to an unknown number
 > of subscribers is quite interesting/dangerous in the point of view
 > of securing the information.

True, but this is out of scope for this list.  I'm not saying you
shouldn't discuss here if you want to, just that from the point of
view of the Mailman developers we are assuming that users have answers
to (enough of) that set of questions, and we're merely interested in
how much demand there is.

 > Could you describe the goal to achieve?

One goal that Mailman is interested in is chaining trust, via
signatures.  I think it's reasonable to suppose that if the original
user is supposed to sign her post, and the list verifies and resigns,
we might be able to convince some sites to whitelist those lists.

That would be worthwhile even if we never do really solve the issues
of encrypted mailing lists.  I'm not sure if there are any issues with
encrypted lists that don't come up with signed lists (well, I guess
there's the issue that signed lists are useful to users even if they
don't use a PGP tool, but that's definitely out of scope for us).

 > Also I noticed that despite we are in 2014, using GPG is still quite
 > "repulsing" for basic user?

Sure.  There's obviously no hope of getting enough yahoos[1] to sign
mail that Yahoo! will give up on "p=reject". ;-)

Footnotes: 
[1]  http://dictionary.reference.com/browse/yahoo.  Appropriate, eh?
Note that Yahoo! almost certainly intends a different etymology....

From johnl at taugh.com  Sun Jun 15 16:18:56 2014
From: johnl at taugh.com (John Levine)
Date: 15 Jun 2014 14:18:56 -0000
Subject: [Mailman-Developers] GnuPG support
In-Reply-To: <539C8B32.8050301@eisenbits.com>
Message-ID: <20140615141856.80664.qmail@joyce.lan>

>Yes, except we don't want to use the mailing list maintainer keys, or
>make him manually decrypt/encrypt every message.
>This should be done automatically by Mailman, and we want to use the
>mailing list keypair.

Sympa does something like this with S/MIME.  Incoming list messages
are encrypted to the list's key, the list decrypts it and reencrypts
it to the subscribers keys and sends it back out.  S/MIME allows one
message to be encrypted to multiple recipients' keys and I don't know
whether it makes up one message with everyone's key, or separately
encrypts each copy.

It is my impression that this feature is in regular use in Europe.
Have you checked to see what people's experience with it is?

R's,
John

From Pidgeot18 at gmail.com  Mon Jun 16 02:35:58 2014
From: Pidgeot18 at gmail.com (=?UTF-8?B?Sm9zaHVhIENyYW5tZXIg8J+Qpw==?=)
Date: Sun, 15 Jun 2014 19:35:58 -0500
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <20140614221537.5071.qmail@joyce.lan>
References: <20140614221537.5071.qmail@joyce.lan>
Message-ID: <539E3BEE.9080207@gmail.com>

On 6/14/2014 5:15 PM, John Levine wrote:
> AOL and Yahoo both have OAUTH APIs, but they are not the same, and I
> see no likelihood that the APIs will converge, or that the next large
> webmail provider to DMARC us will be compatible with either.  But
> everyone has a SUBMIT server.

For other reasons, I've poked into OAUTH for email before. I've been 
told that some Google employees are working on documents for dynamic 
client registration and endpoint discovery, but all the references I've 
found seem to imply that endpoint discovery is consistently being tabled 
for later work.

-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code arch?ologist


From sylvain at opensource-expert.com  Mon Jun 16 09:33:46 2014
From: sylvain at opensource-expert.com (Sylvain Viart)
Date: Mon, 16 Jun 2014 09:33:46 +0200
Subject: [Mailman-Developers] GnuPG support - PGP - GPG encrypted
 mailing list
In-Reply-To: <87ppiamsyv.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <539AA945.9060207@eisenbits.com>	<539C0C14.5000603@opensource-expert.com>	<539C8B32.8050301@eisenbits.com>	<539D4E72.50009@opensource-expert.com>
 <87ppiamsyv.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <539E9DDA.7050700@opensource-expert.com>

Le 15/06/2014 11:18, Stephen J. Turnbull a ?crit :
> [distributing encrypted email to an unknown number subscribers?]
> True, but this is out of scope for this list.

Just to emphasis that the goal of keeping information private that way
could be wrong, if done the wrong way.
(For example, you may not want to store a clear temporary file of the
decrypted email, on the server hard drive.)


I totally agree that from the point of view of software developer the
perception can be different. May be, I didn't say that clearly but it's
a very interesting challenge to bring cryptography and mail distribution
to some more simplicity? while keeping the chain of trust. :-)

>  yahoos :[1] http://dictionary.reference.com/browse/yahoo

Oh lovely! Thanks for sharing. :-D
In French I may say "propos croustillants" (crunchy).

Regards,
Sylvain

From barry at list.org  Mon Jun 16 16:12:26 2014
From: barry at list.org (Barry Warsaw)
Date: Mon, 16 Jun 2014 10:12:26 -0400
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <20140614221537.5071.qmail@joyce.lan>
References: <20140613102145.72b78b0c@anarchist.wooz.org>
 <20140614221537.5071.qmail@joyce.lan>
Message-ID: <20140616101226.22689963@anarchist.wooz.org>

On Jun 14, 2014, at 10:15 PM, John Levine wrote:

>AOL and Yahoo both have OAUTH APIs, but they are not the same, and I
>see no likelihood that the APIs will converge, or that the next large
>webmail provider to DMARC us will be compatible with either.  But
>everyone has a SUBMIT server.

Mailman has always been about adhering to standards, preferably RFCs, but
de facto standards are acceptable when it makes sense.  OAUTH submission
could make sense, but I'm not in favor of a supporting a proliferation of
incompatible hacks.  If this is going to be A Thing, then these webmail
providers need to get together and agree on some standard.  Otherwise, what
Mailman should do IMHO, is support a framework for supporting the feature in
general, and leave it to third parties to support their email providers of
choice.

>At least one of the large providers has told me they plan to do OAUTH
>submission, presumably with long lived tokens, which would greatly
>mitigate the security issues.  It is my impression that if word got
>back that lists were considering doing the submit trick, it would
>motivate them to get OAUTH submission working sooner.

It's the least crappy solution (so far) to a problem of their making, but
please get them to agree on some kind of common API.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20140616/9652a277/attachment.sig>

From johnl at taugh.com  Mon Jun 16 17:33:05 2014
From: johnl at taugh.com (John R Levine)
Date: 16 Jun 2014 11:33:05 -0400
Subject: [Mailman-Developers] Two more DMARC mitigations
In-Reply-To: <20140616101226.22689963@anarchist.wooz.org>
References: <20140613102145.72b78b0c@anarchist.wooz.org>
 <20140614221537.5071.qmail@joyce.lan>
 <20140616101226.22689963@anarchist.wooz.org>
Message-ID: <alpine.BSF.2.00.1406161129020.83297@joyce.lan>

> Mailman has always been about adhering to standards, preferably RFCs, but
> de facto standards are acceptable when it makes sense.  OAUTH submission
> could make sense, but I'm not in favor of a supporting a proliferation of
> incompatible hacks.  If this is going to be A Thing, then these webmail
> providers need to get together and agree on some standard.

Well, yeah.  They all do SUBMIT.  I understand the security issue of 
submission with a password, but it's the only thing that consistently 
works.

>> At least one of the large providers has told me they plan to do OAUTH
>> submission, presumably with long lived tokens, which would greatly
>> mitigate the security issues.

I'm trying to track down what's actually going on here.  It's SUBMIT 
either way, so everything in the code except the way that authorization is 
sent to the SUBMIT server is the same.

Regards,
John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

From rajeevs1992 at gmail.com  Mon Jun 16 19:53:24 2014
From: rajeevs1992 at gmail.com (Rajeev S)
Date: Mon, 16 Jun 2014 23:23:24 +0530
Subject: [Mailman-Developers] [CLI Project] Describe instance and
	Subscription features
Message-ID: <539F2F14.8020101@gmail.com>

Hi,

I have completed the describe instance feature and the subscription 
features for
the CLI. I have pushed the changes as r58.[1]

The describe feature is implemented as an extension to the `show` command.

This feature adds 3 new usages for the `./mmclient show` action, apart 
from the
previous functionalities.

    ./mmclient show user foo at bar.com [2]
    ./mmclient show list list1 at domain.org [3]
    ./mmclient show domain domain.org [4]

The subscription features are built as mentioned in my previous mail

    ./mmclient subscribe user user1 at foo.com user2 at bar.com --list 
list at domain.org
    ./mmclient unsubscribe user user1 at foo.com user2 at bar.com --list 
list at domain.org

The commands support usage with either a single user or multiple users.

[1] 
http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/58
[2] https://gist.github.com/rajeevs1992/3ca077fd7d1a5a1d5729
[3] https://gist.github.com/rajeevs1992/15f69f5bfdbda52c4e36
[4] https://gist.github.com/rajeevs1992/49fbe250ab9e1f254c11

From johnl at taugh.com  Mon Jun 16 20:47:34 2014
From: johnl at taugh.com (John Levine)
Date: 16 Jun 2014 18:47:34 -0000
Subject: [Mailman-Developers] SUBMIT and OpenID,
	was Two more DMARC mitigations
In-Reply-To: <alpine.BSF.2.00.1406161129020.83297@joyce.lan>
Message-ID: <20140616184734.84254.qmail@joyce.lan>

>>> At least one of the large providers has told me they plan to do OAUTH
>>> submission, presumably with long lived tokens, which would greatly
>>> mitigate the security issues.
>
>I'm trying to track down what's actually going on here.  It's SUBMIT 
>either way, so everything in the code except the way that authorization is 
>sent to the SUBMIT server is the same.

After digging through a festival of acronyms, I ended up at RFC 6616.

Mail submission (port 587) is defined in RFC 4409.  It refers to RFC
2554, now replaced by RFC 4954, which defines the AUTH extension to
SMTP.  That in turn punts to SASL, defined in RFC 4422, which
describes the authorization framework and the initial schemes.  RFC
6616 adds OpenID as a SASL authorization scheme.  It's fairly
impenetrable, but I know the guy who wrote it, so I can probably get
some help, and it's definitely a standards track document so we can
expect everyone who implements it to do so in the same way.  OpenID
tokens can be very long lived -- I've been doing programmed posts to
my Twitter account using the same token for several years.

There are certainly OpenID libraries, but I don't know to what extent
anyone has written the code to splice them into SASL.  It (SASL) is
used for many mail applications including POP and IMAP.  Considering
how easily malware can scrape passwords out of software on PCs, I
expect that the providers have considerable incentive to replace them
with OpenID tokens in MUAs.

I would propose doing the submission hack, explicitly noting that SASL
has a variety of different ways to authenticate with different
usability and security trade offs.

R's,
John

From stephen at xemacs.org  Tue Jun 17 04:28:11 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 17 Jun 2014 11:28:11 +0900
Subject: [Mailman-Developers] SUBMIT and OpenID,
	was Two more DMARC mitigations
In-Reply-To: <20140616184734.84254.qmail@joyce.lan>
References: <alpine.BSF.2.00.1406161129020.83297@joyce.lan>
 <20140616184734.84254.qmail@joyce.lan>
Message-ID: <87fvj4jmmc.fsf@uwakimon.sk.tsukuba.ac.jp>

John Levine writes:

 > After digging through a festival of acronyms, I ended up at RFC
 > 6616.

Thank you!

 > There are certainly OpenID libraries, but I don't know to what extent
 > anyone has written the code to splice them into SASL.

Were we (on dmarc at ietf) talking all along about OpenID when we wrote
"OAuth"?  They're different, although I don't know exactly how or why
(and neither RFC made obvious mention of the other :-( ).

I'm not sure who you know among the authors of that RFC, but I've
worked with Simon Josefsson, who would surely help if he has time, and
has done a lot of implementation.  (I suspect Barry knows him too.)
Given that Simon is on the side of SASL/OpenID vs. OAuth, I suspect
that OpenID is the more practical of the two standards.

 > I would propose doing the submission hack, explicitly noting that SASL
 > has a variety of different ways to authenticate with different
 > usability and security trade offs.

I think that's a good starting point for discussion.  With a little
luck it could be quite close to eventual implementation, too. :-)

Steve

From Pidgeot18 at gmail.com  Tue Jun 17 16:34:23 2014
From: Pidgeot18 at gmail.com (=?UTF-8?B?Sm9zaHVhIENyYW5tZXIg8J+Qpw==?=)
Date: Tue, 17 Jun 2014 09:34:23 -0500
Subject: [Mailman-Developers] SUBMIT and OpenID,
 was Two more DMARC mitigations
In-Reply-To: <87fvj4jmmc.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <alpine.BSF.2.00.1406161129020.83297@joyce.lan>
 <20140616184734.84254.qmail@joyce.lan>
 <87fvj4jmmc.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <53A051EF.4020207@gmail.com>

On 6/16/2014 9:28 PM, Stephen J. Turnbull wrote:
> Were we (on dmarc at ietf) talking all along about OpenID when we wrote
> "OAuth"?  They're different, although I don't know exactly how or why
> (and neither RFC made obvious mention of the other :-( ).

OAuth calls itself an authorization framework. I like to think of it 
personally as a less secure and less well-specified variant of Kerberos. 
:-) OpenID in contrast is more of a third-party authentication provider. 
It looks like OpenID is repositioning itself to work on top of OAuth 2.0 
with OpenID Connect, though.

The problem with OAuth is that a lot of its details are left up to the 
whims of the implementor, such as the location of its various endpoints 
or even what elements in the query are mandatory. Figuring out how to go 
from "email address" to "OAuth bearer token" is currently impossible 
without hardcoding a lot of mapping details.

-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code arch?ologist


From barry at list.org  Tue Jun 17 23:35:42 2014
From: barry at list.org (Barry Warsaw)
Date: Tue, 17 Jun 2014 17:35:42 -0400
Subject: [Mailman-Developers] SUBMIT and OpenID,
 was Two more DMARC mitigations
In-Reply-To: <87fvj4jmmc.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <alpine.BSF.2.00.1406161129020.83297@joyce.lan>
 <20140616184734.84254.qmail@joyce.lan>
 <87fvj4jmmc.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20140617173542.37318aeb@anarchist.wooz.org>

On Jun 17, 2014, at 11:28 AM, Stephen J. Turnbull wrote:

>Were we (on dmarc at ietf) talking all along about OpenID when we wrote
>"OAuth"?  They're different, although I don't know exactly how or why
>(and neither RFC made obvious mention of the other :-( ).

I haven't been keeping up with the latest OpenID and OAuth specs, but one way
I think about it is that OAuth is a web-service delegation protocol, while
OpenID is more of a single-sign-on protocol.

Let's say you have a web service, like, oh I don't know, Mailman 3's REST
API.  You want to script some interactions with this service, perhaps locally,
or you want to allow some other application to do it on your behalf.
Normally, you'd have to hard code your username and password in some local
file, or enter it into the third party app.  With OAuth, you can acquire a
token from the service which is used to sign requests, so that the service
knows it's coming from you.  Thus you can hand the third party application
your token without giving it your password, and most services provide you a
way to revoke tokens if you e.g. stop using the third party app.  Usually, you
round-trip through a web browser (the only "trusted agent" on your system) to
acquire the token, but there can be other ways.

OpenID is more like a single-sign-on technology.  Let's say you want to log
into Bitbucket for the first time, but you don't want to have to register yet
another username and password with yet another web site.  Fortunately, you
have a Launchpad account, which is an OpenID provider, so on Bitbucket's login
page you enter your OpenID, which is an https url pointing to your Launchpad
page.  After some dancing with Launchpad and Ubuntu's SSO, Bitbucket logs you
in.  The point is that Bitbucket doesn't have access to your Launchpad
password - it delegates authentication to Ubuntu's SSO and Launchpad, which as
it turns out can also be made to require two-factor auth for additional
security.

Thinking about it this way, I'm not really sure what's being considered for
DMARC, although either make some sense in different contexts.  My guess is
that it's probably OAuth based; I'd get a token to submit messages via a web
service using authenticated and signed requests.  But that's just a guess.

-Barry

From barry at list.org  Tue Jun 17 23:38:29 2014
From: barry at list.org (Barry Warsaw)
Date: Tue, 17 Jun 2014 17:38:29 -0400
Subject: [Mailman-Developers] SUBMIT and OpenID,
 was Two more DMARC mitigations
In-Reply-To: <53A051EF.4020207@gmail.com>
References: <alpine.BSF.2.00.1406161129020.83297@joyce.lan>
 <20140616184734.84254.qmail@joyce.lan>
 <87fvj4jmmc.fsf@uwakimon.sk.tsukuba.ac.jp>
 <53A051EF.4020207@gmail.com>
Message-ID: <20140617173829.4abe51c6@anarchist.wooz.org>

On Jun 17, 2014, at 09:34 AM, Joshua Cranmer ? wrote:

>The problem with OAuth is that a lot of its details are left up to the whims
>of the implementor, such as the location of its various endpoints or even
>what elements in the query are mandatory. Figuring out how to go from "email
>address" to "OAuth bearer token" is currently impossible without hardcoding a
>lot of mapping details.

Not to mention that there are lots of OAuth 1.x implementations out there
(client and server), and it's a fairly easy protocol to understand.  At a
Python conference a few years ago I spoke with someone who resigned from the
committee designing OAuth 2 due to lots of problems with the new spec,
essentially ill you could imagine with a designed-by-committee new version.
(In the music biz, we call this the sophomore slump.  Great debut album, but
all the good material got used up. :)

-Barry

From johnl at taugh.com  Wed Jun 18 02:51:51 2014
From: johnl at taugh.com (John Levine)
Date: 18 Jun 2014 00:51:51 -0000
Subject: [Mailman-Developers] SUBMIT and OpenID,
	was Two more DMARC mitigations
In-Reply-To: <20140617173542.37318aeb@anarchist.wooz.org>
Message-ID: <20140618005151.52110.qmail@joyce.lan>

>Thinking about it this way, I'm not really sure what's being considered for
>DMARC, ...

Nothing specifically for DMARC.  The idea is that SASL, the layer you
use to log into pop, imap, and submit servers, now includes oauth as
an authentication scheme and OpenID as the common way to get the
token.  This is all in RFC 6616, and is allegedly implemented in
gsasl.

Once you have access to the subscriber's submit server, you can run
the decorated message through it to get the mail providers's
signature, then remail that.  OAuth just avoids the need to ask the
user directly for her password.

R's,
John

From stephen at xemacs.org  Wed Jun 18 03:34:26 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 18 Jun 2014 10:34:26 +0900
Subject: [Mailman-Developers] SUBMIT and OpenID,
	was Two more DMARC mitigations
In-Reply-To: <20140618005151.52110.qmail@joyce.lan>
References: <20140617173542.37318aeb@anarchist.wooz.org>
 <20140618005151.52110.qmail@joyce.lan>
Message-ID: <8761jzj90d.fsf@uwakimon.sk.tsukuba.ac.jp>

John Levine writes:

 >> Thinking about it this way, I'm not really sure what's being
 >> considered for DMARC, ...
 > 
 > Nothing specifically for DMARC.

Yeah, I got that far.

 > OAuth just avoids the need to ask the user directly for her
 > password.  Once you have access to the subscriber's submit server,
 > you can run the decorated message through it to get the mail
 > providers's signature, then remail that.

This is potentially a lot of remailing, though.  Somebody who has been
posting twice a day to a mailing list with 1000 subscribers suddenly
goes from 10 outgoing messages a day to 2008.  I suppose this is just
a drop in the bucket for the MTAs, but I wonder if the mailbox
providers will really go for this given their sensitivity to taking
responsibility for anything (except keeping spam out of their users'
mailboxes).





From johnl at taugh.com  Wed Jun 18 03:56:13 2014
From: johnl at taugh.com (John R Levine)
Date: 17 Jun 2014 21:56:13 -0400
Subject: [Mailman-Developers] SUBMIT and OpenID,
 was Two more DMARC mitigations
In-Reply-To: <8761jzj90d.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <20140617173542.37318aeb@anarchist.wooz.org>
 <20140618005151.52110.qmail@joyce.lan>
 <8761jzj90d.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <alpine.BSF.2.11.1406172152460.52338@joyce.lan>

> > OAuth just avoids the need to ask the user directly for her
> > password.  Once you have access to the subscriber's submit server,
> > you can run the decorated message through it to get the mail
> > providers's signature, then remail that.
>
> This is potentially a lot of remailing, though.  Somebody who has been
> posting twice a day to a mailing list with 1000 subscribers suddenly
> goes from 10 outgoing messages a day to 2008.

No, he goes from two to four.  He sends the first original message to the 
list (1) which adds subject tags and footers or whatever, then uses OAuth 
to resend it back to the list to get a new DKIM signature (2), and the 
list then remails that to the thousand subscribers.  He sends the second 
message (3) which is treated the same way (4).

If you have the list set to customize the message per recipient, this hack 
doesn't work.  Do you have any idea how many lists do that?

Regards,
John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

From mark at msapiro.net  Wed Jun 18 04:16:06 2014
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 17 Jun 2014 19:16:06 -0700
Subject: [Mailman-Developers] SUBMIT and OpenID,
	was Two more DMARC mitigations
In-Reply-To: <alpine.BSF.2.11.1406172152460.52338@joyce.lan>
References: <20140617173542.37318aeb@anarchist.wooz.org>
 <20140618005151.52110.qmail@joyce.lan>
 <8761jzj90d.fsf@uwakimon.sk.tsukuba.ac.jp>
 <alpine.BSF.2.11.1406172152460.52338@joyce.lan>
Message-ID: <53A0F666.3060800@msapiro.net>

On 06/17/2014 06:56 PM, John R Levine wrote:
> 
> If you have the list set to customize the message per recipient, this
> hack doesn't work.  Do you have any idea how many lists do that?


Many. Take a look at the footer in messages from this list. It contains
an Unsubscribe: link to the recipient's user options page.

I have no idea exactly what fraction of Mailman lists are configured
with personalized footers, but I suspect it's significant.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From stephen at xemacs.org  Wed Jun 18 10:37:17 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 18 Jun 2014 17:37:17 +0900
Subject: [Mailman-Developers] SUBMIT and OpenID,
	was Two more DMARC mitigations
In-Reply-To: <53A0F666.3060800@msapiro.net>
References: <20140617173542.37318aeb@anarchist.wooz.org>
 <20140618005151.52110.qmail@joyce.lan>
 <8761jzj90d.fsf@uwakimon.sk.tsukuba.ac.jp>
 <alpine.BSF.2.11.1406172152460.52338@joyce.lan>
 <53A0F666.3060800@msapiro.net>
Message-ID: <874mzik402.fsf@uwakimon.sk.tsukuba.ac.jp>

Mark Sapiro writes:

 > I have no idea exactly what fraction of Mailman lists are configured
 > with personalized footers, but I suspect it's significant.

@John: Sorry, I definitely was assuming personalization; I should have
said so.

I think personalization is quite a desirable feature in some contexts.
All of my educational lists have personalized footers (subscribers min
5, max 20, mean 7 -- tiny, or "nano" if you prefer).  I would guess
lists with "naive" users are more likely to want to personalize.

OTOH, XEmacs lists are ancient, they don't personalize.  Emacs-devel
(probably by Savannah policy) doesn't have them at all.  python-dev
and python-ideas *do* have personalized footers (maybe somebody here
knows how many subscribers?)  Sourceforge's weekly ping doesn't have a
footer, the monthly news letter does.  (Of course those SF lists aren't
discussion lists, but it's indicative of expectations among developers
-- we probably don't need them.  It also shows that lists with many
thousands of users sometimes use personalized footers, at least if
they're low-traffic.)


From stephen at xemacs.org  Wed Jun 18 18:51:29 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 19 Jun 2014 01:51:29 +0900
Subject: [Mailman-Developers] Disabling SELinux
In-Reply-To: <CAG8E47STta-1Ax7ft8645i22pzLcZdnBKPShZt70JHXpLLtc6g@mail.gmail.com>
References: <CAG8E47SGtuQ8jcKkqfeo0VvHTzBg92SrOUb-Zf9cqS7LAvYmgg@mail.gmail.com>
 <53992E9C.7070907@msapiro.net>
 <CAG8E47R8013RJtUzgvNq=cuQLVMWPjDQE3vw7U0ARUHmY31y2Q@mail.gmail.com>
 <5399F7AD.5020107@msapiro.net>
 <CAG8E47Rm5Wa_SmdDDHLAj0xiZdDNuD3NZvC1kg73cJYk5nZTjQ@mail.gmail.com>
 <539A392E.3070001@msapiro.net>
 <CAG8E47TPFfzUqKABbNEMMs-ucV58xdV3ZA1bDScTiDP+zyLs8Q@mail.gmail.com>
 <539B3CA1.9080203@msapiro.net>
 <CAG8E47TikittH_frk1jm7P0-N_YXfcS=fBbWXmBN6NqogcPnCg@mail.gmail.com>
 <539B58F5.8040909@msapiro.net>
 <CAG8E47STta-1Ax7ft8645i22pzLcZdnBKPShZt70JHXpLLtc6g@mail.gmail.com>
Message-ID: <87wqcei2jy.fsf@uwakimon.sk.tsukuba.ac.jp>

I thought I sent this but my MUA disagrees....

A user (one among many) writes:

 > Mark,
 > Good straw to grasp at. I thought SElinux had already been disabled but it
 > hadn't. It seems to be working now.

Do we have better advice than just "disable SELinux" to offer?

I ask because "solving" the DMARC "problem" seems to involve trust of
Mediators (the technical RFC term for middlemen like Mailman) by
Author Domains (RFC-ese for domains with DMARC policies about
verifying From:).  Asking upstream to trust sites which have
deliberately disabled security features seems like poor strategy at
best.

Note: reply-to set to Mailman-Developers.  Please follow up there.  If
you want to follow but not subscribe to MM-D, perhap the archives are
an option: http://www.mail-archive.com/mailman-developers%40python.org/.

Steve


From mark at msapiro.net  Thu Jun 19 03:05:14 2014
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 18 Jun 2014 18:05:14 -0700
Subject: [Mailman-Developers] Disabling SELinux
In-Reply-To: <87wqcei2jy.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CAG8E47SGtuQ8jcKkqfeo0VvHTzBg92SrOUb-Zf9cqS7LAvYmgg@mail.gmail.com>
 <53992E9C.7070907@msapiro.net>
 <CAG8E47R8013RJtUzgvNq=cuQLVMWPjDQE3vw7U0ARUHmY31y2Q@mail.gmail.com>
 <5399F7AD.5020107@msapiro.net>
 <CAG8E47Rm5Wa_SmdDDHLAj0xiZdDNuD3NZvC1kg73cJYk5nZTjQ@mail.gmail.com>
 <539A392E.3070001@msapiro.net>
 <CAG8E47TPFfzUqKABbNEMMs-ucV58xdV3ZA1bDScTiDP+zyLs8Q@mail.gmail.com>
 <539B3CA1.9080203@msapiro.net>
 <CAG8E47TikittH_frk1jm7P0-N_YXfcS=fBbWXmBN6NqogcPnCg@mail.gmail.com>
 <539B58F5.8040909@msapiro.net>
 <CAG8E47STta-1Ax7ft8645i22pzLcZdnBKPShZt70JHXpLLtc6g@mail.gmail.com>
 <87wqcei2jy.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <53A2374A.8020204@msapiro.net>

On 06/18/2014 09:51 AM, Stephen J. Turnbull wrote:
> 
> Do we have better advice than just "disable SELinux" to offer?


I'm not sure why the OP had a problem. I suspect it that to do with his
moving lists from an older Fedora server to a newer RHEL server and
something to do with security policy settings or lack thereof on the
moved files.

In any case, RHEL Mailman is supposed to be SELinux compatible. See the
FAQ at <http://wiki.list.org/x/KYCB>.

However, that doesn't address the larger question of how to make Mailman
in general, particularly if installed from our distribution, SELinux
friendly. Unfortunately, I'm not familiar with SELinux or similar
security policy management configuration beyond what's in the
mailman-developers thread (from almost 10 years ago now) linked from the
FAQ article. Thus, I'm not the best person to address the larger question.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From rajeevs1992 at gmail.com  Thu Jun 19 18:49:13 2014
From: rajeevs1992 at gmail.com (Rajeev S)
Date: Thu, 19 Jun 2014 22:19:13 +0530
Subject: [Mailman-Developers] [CLI Project]Commands for adding Moderators
	and owners
Message-ID: <53A31489.5040608@gmail.com>

Hi,

I have pushed r59 (In fact, 2 days before) which adds commands to 
perform the following actions

- Add moderators

     ./mmclient add-moderator list list at domain.org --user a at b.com 
b at c.com d at e.com

- Add owners

     ./mmclient add-owner list list at domain.org --user a at b.com b at c.com 
d at e.com

- Remove Moderator

     ./mmclient remove-moderator list list at domain.org --user a at b.com 
b at c.com d at e.com

- Remove Owner

     ./mmclient remove-owner list list at domain.org --user a at b.com b at c.com 
d at e.com

All the above commands support an extra --quiet flag to suppress the 
action feedback message.

http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/59

From aurelien at bompard.org  Fri Jun 20 01:06:53 2014
From: aurelien at bompard.org (Aurelien Bompard)
Date: Fri, 20 Jun 2014 01:06:53 +0200
Subject: [Mailman-Developers] Disabling SELinux
In-Reply-To: <53A2374A.8020204@msapiro.net>
References: <CAG8E47SGtuQ8jcKkqfeo0VvHTzBg92SrOUb-Zf9cqS7LAvYmgg@mail.gmail.com>
 <53992E9C.7070907@msapiro.net>
 <CAG8E47R8013RJtUzgvNq=cuQLVMWPjDQE3vw7U0ARUHmY31y2Q@mail.gmail.com>
 <5399F7AD.5020107@msapiro.net>
 <CAG8E47Rm5Wa_SmdDDHLAj0xiZdDNuD3NZvC1kg73cJYk5nZTjQ@mail.gmail.com>
 <539A392E.3070001@msapiro.net>
 <CAG8E47TPFfzUqKABbNEMMs-ucV58xdV3ZA1bDScTiDP+zyLs8Q@mail.gmail.com>
 <539B3CA1.9080203@msapiro.net>
 <CAG8E47TikittH_frk1jm7P0-N_YXfcS=fBbWXmBN6NqogcPnCg@mail.gmail.com>
 <539B58F5.8040909@msapiro.net>
 <CAG8E47STta-1Ax7ft8645i22pzLcZdnBKPShZt70JHXpLLtc6g@mail.gmail.com>
 <87wqcei2jy.fsf@uwakimon.sk.tsukuba.ac.jp> <53A2374A.8020204@msapiro.net>
Message-ID: <CAHmoxtWmiM-WEr6hS40KFarCw9+vx8pYvLJ2hw7s2sgLJHoVtw@mail.gmail.com>

For your information, I have written a small SELinux module for Mailman3,
it's included in my Fedora RPM and works fine. In the future (when MM3 is
out), I'll ask for integration in the core policy.

Aur?lien

From stephen at xemacs.org  Fri Jun 20 07:20:35 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 20 Jun 2014 14:20:35 +0900
Subject: [Mailman-Developers] Disabling SELinux
In-Reply-To: <CAHmoxtWmiM-WEr6hS40KFarCw9+vx8pYvLJ2hw7s2sgLJHoVtw@mail.gmail.com>
References: <CAG8E47SGtuQ8jcKkqfeo0VvHTzBg92SrOUb-Zf9cqS7LAvYmgg@mail.gmail.com>
 <53992E9C.7070907@msapiro.net>
 <CAG8E47R8013RJtUzgvNq=cuQLVMWPjDQE3vw7U0ARUHmY31y2Q@mail.gmail.com>
 <5399F7AD.5020107@msapiro.net>
 <CAG8E47Rm5Wa_SmdDDHLAj0xiZdDNuD3NZvC1kg73cJYk5nZTjQ@mail.gmail.com>
 <539A392E.3070001@msapiro.net>
 <CAG8E47TPFfzUqKABbNEMMs-ucV58xdV3ZA1bDScTiDP+zyLs8Q@mail.gmail.com>
 <539B3CA1.9080203@msapiro.net>
 <CAG8E47TikittH_frk1jm7P0-N_YXfcS=fBbWXmBN6NqogcPnCg@mail.gmail.com>
 <539B58F5.8040909@msapiro.net>
 <CAG8E47STta-1Ax7ft8645i22pzLcZdnBKPShZt70JHXpLLtc6g@mail.gmail.com>
 <87wqcei2jy.fsf@uwakimon.sk.tsukuba.ac.jp>
 <53A2374A.8020204@msapiro.net>
 <CAHmoxtWmiM-WEr6hS40KFarCw9+vx8pYvLJ2hw7s2sgLJHoVtw@mail.gmail.com>
Message-ID: <87a99817j0.fsf@uwakimon.sk.tsukuba.ac.jp>

Aurelien Bompard writes:

 > For your information, I have written a small SELinux module for Mailman3,
 > it's included in my Fedora RPM and works fine. In the future (when MM3 is
 > out), I'll ask for integration in the core policy.

"Core policy" means at SELinux?  Why not put it in a contrib directory
in MM3, too?  Why not now?




From rajeevs1992 at gmail.com  Sun Jun 22 07:53:27 2014
From: rajeevs1992 at gmail.com (Rajeev S)
Date: Sun, 22 Jun 2014 11:23:27 +0530
Subject: [Mailman-Developers] [CLI Project] Preference management commands
	added
Message-ID: <53A66F57.8080101@gmail.com>

Hi,

As promised, I have completed the preference related commands and pushed 
it as revision 60 [1].

The preferences form a new scope, along with user, domains and lists. 
There are 2 commands associated
with the `preference` scope.

1.Show Preference

   ./mmclient show preference [scope] [scope_args] [key]

That is, to view a preference of a list member

   ./mmclient show preference member --email a at b.com --list 
list at domain.org receive_own_postings


2. Update Preference

Similar to the above command

   ./mmclient show preference [scope] [scope_args] [key] [value]

   ./mmclient show preference member --email a at b.com --list 
list at domain.org receive_own_postings true

The supported preference scopes are

   global [2]
   user --email
   address --email
   member --email --list

Also, the command scope resolution code in cmdparser.py, which was 
repeated once per scope, has been replaced
with a better and faster approach.

Footnotes:

[1] 
http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/60

[2] Upon updating/editing the global preferences, a `HTTP Error 405 : 
Method not allowed is raised`. I tried as sudo but still
no good. Is that a mailman bug or a design decision?

From varunsharmalive at gmail.com  Tue Jun 24 09:13:08 2014
From: varunsharmalive at gmail.com (varun sharma)
Date: Tue, 24 Jun 2014 12:43:08 +0530
Subject: [Mailman-Developers] GSoC updates till midterm
Message-ID: <CAPkTf0JSrs+q6=dBytieKBw3Wbw=-_YgC8g33Qn_4XHF7OYmmg@mail.gmail.com>

Hi everyone,

This will be my second update email to mm-dev after gsoc started, i'll be
sending weekly summaries in the future. The ci-tool(please suggest some
nice name) is almost finished, i need few more days to get it working on
multiple projects under mailman suite. The following parts of ci-tool are
working:

./ci-tool --pull project_name
./ci-tool --pull all

./ci-tool --test project_name
./ci-tool --test all

./ci-tool --try project_name

The projects under the mailman suite are listed in a config file(currently
settings.py) which contains the a dict projects which has further
dictionaries to store attributes like path, vcs, src location.

For parsing the commands form the command line, i have used argparse module
and while implementation of commands, i have created two different files:
commands.py and utils.py. In commands, i've declared the classes for
various commands like pull, test and try and for making a tcp connection
via twisted, two more classes for Client and Factory. In utils.py, i've
tried to declare the error classes which i'll be able to differentiate
easily and a logging class.

The most interesting command in this whole tool is the 'try' command, which
will take the diff of the project and send it to the server to test it on
the server and run all the tests on different installations (in this case i
am using buildbot's slaves). I am able to send the diff to server and test
it on a single server and now working on how to send the patches for
multiple projects of suite, in case the developer is working on multiple
projects(like postorius and hyperkitty) at the same time.

That's all for the status report, i have to say that whatever i've done
won't be possible without the help of my awesome mentors: florian,
stylistica, steve and maxking. The source of my project is available at
http://bazaar.launchpad.net/~varun/mailman/ci_tool/files. I try to remain
active on #mailman and #mailman-gsoc for most of the daytime under nick
'varun'.

Thanks
Varun

From rajeevs1992 at gmail.com  Sat Jun 28 19:25:26 2014
From: rajeevs1992 at gmail.com (Rajeev S)
Date: Sat, 28 Jun 2014 22:55:26 +0530
Subject: [Mailman-Developers] [CLI Project] Support of filtering of objects
	in Command Shell
Message-ID: <53AEFA86.9090801@gmail.com>

Hi,

Now the mid term evaluations are done, I would be building the command 
line shell, as planned. I would like to present how I would like to 
tackle the requirement at hand.

As mentioned in my proposal and the most logical approach, all the 
common functionalities between the shell and the already built command 
line tools would use the same classes, the ones built for the command tools.

As this is a command shell, I wish to give it a SQL like feel. However, 
The SQL commands SELECT, INSERT INTO do not look nice in Mailman 
context, as we are dealing with objects and not tables. I would be using 
the object related terms like SHOW, CREATE etc for the respective actions.

However, I would like to discuss about the support for the WHERE clause 
by the shell.

The WHERE clause is not mentioned in my proposal, but I feel that this 
feature ought to be in the project.

If the commands require to support a WHERE clause, as SQL does,

For example,

 >>> show users where display_name = 'foo' and subscribed_list_ids 
contains = 'list at domain.org <mailto:%27list at domain.org>'

The steps involved in processing a command with a WHERE clause would be


1.Parse the command
2.Filter the results from the database
3.Perform the action using the command line tool methods if possible 
else write a new procedure.

For the Step 2, there are two approaches in hand:

1.Use the Storm library to query the database directly, as mailman core 
does.
2.Use the REST API

By using the first approach, a good performance improvement is achieved, 
by leaving the data filtering to database engine. But this limits the 
usability of of the CLI to the system in which the mailman database 
exists, as the remote connections to DB servers are usually disabled.

By using the second approach, the performance is bad, as it requires a 
normal python `for` loop that compares the the results one by one. 
However, this approach might be easier in case that the mailman 
installation be managed remotely, if its OK to enable the REST API to 
accept connections from remote machines.(I believe this is currently not 
supported/disabled by default.)

By building the WHERE clause, its costlier to reuse the command line 
tools methods in many use cases, like delete, subscribe etc. Further, as 
I have already mentioned to Abhilash, it demands more time. I am not 
sure if that will fit into GSoC time frame. I am confident that I can 
make significant progress, but not sure if it can be 'completed'. Also, 
I am fine on completing it even after GSoC.

So, the final question is, Should the CLI support filtering using the 
WHERE clause? Or should I proceed as per my proposal, building a basic 
Mailman shell and leave the rest to be completed in future?


From barry at list.org  Sat Jun 28 21:25:12 2014
From: barry at list.org (Barry Warsaw)
Date: Sat, 28 Jun 2014 15:25:12 -0400
Subject: [Mailman-Developers] [CLI Project] Support of filtering of
 objects in Command Shell
In-Reply-To: <53AEFA86.9090801@gmail.com>
References: <53AEFA86.9090801@gmail.com>
Message-ID: <20140628152512.1e404b91@anarchist.wooz.org>

On Jun 28, 2014, at 10:55 PM, Rajeev S wrote:

>By using the first approach, a good performance improvement is achieved, by
>leaving the data filtering to database engine. But this limits the usability
>of of the CLI to the system in which the mailman database exists, as the
>remote connections to DB servers are usually disabled.

Not only that, but there no backward compatibility guarantees about the
database schema.  The only guarantee is that there will be some automated
scripts to do schema migration if it does change.

>By using the second approach, the performance is bad, as it requires a normal
>python `for` loop that compares the the results one by one. However, this
>approach might be easier in case that the mailman installation be managed
>remotely, if its OK to enable the REST API to accept connections from remote
>machines.(I believe this is currently not supported/disabled by default.)

Correct, and the core's REST server should never be exposed to the internet.
That's the purpose of the REST proxy layer, probably best provided by
Postorius, which mediates access to the REST API via an authorization layer.

However, it's entirely feasible that additional REST APIs be built that can
provide more advanced access to the data model, such as filtering.  Membership
search and rosters already provide some functionality like this.

Cheers,
-Barry

From stephen at xemacs.org  Sun Jun 29 07:02:16 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 29 Jun 2014 14:02:16 +0900
Subject: [Mailman-Developers] [CLI Project] Support of filtering of
	objects	in Command Shell
In-Reply-To: <53AEFA86.9090801@gmail.com>
References: <53AEFA86.9090801@gmail.com>
Message-ID: <87bntcwbon.fsf@uwakimon.sk.tsukuba.ac.jp>

You don't need to put me in the addressee list if you Cc
mailman-developers.

Rajeev S writes:

 > As this is a command shell, I wish to give it a SQL like feel.

I don't understand why you want it to feel like SQL.  SQL is hardly
something I would expect typical list admins to know about.  Choice of
some of the operators might be inspired by SQL's more-or-less natural
language style.

 > For example,
 > 
 >  >>> show users where display_name = 'foo' and subscribed_list_ids 
 > contains = 'list at domain.org <mailto:%27list at domain.org>'

Given that we use objects, I somewhat prefer

  >>> show users with display_name = 'foo' and
      subscribed_lists containing 'list.domain.org' or 'list.domain.net'

Or somewhat contorted grammar:

  >>> show users with 'foo' as display_name and
      'list.domain.org' or 'list.domain.net' in subscribed_lists

 > 1.Use the Storm library to query the database directly, as mailman core 
 > does.
 >
 > 2.Use the REST API
 > 
 > By using the first approach, a good performance improvement is
 > achieved, by leaving the data filtering to database engine. But
 > this limits the usability of of the CLI to the system in which the
 > mailman database exists, as the remote connections to DB servers
 > are usually disabled.

I think this is a distinction without a difference as the REST API is
usually disabled for remote clients as well.

 > By using the second approach, the performance is bad, as it requires a 
 > normal python `for` loop that compares the the results one by one. 

Extend the REST API if performance bothers you.  (FVO "you" that
include future GSoC students and users.)  I don't think performance
should be a consideration here.  Focus on functionality.

 > So, the final question is, Should the CLI support filtering using the 
 > WHERE clause? Or should I proceed as per my proposal, building a basic 
 > Mailman shell and leave the rest to be completed in future?

I think it should support simple filtering at least.


From rajeevs1992 at gmail.com  Mon Jun 30 09:37:47 2014
From: rajeevs1992 at gmail.com (Rajeev S)
Date: Mon, 30 Jun 2014 13:07:47 +0530
Subject: [Mailman-Developers] [CLI Project] Portioning Commands as Singular
	or Plural
Message-ID: <CAPq4ZOJeAcQvH1EJFAJ7UsAPUK9M0vnRCNeUJi5kdbf04vmkOw@mail.gmail.com>

Hi,

A modification has been suggested for the Command line tools in an IRC
discussion with Abhilash.

It was suggested that, to make commands more intuitive, the commands be
partitioned into singular and plural as per the scale of the action
performed.

For example,

In the current scenario

  >>>./mmclient show user //Lists all users in the system

  >>> ./mmclient show user foo at bar.com //Describes the user foo at bar.com

Usage after the suggested change

  >>>./mmclient show users //Lists all users in the system

  >>>./mmclient show user foo at bar.com //Describes user foo at bar.com

The commands surely do become more intuitive and make more sense, but this
has a negative,the number of commands almost doubles.

Further, Use cases like delete, subscribe and unsubscribe support actions
on multiple users simultaneously.

Currently, the following commands are valid

  >>>./mmclient delete user a at b.com b at c.com d at e.com

  >>>./mmclient delete user a at b.com

If the suggested change is applied, the following commands must work

  >>>./mmclient delete users a at b.com b at c.com d at e.com

  >>>./mmclient delete user a at b.com

both of which perform the same action, using the same procedure.

Another option might be to use *only plurals*, which seems OK for most of
the use cases.

From stephen at xemacs.org  Mon Jun 30 14:52:24 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 30 Jun 2014 21:52:24 +0900
Subject: [Mailman-Developers] [CLI Project] Portioning Commands as
	Singular	or Plural
In-Reply-To: <CAPq4ZOJeAcQvH1EJFAJ7UsAPUK9M0vnRCNeUJi5kdbf04vmkOw@mail.gmail.com>
References: <CAPq4ZOJeAcQvH1EJFAJ7UsAPUK9M0vnRCNeUJi5kdbf04vmkOw@mail.gmail.com>
Message-ID: <87vbriv9tj.fsf@uwakimon.sk.tsukuba.ac.jp>

Rajeev S writes:

 > The commands surely do become more intuitive and make more sense,
 > but this has a negative,the number of commands almost doubles.

The number of instances of "class Command" or whatever it's called
doesn't need to double, though.  You could simply have the parser
recognize the relevant plurals as equivalent to the corresponding
singular forms.  If you want to make life hard, you could do that but
in addition in the parse constrain the command to number agreement
(ie, singular forms of the command must take exactly one argument,
while the plural form must take zero, two, or more arguments).

You could really cheat by simply matching the shortest unambiguous
prefix, so that

    show usersallofthemifyouplease

shows all the users, and (probably) just "show u" does too.  I think
this is perhaps the most efficient solution, although it's not obvious
that unsophisticated users would like it as much as us greybeards do.
For bonus points, if the prefix is ambiguous, show the matching
possibilities.  A trie might be a good data structure for this, and
you could build it on the fly from the list of command names (where
ambiguity would of course be a fatal error).

Finally, if you *do* allow abbreviations, you should restrict that
usage to interactive use; scripts should not be allowed to abbreviate
(they'll break if a new command makes the abbreviation ambiguous).