Re: [Mailman-Developers] GSoC 2015: brainstorming ideas suitable for beginners?
On Feb 27, 2015, at 01:02 PM, Ankush Sharma B.Tech. Electronics Engg, IIT(BHU), Varanasi (U.P.), INDIA wrote:
A personalized mailing list will allow mailman users to send personalized emails to all the list members from a common email template.
Almost all the pieces are already there to support mail merging, at least as a plugin. There's quite a bit of functionality in place to allow for pluggable MTA delivery methods. Right now, there's only one. Search src/mailman/config/schema.cfg for the [mta]outgoing variable.
We also already do a bit of mixin class composition to implement various aspects of the existing personalized delivery machinery. The proper class is chosen (based on the default [mta]outgoing value) from the value of mlist.personalize.
To support mail merge, we'd need a little more flexibility in composing these basic bits. You'd like for individual mailing lists to be able to choose a custom delivery mechanism from a set of site-defined choices, for example.
Then a plugin could define a new delivery class which does the database lookups and the mail merge into the template at the point where the VERP'd message is handed off to the upstream MTA. You'd register this new delivery class with the system and them mailing lists could opt into it.
Cheers, -Barry
Thanks. Barry for the detailed explanation. I will surely have a look on that part as you mentioned.
Thanks, Ankush Sharma github.com/black-perl
On Fri, Feb 27, 2015 at 9:47 PM, Barry Warsaw <barry@list.org> wrote:
On Feb 27, 2015, at 01:02 PM, Ankush Sharma B.Tech. Electronics Engg, IIT(BHU), Varanasi (U.P.), INDIA wrote:
A personalized mailing list will allow mailman users to send personalized emails to all the list members from a common email template.
Almost all the pieces are already there to support mail merging, at least as a plugin. There's quite a bit of functionality in place to allow for pluggable MTA delivery methods. Right now, there's only one. Search src/mailman/config/schema.cfg for the [mta]outgoing variable.
We also already do a bit of mixin class composition to implement various aspects of the existing personalized delivery machinery. The proper class is chosen (based on the default [mta]outgoing value) from the value of mlist.personalize.
To support mail merge, we'd need a little more flexibility in composing these basic bits. You'd like for individual mailing lists to be able to choose a custom delivery mechanism from a set of site-defined choices, for example.
Then a plugin could define a new delivery class which does the database lookups and the mail merge into the template at the point where the VERP'd message is handed off to the upstream MTA. You'd register this new delivery class with the system and them mailing lists could opt into it.
Cheers, -Barry
participants (2)
-
Ankush Sharma -
Barry Warsaw