The mailing list for listmasters using Sympa

[Steve Rich <address@concealed>]

Hi Soji,

Thanks for this.  It’s close but not quite what we are looking for.

One of the major problems is that in order for our ticketing system to get 
creation/rename requests, listmaster includes the email address of our 
ticketing system.  We are using a hosted solution and do not control that 
domain so it is sort of a security issue for an email address that we do not 
control to be a listmaster.  We could technically put the email address we 
want to receive request notifications in the administrators option and remove 
request_list_creation and request_list_renaming from listmaster_notifications 
but that would still hit our ticketing system with a barrage of error 
notifications.

For this one reason, I believe Michael’s solution to be the better one.  
Otherwise, your implementation seems more configurable and probably more 
sustainable over the long run.


Thanks,
Steve







On 10/5/15, 1:15 AM, "address@concealed on behalf of 
IKEDA Soji" <address@concealed on behalf of 
address@concealed> wrote:

>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/