Hello everyone in the community. As you may or may not know,
I've applied a proposal in Melange for Web Posting Interface.
The description of the project idea states: the interface
itself may not take the whole summer, so I've come up with
some features that I would like to implement for Mailman
On 27 Apr 2013, at 14:40, Richard Wackerbarth r...@dataplex.net wrote:
I don't think that we have the expertise to create a secure system. At
best, we can adopt good practices and provide an obscured traffic stream. I
consider anything more to be beyond the scope of the MM project.
Also,
On 29 Apr 2013, at 09:39, Peter Markou markoup...@gmail.com wrote:
Hello everyone in the community. As you may or may not know,
I've applied a proposal in Melange for Web Posting Interface.
The description of the project idea states: the interface
itself may not take the whole summer, so
On Apr 28, 2013, at 11:59 PM, Stephen J. Turnbull step...@xemacs.org wrote:
Richard Wackerbarth writes:
snip
My point is that IMHO it's flexible *enough*.
I'm advocating that we attach the roles (whatever they may be) to
an entire collection of lists.
I know what you're advocating, and I
On 29.04.2013 11:40, Ian Eiloart wrote:
Also, what kind of secure list would have automated processing of
message content as a requirement?
imho you're asking the wrong question ;-) _All_ network communication
should be encrypted, it is a pity that mail encryption is so little adopted.
If a
Ian Eiloart writes:
Also, what kind of secure list would have automated processing of
message content as a requirement?
Precisely, a list that wants to avoid this requirement:
If a message is gpg encrypted, then every sender would require the
public keys of every recipient, would they
On 4/29/13 5:40 AM, Ian Eiloart wrote:
Also, what kind of secure list would have automated processing of
message content as a requirement? If a message is gpg encrypted, then
every sender would require the public keys of every recipient, would
they not? Which means that a PKI for the list
Richard Wackerbarth writes:
So you have at least three layers. Do you really think that it is
more difficult to implement a general recursive tree than it is to
implement those layers?
No. What I think is difficult is to implement a general recursive tree
*and* an API for expressing
On Apr 29, 2013, at 8:12 AM, Stephen J. Turnbull step...@xemacs.org wrote:
Richard Wackerbarth writes:
So you have at least three layers. Do you really think that it is
more difficult to implement a general recursive tree than it is to
implement those layers?
No. What I think is
1. I would like to remind/tell you all that FOR THIS RELEASE, we will
ONLY be supporting Mozilla Persona and passwords as authentication
methods. This is not up for discussion at this time; it's a choice
we've made to in order to help move the release forwards.
2. As such, any discussion
On Apr 29, 2013, at 3:06 PM, Terri Oda te...@zone12.com wrote:
1. I would like to remind/tell you all that FOR THIS RELEASE, we will ONLY be
supporting Mozilla Persona and passwords as authentication methods. This is
not up for discussion at this time; it's a choice we've made to in order
On 13-04-29 3:25 PM, Richard Wackerbarth wrote:
I'll go further than that and suggest, for the purpose of GSoC:
[snip details]
These are good if you're going to do the implementation. If you're not,
I'm happy to leave some of these details up to the person who actually
writes the code.
Richard Wackerbarth writes:
There are two aspects of using a generic tree. The first is some
customization of the tree to fit the installation's delegation
model. Here, I would suggest that sample base installations
Once again, you're making an argument based on theory that nobody
Terri Oda writes:
1. I would like to remind/tell you all that FOR THIS RELEASE, we will
ONLY be supporting Mozilla Persona and passwords as authentication
methods.
3. While I agree that thinking about these things in advance is useful,
I think this discussion is starting to crowd
14 matches
Mail list logo
