Hi there,
Although mailman3 installation is well documented, but putting everything
together is still not a trivial job.
To ease the task, I made a mailman3 chef cookbook and vagrant file:
https://github.com/xuwang/mailman3-vbox
If you already had virtualbox/vagrant installed on your mac or pc,
Hi ,
Sorry for late reply, there's lot of college work on hand.
> Thanks for creating the two examples! I took a quick look at them and
> it looks like both frameworks are pretty easy to use if a resource is
> based on a typical Django model. The Mailman resources OTOH are not
> retrieved from a d
Main comment: Sounds like LDAP to me.
Florian Fuchs writes:
> 5) It should implement an oAuth provider.
I don't see this. Mailman is an auth consumer. The only people
Mailman can provide auth for are the site admins. Everybody else is
more or less untrustworthy.
I can see that there are app
2013/4/18 Stephen J. Turnbull :
> Florian Fuchs writes:
>
> > 5) It should implement an oAuth provider.
>
> I don't see this. Mailman is an auth consumer. The only people
> Mailman can provide auth for are the site admins. Everybody else is
> more or less untrustworthy.
>
> I can see that there
Whoa! Perhaps I don't understand oAuth. I thought that oAuth (and persona,
kerberos, etc.) were protocols whereby one system (the provider) furnishes
credentials for a second system (the client) to some third system (the
consumer).
By configuration, the consumer trusts that the provider has ver
On Apr 18, 2013, at 1:19 AM, Florian Fuchs wrote:
> Hi,
>
> some first thoughts on it:
>
> 1) It should be self-contained.
> Meaning: It should not depend on any
> mailman/mailman.client/postorius/hyperkitty packages.
Agreed
> 2) Like the core, it should implement a Python-based webserver.
>
Thank you Terri and Stephen for your replies and explaining the whole
procedure of selection.
Coming back to the project,do we need to write patches for the SpamAssassin
or SpamBayes(which are integrated in Mailman) or do we need to start over
and make a whole new filter and start reinventing the w
Florian Fuchs writes:
> But maybe we can take a moment to think about the usefulness of such a
> feature and the possibilities this might open up, rather than
> dismissing the use of a certain technology right off the bat.
I'm not dismissing the use; I'm saying an authentication provider is
ou
Pratik Sarkar writes:
> Coming back to the project,do we need to write patches for the
> SpamAssassin or SpamBayes(which are integrated in Mailman)
No. You write a Handler which delegates to those external packages.
A Handler is a sort of plug-in.
> or do we need to start over and make a who
On 13-04-18 8:03 AM, Richard Wackerbarth wrote:
On Apr 18, 2013, at 1:19 AM, Florian Fuchs wrote:
1) It should be self-contained.
Meaning: It should not depend on any
mailman/mailman.client/postorius/hyperkitty packages.
Agreed
I agree about not needing postorious/hyperkitty, but I think a
Richard Wackerbarth writes:
> Whoa! Perhaps I don't understand oAuth. I thought that oAuth (and
> persona, kerberos, etc.) were protocols whereby one system (the
> provider) furnishes credentials for a second system (the client) to
> some third system (the consumer).
That's correct.
> If we
On Apr 18, 2013, at 11:42 AM, "Stephen J. Turnbull" wrote:
> Richard Wackerbarth writes:
>> There is no reason why alternate channels [to a connection from
>> localhost authorized by the OS] cannot be substituted as long as a
>> means of identification (such as shared secrets) is utilized.
>
>
On Sat, Apr 13, 2013 at 12:09 PM, Terri Oda wrote:
>
> go ahead and get a VM set up;
>
> Chris, who was working on such a thing before, seems to have gotten stuck
> somewhere You probably also want to talk to other incoming students
> who've already set up their dev environment since they'll
Richard Wackerbarth writes:
> On Apr 18, 2013, at 11:42 AM, "Stephen J. Turnbull"
> wrote:
>
> > Richard Wackerbarth writes:
>
> >> There is no reason why alternate channels [to a connection from
> >> localhost authorized by the OS] cannot be substituted as long as a
> >> means of ident
On Apr 18, 2013, at 11:42 AM, "Stephen J. Turnbull" wrote:
> Richard Wackerbarth writes:
>
>> Whoa! Perhaps I don't understand oAuth. I thought that oAuth (and
>> persona, kerberos, etc.) were protocols whereby one system (the
>> provider) furnishes credentials for a second system (the client)
On Apr 18, 2013, at 12:21 PM, "Stephen J. Turnbull" wrote:
> Richard Wackerbarth writes:
>> On Apr 18, 2013, at 11:42 AM, "Stephen J. Turnbull"
>> wrote:
>>
>>> Richard Wackerbarth writes:
>>
There is no reason why alternate channels [to a connection from
localhost authorized by th
On Apr 18, 2013, at 11:26 AM, Terri Oda wrote:
> On 13-04-18 8:03 AM, Richard Wackerbarth wrote:
>> On Apr 18, 2013, at 1:19 AM, Florian Fuchs wrote:
>>
>>> 1) It should be self-contained.
>>> Meaning: It should not depend on any
>>> mailman/mailman.client/postorius/hyperkitty packages.
>> Agr
2013/4/18 Richard Wackerbarth :
> Whoa! Perhaps I don't understand oAuth. I thought that oAuth (and persona,
> kerberos, etc.) were protocols whereby one system (the provider) furnishes
> credentials for a second system (the client) to some third system (the
> consumer).
>
> By configuration, th
* Barry Warsaw :
> On Apr 12, 2013, at 08:28 AM, Patrick Ben Koetter wrote:
>
> >I think it would be real nice to have a MILTER interface at LMTP server level
> >to allow mail modification as required. Mailman runs in large environments
> >and
> >all the 'large organizations' I have worked asked
2013/4/18 Richard Wackerbarth :
> On Apr 18, 2013, at 1:19 AM, Florian Fuchs wrote:
>> 3) It doesn't need Django.
>> Since it will not deliver any HTML (except an oAuth login form -- see
>> 5.) and it doesn't need to be integrated into any existing web site,
>> we can choose a more light-weight fr
On 13-04-18 2:28 AM, Stephen J. Turnbull wrote:
Main comment: Sounds like LDAP to me.
Actually, this is a really important comment. I was sort of wondering
that too when I started writing the description. LDAP is a moderately
frequently requested feature already. Would it make sense to use t
2013/4/18 Terri Oda :
> We're probably going to be running around with a bit of a hack job for the
> user database in the near future (either done by a student who needs it in a
> hurry or done by one of the core devs to support a student who needs it in a
> hurry) so while I don't like to design o
* Pratik Sarkar :
> Hi guys,
>Is the anti-spam/abuse filter still being seriously considered
> as a gsoc project this year?
I - personal opinion - think adding a anti-spam/abuse filter is a good idea. I
do however stronly oppose against a hardcoded implemenation that e.g.
integrates S
On 13-04-18 1:40 PM, Patrick Ben Koetter wrote:
I - personal opinion - think adding a anti-spam/abuse filter is a good
idea. I do however stronly oppose against a hardcoded implemenation
that e.g. integrates SpamAssassin only or a new Bayesian filter.
I hope that no one was seriously consider
Yeay, thanks!
If you've got time, could you make sure your vm is linked on the mailman
wiki docs? You can replace the comment I have on the GSoC page for
sure, and there's probably a good place to link it in a couple "setting
up your dev environment" pages.
Terri
On 13-04-18 1:39 AM, Xu W
On Apr 18, 2013, at 2:39 PM, Florian Fuchs wrote:
> 2013/4/18 Terri Oda :
>> We're probably going to be running around with a bit of a hack job for the
>> user database in the near future (either done by a student who needs it in a
>> hurry or done by one of the core devs to support a student wh
Yes, yes. Please re-invent the wheel once again.
And while you are at it, you might just remove the dependancies on zope and
storm, etc.
I think that you are missing the point that, at this time, this is intended to
provide the capabilities that MM-core chooses not to implement.
Those website c
On Apr 18, 2013, at 1:54 PM, Florian Fuchs wrote:
> 2013/4/18 Richard Wackerbarth :
>> Whoa! Perhaps I don't understand oAuth. I thought that oAuth (and persona,
>> kerberos, etc.) were protocols whereby one system (the provider) furnishes
>> credentials for a second system (the client) to som
* Terri Oda :
>
> On 13-04-18 1:40 PM, Patrick Ben Koetter wrote:
> >I - personal opinion - think adding a anti-spam/abuse filter is a
> >good idea. I do however stronly oppose against a hardcoded
> >implemenation that e.g. integrates SpamAssassin only or a new
> >Bayesian filter.
>
> I hope that
2013/4/18 Richard Wackerbarth :
> Yes, yes. Please re-invent the wheel once again.
>
> And while you are at it, you might just remove the dependancies on zope and
> storm, etc.
>
> I think that you are missing the point that, at this time, this is intended
> to provide the capabilities that MM-co
What I am suggesting is that we use the JSON format and URLs that are generated
by this combination.
If you later decide to implement it in a different framework, you can still use
the same external representation.
On Apr 18, 2013, at 4:33 PM, Florian Fuchs wrote:
> 2013/4/18 Richard Wackerbar
On 4/18/2013 1:32 PM, Patrick Ben Koetter wrote:
> * Terri Oda :
>>
>> I hope that no one was seriously considering that level of
>> hardcoding. What we are almost certainly talking about is setting
>> up a handler (I think Stephen estimated this to be around 10 lines
>> of code).
>
> And that ha
On Apr 18, 2013, at 10:32 PM, Patrick Ben Koetter wrote:
>And that handler would be - excuse my ignorance I don't program - a Python
>function to handle a Python program? Could the handler pass a message over to
>e.g. SpamAssassin (Perl) or openDKIM (c code) or any other non Python program
>withou
On Apr 18, 2013, at 01:10 PM, Chris Cargile wrote:
>The cause in both cases seems to stem from failing at the SMTPLayer, where
>it shows: [Error98] Address already in use.
This almost always means that some runner process from a previous test didn't
exit. I've tried to bulletproof the process ma
On Apr 18, 2013, at 01:56 PM, Rahul Gaur wrote:
>Talking about authentication, django-restframework has a wrapper for OAuth2
>out of the box, but I will have to check how to use non form data sources.
I keep hearing terrible things about OAuth2.
OAuth1 is nice and simple and there are plenty of
* Mark Sapiro :
> On 4/18/2013 1:32 PM, Patrick Ben Koetter wrote:
> > * Terri Oda :
> >>
> >> I hope that no one was seriously considering that level of
> >> hardcoding. What we are almost certainly talking about is setting
> >> up a handler (I think Stephen estimated this to be around 10 lines
>
On Apr 19, 2013, at 02:40 AM, Patrick Ben Koetter wrote:
>My original point was that we should use MILTERs because we shouldn't reinvent
>what already has been implemented very well and we shouldn't come up with a
>proprietary solution, because that will make it harder to expand Mailman and
>also
Richard Wackerbarth writes:
> Perhaps I didn't understand you. I thought that you were
> advocating the omission of any channels other than "shell" and
> "localhost".
I'm saying that we should make appropriate Mailman components be OAuth
clients (subject to site policy, per component), but tr
Richard Wackerbarth writes:
> I have no problem with, and actually encourage, that we act as a
> consumer of oAuth credentials.
+1
> However, the issue here is whether we should be provider of oAuth
> credentials (which might then be presented to some outside, totally
> unrelated, entity.
Terri, thanks for kicking off this discussion!
On Apr 18, 2013, at 01:34 PM, Terri Oda wrote:
>On 13-04-18 2:28 AM, Stephen J. Turnbull wrote:
>> Main comment: Sounds like LDAP to me.
>Actually, this is a really important comment. I was sort of wondering that
>too when I started writing the des
Florian Fuchs writes:
> If the instance of the user store does not act as provider, we would either:
>
> 1) effectively require every api user to have an account with some
> other oauth provider.
Most people do.
Sites that care can bring up their own provider. AFAIK that's not
terribly har
Richard Wackerbarth writes:
> Since we consider the user manager to be a part of the MM complex,
> what have we gained by hiding the underlying credential from the
> web interface?
Security. See the OAuth 2.0 spec (RFC 6749) which recommends (at
SHOULD level) this practice.
_
Barry Warsaw writes:
> I still think this wouldn't be a handler, but a rule.
Is this distinction implemented and enforced by the API? If not, it's
going to be hard to persuade myself to make the distinction in
discussion. Ie, I'll probably just go on calling everything a Handler
unless somebod
Barry Warsaw writes:
> What's interesting to me about it is that this acknowledges that
> administrative control of this extra user information may fall to
> folks not at all directly involved in mailing list administration.
I think this is crucial to World Domination^W^WMailman 3 uptake.
>
On Apr 18, 2013, at 8:25 PM, Stephen J. Turnbull wrote:
> Richard Wackerbarth writes:
>
>> Since we consider the user manager to be a part of the MM complex,
>> what have we gained by hiding the underlying credential from the
>> web interface?
>
> Security. See the OAuth 2.0 spec (RFC 6749) w
45 matches
Mail list logo
