The mailing list for listmasters using Sympa

[Steve Rich <address@concealed>]

Thank you so much for this info.  It seems to be a good approach to the 
problem that we are having. I was hoping to have a solution that did not 
involve patching Sympa because that can make upgrading a nightmare. I’ll pass 
that along if I get anywhere with it.

Thanks,
Steve








On 10/1/15, 7:19 AM, "address@concealed on behalf of 
Michael Howe" <address@concealed on behalf of 
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
>
>-- 
>Michael Howe, Infrastructure and Hosting Team
>Systems Development and Support
>IT Services, University of Oxford