This is a subscription service to be automatically notified by e-mail when topics change in this _default web. This is a convenient service, so you do not have to come back and check all the time if something has changed. To subscribe, please add a bullet with your WikiName in alphabetical order to this list:

• 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.

Users may further customize the specific content they will receive using the following controls:

• 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

Subscribe Daisy to all changes to topics that start with Web.

   * daisy.cutter@flowers.com : Web*

Subscribe Daisy to changes to topics starting with Petal, and their immediate children, WeedKillers and children to a depth of 3, and all topics that match start with Pretty and end with Flowers e.g. PrettyPinkFlowers

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

Subscribe StarTrekFan to changes to all topics that start with Star except those that end in Wars, sInTheirEyes or shipTroopers.

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

Subscribe Daisy to the full content of NewsLetter whenever it has changed

   * daisy@flowers.com: NewsLetter?

Subscribe buttercup to NewsLetter and its immediate children, even if it hasn't changed.

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

Subscribe GardenGroup (which includes Petunia) to all changed topics under AllnewsLetters to a depth of 3. Then unsubscribe Petunia from the ManureNewsLetter, which she would normally get as a member of GardenGroup? :

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

Subscribe IT:admins (a non-TWiki group defined by an alternate user mapping) to all changes to Web* topics.

   * '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

Mail Delivery in A Cyrus Murder

There are several alternate ways to handle mail delivery in a Cyrus murder, which may improve performance depending on your setup and mail volume.

Standard Way

In a standard setup (as suggested by the documentation) each time a message arrives at a frontend, lmtpproxyd will contact the master server to determine which backend the mailbox is on.

pros

• Most people do it this way
• Easy to setup

cons

• Murder master can become overloaded if you have large amount of incoming mail
• Mail delivery hangs if murder master is unavailable.

Query local mailboxes.db

Each frontend will generally have its own copy of the mailboxes.db file and lmtpproxyd can be set to query the localhost for the backend of a specific mailbox.

pros

• Resolve mailbox location faster
• An increase in messages does not increase load on murder master
• Mail can be delivered if murder master is unavailable (*1)

cons

• More complicated setup/requires patches

There are currently two ways to setup lmtpproxyd to query the localhost. I think the UMich method is better since it is much simpler to setup.

*1) The UMich way should keep delivering mail if the murder master is down. If use the alternate method, then you will need to reconfigure mupdate to keep mail delivery going during a murder master outage. You simply add '-m' to the mupdate arguments in cyrus.conf, restart, and mupdate will no longer contact your murder master. Mail delivery will work. Once the murder master has been fixed, remove -m so the local mupdate will start receiving updates again. Since this involves restarting Cyrus, we ran lmtpproxyd on its own machines (without imap/pop users)

UMich patch

Patch

Patches are against 2.2 but are being moved to 2.3

Lmtpproxyd will now use the local mailboxes.db

Contact local mupdate server

Mupdate is running on each frontend to receive updates from the murder master. Lmtpproxyd can be configured to query the local mupdate process instead of the one on the master server.

The steps are briefly outlined below

1. Create a config file for lmtpproxyd. Copy your current imapd.conf file and set 'mupdate_server: localhost'. Edit cyrus.conf and tell lmtpproxyd about the new config file. cmd="lmtpproxyd -C /etc/lmtp.conf"
2. Make sure you can login to mupdate locally. Test with mupdatetest. Example 'mupdatetest -u frontend -a frontend -m PLAIN localhost'
3. Depending on how restrictive your setup is, you may have to create a config file for mupdate.

Delivery directly to backends

Delivering mail directly to the backends lets you avoid the performance hit (and other potential problems) of sending mail through the frontends

pros

• Best performance for through put and volume
• Not affected by murder master problems
• Avoid any bottle necks/issues with frontends

cons

• Need external (to murder) routing of mail. Generally you need to be able to tell sendmail/postfix/etc where to send mail for each user.
• Harder to move users between backends.

At Columbia we deliver directly to the backends. We generate sendmail alias files from our ID system to direct mail to the appropriate backend. When moving a user between backends we will temporarily send their mail to the frontends while they are being moved. We tried each method listed on this page (except for the UMich patch) but always had some problems when there was a sudden increase in mail volume.

-- PatrickRadtke? - 19 Jun 2006