Xu Wang writes:
For OAuth http://en.wikipedia.org/wiki/OAuth, you need to
implement token based auth in API, as well as a provider service
because there is no open OAuth provider service for third party API
out there :-(
No, we don't *need* to implement *anything*. We implement what we
Richard Wackerbarth writes:
Ah so you don't mean what I wrote above, you want to represent
preferences as a table with
row = preference-owning-entity att_name att_key
Correct. But isn't it
row = preference-owning-entity att_name att_value
Yes.
Richard Wackerbarth writes:
ABCDEFG is what? The list?
Yes. But note that it is some pk provided by the list store.
pk ?
https://server.example.com/mailman/attribute/posting_address/test_l...@example.com
would return the URI representing the list
Why have you changed the
Richard Wackerbarth writes:
It is not necessary to have more than a flat collection of lists.
I don't know how it will be represented, but we *do* need to support
virtual hosting, where the mailman administrator delegates site
administration to the owner of the virtual host.
In fact, that
Richard Wackerbarth writes:
Primary Key == An identifier of the server's choice that identifies
a unique instance of the specified resource. It is important to
note that the client CANNOT rely on any particular scheme for
mapping other keys to this identifier.
That's true for resources
Stefan Schlott writes:
2. Your list has elevated security requirements. In this case, you can
use gpg-agent to manage the secret key (and its passphrase).
I don't understand what threat you propose to address in this way.
It's true that you can prevent the attacker from getting access to the
Barry Warsaw writes:
OTOH, maybe that's all security theater. If the Mailman system's
private key is available to an attacker, then having the encrypted
message on disk temporarily is probably not going to stop them from
decrypting it.
It's worse than that. The attacker doesn't need
Richard Wackerbarth writes:
subscription - the binding of an email address to a list.
Also preferences are bound here. (This is not the only kind of thing
that preferences can be bound to, but experience shows that we need
per-subscription preferences.)
First, rather than having multiple
Abhilash Raj writes:
I made a small list[1]
[1]: https://gist.github.com/maxking/5455462
I strongly recommend that you put this in your proposal on Melange.
The mentors will all see it on the mentors' list that way, and you
won't get caught short at deadline when Melange crashes.[1]
If you
Chris Cargile writes:
test_not_enough_parameters
(mailman.rest.tests.test_users.TestLogin)
Either the test or the code is borked. Last I heard (at the sprint),
we didn't know why. Comment out that test so that the rest of the
test suite can run.
Abhilash Raj writes:
Can you tell about who is going to mentor this(OpenPGP integration with
mailman)
I would guess the official mentors are likely to be myself and Wacky
(Richard Wackerbarth). Joost isn't official (why not? -- you get a
T-shirt! :-) but he has expressed interest and
Pratik Sarkar writes:
Okay so what should a gsoc student concentrate on for the project?
Writing the proposal!wink/
1.a standardized interface (e.g. MILTER, SMTP/LMTP transport)
Very important. In the case of a filter proposal, which one is up to
you (both are important to Mailman because
Richard Wackerbarth writes:
On Apr 18, 2013, at 8:25 PM, Stephen J. Turnbull step...@xemacs.org 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
Barry Warsaw writes:
There are several ways to think about it, but I guess the easiest
one is does this chunk of processing change the message or make a
non-destructive moderation decision? Or more simply, is it
moderation or modification?
At least for me, the concept is not a problem.
Barry Warsaw writes:
I would love to have contributions to support at least Exim and
Sendmail out of the box. If you're an expert willing to contribute
that code, please get in touch.
I'm not an Exim expert, but my production[1] system uses Exim. I'm
working (slowly) on Mailman 3
Barry Warsaw writes:
It's also probably true that few people actually use the email command
interface - heck even I rarely use it.
Emacs and (some) Debian folks do, though. It's not random, there are
whole constituencies (small) out there for this feature.
Barry Warsaw writes:
but also remember how much pain we had at the sprint trying to get Postorius
and HyperKitty deployed together (how's that coming by the way?).
I got mail from Yarko, does that help? :-)
I hope to get back to that this week, now that I've initialized my
classes. Dunno
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
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
out
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 whole
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
Richard Wackerbarth writes:
On Apr 18, 2013, at 11:42 AM, Stephen J. Turnbull step...@xemacs.org
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
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 try to
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.
-1
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 hard,
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
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.
Avik Pal writes:
Meanwhile It would be much appreciated if someone can direct me to
an labeled dataset available on line.
By labelled you mean pre-classified into spam vs ham? I see you
already found one, but you could also check the SpamBayes and
SpamAssassin distributions.
Here I have
Sneha Priscilla writes:
The one I am most interested in is 'Better User Settings Management'.
I'd like to know if it's a feasible idea for this summer and how
important is it on the list of project ideas for Mailman this year?
As far as I'm concerned, definitely yes (since better involves
Florian Fuchs writes:
2013/4/12 Stephen J. Turnbull step...@xemacs.org:
... is *convenient access to logs via the admin interface*.
This could be something for a HTML(5)/JS/CSS savvy person (to make it
*really* convenient). I'm thinking scrollable log views, that
interactively append
Paul Wise writes:
On Tue, Apr 16, 2013 at 4:08 AM, Florian Fuchs wrote:
This could be something for a HTML(5)/JS/CSS savvy person (to make it
*really* convenient). I'm thinking scrollable log views, that
interactively append/prepend entries to the view, depending on your
position
Pratik Sarkar writes:
Can someone please give me a link of the existing mailman spam filter
techniques.?
Besides the links Mark sent, Mailman 2 site admin pages under Privacy
will explain how to use the already integrated regexp-based filtering.
I'm copying to Mailman-Developers to ensure the other mentors are
aware of your plans.
Pratik Sarkar writes:
Actually my college semester exams are starting from next week thats why I
couldn't spend much time on this proposal.Since you gave a positive
feedback,I will start working on it.
CC-ing Mailman Developers to keep all mentors up to date on what
you're thinking.
Sreyanth writes:
On Mon, Apr 15, 2013 at 4:13 PM, Stephen J. Turnbull
step...@xemacs.orgwrote:
Worse, quoted footers are often actively harmful, because they contain
unsubscribe links for somebody else
Pratik Sarkar writes:
I am working on the proposal.And how many slots are there for the filter
project?
There are no slots for the filter project as such. The whole Mailman
project has slots, and they are somewhat fluid, since we operate under
the umbrella of the Python Software Foundation.
Terri Oda writes:
Or, if it's less trouble, feel free to stick it on the Python wiki
(which is moin) under SummerOfCode; I was hoping to link to it anyhow as
advice to help students, so it is actually going to be relevant to
python students in general.
I think that's the way to go,
Pratik Sarkar writes:
Is the anti-spam/abuse filter still being seriously considered as a
gsoc project this year?
I would say so, yes. Personally, I am fundamentally opposed to it; I
think it's wrong in principle (filtering of this kind should be done
by the incoming MTA) and inappropriate
Paul Wise writes:
One really useful thing to have would be removal of spam from
archives. Here are some examples of how it has been done before:
That's a great idea (and a great example of why I don't think
spam-filtering technology should be embedded in a Mailman handler! :-)
Sreyanth writes:
I have implemented a binary Bayesian classifier which classifies an email
either spam or not spam.
Is it better than (or at least different from) SpamBayes (available on
PyPI), which some third parties already use in Mailman installations?
Let's not reinvent wheels, here!
Sreyanth writes:
Just hide the boilerplate in the email, giving a link to
click. When clicked, use js to unhide the boilerplate. This would
not anyhow require separate storage. Suggest me something if this
is bad!
The main point of sharing links is not storage compression; it's that
the
Patrick Ben Koetter writes:
Perhaps the integration could create an interface itself that makes
it easy to add other filters in the future. I am thinking Postfix
'content filter', which uses SMTP/LMTP to send messages to an
external filter and they send it back then using SMTP.
The
Paul Wise writes:
A generic mailing-list-hoster hosting all 3 of those will want to
allow most mail and add per-list filters.
Of course. SpamAssassin at least can already do that (it allows
mailbox-specific rules).
A properly set up Bayesian filter will notice that certain criteria
are
Sreyanth writes:
I I understood it before too. I proposed this JS approach, as I wondered
why people would anyhow look at the boilerplate! (That's the main point of
the project right!)
Depends on your definition of boilerplate. I consider quoted
mailing lists' footers and those stupid
Sreyanth writes:
Also, I would like to hear more about : Boilerplate stripper AND Better
content-filtering / handling error messages.
Boilerplate stripping is trivial to understand. But, can anyone elaborate
on Better content-filtering / handling error messages?
But boilerplate
Terri Oda writes:
Writing individual pipelines may be trivial, but making a user interface
for managing said pipelines is non-trivial. Right now, our pipeline
management interface is there's a text box in postorius that lets you
choose a pipeline. It's not even a dropdown, and you
Richard Wackerbarth writes:
Therefore, I would suggest that a migration be broken into some components,
1) Migrate individual list parameters
2) Aggregate groups of lists
3) Migrate individual subscriptions
4) Aggregate subscriptions by person.
+1, and perhaps some of these are
Elias Assarsson writes:
On another note I have been able to setup a web UI although it took far
longer than 5 minutes as I struggled with problems due to having both
Python 2.7 and 3.2 on my system.
Did you try a virtualenv? That usually helps with such problems.
Sreyanth writes:
3. Anti-spam / anti-abuse in Mailman.
A couple of people have mentioned anti-spam, and it's a frequently
requested feature. Nevertheless, I don't think we should spend Google
money and mentor time on it.
1. Mailman is the wrong place to do filtering. It's equally
Pierre-Yves Chibon writes:
How do you reply to a thread if you don't have access to the
archives?
The archives provide a URL to the web interface instead of a mailto
URL.
If it is thought as a different system then I understand. I was more
confused if that was thought as part of
Abhilash Raj writes:
Can you please point me in some direction to learn about the various
possible ways to sign a mail and/or encrypt it.
Basically that's going to be MUA-dependent. There are standards for
this (prominently S/MIME aka RFC 5751), but whether MUAs implement it
is
Surya Kasturi writes:
Since no one had so far configured mailman on windows, I guess, I
can try it (not now but.. later on). Why not we build an executable
for windows (.exe) for users to install? This could take sometime
to port and solve conflicts.. but at the end, it would be superb.
Pierre-Yves Chibon writes:
On Sat, 2013-04-06 at 15:03 +0530, Udit Saxena wrote:
2. Web Posting Interface.
Isn't this similar/overlapping to what HyperKitty already does?
No. There's no reason why a web posting interface needs to interact
with the archives; it can talk directly to
Abhilash Raj writes:
Well what i want to make it is that whenever a user sends a mail to the
list it should be singed with his private key so that it can be verified
against his public that he uploads if he wants permissions to post in the
list.
You mean that the user should sign it
Surya Kasturi writes:
Actually, I am on Windows. setting up Mailman is a problem for me.. need
time for that.
Ouch. Do you have access to a VM hypervisor so you can run Linux
inside of Windows? If so, the shortest path home is likely to be
installing Ubuntu there.
Otherwise, we'll help as
Here's a brain bubble for you:
Stephen J. Turnbull writes:
I don't want to discourage you. But please be realistic about your
choice of environment.
Ooh, tasty! How about a Mailman Raspberry Pi?
Seriously, Barry, ya think it's possible?
This would solve the environment problem
Terri Oda writes:
Hi Surya!
On 04/01/2013 09:00 AM, Surya Kasturi wrote:
I have gone through the proposed ideas
http://wiki.list.org/display/DEV/Google+Summer+of+Code+2013 and found some
of them to be interesting..
1. RSS and NNTP access to mailman services
2.
Terri Oda writes:
On 13-03-05 8:28 PM, Stephen J. Turnbull wrote:
OTOH, would it really be that burdensome to keep styles in the
database and allow styles to be updated with appropriate effects on
the lists? A style *change* that could be applied domain-wide (and
DRY-ly!) without
Barry Warsaw writes:
Note that styles are only applied when a list is created, so it is
better to think of them as the default set of attributes for a
list.
I'm unhappy with the name, then. Style defaults would be
pedantically correct.
IOW, if you changed a style after a list is
Paul Boddie writes:
(I love that you'll be able to author pages in reST. :)
You lose some of the more interesting features doing that, though,
I think.
Like what?
And of course if you don't need those features you can use ReST,
right? That is, there's some way to specify markup
Paul Boddie writes:
I was just reading the discussion about Wiki migration from
Confluence to MoinMoin on this list (mailman-developers). When this
topic was first raised, a mailing list was set up
IMO, this list is the appropriate place, and one shouldn't hesitate to
post here about it as
Terri Oda writes:
I know we've been under some pressure from the FSF to switch to a
more free wiki, and they'd offered to find us some help in doing
the migration.
The pressure is real and will intermittently reappear. In my
experience, *specific* help on infrastructure from the *FSF*
Sandesh Agrawal writes:
But i have no idea about how to proceed , can somebody help me please.
Well, first you need to tell us where you're stuck!
The basic procedure is
1. Get a Launchpad account (sooner or later).
2. Check out the most recent commit to the sources you're interested
Gordon P. Hemsley writes:
Thus, a subject line that begins [css3-fonts] will be assumed to
be about only the css3-fonts spec, [...] and not, say, the
css3-flexbox spec (subject lines prefixed with [css3-flexbox]).
To handle this, the Mailman archive interface would provide an option
Terri Oda writes:
Is it possible to split or merge threads?
Posters can split off a thread at any time by just replying to +new
instead of the existing thread.
So if somebody is subscribed to the old thread, and their default is
not to automatically subscribe to new threads, they lose
Terri Oda writes:
In a dlist-enabled list, every message is part of a thread, as
determined by the posting address used
(mailinglist+threadn...@example.com or +new for a new thread whereupon
we create a new name).
How is the new name determined?
What happens if you just post to
Mark Sapiro writes:
Scot Hacker wrote:
Long story short, if I were to submit a patch, would it likely be
accepted? Or is there a good reason why it's not included?
Probably yes. The reason it was never include upstream is that Apple
has *never* shared any of its Mailman changes
Terri Oda writes:
I think people had a lot of fun seeing their code go live on our test
server and watching their bugs get fixed, and I think we've got a few
contributors who'll be interested in doing more (and maybe, once I
wrangle the travel funds, coming to pycon!). I'm so very
Terri Oda writes:
I don't suppose anyone here has some hidden graphics-fu and could help
me out? the buttons have a 1.375in printable area,
I'm no graphics expert, but at that size, I'd avoid gradients unless
you've got at least 1200dpi, preferably 2400dpi resolution.
You could try
Patrick Ben Koetter writes:
I think if we release MM3 without 'a frontend' we will miss
people's expectation to get a feature complete MLM - which includes
a frontend in most peoples opinion I guess.
I agree on the basis of introspection (which is obviously a
statistically biased sample),
Barry Warsaw writes:
Currently, JSON is the only supported output format. I'd be open to patches
that provide other output formats.
Please, no. Filters are one honking great idea. Let's do more of
those!
I think most of the interesting programming languages people might
write Mailman
Bob Puff@NLE writes:
I don't want more servers (processes). I need secure,
low-footprint, low cpu-utilization processes.
You're not going to get more processes unless you want them. The
processes currently planned are just called runners now, and will be
less coupled than currently.
Terri Oda writes:
That said, I'm tentatively planning a personal postorious hackathon all
day Saturday the 22nd. If anyone wants to join me, I'll be on #mailman
on freenode!
I don't think I can join but maybe Could you be a bit more
specific than all day (especially time zone)?
Mark Sapiro writes:
If mailman generates web pages with non-ascii, say utf-8 encoded
characters and the installation's web server assigns a default character
set other than utf-8, all the utf-8 encoded characters will be garbled.
This will not happen if the characters are encoded as HTML
Patrick Ben Koetter writes:
They have free accounts for open source projects. It might be a
nice way to organize a translation community.
It's likely that we don't have to organize one, we already have one.
Barry, why don't you try to get in touch with that Vietnamese lady and
see what she
Patrick Ben Koetter writes:
My bet is you will receive more feedback if you start implementing DMARC
relevant features into MM3 code. If you get Murray Kucherawy, I don't know if
he's still on the list, to contribute/share ideas on DMARC you will very
likely get a bulletproof
Richard Wackerbarth writes:
I think that you are finally beginning to understand the
perspective that I am trying to provide.
I don't have any trouble understanding the perspective you're trying
to provide in the abstract; it's just Software Systems Design 301.
What I have trouble seeing is
Joshua Cranmer writes:
How to solve that? The only possibility I could think of uses the
filter mechanism of the available newsgroups. The clients could supply
a regexp like filter. I would implement a mechanism, that shows
unadvertized lists with an archive only if the supplied
Richard Wackerbarth writes:
We should not be required to repeat this in the future. Therefore,
we need to have a service level interface for ALL inter-service
interactions, even if we do not require the RESTful implementation
of those interactions at this time.
I guess I think of
Richard Wackerbarth writes:
I think that you have missed a level of abstraction.
Why do we need it? AFAICS, at this point we have a bunch of services
that need to be specified somehow. We *need* a RESTful interface for
some functions because they make the most sense if accessed remotely,
and
Richard Wackerbarth writes:
As an example, suppose that I want to have an intelligent ToDo
indicator. As a minimum, I need to be able to get from the data
store a list of MLs that have pending requests AND for which I am
authorized to do that work. Typically, this would be some kind of
Alexander Sulfrian writes:
If the list_name would be also reversed, it could lead to some
surprising subtree clashing. For example web2.0 would be in the same
subtree like something1.0 (people sometimes use strange list
names...).
I agree that list_name should *not* be reversed; it is an
Richard Wackerbarth writes:
There seems to be two fundamental design strategies being discussed.
One of them has a monolithic data store and the other has a
distributed store.
Barry has expressed some reservations about overloading a
monolithic data store with data extraneous to the
Barry Warsaw writes:
I don't see any reason why it couldn't be mapped to a REST API; it's just a
lack of need, and nobody's written it yet. The question is whether
IUserManager is actually the right API for a REST interface - in general I
don't think you need a 1-to-1 mapping of internal
Barry Warsaw writes:
The question is whether we want to support running the core without
having this user service available, i.e. in standalone mode. Are
we going to require that this service be running in order to run
the core? I think we shouldn't be so strict.
But *some* user
Richard Wackerbarth writes:
What I am advocating is that the core message handler NOT be the
keeper of ONLY PART of it.
What I'm advocating (mildly, because somebody else is going to have to
do the work) is that the core be the keeper of ALL of it. The core is
not just a message handler.
Florian Fuchs writes:
But I also agree with Terri that there might be a good amount of user
data used by Postorius, Hyperkitty or any other web ui/client that just
doesn't have anything to do with mailman's core tasks. And I don't see
why something like preferred ui theme or
Richard Wackerbarth writes:
Pretty soon, you will find that what you need approaches something
that already exists -- a relational database. Rather than
reinventing the wheel, we should just use an already existing
database system and make all of the data directly accessible.
We're
Richard Wackerbarth writes:
No! Although you are making available (some/most/all) of the data
values, you are not making available the ability to make arbitrary
SQL-type queries to view the data.
AFAIK the plan is to do that via the REST interface. I don't see why
they need to be
Richard Wackerbarth writes:
I am encountering a problem with login on Postorius. There is no
mechanism to keep the MM user database synchronized to the one
which django creates.
Since Postorius is the facility by which admins will expect to access
the user database, I have to consider that
Richard Wackerbarth writes:
Since by far the most complicated, and most used, logins will be
made from the web interface, it is much more logical to allow
Postorius to be responsible for all of the user profile information
and have the core, on those rare occasions where it requires it,
Danci Emanuel writes:
After all I managed to fix this one also. The problem was that mailman was
trying to access /var/data/mailman.db, which did not contain
the dlists_enabled column, so it was seeing it as a corrupt file.
I just deleted it, restarted mailman and it`s working great!
I
Barry Warsaw writes:
What's blocking progress is SQLite, [which] has a very limited
ALTER TABLE command, and specifically does not support column
renaming or deleting. This really sucks for implementing any kind
of schema migration, regardless of the framework.
So it's the renaming that
Barry Warsaw writes:
Should the prefix [for the archived news hierarchy] be
configurable then?
Yes, but once we figure out what it should be, admins should be
strongly advised not to change the prefix if they allow mirrors.
___
Mailman-Developers
Ian Eiloart writes:
OK. Where do these two email addresses sit?
Addresses aren't relevant. I proposed using List-Ids, which have to
be unique (RFC 2919). If an administrator specifies List-Ids that
collide, that's not our problem. (The author of RFC 2919 was aware of
similar problems,
I don't think Terri needs a cc, if she's not on mm-d.
Barry Warsaw writes:
The top-level maybe shouldn't be mailman, but rather something like
list-archive.
Why is the prefix needed at all, especially since you qualified this as not
gatewayed to Usenet? If all the messages are local
Alexander Sulfrian writes:
RFC 3977 explicit requires the CAPABILITIES command to work for
conformance. It should not be hard to implement it, so in my opinion
it should be listed as required.
Sure, but please remember that *you* have a deadline. When you write
up requirements, make sure
Note: CC'ing Mailman Developers. I think this was private, so not
trimming.
At the bottom there's a discussion of the newsgroup naming scheme,
which is an important bikeshed to paint. If you're not interested in
a bunch of me too comments, skipp right on down there!
Barry Warsaw writes:
Hi
Lindsay Haisley writes:
pkg_resources.DistributionNotFound: zc.buildout==1.5.2
Butbutbutbutbut:
ii python-zc.buildout 1.5.2-1
system for managing development buildouts
Hm. I suspect that Debian has installed zc.buildout for a different
Richard Wackerbarth writes:
The current design of the Postorius and Hyperkitty web interfaces
to the mailing list and its archives uses the fully qualified list
submission email address as a component of the URLs presented to
the public.
I fear that doing this will create an even
601 - 700 of 969 matches
Mail list logo
