(no commit message)

diff --git a/projects/mailman-acl.mdwn b/projects/mailman-acl.mdwn
index ba7ce1ae85c7e11d584d821b19ecc5c53ece7a01..aa8503e1686c17513d3cbae45f7a30fa4e585279 100644 (file)
--- a/projects/mailman-acl.mdwn
+++ b/projects/mailman-acl.mdwn
@@ -5,11 +5,11 @@ We identified two main goals for Mailman/Moira integration: using Mailman lists
 
 1. Mailman->Moira ACLs
 
-Currently, every Mailman list has a corresponding Moira list that contains listname@mailman.mit.edu and can contain other entries.  Our proposal is for this setup to be modified slightly.  First, the AFS group bit ('blanche -G') on such lists will be set.  Secondly, there will be a synchronization script that runs on the Mailman server (using the list_members command).  The synchronization script would run as a cron job.  When the synchronization script runs, it looks at the members of the Mailman list.  For each that ends in @mit.edu or another ending where we have cross-cell authentication (@csail.mit.edu, etc.), it adds the corresponding Kerberos principal as a KERBEROS: member to the Mailman list's Moira counterpart.  This allows the relevant users to have rights in ACLs without receiving the mail that would otherwise be sent to them by Moira.  @mit.edu addresses that are Moira lists will be expanded as 'blanche -r'.  USER: and KERBEROS: members will be added as KERBEROS: members; STRING: members will be ignored.  Any KERBEROS: members previously on the Moira list other than the @mailman.mit.edu entry that are not generated by this process will be removed.
+   Currently, every Mailman list has a corresponding Moira list that contains listname@mailman.mit.edu and can contain other entries.  Our proposal is for this setup to be modified slightly.  First, the AFS group bit ('blanche -G') on such lists will be set.  Secondly, there will be a synchronization script that runs on the Mailman server (using the list_members command).  The synchronization script would run as a cron job.  When the synchronization script runs, it looks at the members of the Mailman list.  For each that ends in @mit.edu or another ending where we have cross-cell authentication (@csail.mit.edu, etc.), it adds the corresponding Kerberos principal as a KERBEROS: member to the Mailman list's Moira counterpart.  This allows the relevant users to have rights in ACLs without receiving the mail that would otherwise be sent to them by Moira.  @mit.edu addresses that are Moira lists will be expanded as 'blanche -r'.  USER: and KERBEROS: members will be added as KERBEROS: members; STRING: members will be ignored.  Any KERBEROS: members previously on the Moira list other than the @mailman.mit.edu entry that are not generated by this process will be removed.
 
-Note that the current practice of putting KERBEROS: principals on Moira lists can be maintained by creating an auxiliary Moira list containing only Kerberos principals and adding this list to the Mailman list.
+   Note that the current practice of putting KERBEROS: principals on Moira lists can be maintained by creating an auxiliary Moira list containing only Kerberos principals and adding this list to the Mailman list.
 
-If the overhead of this syncing process is nontrivial, the syncing could be enabled or disabled via a checkbox in the Mailman admin options.
+   If the overhead of this syncing process is nontrivial, the syncing could be enabled or disabled via a checkbox in the Mailman admin options.
 
 
 2. Allowing Moira Lists to admin Mailman lists