SERVICE LEVEL AGREEMENT

RPost is a global leader in secure and certified electronic communications, built upon its patented RMail^®, RSign^®, and Registered Email™ delivery proof, email encryption, e-security, and e-signature technologies. Millions of users have enjoyed RPost services in more than 100 countries, since 2000.

This Service Level Agreement governs all RPost messaging and document services currently commercially available. If there is another reference that conflicts with a definition in this Service Level Agreement, the definition or description within this Service Level Agreement prevails, unless a customer specially contracts for a different service level in a separate contract.

I. Definitions:

1. R1: RPost infrastructure for standard volumes and human sending.
2. R2: RPost infrastructure for automatic and high volume sending.
3. RDocs™ Platform. RPost software service systems that process all RDocs protected document services.
4. RMail Cloud™. The RMail Platform message intake application to RMail Platform message outbound transmission point, and all processing and message handling systems connected in between.
5. RMail Gateway™. Local application or cloud managed service for filtering email content outbound prior to RMail Platform processing, inbound, or archive.
6. RMail^® Platform. RPost software service systems that process RMail services, subsets, and related services unless otherwise specified, including but not limited to Registered Email™, email encryption, RSign Lite (a/k/a RMail E-Sign), File Share (a/k/a LargeMail), SideNote^®, Anti-Whaling services and some versions of RForms.
7. RPD Status Definitions.
   1. "Available” state is defined as an RPD that is in an access-active state (“Active”) or an access-paused (“Expired”) state.
   2. “Access-paused” state is an RPD that can be toggled accessible (“Active”) to inaccessible (“Expired”) and back at the click of a RPD owner option at will.
   3. “Kill” state of an RPD permanently renders the RPD inaccessible and purges related metadata.
   4. “Alive” means not access paused or killed.
   5. “Alive Month” means an RPD file is alive any day of the calendar month.
8. RPost^® Systems. All RPost software service systems, API, and connected applications that process or route customer messages and data.
9. RSign^® Platform. RPost software service systems that process all RSign e-signature services other than RSign Lite (a/k/a RMail E-Sign) and some versions of RForms.
10. Service. Services enabled by RMail Platform, RMail Gateway, RSign Platform, or RPost Systems.

II. RPost General Services:

1. Service Availability. RPost guarantees 99.9% availability for 24 x 7 Service operation without severity level 1 disruption, excluding scheduled maintenance windows.
2. Scheduled Maintenance Outages. Planned, scheduled maintenance outages are limited to a specific window during off-peak hours. Customers and alliance partners will be notified of planned outages in advance. Off-peak hours have a target maintenance window start time of 1am UTC, with variation for off-peak if the maintenance only affects geographical regional systems.
3. Time to Intervene. RPost support ticketing is available 24×7. Reported incidents are required to be logged with a support ticket through a system available on RPost corporate and product marketing websites. RPost support ticketing system provides information related to ticket status. The mean time to investigate basic support plan support tickets is 48 hours based on a 24-hour business day. The mean time to investigate enhanced support plan support tickets is noted in the Premium Support Enhancement section. Tickets that are received and clearly identified as Service Incident Severity Levels 1, 2, 3 and 4 in the Ticket Subject are verified within a mean time of 6 hours of submission with basic support plans and if confirmed as Severity Levels 1, 2, 3 and 4 issues, are responded to within the timeframe noted in Time to Restore.
4. Time to Restore. The mean time to restore from time of identification of any unplanned generalized service outage or Service Incident Severity Levels 1, 2, 3 and 4 is six hours.
5. Time to Change. The mean time to respond and/or implement automatic change requests is one business day. The mean time to respond and/or implement manual change requests is one business day. Completion time for such requests will be subject to the nature of the request.
6. Support Enhancements. RPost offers premium support options that provide enhancements to the above.
   1. Enterprise Support: Customer has the option to immediately escalate all support tickets to level 3 support for senior manager investigation and oversight. Mean time to intervene is 6 hours. The mean time to restore after support ticket submission is 6 hours and if VIP escalated, 3 hours from VIP escalation.
   2. Platinum Support: Mean time to intervene is 12-hours. The mean time to restore after support ticket submission is 12 hours.
   3. Premium Support: Mean time to intervene is 24 hours. The mean time to restore after support ticket submission is 24 hours.
7. Service Incident Severity Definitions and Notices.
   1. Definitions
      1. Severity Level 1: Total loss of all services, e.g., no users on the network can access any services. For example, no user can send any messages through RPost systems from any of its infrastructures or with any feature.
      2. Severity Level 2: Total loss of a main service for a specific region, e.g., no users on the network in a region can access a main service, with main service defined as Registered Email™, encrypted email, file transfer or e-signature transmission services. Severity Level 2 notices are identified in relation to a specific service function, service infrastructure instance and/or geographic region.
      3. Severity Level 3: A specific service function is degraded. Severity Level 3 notices are identified in relation to a specific service function or service infrastructure instance. Users can access the service to send but experience difficulties or significant delays of more than two hours. For example, a user sends a message and it is not rejected by the RPost system but there is an extended delivery delay beyond mean time parameters for service functions, such as a delayed return of the Registered Receipt™ email beyond the mean time to return.
      4. Severity Level 4: Services are delivered with difficulties or delays of less than two hours. Users accessing the service are not significantly impacted. For example, a user sends a message and there is an intermittent delivery delay beyond mean time parameters for service functions.
      5. Unauthorized Information Disclosure: Unauthorized disclosure of information that resides on the service processing systems that becomes public which is considered protected personal information or customer private information under privacy regulatory frameworks of HIPAA, GDPR, or applicable local privacy regulations that govern such data.
   2. Notices: RPost service operations center shall report to affected users with an email notice or by other contact means within a mean time to respond of 72 hours after initial awareness of a service related issue of Severity Level 1, 2, or Unauthorized Information Disclosure, with such notice providing a summary of the issue, duration of the issue, resolution of the issue if resolved, actions to mitigate re-occurrence of the issue if known, and impact of the issue with the best information that the knowledge of the RPost operations staff at the time of the notice is able to obtain.
8. Service Provisioning.
   1. Self-Provisioning Default Plans. RPost services may be self-provisioned for limited ongoing use through select user interfaces including Microsoft Outlook, Gmail and web apps (“Default Use”). Services are immediately available for Default Use.
   2. Corporate Provisioning. RPost services may be provisioned in highly specialized scenarios and with systems integrations including connected to third party systems, volume sending systems, or apps such as Salesforce.com that may require administrative provisioning and corporate orders on business service plans (“Business Orders”). Customers using these specialized provisioning systems may need to be enabled or approved by RPost staff or RPost partner staff after order submission. RPost mean time to process Business Orders is one business day.
   3. Service Enhancements. Throughout this Service Level Agreement RPost may describe capabilities only available to users that are on select service plans or may elect for service enhancements. RPost reserves the right to require fee-based service enhancement packages or premium service plans for access to certain services, settings, or parameters described in this Service Level Agreement. Not all customers may have access to all of the services described in this Service Level Agreement or in other service plan or service description materials, service parameters, service levels or enhancements but may inquire how to obtain access should they so desire.
   4. Swiss FINMA Provisioning. Upon receipt of a professional services request for service provisioning for Swiss FINMA configurations and confirmation of payment by the customer for service costs, the RPost team adds replication of customer data to FINMA certified servers and infrastructure technologies operated within the AWS Services in Scope by Compliance Program — Swiss Financial Market Supervisory Authority (FINMA).

      Amazon Web Services (AWS) offers access to its FINMA ISAE 3000 Type 2 Report. The International Standard on Assurance Engagements (ISAE) 3000 is a standard which is applied for audits of internal controls, sustainability, and compliance with laws and regulations, and completion of the ISAE 3000 Type 2 Report verifies that AWS’s control environment is appropriately designed and implemented to align with certain Swiss Financial Market Supervisory Authority (FINMA) requirements applicable to regulated financial services customers. RPost’s use of AWS Swiss-based infrastructure and services that are within the scope of the AWS FINMA ISAE 3000 Type 2 report demonstrates RPost and AWS alignment with FINMA requirements and our collective continuous commitment to meeting the heightened expectations for cloud service providers set by Swiss financial services regulators and customers.

      The FINMA ISAE 3000 Type 2 Report, conducted by an independent third-party audit firm, provides Swiss financial industry customers with the assurance that the environment operating Swiss replicated RPost data within AWS’s control environment is appropriately designed and implemented to address key operational risks and risks related to outsourcing and business continuity management.

      RPost system and service data that is applicable to FINMA stored-in-Switzerland requirements include:
      1. RMail: Transaction metadata. RPost retains transaction metadata during the billing period associated with each RMail transaction. The content in this Transaction Metadata includes transmission timestamps, message size, addresses, header data, features selected, and may include forensic delivery data.
      2. RSign: Transaction metadata. For FINMA deployments, the RSign message content and agreement data is set with the GDPR purge settings so this data is not retained inside the RSign application. The content retained is only transaction data in XML (enveloped data, view settings used and other related feature-setting-timestamp metadata).
      3. RDocs™ transaction metadata, which includes document settings, create, transmission, and activity history.
      RPost commits to providing access to the abovementioned customer data, should it exist, as it is duly and legally requested to be accessed by Swiss governmental authorities in processes dictated by FINMA regulations. This data repository does not contain an end user interface and data is only accessible through an authorized professional services request by the legal entity authorized to make such a request on behalf of the regulated customer in question. The cost to retrieve and present the data is borne by the requestor or the customer and will be assessed based on the scope of the retrieval request, with costs on par with costs for traditional legal document discovery storage retrieval requests.
      

      RPost requires customers opting for this configuration to sign an RPost Service Enhancement Agreement of type “FINMA Provisioning”.

9. Service Operations Verification.
   1. Deliverability Testing. It is the customer’s responsibility to ensure sent message traffic has proper deliverability and to request white listing, SPF and/or DKIM set-up as the customer may desire (and to test DKIM configurations after set-up) and report DMARC policies that need special attention.
   2. Service Settings. It is the customer’s responsibility to ensure service parameters are as the customer desires, including setting minimum encrypted transmission levels and other retention parameters.
   3. Proper Installation in Customer Environment. It is the customer’s responsibility to ensure that the service has been installed and is in proper function within its technology environment, including testing the Registered Receipt™ verification process to ensure the customer’s anti-virus systems are not altering these receipt emails in a manner that invalidates the authentication process, and including testing message delivery and return receipt and report functionality to ensure the customers’ anti-spam systems do not block RPost system message traffic. RPost offers options to support customers that need to mitigate any issues related to service operations with anti-virus and anti-spam systems including white listing information or use of the RMail Gateway pre-configured anti-virus and anti-spam services.
10. Message Delivery Time. Under normal service operations on R1, RPost service messages will be processed (sent from the sender’s server and received by the R1 RPost processing server) and sent for delivery within a mean time of five minutes of induction by the RPost service. Acknowledgement™ receipt emails will be returned within a mean time of ten minutes after message induction by the RPost service after authentication of sender accessibility. Registered Receipt™ emails will be returned to the sender within a mean time of 2 hours from the original message induction by the RPost service (the time inducted as reported on the Acknowledgement receipt). The above timeframes are valid for 99% of deliveries on R1. R2 mean times are double those of R1 due metering for optimal deliverability of volume batch sends. RPost is not accountable for delays caused by external factors such as Internet network outages, Internet network congestion, sender or recipient mail server failures and/or incorrectly addressed messages, or third-party delays for customer requirements of Registered Receipt™ processing to include locally sourced third-party API retrieved timestamps.
11. Undeliverable Message. In the case of undeliverable messages sent for RPost service processing, the service may attempt to deliver the message through alternate servers (depending on the sender geography and service plan) and if ultimately undeliverable, the service will return an interim notice to the sender if such delivery failure can be determined conclusively upon the first send attempt, and the service will follow with a complete Registered Receipt™ email or other service report to the sender within above time parameters for Registered Receipt™ email and as per schedule for other service reports, depending on the type of status poll or reports. After a reported undeliverable message, RPost services have no additional responsibility to attempt to re-deliver the undeliverable message. It is solely the responsibility of the sender to resend messages. The RPost service operations considers a sent and undeliverable message as a consumed service Unit or Units as if the message had been delivered, with the number of consumed units based on the normal Unit calculation based on service feature, number of recipients and message sent size.
12. RPost Testimony. If the validity of a Registered Email™ receipt or the service is questioned in a legal proceeding, RPost may make in-house or third-party experts trained in the operation of the RPost service available to give testimony at a cost not to exceed a rate of $550 per hour billed in hourly increments, plus reasonable customer pre-approved travel and other expenses.
13. Reporting. RPost may provide monthly usage reports to individual users that present each RPost service Unit with detail including the time sent and the recipient destination. RPost may provide aggregate reports to corporate account administrators and alliance partners as requested. None of these reports contain message body text or attachment content but may contain message header information and message delivery metadata. RPost provides options for a right to be forgotten and levels of data masking which, if opted for, may limit the data available or viewable in its service reports. Review the RPost privacy policy notice for further information.
14. Whitelisting. RPost makes available at support.rpost.com information for whitelisting messages sent from the RPost System. It is the obligation of the customer to employ these whitelisting options for service functionality.
15. Service Plan Definitions.
    1. Term Expiration: 23:59 UTC on the last day of the period (month or year).
    2. Term Renew: Reset on the first day of each calendar month at time zero (UTC).
    3. Individual Plans: Service authorized for one human sender from one sender email address. Examples of these plans are RMail 365, RMail Standard, RMail Business, RSign 365, RSign Standard, RSign Business, RDocs™ 365, RDocs™ Standard, and RDocs™ Business plans.
    4. Shared Volume: Service authorized for finite set of associated email address senders and period message volume authorized for the plan, within one sending company. Examples of these plans are RMail Shared Volume Monthly 10K and RSign Shared Volume Annual 10K.
    5. Maximum Users: Maximum sender email addresses that may be associated with a Shared plan.
    6. Qualified Plan: Individual plans that require a minimum number of plans to be purchased within a sending company. Examples of these plans are RMail Business, RMail Enterprise, RSign Business, RSign Enterprise, RDocs™ Business, and RDocs™ Enterprise plans.
    7. Premium Plans: Individual plans that qualify for special benefits if ordered in volume in some situations. Examples of these plans are RMail Standard, RMail Business, RSign Standard, RSign Business, RDocs™ Standard and RDocs™ Business plans.
    8. Fixed: Service shuts off when the plan message allotment in the period (month/year) has been reached. Users may upgrade plans at any time. If no upgrade is available, the user will need to contact their account manager or switch certain users to a different plan or a shared volume plan.
    9. Service Plan Message and Unit Expiration: For Monthly plans (Individual plans that have message units reset monthly and Shared Volume monthly plans), unused units expire every month; for Shared Volume Annual plans, unused units expire after 12 months from the service plan availability date or as used if used sooner.
16. Units of Measurement.
    1. RMail Unit. Each recipient destination per 5-megabyte message size is one Unit, whether deliverable or undeliverable.
       1. Explanation of Service Enhancement Units:
          1. RMail Encrypted Reply™: If a recipient clicks the link to initiate an Encrypted Reply™ message, there is one additional RMail Unit consumed per up to five replies per original sender’s sent message, regardless of cumulative file upload size.
          2. RMail File Share™: If a recipient initiates a large file share transmission, one RMail Unit is consumed per 100mb cumulative size of the files transmitted per send.
          3. RMail Register Reply™: If a recipient replies to a Register Reply™ message, there is one additional RMail Unit consumed per reply to that Register Reply™ message.
          4. RMail E-Sign™: When a sender initiates an RMail E-Sign™ message (regardless of feature combination, E-Paper, Tags, Click, Sequential) one additional RMail Unit is consumed even if the recipient does not complete the e-sign process.
          5. RMail Registered Receipt Authentication: Each automated authentication of a Registered Receipt™ email record is one Unit; except for extra-large Registered Receipt™ email record authentication (defined as Registered Receipt™ file size greater than 15 MB) which is five Units. These RMail Units are consumed on the original sender’s account.
       2. Default Plan Recipients per Message. For each sent message under the default service plan, one Message Unit may include up to 10 recipients and may be up to 25MB.
    2. RSign Unit. Each message envelope comprising up to 25 recipients and per 25 MB message size is an RSign Unit (other than abovementioned RMail E-Sign (a/k/a RSign Lite usage). RSign Bulk Send services consume one RSign Unit per sent message envelope (a set of recipients associated together in the Bulk Send process is one envelope, and therefore one RSign Unit).
    3. RDocs™ Unit. Use is measured per RPD Unit Count, and RPD Units are made available per service plan and associated with the RPD document owner also known as the Originator (not necessarily a sender, but the user account that created or originally converted and sent the RPD file). There are two types of Units, Page View (PV) Units and Create (C) Units, the sum of both PV and C Units is the total RPD Unit Count. A C Unit is defined as per document per created page, a created page is a page converted into RPD format, with the count being one C Unit for each of the first ten created pages and one C Unit per additional ten created pages, per document created. A PV Unit is defined as one PV Unit for each of the first ten unique page views per Viewer Session per RPD file, and in the same Viewer Session plus one Unit per additional ten Unique Page Views per Viewer Session of the same document. A Viewer Session is defined as an uninterrupted browser view by viewer, regardless of duration, until timeout or the session is technically required to re-process. A Unique Page View is defined as the first time a particular page is viewed per viewer session. Note, RDocs™ Service makes available an alternate Unit accounting model for select OEM partners, called X-Units. X-Units should not be confused or compared with RPD Unit Count based on PV and C Units.
17. Default Service Parameters. Refer to the support references for Default Service Parameters of the RMail Platform, RSign Platform, and RDocs™ Platform. Refer the RPost Billing Guide (available upon request) for further details on service and plan parameters and accounting for use. These service parameter reference pages are incorporated by reference. The Default Service Parameters Notice is available at rpost.com.
18. Fair Use Policies. Fair use policies apply to all plans, and include limits per plan, limits per send, non-use for unsolicited marketing purposes, and non-use for unlawful transmissions. RPost reserves the right to terminate service or to temporarily freeze the user’s account and/or contact the user or their administrator to verify if traffic is authentic and determine if the particular user’s plan parameters should be adjusted. RPost reserves the right to change this Fair Use Policy at any time. Changes shall become effective after thirty (30) days of publication of the revised version on rpost.com. Continued use of a subscription after expiry of the 30-day period shall constitute acceptance to be bound by the terms and conditions of the revised fair usage policy. Refer to the Fair Use Policy notice available in the rpost.com/legal for further details.
19. Privacy Policies. All RPost services, including RMail and RSign, are governed by the RPost privacy policy notice incorporated by reference. The Privacy Policy Notice is available on rpost.com/legal.
20. Administrator Access. All RPost services provide the customer administrator access to some service data or metrics that may be useful to manage the customer account. It is the responsibility of the customer to determine who should be provided and who should be limited from having customer administrator access privileges. RPost provides various enhanced security options and it is the responsibility of the customer to request non-default settings or settings that limit access to customer administrators or other users. These defaults and settings vary depending on service app, interface, service plan, and/or service function.
21. Recourse for Breach. If RPost is found to be in a material breach of this Service Level Agreement that caused quantifiable damage to a customer user, with that customer and user properly using the service within the Fair Use Policies and properly paying fees in compliance with a personal or business service plan and its plan parameters (“Breach”), RPost shall have liability limited to the amount paid for those RPost messages damaged by such Breach on a pro-rata basis, based on payments made for service and service use over the prior annual period or if there is not yet an annual term for the customer and user, the average prior months payments made for service and service use since customer and user inception whichever is shorter. RPost shall not have liability for Breach for service users that do not fall within this definition of Breach. RPost shall not have punitive liability associated with service use.

III. RPost Specialized Services

1. Registered™ System
   1. Registered Email™ and its Registered Receipt™ E-Delivery Evidence
      1. Deliverability and Timestamps. Messages are sent with times recorded for: (a) proof of time of delivery (“POD”) which is the time the message that left the sender system was inducted into the RMail system for processing, and (b) proof of time of receipt (“POR”) which is the time the message was inducted into the system under the control of the recipient or authorized by the recipient to accept email on their behalf. This POR timestamp can be the time of receipt by the recipient mail server, time the email was placed in the recipient mailbox directory, or time opened at the recipient. RPost offers a special configuration option to suppress detection of opening by recipient systems which is enabled with a default setting and may be adjusted as a service enhancement, based on the desire of a customer administrator. For non-deliveries, the RMail system may return an immediate notice or may return the Registered Receipt email recording the delivery failure. Deliver Failure status is presented to the sender in these receipt emails, and it is the sender’s responsibility to contact RPost to further investigate any deliverability issues.
      2. Accessibility.
         1. Registered Receipt™ emails that are delivered to the sender are purged within the same day of delivery (24-hour period); delivery defined herein by collection or transmission of the Registered Receipt™ email by API to the sending organization or sender controlled systems, or by time of first attempt to transmit the Registered Receipt™ record by email to the sending email address, the sending organization, or sender controlled systems, except
            1. if the Registered Receipt™ email has not been collected by the sending organization or sender- controlled systems by API, this Registered Receipt™ record shall be retained for a maximum of 14-days, or
            2. if the Registered Receipt™ email has not been deliverable by SMTP to the sending email address, the sending organization, or sender-controlled systems (as configured in normal settings or otherwise in the RPortal) on first attempt, the Registered Receipt™ email record shall remain available for delivery retries for a maximum of 14-days from the original send attempt, unless
            3. an alternate arrangement has been established for a specific customer.
         2. Registered Receipt™ emails that are larger than the threshold set in RPortal for the feature, “Automatically send Registered Receipt email by LargeMail file share when over this size” will be sent by the RMail File Share service and will be retained for a maximum of 7-days. In the case where the RMail system cannot deliver the Registered Receipt™ email record to the sender due to problems with the sender mail system receiving email address, size limitations, receipt retrieval deficiencies, administrator data entry or an otherwise misconfiguration of Registered Receipt™ email destination addresses in RPortal, or otherwise, and if the Registered Receipt™ email record is no longer available, the sender must rely on delivery information (Transaction Metadata) in the Usage Report for that transaction. It is the responsibility of the user to retrieve their Registered Receipt™ emails before the retention time periods expiration.
      3. Managed Receipt Archive. Registered Receipt™ email records are not automatically stored by the RMail system as described herein. The RMail system has an opt-in feature enhancement that provides for long term storage of Registered Receipt email records for 18 months or longer if extended by contract. These receipts are stored on servers managed by one of RPost’s cloud infrastructure providers and availability of these stored receipts is dependent on redundancy based on these providers infrastructure management policies. Registered Receipt email record size limits are dependent on RPortal settings (conversion to large file format may be set by customer administrators or users at 10Mb, 15Mb, or 20Mb or with no limit; it is the responsibility of the sender organization to manually capture Registered Receipt email records returned in the large file share format as these are not captured and stored in the RMail Managed Receipt Archive.
      4. Authentication. Registered Receipt™ email records may be automatically authenticated by an active service user or their designee while the service user who sent the original message that generated the Registered Receipt email record maintains a commercial fee-for-service plan with automatic authentication and a properly maintained Registered Receipt email record. Once a service customer cancels their service account or ceases to pay fees due, RPost does not have any responsibility to continue to provide authentication services. RPost has no obligation to authenticate the same Registered Receipt for more than ten authentication requests or for more than seven years from original creation, although it may do so at its sole discretion. Users may use their own experts to authenticate the receipt information at any time. Users may request RPost to provide additional receipt authentication services at any time and RPost reserves the right to charge additional fees for such additional authentication services or authentication services for cancelled customers. For service users that received a Registered Receipt email record while using a Default and Trial service plan, while RPost generally provides automatic authentication services for those Registered Receipt emails generated during Default service plan use within the parameters mentioned above with no fee for service requirement, RPost has no obligation to authenticate any Registered Receipt email sent with a Default or Trial service plan and may at its sole discretion require a fee for such Default and Trial plan user authentication services.
      5. Encrypted Content. Registered Receipt™ email records may be automatically authenticated and if so, reconstruct the original message content. This original message content is not stored by the RMail System. It is reconstructed from data embedded within the Registered Receipt itself. For encrypted messages, the reconstructed message will remain encrypted. It is the responsibility of the customer or customer user to maintain a means to decrypt the reconstructed encrypted message using original encryption passwords or requesting support from RPost to obtain a means to decrypt which is available for active fee-paying service users and may require an additional fee.
   2. Registered Encryption™.
      1. Sender to RMail Cloud
         1. Message Level Encryption. The RMail Platform provides an option to send Message Level Encryption (RSA-256Bit) from the sender device to the RMail Cloud if the sender is using the RMail for Outlook app to send, with the Local Encryption setting enabled. The customer or their administrator may disable Local Encryption and rely on their Network Encryption -- in doing so, the Registered Encryption™ service will report, if detected, the level of transmission encryption from the sender’s last Internet hop to the RMail Cloud.
         2. Transmission Encryption. The RMail Platform provides customer senders, their administrators, or their email sending providers the availability of transmitting messages encrypted directly to the RMail Cloud using HTTPS connections or SMTP connections with TLS enabled. It is the customer sender, their administrator, or their email sending provider responsibility to select the method of secure transmission to the RMail Cloud and if transmitted using SMTP connections with TLS enabled, that the sending servers are properly configured for such a transmission.
      2. RMail Cloud to Recipient
         1. Message Level Encryption. Customer administrators and/or senders are responsible for selecting the default and/or minimum encryption method from the RMail Cloud to the recipient; which default method varies depending on the sending app, sender configuration or sending customer administrator preferences. If Message Level Encryption is triggered, that minimum level is AES256-bit PDF encryption. Password option defaults if applicable vary depending on the sender app, sender preferences, sender customer administrator, and/or recipient preferences. Customer administrators are responsible for setting any short term encrypted message attachment download alternate options (e.g., default download option enabled or disabled, default 7-day attachment download option enabled with options to extend the storage for up to 90-days).
         2. Transmission Encryption. Sender or customer administrators are responsible for selecting the minimum level of transmission layer security that they would like to enforce (e.g., TLS 1.0, 1.1, 1.2, 1.3) and, if the minimum set level cannot be met, the system transmission dynamically reverts to an alternate Message Level Encryption with the RMail AES256-bit PDF Message Level transmission method.
         3. Encrypted Reply. The reply message and its attachments transmit back to the sender encrypted using the same settings set by the originating message if the encrypted reply service is used.
      3. Auditable Record of Affirmative End-to-End Encrypted Transmission.
         1. The Registered Receipt™ email record: provides a fact record of affirmative encrypted transmission from the RMail Cloud to the recipient.
         2. With the Registered Encryption™ enhancement enabled: the Registered Receipt™ provides a detailed encryption status report for the transmission leg from the sender (or sender’s last Internet hop to the RMail Cloud) to the RMail Cloud and from the RMail Cloud to the recipient (or recipient Internet email gateway). An encryption status report that indicates end-to-end encryption is a record of fact of affirmative end-to-end encrypted transmission based on information the RMail Platform collects from normal transmission server operations. The encryption status report describes the level of encryption that the system could determine using information created at third party systems and therefore, in some embodiments, may rely in some part on the accuracy of some of the data added to the message structure by third party systems. A report of an affirmative end-to-end encryption transmission is created with underlying forensic data in a format that may be authenticated with the message content and timestamps of transmission.
         3. Encryption status scores: the 5-star end-to-end encryption status framework and the Fail, Inconclusive, Fair, Moderate, Best, Best+ ratings are subjective scores based on criteria that the RMail Platform deems to be important. These scores are based upon criteria that the RMail Platform associates with a level of adequacy of a particular form of transmission encryption – each sender or customer administrator may choose to rely on these scoring scales at their own discretion; to facilitate a sender or customer administrator in making their own determination of the adequacy of the score criteria, the Registered Encryption™ transmission encryption status report provides the underlying data such that any sender, their experts, or their assigns may make their own determination of encryption adequacy based on their own criteria. Each customer may request how these ratings are derived and choose on their own how to use the rating data.
         4. Encryption status of “Inconclusive”: means the RMail Platform could not conclusively determine if a transmission leg was encrypted or not encrypted, through its initial analysis.
         5. Encryption status with an “*”: means the RMail Platform could not conclusively determine if a transmission leg was encrypted or not encrypted, through its initial analysis, yet is opining and reporting on a level of expected encryption in that transmission leg based on a recent (within 14-days) analysis of the normal behavior of that sending server (last hop into the RMail Cloud).
         6. The RMail Platform forensic Request: RMail makes available a process to request a further forensic analysis of any Registered Encryption™ transmission with a status reported as “Inconclusive” or with an “*” if such request is made within five days of the original Registered Receipt™ generation date. The RMail Platform makes available a process to request a further forensic analysis of any Registered Encryption™ transmission with any other encryption status reported, one time per month per customer, if such request is made within five days of the original Registered Receipt™ generation date. Both such requests must be submitted through the RMail Platform support ticket process and are available only if the sender has a valid Enterprise paid support plan. The “further forensic analysis” service has a mean time to complete of 72 hours from request submission.
   3. Digital Seal^® Sent Message Authentication at Recipient.
      1. Digital Seal Service Requires Seal HTML File. Recipients of messages sent from senders originating their message and sending with the RMail for Outlook app, other RPost apps with the Digital Seal Sender Authentication, or API and automated sending options specially configured to enable the Digital Seal^® service option can verify the integrity of the sent message, original sender address, original content, and original time of transmission so long as the Digital Seal HTML file (“Digital Seal Mark”) is available. RPost makes no warranty that the Digital Seal Mark will remain valid in all email systems of all recipients and as that email sent with a Digital Seal Mark is forwarded. RPost makes no representation that a Registered Email™ message with a Digital Seal Mark will have the Digital Seal remain associated with the Registered Email™ message at or after that Registered Email message reaches its first destination. RPost makes no representation that the RPost service will be capable of sending all email, tagged by the End-User for Digital Seal protection, with a Digital Seal. Further, RPost does not claim that the Digital Seal Mark can prove the human identity of the End-User or sender of the Registered Email™ message that has Digital Seal protection.
      2. Authentication. The Digital Seal^® Mark may be automatically authenticated by an active service user or their message recipient as long as the service user who sent the original message that generated the Digital Seal Mark maintains a commercial fee-for-service plan. Once a service customer cancels their service account or ceases to pay fees due, RPost does not have any responsibility to continue to provide authentication services. RPost has no obligation to authenticate the same Digital Seal Mark for more than ten authentication requests or for more than seven years from original creation, although it may do so at its sole discretion. Users may use their own experts to authenticate the Digital Seal^® Mark information at any time. Users may request RPost to provide additional Digital Seal^® Mark authentication services at any time and RPost reserves the right to charge additional fees for such additional authentication services or authentication services for cancelled customers. For service users that sent or received a Digital Seal^® Mark email record while using a Default and Trial service plan, while RPost generally provides automatic authentication services for those Digital Seal^® Mark emails generated during Default service plan use within the parameters mentioned above with no fee for service requirement, RPost has no obligation to authenticate any Digital Seal^® Mark email sent with a Default or Trial service plan and may at its sole discretion require a fee for such Default and Trial plan user.
      3. Digital Certificate. For key accounts and partners that have proper authentication and identity trust chains in place, the Digital Seal^® service may be configured to additionally digitally sign an email attached PDF file using a PKI digital certificate and may be additionally configured to digitally sign an email attached PDF file using a digital certificate provided by and uniquely tied to the identity of a sender. While RPost does use best efforts to verify the validity of such a digital certificate provided by a sender, RPost is not the issuer of such digital certificate and relies on the RPost customer to provide RPost a validly issued digital certificate.
2. RMail^® System
   1. RMail Gateway
      1. Message History Storage. RMail Gateway default settings include a 7-day cache of message history metadata with no retention of message body and attachment content.
      2. Inbound. Customers are obligated to monitor and manage inbound services in terms of inbound quarantines. All inbound message quarantined traffic is retained in a 7-day quarantine cache.
      3. Outbound. RMail Gateway default settings include standardized packages of message filter and route rules. Customers may request custom filter and route rules that may be considered packages for compliance for various regulations (i.e., HIPAA, GDPR, etc.). While RPost provides standardized rule sets, may suggest standardized or custom rule sets, or may create new standardized or on-demand custom rule sets, RPost does not attest to any rule set guaranteeing compliance with any regulation or requirement, regardless of what the rule set is named or how referenced. It is the customer’s sole responsibility to determine which filter and route rules are suitable for their business needs, regulations, and/or requirements. Should a customer opt to use filtering policies that block outbound transmission and quarantine outbound messages before transmission, customers are obligated to monitor and manage all their outbound message quarantines. All outbound message quarantined traffic is retained in a 7-day quarantine cache.
      4. Archive. If any RMail Gateway service is used for message archiving, it is the responsibility of the customer to manage their desired archive retention policies and remain current for fees associated with archive storage. RPost retains the right to purge archived messages after a customer ceases to make timely payments for services or otherwise cancels their service agreement for RPost services. If service fees are less than 90 days past due, RPost shall provide at least one electronically delivered notice with a record of sending attempt, to the last recorded administrator email address associated with the customer account prior to purging an archive. If service fees are more than 90 days past due, RPost does not have any obligation to continue to store data and may purge data without notice.
   2. RMail Recommends™. RMail Recommends default settings include standardized packages of message filter and processing rules. Customers may request custom filter and service processing rules that may be considered packages for compliance for various regulations (i.e., HIPAA, GDPR, etc.). While RPost provides standardized rule sets, may suggest standardized or custom rule sets, or may create new standardized or on-demand custom rule sets, RPost does not attest to any rule set guaranteeing compliance with any regulation or requirement, regardless of what the rule set is named or how referenced. It is the customer’s sole responsibility to determine which filter and service processing rules are suitable for their business needs, regulations, and/or requirements. RPost reserves the right to charge additional fees for use of this service or for users who modify filter and processing rules on their own or with RPost support.
   3. RMail PRE-Crime™ Targeted Attack Pre-Emption
      1. Active Tracker™ Technology: As a main module of RMail, an option in RSign, in RDocs™ service, or as a standalone widget that may be added to RPost or third-party applications, the RPost Active Tracker™ technology offers services including its Email Eavesdropping™ alerts, its Aggregate Heartbeat™ monitor, and its Active Threat Hunting alerts, among others. These technologies and the resulting services provided to users rely on continuously changing third-party private and public data, databases, and information received as a result of technology methods, that taken together, provide customer insights. Neither RPost nor any service component nor affiliate guarantees that these insights detect active, passive, in-progress or planned cybercriminal threats. These technologies and services are rather designed to, and are offered to users with their explicit understanding that, insights provided (which are in many cases dependent on user or admin settings) serve as an additional layer of information that may help them make informed decisions related to technology messaging use and threats. Read more in the Privacy Policies – Active Tracker Technology in the RPost terms section at rpost.com/legal.
      2. Right Recipient™ Technology: RMail offers services based on analyses using its Right Recipient™ technology, including its Lookalike Domain™ alerts, its Reply Hijack™ monitor, and its Redact+ alerts, among others. These technologies and the resulting services provided to users rely on continuously changing third-party private and public data, databases, and information received as a result of technology methods, that taken together, provide customer insights. Neither RPost nor any service component nor affiliate guarantees that these insights detect active, passive, in-progress or planned cybercriminal threats. These technologies and services are rather designed to, and are offered to users with their explicit understanding that, insights provided (which are in many cases dependent on user or admin settings) serve as an additional layer of information that may help them make informed decisions related to technology messaging use and threats.
      3. Email Impostor Alerts. RMail makes available certain tools to assist in detecting impostor email and/or assist in preventing mis-directed email. These systems use header structures, RMail proprietary algorithms, and other data including third party domain name registry information. These RMail tools do not themselves prevent customers from receiving or being harmed by impostor email or other malicious email threats. They are designed to provide users with additional insights to make them more aware of risks associated with certain types of email or email with certain content.
      4. RMail Protect-the-Thread™ Content Controls. RMail makes available certain tools to assist in removing tagged content from email that the sender or sender organization considers to be sensitive or worthy have being removed from email threads after transmission. These RMail tools do not themselves prevent forwarding or other methods of sharing email content. They are designed to provide users with additional methods of making certain content less sharable. RMail Disappearing™ ink can be configured by the sender or their IT administrator to maintain a copy of the content in the Registered Receipt™ email record returned to the sender, however, by default, there is no copy of this content in either the sent folder or the Registered Receipt™ email record returned to the sender. Redact+ redacted content is always retained in the Registered Receipt™ email record returned to the sender.
   4. File Share. File share services store message content for short terms, and after the term, the message content is automatically purged. It is the responsibility of the customer or customer user to maintain the privacy of this content by choosing the encrypted File Share option or otherwise using methods not to publicize the link to retrieve the message or files sent. The RMail system secures the internet connection in the browser and may additionally secure access to the files shared if the encryption option is selected. File(s) are stored for 14-days from when the message was received by the RMail system for processing by default. Customers may request service enhancements to permit changes in storage times with default parameters from 1 to 90 days.
   5. API Use. RPost reserves the right to charge additional fees based on the volume of transactions and data transferred using RPost APIs. It is the customer’s responsibility to use the API that it may be provided to obtain Registered Receipt and other data records before those records are purged from RPost systems according to the timeframes and parameters associated with each service function. RPost reserves the right to restrict or adjust access to APIs.
3. RSign System.
   1. RSign Lite. RSign Lite (also known as RMail E-Sign) service messages are processed by the RMail System. RSign Lite services do not retain any document records after the transaction processing period ends, which is a default of 30 days after the message was originally sent through the service with configurable parameters up to 90 days.
   2. RSign Storage. Customers may opt for the RSign system to store copies of transaction data and completed transactions in a repository available to the customer user or customer administrator. Unless storage enhancements are selected or service plans are activated that dictate longer term storage, and unless the sender organization opts to purge data sooner, RSign Systems will retain information for a minimum of 90 days in live storage and 1 year in archived storage. With RSign Business Plans, unless the sender organization opts to purge data sooner or opts for other parameters, RSign Systems will retain information for 18 months in live storage and 3 years in archived storage with a mean time 48-hour archive retrieval window. RPost may at its sole discretion maintain information in live storage or archived storage for longer periods of time so long as it does not exceed the maximum storage period selected by the customer. It is the responsibility of the customer to manage their desired retention policies and remain current for fees associated with storage. RSign transaction data will be maintained for commercial fee-for-service plan users according to these policies. Once a service customer cancels their service account or ceases to pay fees due, RPost retains the right to purge archived transaction data after a customer ceases to make timely payments for services or otherwise cancels their service agreement for RPost services. If service fees are less than 90 days past due, RPost shall provide at least one notice recorded as sent electronically with a record of sending attempt, to the last recorded administrator email address associated with the customer account prior to purging an archive. If service fees are more than 90 days past due, RPost does not have any obligation to continue to store data and may purge data without notice. It is the responsibility of the customer to manage their desired retention policies and remain current for fees associated with storage. RPost may continue to retain service billing audit records which comprise of transaction metadata. RPost has no obligation to maintain storage for Default and Trial service plan users or users that access RSign from within their RMail service plan as a Default or Trial service plan.
   3. RSign Privacy Modes and Storage Opt-Out. Customers may opt out from any storage of completed transactions. RPost may continue to retain service billing audit records which comprise of transaction metadata. RSign includes three advanced data privacy, masking and deletion settings that may be available to customers based on their geographic location or service plans; and may be relied upon for privacy compliance with the European General Data Protection Regulation (GDPR). These include:
      1. RSign Private Mode, which may be enabled (1) on a transaction-by-transaction basis by the end user (at the time of sending), (2) on a transaction-by-transaction basis with a template or rule configuration setting, (3) enabled for all of an individual user’s e-sign transactions by default or for a set period of time (when Private Mode is enabled), or (4) enabled for all users in a company account for all e-sign transactions by default for a set period of time (when the setting is enabled). This setting, only for transactions that are initiated while Private Mode is enabled, permanently prevents viewing of a specific RSign transaction document sent for e-signature and e-sign record content, other than for the user initiating the transaction and for the participants in the transaction. It is important to note that this setting is timestamp-transaction dependent meaning Private Mode applies to specific transactions that are initiated at a time when the setting is enabled for a user, or for a transaction that the user applies it to, and it cannot be reversed for that or those particular transactions (e.g. enabling Private Mode permanently prevents a customer administrator access to the content of a particular transaction).
      2. RSign Masking Mode, which may be enabled for all customer records and may be disabled at any time by the customer administrator, and while enabled, obfuscates the message transmission data in the RSign interface and prevents record or document download for all records for any user except for the customer administrator and the initiator of the transaction. It is important to note that this setting works like a “toggle” that may be adjusted by the customer administrator and if enabled (Masking On) it will apply to all past and future transactions; if later disabled (Masking Off) it will disable for all past and future transactions. RPost recommends enabling RSign Masking Mode by default for customers that user RSign for transactions across a variety of business groups or business roles within a business group. RSign Masking is compatible with “RSign Private Mode”, meaning, a user may select a transaction for Private Mode even if RSign Masking Mode is enabled, meaning that particular transaction be private from that customer administrator per the Private Mode functionality; the Private Mode functionality remaining for that transaction that occurred with Private Mode enabled, even if RSign Masking Mode is later toggled off (disabled).
      3. RSign Delete Mode, which permanently obfuscates the message transmission data in the RSign interface and prevents record download for all users including the customer administrator and the initiator of the transaction (other than for the record that the transaction parties receive by email) and auto-purges the transaction record after a pre-defined number of days (7, 10, 14, 30, 60, 90, 180 or 365 days) from the transaction initiation date, with the RPost system only maintaining base transaction metadata for billing records purposes.
         1. Transaction Data and Metadata: When RSign Delete Mode does not apply, then RPost retains transaction data and metadata during the billing period associated with each RSign transaction. RPost generally retains RSign transaction data and metadata (metadata excludes message body, attachment, or transaction complete content) during the contract period associated with each customer. RPost may retain RSign transaction data and metadata during the transaction billing period, the customer contract period, and after the customer contract period; however, RPost does not have an obligation to retain RSign data or transaction metadata beyond the transaction billing period unless specifically contracted for such. RPost provides professional services to permit an individual user (a user who is not part of multi-user customer account) who ceases to continue to use RSign services to request a purge of that individual’s RSign transaction data and metadata and RPost shall provide such services at no cost to the individual if privacy regulations within the jurisdiction of that individual require such to be free-of-charge. RPost provides professional services to permit a business customer (a customer account with multiple users) that ceases to continue to use RSign services to request a purge of that customer’s transaction data (while a customer, via the RSign Delete Mode) or transaction metadata and RPost offers to provide such services based on an approved professional services statement of work. The content in this Transaction Data and Metadata section does not relate to the authentication capabilities associated with a valid RSign applied digital signature on an RSign transaction record which operates independently of the abovementioned retention of transaction data and metadata.
      4. RSign End-to-End Encryption Feature, when used with RSign Privacy Modes and Storage Opt-Out, changes the ability to access unencrypted transaction records as downloads from within the RSign web interface (or API). Transaction record content will be accessible for viewing and download without a password associated with that transaction record after log-in to the relevant RSign account unless RSign Privacy Modes and Storage Opt-Out options maintain the privacy, masking, or deletion of that particular transaction or views per these settings.
      5. RSign API Record Retrieve, when used with RSign Privacy Modes and Storage Opt-Out, will only retrieve transactions that would be permissible to view under the user’s (API key user’s) permissions per the RSign Privacy Modes and Storage Opt-Out options associated with the user or the transaction.
   4. API Use. RPost reserves the right to charge additional fees based on the volume of transactions and data transferred using RPost APIs. It is the customer’s responsibility to use the API that it may be provided to obtain transaction data and other data records before those records are purged from RPost systems according to the timeframes and parameters associated with each service function. RPost reserves the right to restrict or adjust access to APIs.
4. RDocs™ System.
   1. Document Availability. RDocs™ protected document (also known as “RPD” files) may be automatically authenticated by an active service user or their designee while the service user who sent the original message that generated the RPD record maintains a commercial fee-for-service plan associated with ongoing RPD services. Once a service customer cancels their service account or ceases to pay fees due, neither RPost nor its service providers, affiliates or sellers have any responsibility to continue to provide document authentication services, although they may do so at their sole discretion. Once a service customer cancels their service account or ceases to pay fees due, neither RPost nor its service providers, affiliates or sellers have any responsibility to maintain the sender user interface where the original sender may access data about the RPD and/or control the future accessibility of any of that sender’s previously sent RPD messages. If a user cancels, after cancellation, they no longer have access to use the sender interface to kill or control a document already sent. Neither RPost nor its service providers, affiliates or sellers have an obligation to authenticate the same RPD for more than one hundred authentication requests or for more than one year from original creation, although they may do so at their sole discretion or under service plans or specific service agreements. When authentication services are terminated for an RPD, the RPD content may no longer be accessible. If an RPD is disabled, it will no longer be available for a viewer, unless it is re-enabled. If an RPD is “killed” it will irretrievably be disabled and data associated with it may be purged by RPost. Refer to RDocs™ Unit definitions for more information.
   2. Document Settings - RPost Admin. There are many settings that RPost Admin can enable or alter for a customer. Two main settings are:
      1. Max pages per RPD for all users within the customer (or customers within the hierarchy). Options: select from pull down: 100, 250, or 500. The default 100.
      2. Max Reads per RPD maximum of default in 100,000, can be configured higher or lower by global admin per customer.
   3. Document Settings - Customer Admin. There are many settings that customer admins can enable or alter for a customer. Some main settings are:
      1. Access-Paused Automation: # days from creation to automatically become Access-Paused. Options: configurable number, default 365, max 2000.
      2. Permanent Expire Re-Activation Window: # days from creation to automatically become permanently Access-Paused (with metadata remaining accessible) if not re-activated within the set number of days after entering this access pause state. If re-activated, remains Available for the Access-Pause Automation parameter. (This is the window of days of ability to re-active after access paused RPD before permanent access pause.) Options: Days available to re-activate a Permanent Expired RPD: default 30, configurable, max 365.
      3. Permanent Kill State: Time before Kill state becomes irreversible including purge of metadata. Options: configurable by hours, range 0 to 72, default 48. Note, a Kill can only be reversed through a professional services ticket within the first (default) hours.
      4. Track Kill Data: Enable or disable tracking of total killed documents by date range.
      5. Max Reads per RPD has default of 1000 with a maximum of 100,000.
5. Infrastructure and Data.
   1. Transaction Metadata. RPost retains transaction metadata during the billing period associated with each RMail transaction. RPost generally retains RMail transaction metadata (which excludes message body or attachment content) during the contract period associated with each customer. RPost may retain RMail transaction data during the transaction billing period, the customer contract period, and after the customer contract period; however, RPost does not have an obligation to retain RMail transaction metadata beyond the transaction billing period unless specifically contracted for such. RPost provides professional services to permit an individual user (a user who is not part of multi-user customer account) who ceases to continue to use RMail services to request a purge of a that individual’s RMail transaction metadata and RPost shall provide such services at no cost to the individual if privacy regulations within the jurisdiction of that individual require such to be free-of-charge. RPost provides professional services to permit a business customer (a customer account with multiple users) that ceases to continue to use RMail services to request a purge of that customer’s transaction metadata and RPost offers to provide such services based on an approved professional services statement of work. The content in this Transaction Metadata section does not relate to Registered Receipt™ email records or Digital Seal^® email or sender authentications, both of which operate independently of the abovementioned retention of transaction metadata.
   2. Data Cloud Systems. RPost relies on three main cloud infrastructures, Amazon AWS, Microsoft Azure, and Google Cloud. RPost makes available by request, information related to which services operate on which infrastructures in which geographies, for customers that require information or documentation related to the RPost services that they contract or pay for.
   3. Cryptography. Each RPost service that employs encryption and where it employs encryption uses strong encryption algorithms suitable for commercial use. These algorithms may change over time as new best-practice definitions emerge, or RPost may provide options to users or administrators to choose what encryption levels to user for which services. RPost cannot guarantee the privacy of, or non-adverse impact on past encrypted message or document privacy, past encrypted message or document access within any of its services if a user or threat actor has access to computing power and technology referred to as quantum computing or computing power and technology sufficient to obsolete today’s standard encryption algorithms. These standard encryption algorithms in use at the time of publishing this version of the service level agreement are TLS 1.0, 1.1, 1.2, 1.3 (with variance dependent on sender or admin settings and/or recipient server acceptance), RSA-AES256, and/or PDF-AES256. All system stored data is encrypted at rest. The storage volumes are encrypted at block level using AES-256 in a manner consistent with NIST 800-57 and with FIPS 140-2 approved algorithms. Read more in the NIST FIPS 140-2 section of RPost terms at rpost.com/legal.
   4. Online Marketplaces Europe Access. RPost is considered a “Trader” for EU Transparency Requirements. (On April 11, 2018, the European Commission adopted the New Deal for Consumers, stating that the legislation is “aimed at strengthening enforcement of EU consumer law” and “modernizing EU consumer protection rules in view of market developments.” If the declaration is made, the “Trader” for the purposes of this is: RPost UK Limited, The Glades, Festival Way, Festival Park, Stoke on Trent, ST1 5SQ, United Kingdom.

Download PDF Version Spanish PDF