• TWikiGuest - example@your.company

Web Changes Notification Service

Each TWiki web has an automatic e-mail notification service that sends you an e-mail with links to all of the topics modified since the last alert.

Users subscribe to email notifications using their WikiName or an alternative email address, and can specify the webs/topics they wish to track, Whole groups of users can also be subscribed for notification.

The general format of a subscription is:

three spaces * subscriber [ : topics ]

Where subscriber can be a WikiName, an E-mail address, or a group name. If subscriber contains any characters that are not legal in an email address, then it must be enclosed in 'single' or "double" quotes.

topics is an optional space-separated list of topics:

• ... without a Web. prefix
• ...that exist in this web.

• Using wild-card character in topic names - You can use * in a topic name, where it is treated as a wildcard character. A * will match zero or more other characters - so, for example, Fred* will match all topic names starting with Fred, *Fred will match all topic names ending with Fred, and * will match all topic names.
• Unsubscribing to specific topics - Each topic may optionally be preceded by a '+' or '-' sign. The '+' sign means "subscribe to this topic". The '-' sign means "unsubscribe" or "don't send notifications regarding this particular topic". This allows users to elect to filter out certain topics. Topic filters ('-') take precedence over topic includes ('+') i.e. if you unsubscribe from a topic it will cancel out any subscriptions to that topic.
• Including child-topics in subscription - Each topic may optionally be followed by an integer in parentheses, indicating the depth of the tree of children below that topic. Changes in all these children will be detected and reported along with changes to the topic itself. Note This uses the TWiki "Topic parent" feature.
• Subscribing to entire topic ("news mode") - Each topic may optionally be immediately followed by an exclamation mark ! and/or a question mark ? with no intervening spaces, indicating that the topic (and children if there is a tree depth specifier as well) should be mailed out as complete topics instead of change summaries. ! causes the full topic to be mailed every time even if there have been no changes, and ? will mail the full topic only if there have been changes. One can limit the content of the subscribed topic to send out by inserting %STARTPUBLISH% and %STOPPUBLISH% markers within the topic. Note that "news mode" subscriptions require a corresponding cron job that includes the "-news" option (see details).

Examples: Subscribe Daisy to all changes to topics in this web.

   * daisy.cutter@flowers.com

   * daisy.cutter@flowers.com : Web*

   * DaisyCutter: Petal* (1) WeedKillers (3) Pretty*Flowers

   * StarTrekFan: Star* - *Wars - *sInTheirEyes - *shipTroopers

   * daisy@flowers.com: NewsLetter?

   * buttercup@flowers.com: NewsLetter! (1)

   * GardenGroup: AllNewsLetters? (3)
   * petunia@flowers.com: - ManureNewsLetter

   * 'IT:admins' : Web*

A user may be listed many times in the WebNotify topic. Where a user has several lines in WebNotify that all match the same topic, they will only be notified about changes that topic once (though they will still receive individual mails for news topics).

If a group is listed for notification, the group will be recursively expanded to the e-mail addresses of all members.

__ Warning: Because an email address is not linked to a user name, there is no way for TWiki to check access controls for subscribers identified by email addresses. A subscriber identified by an email address alone will only be sent change notifications if the topic they are subscribed to is readable by guest users. You can limit what email addresses can be used in %NOTIFYTOPIC%, or even block use of emails altogther, using the {MailerContrib}{EmailFilterIn} setting in =configure.

Tip: List names in alphabetical order to make it easier to find the names.

Note for System Administrators: Notification is supported by an add-on to the TWiki kernel called the MailerContrib. See the MailerContrib topic for details of how to set up this service.

Note: If you prefer a news feed, point your reader to _default.WebRss (for RSS 1.0 feeds) or _default.WebAtom (for ATOM 1.0 feeds). Learn more at WebRssBase and WebAtomBase, respectively.

Related topics: WebChangesAlert, TWikiRegistration

Sample Cyrus config: POST Newspapers

Craig Ringer (craig at postnewspapers dot com dot au), using Cyrus 2.1.14

Getting things going

The POST Newspapers deployed a fairly standard Cyrus IMAPd setup, and I thought it'd be useful to document here to help others who're having trouble getting started with Cyrus. I'm going to focus on authentication, as that's the hardest bit to understand about how Cyrus works.

We're using Cyrus on a single host and authenticating users against an LDAP directory via Linux-PAM using saslauthd. We're running Cyrus 2.1.14 (built from source) on Red Hat 8 with the redhat-packaged cyrus-sasl-2.1.10 (update: now on Debian Sarge with stock Debian Cyrus. These configs required no changes.). We're using both IMAPs and TLS-enabled IMAP, but only for external hosts. The config immediately below does not show that, please see further down for a TLS-enabled setup.

Cyrus was configured to use saslauthd for authentication, with saslauthd in turn using the system PAM services. Saslauthd is a helper daemon for cyrus-sasl that acts as a sort of proxy to handle authentication methods not supported directly in the cyrus-sasl libraries.

First, cyrus is configued to use saslauthd for authentication by adding the following lines to /etc/imapd.conf:

sasl_pwcheck_method: saslauthd

allowplaintext: yes
sasl_mech_list: PLAIN
sasl_minimum_layer: 0

Once Cyrus is set up to use saslauthd, we need to configure PAM. Saslauthd uses the service name provided to it by the underlying application instead of using 'saslauthd' as it's PAM service name, so we'll need to create separate PAM files for each service. The service names used by Cyrus will be 'imap' and 'pop', so we need an /etc/pam.d/imap and /etc/pam.d/pop.

We've configured Cyrus to use the basic system PAM config via pam_stack:

/etc/pam.d/imap and /etc/pam.d/pop:

auth       required     /lib/security/pam_stack.so service=system-auth
account    required     /lib/security/pam_stack.so service=system-auth
password   required     /lib/security/pam_stack.so service=system-auth
session    required     /lib/security/pam_stack.so service=system-auth

This configuration will let any user who can log in locally authenticate to cyrus, too.

A trimmed version of our system-auth file (redhat-generated) shows the use of pam_ldap for authentication:

/etc/pam.d/system-auth:

auth        sufficient    /lib/security/pam_unix.so likeauth
auth        required    /lib/security/pam_ldap.so use_first_pass
account     required      /lib/security/pam_unix.so
account     [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore] /lib/security/pam_ldap.so debug
session     required      /lib/security/pam_unix.so
session     optional      /lib/security/pam_ldap.so

This configuration will allow logins using both UNIX accounts and LDAP accounts. The configuration of pam_ldap and LDAP authentication isn't really about Cyrus, and I won't cover it here. Many distros can set up PAM to authenticate against LDAP using GUI management tools.

Now that PAM is set up and cyrus is configured to use saslauthd, we need to start saslauthd and tell it to use PAM to authenticate users. How you start saslauthd isn't all that important so long as it gets run as:

saslauthd -a pam

I modified /etc/init.d/saslauthd and changed "MECH=shadow" to "MECH=pam". This only relates to the redhat-packaged cyrus-sasl however - if you've installed cyrus-sasl from source you'll want to write a simple sysV init script for saslauthd.

Once this is all done, you should be able to log in to Cyrus. I've included my full imapd.conf below in case it's useful.

configdirectory: /var/imap
partition-default: /var/spool/imap
admins: root cyrus
sendmail: /usr/sbin/sendmail
sieveusehomedir: true

allowplaintext: yes
sasl_mech_list: PLAIN
sasl_minimum_layer: 0
sasl_pwcheck_method: saslauthd

debug_command: /usr/bin/strace -tt -o /tmp/strace.cyrus.%s.%d -p %2$d <&- 2>&1 &

-- Craig Ringer - 19 Nov 2003

TLS for connection encryption and external access

We now have TLS encrypted communication going. It required the creation of a private certificate authority using OpenSSL, the creation of a certificate and key for the server, some simple configuration to the cyrus server, and some fiddling with clients to make them accept our private CA as valid. I won't cover creating a private ca here, creating TLS certificates, or getting the clients to accept private CA certificates (someone please feel free to add that info). It is, however, important to note that the common name listed in the certificate must be the same as the hostname the client connects to, or the client will either warn about or reject the certificate.

We wanted our mail server to require very strict security for clients connecting over the internet, but minimize the complexity of client configuration for mail users on the LAN. We decided to use two separate cyrus configurations - one listens on a high port for traffic forwarded to it from our firewall, and is configured to require TLS with a valid client certificate before it'll talk to the client. The other listens on the normal imap port, and does not require any TLS. The SERVICES section from our cyrus.conf looks like this:

SERVICES {
  # add or remove based on preferences
  imap          cmd="imapd" listen="imap" prefork=0
  # imaps         cmd="imapd -s" listen="imaps" prefork=0
  imapext      cmd="imapd -C /etc/imapd_external.conf" listen="imapext" prefork=0
  imapsext      cmd="imapd -C /etc/imapd_external.conf -s" listen="imapsext" prefork=0
  pop3          cmd="pop3d" listen="pop3" prefork=0
  pop3s         cmd="pop3d -s" listen="pop3s" prefork=0
  sieve         cmd="timsieved" listen="sieve" prefork=0

  lmtpunix      cmd="lmtpd" listen="/var/imap/socket/lmtp" prefork=0
}

Note that we're not currently using normal IMAP for outside access, only TLS-wrapped imaps. As you can see, the "imapsext" service is a normal imapd running in TLS-wrapped mode (-s), but it's using a different config file and listening only to a special port (defined in our /etc/services</code as 4205/tcp).

The config file for the external access IMAPd is:

configdirectory: /var/imap
partition-default: /var/spool/imap
admins: root cyrus
sendmail: /usr/sbin/sendmail
sieveusehomedir: true

allowplaintext: yes
sasl_mech_list: PLAIN
sasl_minimum_layer: 128
sasl_pwcheck_method: saslauthd

tls_imap_require_cert: 1
tls_ca_file: /var/imap/ssl/ca.pem
tls_cert_file: /var/imap/ssl/mail.ourdomain_cert.pem
tls_key_file: /var/imap/ssl/mail.ourdomain_key.pem

iptables -t nat -A PREROUTING -p tcp -d `ipofif ppp0` --dport 993 -j DNAT --to-destination 10.0.0.4:4205
iptables -A FORWARD -p tcp --dport 4205 --destination 10.0.0.4 -j ACCEPT