Sympa Mailing List Server New features in Sympa New Web interface Approving posts (in Moderation) Web Archive and Posted Files Membership management Controlling access with Scenari Creating a list Defining membership Customising notifications S/MIME (and other cool features) Questions!

Sympa Mailing List Server What are mailing lists? Point In time Event Based Historical Personal, active Email archive Phone call eMail Public, active Mailing List Mailing List web archive Communication can be broadly classified using three criteria: personal/public, active/passive, and time frame. Personal/public – is it directed at a specific person (phone call), or broadcast (possibly to a restricted set of subscribers)(newspaper) Active/passive – does it come to you (phone call), or do you have to fetch it (newspaper)? Time frame – tied to a specific time (phone call), tied to an event (a letter), or not tied to a time at all (a history book)? The only thing I can think of that is Personal/Passive is a message specifically for you in the newspaper small ads.. “If you were the cute blonde on the bus this morning….”. IE, a message specifically for you that you wont receive unless you are actively looking for it. This is very rough as many forms of communication fit over multiple categories. Also there are things like interactivity to consider. Mailing lists fill a gap for Public/Active delivery of event-based information. A list of recipients to forward a given message to Single or multiple posters (announce/discussion) Active delivery (not passive, eg Facebook) No such thing as personal/passive, that would be silly Web-based historical archives Facebook Web forum Public, passive Twitter

Sympa Mailing List Server New features in Sympa Self-service list request, creation, management, etc Virtual list domains with different rules, interface, etc High level of control over posting and subscription rules LDAP, SQL and HTTP integration S/MIME authentication support Shibboleth/LDAP authentication Consolidated personal subscription management Personalisation (Mail-Merge) support Autoprovisioning of lists Many new features that the old MailMan system did not provide. Also, a more user-friendly web interface for administrators!

Sympa Mailing List Server Why are we changing? Efficiency Bringing all list servers together into a common interface Roles & Responsibilities project Bring faculty list servers into common systems Need new features to provide capabilities required Improved service Self-provisioning capabilities Netaccount Integration = simpler membership management Stability New software under active development and support Also, New features – secure and signed mailing lists! Mail merge capability!

Sympa Mailing List Server New Web Interface One login for all your lists Shibboleth Integration and single-signon Creation and configuration of lists Membership management Post moderation Web archive of list postings Vacation controls Personal preferences New terminology: ‘Editor’ is a Moderator. ‘Owner’ is list administrator. Editors can approve postings, manage membership and archives Owners can reconfigure list Editors are notified of new members, new moderated postings, etc Owners are only notified for major tasks (list removal, etc) Owners and Editors are notified if their roles change

Top banner allows login via Shibboleth, NetAccount password, and generated password (for non-UoA accounts) Tab row lets you select admin commands, search pages, and different list domains Departmental list domains can be created for you Search for lists by name, partial name, or Category (also called a ‘topic’). We can create new Categories if required. See the list of lists you have subscribed to or are owner/moderator for in the Subscribed Lists box. You can manage your subscriptions in bulk if required (unsubscribe, set vacation settings, etc) Links are hidden if you do not have the required level of access to use them Context-sensitive help available everywhere!

List information shows list owners and moderators, as well as member count Can conceal owners and/or moderators as required. Owners can be ‘figureheads’ who are not mailed with list information. List Information is configurable by list owners Commands box allows you to manage your subscription, view archives, perform moderation, and administer list memberships and configuration. Links are hidden if you do not have the required level of access to use them Shared documents link is here as well, if your list is using this feature.

Sympa Mailing List Server Approving Postings: All things in Moderation User Moderator User makes post Posting scenario checked If rejected, notify sender If accepted, distribute post If moderated, notify user of moderation, and notify editors of arrival of new post Admin can confirm or reject post by web or by email ‘Scenario’ is a rule set defining who is allowed to perform an action – in this case, who can post to the list. Scenario outcome in this case may be accept, reject, or require some sort of verification or moderation Scenario rules can allow some people to post but require others to be moderated Moderators can approve postings either via the web interface, or by replying to notification email using certain subject keywords. All instructions are in the notification email.

Sympa Mailing List Server Moderator notification email One new message for list sshi052-test from s.shipway@auckland.ac.nz arrived.   1 messages are awaiting moderation. To view the messages, please click on the following URL: /ticket/ <https://sympa.auckland.ac.nz/sympa/ticket/17053309131637> To distribute the attached message in list sshi052-test: <mailto:sympa@sympa.auckland.ac.nz?subject=DISTRIBUTE%20sshi052-test%20bf95f771ef3cc4c59ddb1d825ba68054> Or send a message to sympa@sympa.auckland.ac.nz with the following subject: DISTRIBUTE sshi052-test bf95f771ef3cc4c59ddb1d825ba68054 To reject it (it will be removed): <mailto:sympa@sympa.auckland.ac.nz?subject=REJECT%20sshi052-test%20bf95f771ef3cc4c59ddb1d825ba68054> REJECT sshi052-test bf95f771ef3cc4c59ddb1d825ba68054 The messages moderating documentation: <https://sympa.auckland.ac.nz/sympa/help/admin#moderate> Notification email contains embedded links Email for moderation can be attached to notification email

Web-based moderation interface lists all pending emails Moderator can view emails before deciding Rejection can be set to notify the sender or not; also senders can optionally be added to a blacklist.

Sympa Mailing List Server Membership Management Posting User: Subscribe, Unsubscribe Via email or web May require approval Blacklist User Subscribers Admin: Add and remove users Approve pending Set blacklists Explicit adds External Sources Admin Database: NetAccount groups LDAP query Other lists’ members External files SQL query Depending on list configuration, users may subscribe to and unsubscribe from list using either email or web interface List Editors (Moderators) can manually add and remove list members, and administer the Blacklist Members can be set to ‘mail’ or ‘nomail’, and visible or concealed If you want a specific non-member email address to be able to post to the list, then you should add the address as a ‘nomail/concealed’ list member or Editor. This is a big change from the old MailMan lists which had a separate group for this category. Exclusions Database Deliver!

Can see which source members come from (explicit adds, subscription, or external data source) Can click on users to set options (name, delivery options, etc) Add or delete users from list, use ‘quiet’ option to avoid sending a notification email. Use ‘Remind’ option to remind users of their list membership, and allow them to unsubscribe Approve pending subscriptions, administer blacklist, check bounces list and exclusions. Resynchronise external datasource manually (automatic frequency is set in list configuration, but defaults to Daily in order to not overload LDAP server)

Sympa Mailing List Server Web Archives and Posted Files Automatic archive expiry Restrict archives to members, moderators, or public Searchable View chronologically or by thread Posted files are similar to Web Dropoff Restrict posted files to members or public Allow members or only moderators to post files Currently, only limited disk space is available for files Archives kept for 3 years by default; high volume lists may be set lower. Archive access to members by default; can be changed to public or moderators only. The Posted Files feature is available, but not generally advertised as we do not yet have sufficient disk quota to handle heavy use of it. Posted Files allows files to be permanently uploaded to the system for access by list members, in much the same way as Web Dropoff. However in this case they are not deleted automatically and are accessible to all list members (or public, depending on list configuration)

Archives set up by month Searchable for text View chronologically or by thread Moderators are able to selectively delete from the archives

Sympa Mailing List Server More Advanced Tasks Access control List Creation List configuration management These are more advanced tasks used by list owners You can run away now if you want to!

Sympa Mailing List Server Controlling access with Scenari Specific rules for who can perform a task, and what action should be taken. Result: Permit action Deny action Require approval Require further authentication Require Certificate Check: How did the person authenticate? List owner? List editor/moderator? Location (IP Address) LDAP group membership? Database lookup Static list lookup Other list membership status List moderator approval (subscription, posting) Email address confirmation (subscription, posting) Scenario : a set of rules for what rights should be given to people for a given task Authenticated by either Email address, web authentication/token, or client certificate/signed email Many rule sets pre-defined for selection

Sympa Mailing List Server Creating Lists Self-service : Request a list online Custom virtual domains for groups requiring it Choose a Template, or copy an existing list Select list name, description Make any changes to list configuration Request any @auckland.ac.nz aliases (Service Desk) Possibly request approval for list creation (Service Desk) A Scenario is used to specify who can request lists in this domain Templates can be created at top level or at domain level Templates can be used in ‘batch mode’ to create whole groups of lists at once, by passing the parameters in a pre-created text file Any @auckland aliases are created and managed by the Service Desk If you do not have authority to create a list, but may request one, then Service Desk can approve a pre-configured but not yet activated list Pre-configured templates makes it very easy for anyone to create a list

Only staff can create lists; if you have a departmental list server, then you may be able to grant create rights to other people. Staff may only request lists in the @list and @sympa domains, not activate them. Contact Service Desk to activate. Create by copying the definition of an existing list, or from a preconfigured template List Owners may also delete or rename their lists Create a new list from a template, or by copying the configuration of an existing list. Then make your own modifications. New templates can be created if there is a particular set of configuration that is frequently requested Lists can be created in bulk from XML or CSV exports in the correct format

Sympa Mailing List Server Controlling Membership Posting Who can subscribe? Who can unsubscribe? List owners can add people Link to one or more LDAP groups (e.g. NetAccount) Link to external Database Link to external address list via HTTP Include members from another list Can allow unsubscription of members retrieved from external sources! Blacklist User Subscribers Explicit adds External Sources Admin Scenario is used to control subscribe, unsubscribe, post Blacklist blocks all commands (post, subscribe, unsubscribe) for email address Users can subscribe or unsubscribe: a scenario is selected for rules External datasources are usually synchronised daily (the same as Netaccount/LDAP synch frequency) but this can be more frequent Can be zero or many external sources External sources can be LDAP (Netaccount), SQL, other lists, text files retrieved by HTTP, etc Can allow some to unsubscribe but not others Custom scenario might be required; this can take some time if you need help. Exclusions Database Deliver!

Sympa Mailing List Server Customising Notifications Disposition: Editor Subscriber Ask for approval Sent to editor Moderated Confirm your post AuthKey Rejected Rejected Editor == Moderator Approval can be by reply email, via web interface, or via embedded link in notification Header/footer only added to plain text emails, only if not signed, so rarely used these days. RFC Header fields used instead. Notification emails in template format; can contain symbols. Template format is extremely powerful – and complex. The TT2 scripting language manuals are all available online. Approved Add header and/or footer Deliver

Sympa Mailing List Server S/MIME (and other cool features) S/MIME Signatures Only Signed messages will be accepted on the list Protects list from forged postings on official lists Does not work with Personalisation feature! Recipients MUST have S/MIME capable mail reader Can sign or encrypt list postings before delivery with List key Possibly more trouble than it is worth! Personalisation All postings are merged with member data using TT2 templating Allows “Dear Sid Bloggs…” message personalisation Can add any other custom data fields to list membership Awkward to automatically populate custom fields Does not work with S/MIME signatures! Was used to create list owner notification emails Using S/MIME signatures for authentication is complex, and only works if you are sending an S/MIME signed message with no alternate unsigned part (Outlook sends an unsigned part by default) Sending a compatible S/MIME message will pass the signing through, so it is not compatible with Personalisation (which modifies the message) An S/MIME message is only readable by a compatible mail reader (eg, Outlook). Others will just see a .p7m attachment. Lists can have their own S/MIME certificate and sign the message at distribution time. TT2 templating used for personalised messages. The field names are not obvious; For example, [% user.gecos %] is replaced by the subscriber’s full name, if known. Lists taking membership from external sources may also require an external source for the Name attribute, if you want to use it. S/MIME is good for lists where you want to guarantee that only certain people can post; however your message may not be readble by the final recipient’s mail client.

Sympa Mailing List Server If you want to know more… Questions After this long, do you want to ask questions, or would you rather escape?