> It's probably going to require a separate table foreign
> keyed to the mailing list which contain a list of regexps and their actions,
Yeah, it's currently a python list pickled into the header_matches
field of a mailinglist, we can do better :-)
> Then this has to be exposed through the REST
On Sep 10, 2015, at 11:33 AM, Aurelien Bompard wrote:
>> It's probably going to require a separate table foreign
>> keyed to the mailing list which contain a list of regexps and their actions,
>
>Yeah, it's currently a python list pickled into the header_matches
>field of a mailinglist, we can do
Aurelien Bompard writes:
> Hmm, do you think so? I would have thought that list settings
> should take precedence, since they are the most precise. A list
> could decide to not filter the spam and deal with it in their own
> manner (holding it instead of discarding it).
That makes sense when
Hey,
As a Debian fanboy and also a mailman addict, I'd like to try packaging it
in Debian. As I'm not a DD and as I'm not in a hurry, I'd like to take some
time to think about what would be relevant.
For that, I'd like to have some help. And I was suggested to come here and
ask.
I decided to
Pierre-Elliott Bécue writes:
> It seems that if I want to have a good source package, I need 5 repos :
>
> - Mailman
> - HyperKitty
> - Postorius
> - HyperKitty - MailMan Plugin
> - MailmanClient
In the spirit of the refactoring, I would say mailman-core (mailman +
mailmanclient),
On Fri, Sep 11, 2015 at 11:26:44AM +0900, Stephen J. Turnbull wrote:
> Pierre-Elliott Bécue writes:
>
> > It seems that if I want to have a good source package, I need 5 repos :
> >
> > - Mailman
> > - HyperKitty
> > - Postorius
> > - HyperKitty - MailMan Plugin
> > - MailmanClient
>
