[Mailman-Developers] Approach for plugin ideas

Abhilash Raj raj.abhilash1 at gmail.com
Sat Feb 28 06:44:52 CET 2015


On 27 February 2015 at 19:16, Aanand Shekhar Roy <2013001 at iiitdmj.ac.in> wrote:
>
> Based on the discussion with @Abhilash, Below is the modified   approach
> for plugin ideas:
>
> *Banned Words*:
>
>>> 1. We create a common set of words that are to be banned in a mail.
>>
>> How do you create such a list, who decides which words are banned?
>
>> Would it be possible to add/remove words from these lists from postorius?
>
> We create a default list of such words, like common racial and abusive
> words, the list will be displayed on the UI along with which we will
> provide two buttons "add" or "remove" which can allow list admin to modify
> it.

>From where do you obtain such a list? There is only a subset of which
you'd know and that too in a single language. It would be better to just
let the admin add the words he wants to be checked form before the
message is posted to the list.

>> Will this list be list specific or global to one mailman installation?
>
> By default this list will be global to one mailman installation.But then,
> it can be modified as per needs of the list admin so it will be specific
> in general.

So, if we do what I mentioned above, you won't have any list and hence
these checks will be per-list.

>>> 2. In list settings we create an option for list admin to choose action
>>>taken if a mail has banned words.
>> What according to you should be sane default for this?
>> Is is possible that
>> the banned words be removed or replaced with ****** and the mail be sent
>>to
>> the list so as to ease the life of list-admins?
>>
>
> Yes it is possible in the pipeline of handlers where we can extract and
> modify message string object, so the sane default will be replacing the
> banned word with "****". But the UI will provide
> options to list admin to change the default to "accept" or "discard".
>
>>> 3. We need to create a new rule in src/mailman/rules that checks
>>> for banned words in a msg string.
>>> 4. This rule is to be implemented in
>>> src/mailman/chains/builtin.py
>>> where it takes the action as chosen by list admin and then the control is
>>> passed further depending on the action taken.
>
> *Confidential Information Check*:
>
>>> 1. We need to create another rule which check for confidential info. like
>>> phone no and address credit card no. using regexp search.
>> How do you do that check? How can you differentiate any number from
>>phone number,
>
> Below is a regex for a 7 or 10 digit number, with extensions allowed,
> delimiters are spaces, dashes, or periods :
> For example: For numbers like (123) 456 7899, this helps in catching the
> ones with an area code in parentheses ([0-9]\{3\})[ .-][0-9]\{3\}[
> .-][0-9]\{4\}
> We can extend it further to accommodate other international phone-numbers
> as well.
>
>>  or credit card number? (Using reg-ex, yes, but what would the rules
>>be?)
>
> For credit-card numbers like:
>
> Visa : ^4[0-9]{12}(?:[0-9]{3})?$ All Visa card numbers start with a 4. New
> cards have 16 digits. Old cards have 13.
>
> MasterCard: ^5[1-5][0-9]{14}$ All MasterCard numbers start with the
> numbers 51 through 55. All have 16 digits.
>
>> Why is address a confidential information
>
> It depends, for some lists it could be a confidential information.
>
>>and how do you actually decide what
>> level of confidentiality you want to maintain? Will that be
>> configurable per-list or
>> globally in a mailman installation?
>
> We can provide provide checkboxes in postorius which will allow list admin
> to mark  on the required fields.
> Like 1,Phone number
>       2,Credit-card No.
>       3,Address, etc.

How do you check for an address in an email?

The plug-in that you create here should be easy to extend so that others
can add checks for other information which they think are confidential  in
their scenario.

>>> 2. If found we hold that message, and then we send an auto-reply to
>>>sender
>>> asking for confirmation if he
>>> intends to post such information.
>>> 3. This system works similar to the mail-back verification procedure
>>>during confirmation of email while subscribing where potential
>>> subscriber's reply decides the further action to be taken.
>>
>> How will you parse the response of the sender, will there be a
>> pre-defined format
>> like email commands in mailman?
> Yes, we will have some commands like say "OK-forward" in reply that will
> let it proceed further and "No-discard" if we don't want to.
>>Will you provide option in postorius too for the
>> same? If yes, how?
>
> No, keeping same settings will remove the flexibility, sometimes I would
> like to provide my phone number and sometimes no, so email command would
> be a better option.
>
>>> 4.Based on the user's response the held message will be processed
>>>further.
>>
>> Where will the message be stored while mailman waits for the reply from
>>the sender?
>
> We will have to make a queue similar to held message queue for this purpose.

Why is that? Why not just store it in the 'held' messages queue? Why go ahead
and define a whole new queue just to "hold" emails?

>> Will there be a timeout for response after which the email will
>> automatically be
>> rejected (or discarded? )
>> or will mailman wait forever for the
>> response? If you plan
>> to timeout what would be default value?
>
> The timeout will be there for a week after which it will be discarded.
>

I am still expecting an answer on how do you actually plan to create plug-ins
for mailman? All the above ideas are *not* to be just implemented in the core.

-- 
thanks,
Abhilash Raj


More information about the Mailman-Developers mailing list