Terms of Service: Cloud

TERMS OF SERVICE

Addendum 4: Cloud Infrastructure Policies & Procedures

This Addendum is incorporated into the Terms of Service with its other Addenda, hyper-linked here for your convenience:

Cloud sections (11)

  1. Minimum Requirements.  We recommend exceeding the minimum requirements.  The more up-to-date your systems are, the better performance your team will get.  You understand the older your computers and operating system, and slower your broadband connection, the longer it will take to access and/or use Service, and for us to perform technical support for you. While we support most up-to-date, popular browsers, including Safari, Chrome and Explorer, we recommend the free Firefox web browser for best performance across all operating systems.  Other software and devices may be supported, please contact us with questions.

    1. Computers
      1. All computers must have a minimum of 10GB of available hard disk space and 2048 MB of available RAM
      2. Applicable password(s) must be available in the event remote control support is requested and deliverable by us
    2. Operating Systems
      1. Microsoft Windows XP SP2 or greater
      2. Macintosh 10.5 operation system or greater
    3. Desktop clients
      1. For Outlook synchronization: Outlook 2003, 2007, 2010 or 2013 with .PST files of under 2GB (larger sizes may work)
      2. For CalDav and CardDav synchronization: Macintosh 10.5 operation system or greater, iPhone 3.0 or greater, or an up-to-date copy of Thunderbird
      3. For IMAP/POP support: any standard IMAP/POP client software
    4. Mobile Devices
      1. For iPhone ActiveSync connectivity, iPhone 2.1 or greater
      2. For Blackberry (BES) synchronization, at your own cost you must have access to the BES network through your telephone provider
    5. Network
      1. Broadband.  We assume broadband services are installed, adequate and operational prior to the time of Service, including connections to any broadband router or “modem.”
      2. Firewall and Traffic-shaping.  We also assume you are not using traffic shaping or other firewalling or security techniques that may negatively impact Service performance.
  2. Email Throttling. For the protection of our customers, we throttle outbound email to help prevent Abuse.  We do not publish parameters of this system to further discourage abuse.  Request increase for an account, or a domain, using the Customer Center’s Help Desk web ticketing system.
  3. RBLs and Internet Standards.  We subscribe to various RBLs, and require mail servers with which we communicate to conform to generally accepted standards as recognized by published Requests for Comments (RFCs). We use these systems and policies for your protection, even though they sometimes will cause Issues, for example and not limited to the outright rejection of some inbound email.  If you suspect you are not receiving email from a specific individual or group, please verify the Issue by duplicating it, request we investigate the issue, using the Customer Center’s Help Desk web ticketing system, and including the full header information of email not reaching your mailbox(es), by having the mail cc:’d to another account at which you can receive the mail, or by faxing it to us (contact us for the fax number please).
  4. Defaults.  We use certain default settings and policies (“Defaults”) for your convenience and protection, even though they sometimes will cause Issues, for example and not limited to requiring End Users to reset passwords prior to login, changes to your default preferences, and ticketing requests to personalize default settings for you.  For any you cannot change yourself using the Customer Center‘s self-service tools, you may submit a ticket to change Default settings.  Some examples of defaults include:
    1. Retention.  Email and data in your mailboxes are set to remain there until you cause them to be deleted, except for the messages in the Trash and Junk directories.  It is our standard practice to delete messages left in Trash and Junk folders after 30 days.
    2. Security.  Among other security settings, to lock mailboxes with a certain number of failed consecutive login attempts.
  5. Quota reached (“Account full”). When an account reaches 90% or more of its quota, we automatically send a warning to the Account’s user.  If a mailbox reaches 100% of its quota, it is “full.”  When an Account is full, messages can no longer be received by the Account, nor can you add other types of data like calendars or files until you either A) delete some account data to make more room, or else B) raise the account’s quota.  For up to 5 days after an account is full, we will continue to store in-bound mail for delivery.  After 5 days if neither option A) nor B) is taken, then we will return email to senders.  Reference Billing Addendum: Monthly Term Account Quotas.
  6. Security.  We make commercially reasonable efforts to enable the secure transfer of data, such as and not limited to email to and from our Cloud, by using public SSL certificates to offer 256-bit SSL/TLS encryption of network services.  Secured services include the following protocols: SMTP (outbound mail), POP (inbound mail), IMAP (inbound mail and synchronization), LDAP (directory services) and HTTP (web mail, mobile and desktop synchronization).  We make commercially reasonable efforts to secure our Cloud, physically by highly restricting and securing infrastructure administration, and hosting our Cloud in Data Centers monitored by live security guards, video surveillance, biometric and security code access. 
  7. Scheduled Maintenance.  Scheduled Maintenance occurs during regular, planned time periods.
    1. Major maintenance. We have a standard maintenance period every Saturday evening from 10:00 pm to Sunday morning at 10:00 am. Services are normally available during this period. We attempt to minimize major, scheduled service interruptions, resulting in an average of fewer than 4 such periods annually, not more than once in any 30-day period.
    2. Minor maintenance. Additionally, within the major maintenance window and without advanced warning, between 11 pm to 11:59 pm CST/CDT on Saturday evenings, we may test, apply fixes or improvements to zMailCloud. This may cause services to be unavailable for some users or groups for from 5 to 30 minutes, most often less than 10 minutes. Fixes, tests or improvements during this time, announced or not, are also considered Scheduled Maintenance.
    3. Notification.  We shall attempt to notify and coordinate with you a minimum of 4 days in advance and no less than twenty-four (24) hours in advance of all non-emergency maintenance.  By e-mail, RSS newsfeed (“News”) on our blog, or Systems Status, we shall advise you of the expected duration of the maintenance window and the impact of the work to be performed.  No further notice of maintenance windows may be provided to you.
    4. Frequency.  We make commercially reasonable efforts to schedule maintenance no more than once a month at times most convenient for the majority of those customers affected.  We may schedule maintenance as often as we deem necessary to maintain system reliability and integrity, at our sole discretion.
  8. Upgrades.
    1. Objective.  Service reliability is our primary objective.  While we recognize a primary value of our Service is innovative, new features, we are conservative about our upgrades.   It is our policy to prioritize the stability and reliability of zMailCloud over introducing new features and bug-fixes.
    2. Testing Procedures.  Revolve around our sandbox servers, a testbed simulating the zMailCloud cloud environment, and involving much of our team.  We will list minor issues that may impact your experience in our public blog and privately by email before the planned upgrade, along with any material new features, fixes.  The decision to upgrade zMailCloud may be reversed all the way up to the actual night of the upgrade by engineering for a variety of reasons, including for one example, failure of full-backups to complete as expected.
      1. Upgrade the sandbox – Systems Administration
      2. Administrative testing – Systems Engineering
      3. Client-side testing – Support Specialists.  Reference our Client-side Testing Checklist.
      4. Issue review and go/no-go decision – Operations Manager
  9. Fair Use (“Acceptable Use”). We have not set a fixed upper limit on the amount of emails, bandwidth, telephone or online support requests you may make annually.  While we understand that each of the organizations we serve are composed of unique persons, we have based our Service Level Agreement and Pricing on reasonable use by the average Customer (collectively referred to as “Acceptable Use”).  We reserve the right to monitor and record the nature and quantity of Service requested by each Customer.  Notwithstanding anything else in this Agreement, we may immediately interrupt Service and terminate this Agreement without remedy for any one or more of the following reasons, at our sole discretion.  Should we decide to terminate this Agreement for one or more of the reasons set forth below, we will notify you by email, chat or phone.  Within three (3) days of receiving the termination notice, you may set forth reasons why termination is not warranted. We will consider your objections and thereafter render a decision.  Any decision not to terminate your Service does not preclude us from terminating your account at a later date should there be another violation, either the same or different as prior violations, of this Acceptable Use policy, or for other reasons set forth in this Agreement.  We consider unacceptable use of our Service:
    1. requiring materially more Service than we have reasonably expected,
    2. resale of Service, unauthorized by us,
    3. sending Spam or viruses, or other fraudulent uses,
    4. using profanity or other abuse of any one our team, partners, affiliates or other customers,
    5. allowing any non-customer to use your account and receive support services,
    6. publishing an incorrect SPF record and failing to correct it promptly,
    7. allowing any Account to be used by more than one End User,
    8. attempting to benefit from more than one Free Trial Period without our advanced, written approval, or
    9. distributing infringing material.
  10. Beta: Our normal service guarantees, if any, do not apply to beta services and features, and beta service at all times is no more than best effort.  Should you agree to participate in Beta-testing by using Beta services, you will provide helpful feedback so we can prepare the service for production.
  11. Abuse.  Mailbox aliases named postmaster@ and abuse@ your domain name are established by default for you at Service commencement.  You must monitor these addresses for complaints of abuse, and respond promptly to affected recipients with a plan to prevent further complaints from past and future recipients.
Built with HTML5 and CSS3
Copyright © 2013 zMailCloud.
All logos, trade and service marks property of their respective owners.
zmailcloud.com is an independent website and has not been authorized, sponsored, or otherwise approved by Apple, Microsoft, Yahoo, RIM, Mozilla, Google nor VMware.