The mailing list for listmasters using Sympa

[IKEDA Soji <address@concealed>]

Steve, Michael and all,

On Thu, 01 Oct 2015 12:19:32 +0100
Michael Howe <address@concealed> wrote:

> Hi Steve,
> 
> On 30/09/15 17:44, Steve Rich wrote:
> > Hi all,
> > 
> > We are currently running Sympa 6.2.3 and allow external users to use our
> > service.  However, we restrict list creation requests to users within
> > our domains using the following scenario:
> > 
> > title.gettext Only Duke users can request list creation
> > 
> > is_listmaster([sender])                       md5,smime -> do_it
> > match([sender], /.*\@([\w])*\.?duke\.edu$/)   md5,smime -> 
> > listmaster,notify
> > match([sender], /\@gms\.edu\.sg$/)   md5,smime -> listmaster,notify
> > match([sender], /\@dku\.edu\.cn$/)   md5,smime -> listmaster,notify
> > true()                                        md5,smime -> reject
> > 
> > We require the lists to be approved by our service desk so that
> > additional actions can be performed at list creation (reserving the
> > address in identity management systems to prevent mail alias conflicts
> > in various systems, vetting the list name, etc.)
> > 
> > Currently, we have our ticketing system’s email address listed as a
> > listmaster to cheaply get list creation requests to open a ticket so
> > that the bean counter gods are appeased.  This has the undesired effect
> > of opening a ticket every time a notice is sent to the listmasters
> > (sync_include failures, 100% subscriber bounce scenarios, web_internal
> > failures, etc).  
> > 
> > I am seeking a way to have the list creation/change request generate a
> > notice to a specific address outside of the listmasters.  Currently, I
> > am toying with the idea of a custom condition that:
> > 
> >   * Evaluates the regex of the requestor just like the above scenario.
> >       o If allowed
> >           + Sends a notice using perl smtp to the ticketing system.
> >           + Returns true to the scenario
> >       o Else
> >           + Don’t send to the ticketing system
> >           + Return false to the scenario
> > 
> > Does this approach seem logical or is there a better way to do it?
> 
> This sounds very familiar.  I patched our version of sympa (Debian's
> 6.1.17) to add `list_request_notifications_to` and
> `error_notifications_to` config options.  This allows list creation and
> renaming requests to be sent to our helpdesk and error messages to go to
> my team's tracking system.  It also drops mails that would be sent to
> listmaster if there are no owners or they all have nomail set, because
> we decided that we didn't care about such messages.
> 
> I attach the patch; I'm happy to submit it as a feature request if it
> seems like a useful feature.  (Alternatively, if someone comes up with a
> cleaner solution, I'll happily adopt that on my system!)  On re-reading,
> it's got some logic that may need to be tweaked for wider consumption.
> (I also have no idea how it will apply to 6.2; we haven't looked at 6.2
> yet.)
> 
> Best wishes,
> 
> Michael

Attached  patches will classify listmaster notifications in a bit
different way.

Michael's patch defines three sets of emails, while my patch defines
two: "listmaster" and "administrator" parameters.

Listmasters will receive messages sent to <listmaster> address _and_
notifications listed in "listmaster_notifications" parameter.
Remainder of notifications will be received by administrators, _or_
will be ignored at all by setting "administrator" to "none".

I can't decide whether of Michael's way or mine is better.  Please
post your comments.


Regards,

-- Soji

-- 
株式会社 コンバージョン  セキュリティ&OSSソリューション部   池田荘児
〒140-0014 東京都品川区大井1-49-15 アクセス大井町ビル4F
e-mail address@concealed  TEL 03-6429-2880
http://www.conversion.co.jp/

Attachment: sympa-6.1-branch-admin_notif-0.1.patch
Description: Binary data

Attachment: sympa-6.2-branch-admin_notif-0.1.patch
Description: Binary data