|
Registered Receipt
™
|
The core value of the Legal Proof® feature is the functionality of the Registered Receipt™ email , which is returned to the sender within one business day. The Registered Receipt™ is tamper-detectable, and provides the sender with an admissible, legally verifiable record of the entire transaction. It provides:
» Proof of delivery
» Proof of content delivered (including attachments)
» Proof of official time sent and received
RPost does all of this without storing any email or attachment content or requiring any action from the recipient
Snapshot of a Registered Receipt™:
The Registered Receipt™ is returned to the sender of a Registered Email® and can be set to be stored in a separate folder within the sender's inbox called (R)eceipts™ which is automatically created when the first receipt is returned to the sender. The sender can also opt to store an extra copy of the receipt in a central archive, or in RPost’s Transactional Archive™ system (learn more).
The Registered Receipt is delivered after a few minutes and up to one business day after the email has been sent, depending on different factors. There is however no delay in the delivery of the email compared to an unregistered or standard email.
One Registered Receipt™ is returned containing the transmission information for all of the recipients of a particular Registered Email® sent.
Common Questions:
What would make the Registered Receipt vary in time it takes for it to return to the sender?
Factors that determine the time it takes for the Registered Receipt to return to the sender are, among others:
» The number of recipients the email is sent to. The more people cc'd, bcc'd, the longer the system may take to determine legal delivery for each email address because there is a greater chance that one of the recipients' servers will respond more slowly.
» If there is a delivery failure (usually due to an incorrect address, mailbox full or recipient server problems) then the RPost system tries to re-deliver the message for several hours before sending back the Receipt with a Delivery Failure.
» The mail server settings of different recipients may vary. RPost provides the greatest amount of information possible about the delivery of the email. The time it may take to receive information from different recipients systems may vary.
What if I send an email to 10 people -- do I get 10 receipts?
No. Each email message, regardless of the number of recipients, will have one Registered Receipt. The only difference is that in the Delivery Status section, there will be a row of information for each recipient.
What happens if I accidentally delete the receipt, will RPost provide me with another?
No. Neither RPost nor any other party stores a copy of the original email, any content of the original email or any additional copies of the Registered Receipt™ . The sender is responsible for saving this Registered Receipt™ in electronic form. The sender can, however, designate a second email address for RPost to send a copy of Registered Receipts™ . The sender has total control of their information.
|
| |
| |
|
Just as a signature proves delivery of mail, a recorded server-to-server dialogue of message acceptance proves delivery of email. This is a precise statement of fact as to what has transpired. The RPost Registration System™ interprets the server dialog to provide the Delivery Status for each destination in an understandable format. It is included in the “Delivery Audit Trail” section of each Registered Receipt™ email.
|
| |
 |
| |
|
The red text is a recording of the server-to-server conversation that occurs when the sender's server, or mail delivery agent, asks the receiver's server, or mail delivery agent, whether that agent will accept the email on behalf of that recipient. This is an actual conversation that occurs, much like the conversation the mailman or a courier may have with the recipient's mailroom when asking for an acceptance signature.
This dialog is the precise conversation the RPost Registration System™ (the sender's agent) has with the recipient's server (the recipient's agent). This is a true recording of the conversation and is a statement of fact.
RPost translates this information for the layperson and places this translation within the Registered Receipt™ in the Delivery Audit Trail area.
These functions of the RPost Registration System are among those that are patent pending.
Common Questions:
Why do I need this included on my receipt if I cannot read it?
The reason that it is important to have this in the receipt is that this is a recording of the actual conversation that the sender’s delivery agent has with the recipient’s delivery agent. Therefore, this is the actual acceptance signature. If you look at traditional mail delivery, the actual acceptance signature is often recorded as written, even though the delivery agent (person) may also interpret that information for their records. This delivery record is much the same. It is an actual recording of the server-to-server dialog and the RPost Registration System™ then interprets this dialog for the layperson.
|
|
Each component of the RPost Registered Receipts has unique Digital Fingerprints™ for authentication on demand, as well as a data encryption signature that contributes to the RPost Digital Seal® to make the Registered Receipt™ tamper-detectable and verifiable at any time in electronic form.
The RPost Registration System™ can verify the integrity of the original email and content WITHOUT having to store ANY information about that original email.
Common Questions:
What is the largest file size one can send "Registered"?
Without a special setup, a Registered Email user can send an email to 100 recipients with a maximum file size of 10 MB. The limit on recipients per email is to prevent abuse by users who are using it the system inappropriately for email marketing purposes. The file size limit is set at 10 MB, however, most recipients will have their mail servers set with limits much lower (2 to 5 MB), so the limiting factor is not RPost but what the receiver's mail server will accept. For larger files a user will need a special set up with RPost.
Will RPost knowingly contract with known SPAM mass email marketers?
No. RPost has a strict policy against providing service for mass email marketing purposes. RPost has built technical and cost protections into the RPost Registration System™ to prevent such use.
|
|
RPost adds an official timestamp to each Registered Email message which records time sent, time received, and time opened (in many cases). All times are linked to the Atomic Clock and listed in UTC time.
Proof of Time Sent
The Registered Receipt™ records the legal time the email left the sender’s server and entered the RPost Registration Networks for processing. This is analogous to the time a post office receives a letter, processes it, and postmarks it for sending to the recipient. It meets the definition under E-SIGN and UETA for the legal time of sending
|
| |
 |
| |
This time of sending is important because often a person will press "Send" but due to their company server maintenance or other internal network issues, the email may be tied up in an internal send cue and not released until later. Further, this provides a uniform time rather than relying on the accuracy of the sender's system time.
Proof of Time Received & Opened
Time Delivered
There are two legally significant times. In addition to the time of sending, the time of delivery is the other legally significant time. The precise time of legal delivery is synchronized to the Government Atomic Time.
» Delivered (UTC): Coordinated Universal Time is GMT without daylight savings
» Delivered (local): Local time of the sender
» Opened (local): Precise time the recipient opened the email, if it can be determined before the receipt is generated and returned to sender.
|
| |
 |
|
The most significant time is the "Delivered" time. Since the baseline for legal delivery is delivery to the recipient's agent, this time reflects the time the recipient's agent signs for the mail. This is listed in Universal Time and Local Time of the sender. The third time is the time of opening if it can be detected. All times are sourced at the U.S. Atomic Clock.
If RPost™ can determine an email has been opened before the receipt is sent back to the sender, only then will the RPost Registration System™ note the time it was opened on this Delivery Receipt. If a day, week, month or later the email is opened and the RPost Registration System™ can detect it, the sender will receive a separate "Read Receipt" email for that recipient that says that the Registered Email® has been opened at a specific date or time.
Common Questions:
How often does the system know if an email has been opened?
RPost™ can give legal delivery or failure 100% of the time. As a bonus, the system will show additional information such as the "Opened" status or produce a Read Receipt™. Empirically, RPost has seen that this higher level occurs a majority of the time with its current users. Please keep in mind, however, that this depends highly on who is sending the email to whom. For some email or some recipients the recipient may never open that email. In these cases, the sender still retains legal proof of delivery.
If the Registered Receipt™ indicates that the email has been "opened," will I get a Read Receipt™ as well? No. If the Registered Receipt™ shows the email has been opened, there is no need for a Read Receipt™.
Does the receipt tell me if the attachments have been opened?
No. Just like with FedEx or USPS registered mail, these systems indicate legal delivery. However, neither these traditional methods nor RPost™ can force someone to open the email. Further, if the person does open the email, none of these systems can detect whether the recipient could read or understand the email or attachments. Unlike FedEx and USPS registered mail, Registered Email® DOES tell what was inside the "package" - the body of the email and attachment content. Again, no system can tell if it has actually been read and understood unless you stand over their shoulder and interview the recipient.
|
|
Verifying in a Dispute
Durable, verifiable and self-contained proof.
All data needed to verify the authenticity of the Registered Receipt™ or have the original, authenticated email, transmission information, and attachments regenerated, is packaged into the Registered Receipt™ itself. The RPost Registration System™ can regenerate the original content and attachments of a Registered Email® without storing any of the original email content, transmission information, or other data.
This Delivery Receipt, which is sent back to the sender's inbox, is in an authenticable form ready for verification at any time in the event of a dispute. It is a stand alone document and can be forwarded from person to person, or saved on disk and put on anyone's computer for authentication.
To verify the authenticity of a Registered Receipt™, forward the Delivery Receipt with all attachments in place to verify@rpost.net
|
| |
 |
| |
|
Within minutes, a Receipt Authentication™ email is returned to the address that requested verification.
The Registered Receipt™ authentication regenerates the transmission data and delivery status of the email as well as re-presents the original email
|
| |
 |
| |
|
In the event of a dispute, all the sender has to do is forward the Delivery Receipt of the corresponding Registered Email® to the person who is disputing the sending, delivery, times or content of the Registered Email®. Anyone who receives this Registered Receipt™ in electronic form can authenticate it himself or herself.
To authenticate any Registered Receipt™, the person with the dispute simply presses "Forward" and types in the verification address which is noted in the text at the top of the delivery receipt (verify@rpost.net). As soon as the receipt comes back into the RPost Registration System™, the system unzips the attachments and runs them through special algorithms to determine if they have been tampered with. The RPost Registration System™ sends a Receipt Authentication™ email that is returned to the address that sent the Registered Receipt™ for authentication
|
| |
|
Common Questions:
Will the Registered Receipt™ verification process work if the receipt is forwarded?
Yes. The receipt can be forwarded as many times as needed without losing its integrity as long as the attachments remain intact and attached.
How long does it take for the Receipt Authentication™ to return?
The authentication process is automatic so it will take as long as it takes your mail client to send and receive email, plus some processing time. The verification is typically returned by email within fifteen minutes.
Can I forward the Delivery Receipt to the person who is disputing the validity and write a note at the top of the email?
Yes. As long as the attachments associated with the Delivery Receipt remain intact, the Delivery Receipt will authenticate without problems. However, it is important to note that it should not be sent to the verification system "Registered" - it should be sent to the verification system by plain email.
What is the difference between "verifying" an email by using the Registered Receipt™ as opposed to verifying an email that has been sent with a Digital Seal®?
The sender receives the "Registered Receipt," therefore, they can verify the authenticity of the Registered Receipt™ or they can send the Registered Receipt™ to someone who is questioning the transmission and that person can verify the authenticity for himself or herself.
With an email sent with a Digital Seal®, the sender is providing the first recipient, or any future recipient the capability of verifying authorship and content of the **original** email sent. Any recipient can verify the integrity of that email with the Digital Seal® .
Therefore, in short, a Registered Receipt™ provides verifiable proof of delivery and proof of content for the **sender** or anyone who the sender authorized to have this capability. By contrast, an email with a Digital Seal® provides verification of authorship and original content/attachments for **any recipient** of the Digitally Sealed email.
|
|
