Aayush Maini writes:
> The basic proposal goes along viz. "Making the services offered by
> the Postorius available via a browser extension/plugin". I thought
> it would be nice to have the functionality offered by the Postorius
> clubbed into a user friendly browser plugin.
> The main highlights of the plugin could include:
> --> User Authentication for identity verification.
> --> Managing/Moderating the subscription requests.
> --> Managing preferences related to a list.
> --> Support for adding owners/moderators.
This is an interesting idea, but Postorius already does all this.
More important, although presently user *authentication* is done via
social auth services (Persona, OpenAuth), *authorization* is done by
Postorius itself on the Mailman server host, not by Mailman core.
Given that you have to go through Postorius in any case, what benefit
do you see from doing it in a browser plugin?
I can think of some possibilities myself, but I'm not very familiar
with browser plugin technology, and worry that it would be browser-
specific (and so not be available to many potential users, unlike
Postorius itself which is pretty much universally accessible).
In any case, promoting your project is your job<wink/>. But if you
give us some ideas, we can help you understand if they're feasible,
and maybe pick up and run with some of the vaguer ones you propose
(yes, "vague" is acceptable at this stage -- refining ideas is very
much something you can learn effectively from a mentor).
I am Aayush Maini, a student of IIIT-H and I would like to propose an idea
for GSOC 2016, under The GNU Mailman. I have got the build working and
submitted a patch for Postorius currently pending for review. I have worked
on mailman core and have a decent understanding of Postorius too.
The basic proposal goes along viz. "Making the services offered by the
Postorius available via a browser extension/plugin". I thought it would be
nice to have the functionality offered by the Postorius clubbed into a user
friendly browser plugin.
The main highlights of the plugin could include:
--> User Authentication for identity verification.
--> Managing/Moderating the subscription requests.
--> Managing preferences related to a list.
--> Support for adding owners/moderators.
* The class of users who would be largely benefited from the browser plugin
would be the list owners and moderators.
* The main purpose of the browser plugin would be to provide the
functionality of the web interface via the compactness of the plugin.
* The job of managing the preferences related to a list(s) can be done via
* Provide the list owner a functionality, to manage the subscriptions quite
easily with minimal number of clicks.
This was just a basic layout of the idea on which I thought the project
could be built. I would be glad to discuss the specifications and some
extensions that could be later added based on the review. It would be real
help if someone could guide me on along the lines of this idea. Thanks.
Computer Science Engineering
This is regarding the solution for issue #194
<https://gitlab.com/mailman/mailman/issues/194> in mailman-core
The discussion for it can be found in the related merge request here
As suggested by Barry, the discussion has been shifted here.
Whenever an address is subscribed to a mailing list, we need to assign a
recipient name to the outgoing welcome mail. eg. To: Anne <anne(a)example.com
'Anne' being the recipient name.
Now if the address is subscribed without a display name, we should look for
other options for the display name.
Suppose you have a user with two linked addresses, one of which is the
preferred address. Only the preferred address has a display name, and the
user does not. Now in the scenario where the other linked address(not the
preferred one) is subscribed to a mailing list without providing a display
name, it would be natural to check if the user has a display name, and use
that if it exists. But the user too does not have a display name in this
case. In such a case should we perform a further check and try to use the
preferred address's display name if it exists or simply use an empty string
In the opinion I gave, in case we are not supplied with a display name, we
should check the user display name followed by the preferred address
display name, and use them in the specified order respectively. If none
exist, empty string would be used.
In a more general scenario, as pointed out by Barry to question this
method, suppose a user has multiple linked addresses, only one of which has
a display name, and its neither the preferred address, nor the subscribed
address. Should the display name search algorithm find that one too, since
it still is a linked address for the user and hence contains valid user
Redirecting to mailman-developers.
On Mar 17, 2016, at 11:56 AM, Rohit Narurkar wrote:
>Now, I am trying to make calls to the REST API through the Rest Template in
>Spring Java, and also through Postman. In Postman, I am adding 2 key-values
>in the 'headers', Content-Type and Authorization. And I am making a GET
>request to " http://localhost:8001/3.0/domains". Whenever I try this, the
>Mailman stops responding and I do not get any response. I cannot even call
>the REST API through Python until the Postman request is cancelled.
What does the log file say? Do you get any tracebacks? You might have to run
pdb to see what's holding things up.
Good evening, my name is Nosikov Konstantin. I am studying in ITMO
University (Saint Petersburg) on department of Information Technologies and
I am interested in two of suggested projects:
Preset list settings templates (aka list styles)
GitLab/development tools integration
So I'm writing to ask how can I tke part in development process and what
should I do to start this project during SoC?
Little problem is that I dont have much expirience in Python, but, as I
know, Python is easy to learn. I am ready and wish to learn some new things
and Python will be great instance.
Waiting for your answer!
Это сообщение было отправлено с неинфицированного компьютера, защищенного
Some of you may have seen my posts on mailman-cabal, but I am installing
a production instance of Mailman 3 on lists.mailman3.org in order to
support initially a Mailman 3 users list.
The first question is should it be mailman-users(a)mailman3.org or
mailman-users(a)mailman3.org. The former is more of a recognition that
Mailman 3 is now Mailman while the latter offers less possibility for
confusion with mailman-users(a)python.org. Then, I suppose it could be
just users(a)mailman3.org, but we might want to support other 'users'
lists in the future.
The next thing is I'm having much more difficulty than I anticipated,
probably in large part because I haven't followed Postorius and
HyperKitty development that closely. I have lots of things I think I
should be able to do in Postorius and I can't and I don't know if the
issue is Postorius or my installation.
I initially installed mailman-bundler from gitlab. configured it for
production, ran buildout and set it up. My initial issue is I couldn't
log in to Postorius at all. I had set a Django superuser, but I see
nowhere to authenticate as that. The only logins offered were Google,
Yahoo and Persona, and they all threw various but similar exceptions.
With Abhilash's help, I got past some of that and I can now log in with
Persona, but there are still issues with the others.
In the process of working through that, I cloned the head of the mailman
branch from github and upgraded to that, but Postorius and HyperKitty
are still what bundler installed.
I got PostgreSQL, Postfix, openDKIM, nginx and gunicorn all configured
and that all seems good.
In the process of working through some other issues, I enabled SSL in
Django with certificates I got from Let's Encrypt. That has led to a
current issue which is if a list's archiving is on, I can't post. The
post gets shunted in archiving because somewhere in the process the
runner tries to make an SSL connection to 127.0.0.1 and the certificate
is only valid for lists.mailman3.org, mirror.list.org and
mirror.mailman3.org. I'm sure there must be a way to change the
connect to use lists.mailman3.org, but I don't know it.
Then perhaps my biggest issue is I can't do any admin tasks in Postorius
other than on my own lists. I can't create lists or domains or edit
domains or anything like that. I even set my user record is_server_owner
flag True, but that didn't help. I managed to do some of what I needed
via the mailman create and mailman shell commands, but I'm sure I should
be able to do that in Postorius, but I can't log in as superuser and it
doesn't seem to care that I'm a server admin. Maybe I need to upgrade
Postorius and HyperKitty.
Which is the next advice I need. I'm thinking of trying to start clean
and I have questions.
Is it better to use bundler and then upgrade what it installed or just
install the separate pieces and try to knit them together or should I
maybe just upgrade Postorius and HyperKitty in place as I did the core.
If I start clean will running the bin/mailman-post-update script
initialize all the data or will there be residue in the PostgreSQL
database that may cause problems.
Sorry for the long post, but I really need advice. I won't be getting
back to this until Wed Evening US Pacific time, so there's time to
 Tracebacks in attached file.
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
On Tue, Mar 15, 2016 at 11:50:10AM -0500, Okusanya Damilola wrote:
>Thanks for your reply. I am currently studying the existing
>and mailarchive (both in src/mailman/archiving) and also Hyperkitty.
>Someone also mentioned in the thread that studying the GNU mailman
>architecture in the "The Architecture of Open Source Applications" would be
>helpful. Is that applicable to this scenario? I will come up with a draft
>implementation on Thursday.
This article will give you a great introduction into the general architecture
of the Mailman core, so it will certainly benefit you to read it. However,
this particular project will probably require only minimal (if any) changes
to the core.
It's a good idea to code a simple draft to check out how the IArchiver
interface works. But at this point in the GSoC application phase it's also
very important to think about where you want to go with this project, like:
Which backend(s) to choose for a start, what possible use cases could be etc.
Thanks for your reply. I am currently studying the existing
and mailarchive (both in src/mailman/archiving) and also Hyperkitty.
Someone also mentioned in the thread that studying the GNU mailman
architecture in the "The Architecture of Open Source Applications" would be
helpful. Is that applicable to this scenario? I will come up with a draft
implementation on Thursday.
On Tue, Mar 15, 2016 at 4:20 AM, Florian Fuchs <f(a)florianfuchs.com> wrote:
> On Sat, Mar 12, 2016 at 01:34:34AM -0600, Okusanya Damilola wrote:
>> My name is Okusanya Oluwadamilola. I am currently enrolled for my Masters
>> programme at Saint Cloud State University at St.Cloud Minnesota. I played
>> around with Apache ActiveMQ last semester and have some basic Python
>> skills. Could you shed some more light about the project? Thanks for your
>> prompt and favourable response.
> The idea behind this project is to use Mailman's (Python-based) IArchiver
> interface to add outgoing posts to a message queue (or pub/sub) system
> can be consumed by any number of applications, no matter if they're written
> in Python or not -- asynchronously, even simultaneously. This would open up
> Mailman to all kinds of use cases, maybe some of them beyond that of a
> "traditional" mailing list.
> One part of the project would be to choose and integrate a small number of
> backends (ActiveMQ could be one of them, but I think both first-in-first
> as well as pub/sub are interesting concepts) to distribute list posts.
> The other part is to come up with an interesting idea how this could be
> and maybe create an implementation of that too (depending on the
> application's scope): Say, hooking it up to a static web page generator. Or
> creating a websockets server based on this. (These are just spontaneous
> -- get creative!).
> In order to prepare for this it makes sense to study Mailman's IArchiver
> interface in the core (src/mailman/interfaces/archiver.py) and check out
> existing implementations: mhonarc and mailarchive (both in
> src/mailman/archiving), but especially HyperKitty.
>> Okusanya OIuwadamilola.
>> Mailman-Developers mailing list
>> Mailman FAQ: http://wiki.list.org/x/AgA3
>> Searchable Archives:
>> Security Policy: http://wiki.list.org/x/QIA9
> Mailman-Developers mailing list
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives:
> Security Policy: http://wiki.list.org/x/QIA9
Regarding my previous mail,
I have implicitly assumed that the testing would involve the use of
examples which do not have a pre-existing valid ARC chain in them i.e. the
test examples would not be containing mails which have multiple ARC set of
headers, and that the ARC chain would be first initiated by Mailman. Such
examples cannot be used for testing before all the milestones are completed
due to the arc verification test being implemented at the end.
We can, however implement such examples in the testing process once the
entire code is completed, since then the arc verification will be in place.
Also, this can be added as a milestone after all the previously mentioned
milestones are complete or can be merged with milestone 8.