From 96be1b9a3d4ce2b13eb2c7f2e11fc9f037043795 Mon Sep 17 00:00:00 2001 From: Sam Johnston Date: Sat, 19 Apr 2008 08:49:56 +0000 Subject: [PATCH] incorporated feedback from Iang git-svn-id: http://svn.cacert.org/CAcert/Policies@766 14b1bab8-4ef6-0310-b690-991c95c89dfd --- CAcertCommunicationPolicy.html | 47 ++++++++++------------------------ 1 file changed, 14 insertions(+), 33 deletions(-) diff --git a/CAcertCommunicationPolicy.html b/CAcertCommunicationPolicy.html index 7e371bd..ccfb24c 100644 --- a/CAcertCommunicationPolicy.html +++ b/CAcertCommunicationPolicy.html @@ -49,9 +49,10 @@
  • Press Releases
      -
    1. Press releases MUST be approved by the board and issued via:
      +
    2. Community Members MAY communicate on their areas, but these are considered community views.
      3. +
    3. Official press releases MUST be approved by the board and issued via:
        -
      1. Digitally signed email to appropriate mailing list(s) by the president. +
      2. Digitally signed email to appropriate mailing list(s).
      3. Posting and indefinite archiving on the official CAcert web site(s)
        4. @@ -63,42 +64,30 @@ Internet Email
        1. - Email Accounts are official email accounts within the CAcert domain(s) (eg john@cacert.org).
          + Email Aliases are official email addresses within the CAcert domain(s) (eg john@cacert.org).
            -
          1. All official CAcert communications MUST be conducted using an official address. +
          2. All official CAcert communications MUST be conducted using an official address, which is typically a forwarding service.
            3. -
          3. All new accounts MUST be approved by the M-SC (who SHOULD act conservatively on behalf of the board). +
          4. Access to full accounts (available only to officials listed on the organisation chart) SHALL be available via web interface and standard mail protocols.
            5. -
          5. Applicants MUST be assigned a role/office on the CAcert organisation chart. +
          6. Outbound mail SHOULD contain the full name and short reference to the official capacity of the user: John Citizen (CAcert AO) <john@cacert.org>.
          7. Role accounts (eg support@cacert.org) SHALL be implemented as a mailing list or automated issue tracking system as appropriate.
            8. -
          8. All access SHALL be via POP, IMAP, HTTP and SMTP and MUST be authenticated. -
            9. -
          9. Outbound mail SHOULD contain the full name and short reference to the official capacity of the user (eg John Citizen (CAcert AO) <john@cacert.org>). -
            10. -
          10. Outbound mail MUST be relayed via CAcert infrastructure (eg smtp.cacert.org). -
        2. - Mailing Lists are distribution lists containing CAcert community members.
          + Mailing Lists are automated distribution lists containing CAcert community members.
            -
          1. All new mailing lists MUST be approved by the M-SC (who SHOULD act conservatively on behalf of the board). +
          2. List management (new list creation, dead list removal) SHALL be managed by the board.
            3. -
          3. All 'dead' mailing lists SHOULD be removed by the M-SC (on behalf of the board). -
            4. -
          4. List membership SHALL be restricted to CAcert Community members who are subject to the CCA (to be reflected in list info) and all posts are contributions. +
          5. List membership SHALL be restricted to CAcert Community members and all posts are contributions, as described in the CCA.
          6. Lists SHALL follow the naming convention of cacert-<listname>@lists.cacert.org, with important lists (eg support, board) aliased @cacert.org
          7. List policy SHALL be set on a per-list basis (eg open/closed, searchable archives, etc.)
              -
            1. Open lists (eg cacert-policy) shall be accessible by anyone (including Internet search engines) -
              2. -
            2. Closed lists (eg cacert-board) shall be accessible only by list members. -
              3. -
            3. Subscriber lists MUST NOT be revealed, even to list members. +
            4. Open lists (eg cacert-policy) shall be accessible by anyone (including Internet search engines) and closed lists (eg cacert-board) only by list members.
            5. Posting to discussion lists (eg cacert-policy) MUST be restricted to list members and MUST NOT be restricted for role lists (eg cacert-board).
              6. @@ -106,20 +95,16 @@
            8. -
          8. List management MUST be automated (eg Mailman). -
            9. -
          9. Subscription requests MUST be confirmed by the requestor. -
            10. -
          10. Web based archives MUST be maintained and accessible over HTTP and HTTPS. +
          11. Subscription requests MUST be confirmed by the requestor and subscriber lists MUST NOT be revealed..
            12. -
          12. All authentication and authorisation MUST reflect list policy. +
          13. Web based archives SHALL be maintained and authentication MUST reflect list policy.
        3. Automated Email is sent by various CAcert systems automatically.
            -
          1. All new automated emails MUST be approved by the M-SC (who SHOULD act conservatively on behalf of the board). +
          2. All new automated emails MUST be approved by the board.
          3. Automated emails SHOULD only be sent in response to a user action.
            4. @@ -130,10 +115,6 @@
            1. Personal email MUST NOT be used for official CAcert purposes.
              2. -
            2. Personal email MAY be used for unofficial tasks (eg assurers coordinating assurances) -
              3. -
            3. In the event that email accounts are made available to all community members these MUST be used, and personal email MUST NOT be used at all. -