High Speed to Send and Receive E-mails

Data Compression: Depending on its content, this feature may reduce e-mail size up to 10 times, which facilitates a measurable speed increase and minimizes information traffic across the net. This compression always takes place internally and automatically through the method “Normal Deflate 08” (currently used in applications like WinZip). By contrast, the current e-mail protocol (SMTP) requires that all binary data in the email be converted into text format and encodes them using “Base64”, which results in a 30% size increase!

Low Hand-Shaking: HDMP requires very few steps to achieve client-server communication and send or receive e-mails. Only 4 steps are necessary to deliver an e-mail, in contrast to the 14 steps required by the current SMTP standard. This speeds e-mail sending and reception.

Unique Communication Port: Only one communication port is used to send and receive e-mails. Thus both processes take place in only one connection session, without having to connect and authenticate separately for each task (as in SMTP/POP3 standards).

Binary Protocol: HDMP uses data transmission in binary format instead of using Text. At present, data transmission in Text format (as currently used in SMTP) is unnecessary, since the user doesn’t intervene in the communication by entering commands manually. The binary protocol accelerates the transmissions because a great amount of unnecessary data is eliminated. As an additional benefit, information theft is made more difficult.


 Information Protection

Data Encryption: Activating this feature protects the content (text of the message and attached file/s) through the use of encryption methods like AES, 3DES, etc. The AES cipher is currently used by the FBI for “Top Secret” level protection. The decryption can be External (provided by the receiving user) or PDS (see below).

Encryption and decryption code “PDS Security” (Persistent Digital Signature): This code (512-bit PDS Signature) enables not only the user ID verification, but also the protection of information through automatic encryption. To achieve the automation of all these processes, the contact list of the e-mail client application provides a special field that permits to store this particular code for each contact.


 User ID Protection

Protection of Recipients’ Addresses: When an e-mail has more than one recipient, they are all treated as BCC (Blind Carbon Copy). When sending the e-mail to each recipient, the sending server removes all other recipients’ addresses, so that each recipient can only know “how many other people the email was sent to” but not their e-mail addresses. This prevents address theft due to indiscriminate address forwarding, which commonly occurs in “e-mail chains”, for example.

Safe User Authentication: User authentication to send or receive e-mails is safely achieved by sending to the server a 64-byte MD5 code, instead of having to send user name, access code and the domain it belongs to; this prevents account theft and data interception by hackers.


 Protection against SPAM and Phishing

E-mail Trace Verification: When sending an e-mail via HDMP, this goes through a series of servers till it gets to its final recipient; each intermediate server doesn’t send the e-mail to the next server without verifying before that the e-mail really comes from the preceding server. This reverse connection takes place after the primary connection, which allows a complete verification of the trace. Finally, if it is not possible to fulfill this verification at any point of the e-mail trajectory, the e-mail is destroyed and doesn’t get to the receiving user. This prevents the sending of SPAM using software known as SPAM Pumps (software for massive SPAM forwarding).

Sender ID: When sending an email via HDMP, the sending server adds the information of the “sender’s e-mail” and “sender’s name”. This feature prevents the user sending an e-mail from changing any of their data and forging their identity; or if they did, they would leave a trace of their accessing the server where they registered their account.

PDS Identity (Persistent Digital Signature): The persistent digital signature allows the ID validation of a sending user. This is so because every e-mail has a field known as PDS Checksum which stores a 256-bit number created from certain data from the email and the user’s PDS identity. The recipient can verify this number (if they have the sender’s PDS Signature) and in this way verify the authenticity of the received e-mail. If it comes to it the e-mail client application can be configured to filter e-mails that don’t validate the sender’s ID using the PDS; this would completely block unknown or ill-intentioned users.

Nonexistent Open Mail Relay servers: Users who want to send an e-mail must use the server where they opened their e-mail account since they will have to validate their identity in it to send the e-mail. This feature prevents servers from being used by third parties to send SPAM without having an account in them

Client IP Record: When sending an e-mail, the sending server takes the IP number of the sending user and attaches it to the e-mail. In this way the recipient can know the sending user’s ID, thus providing another way to know the e-mail’s origin and judge its validity.

All these features prevent phishing as well as the most common sources of SPAM, thus protecting the recipient.


 Data Transmission Reliability

Integrity Control through CRC-32: When sending or receiving e-mails via HDMP, controls of data validity are made using the cyclic redundancy check CRC-32. By contrast, the Simple Mail Transport Protocol (SMTP) doesn’t make any kind of integrity control.


 Other features

Multi-Body Capacity: E-mails can have more than one message body, a feature similar to the “sheets” in Excel documents.

Linked Attached Files: Attached files are always linked to a message body in particular; this allows separating the file belonging to each body and organizing more efficiently the information within the e-mail.

XML E-mail Header: It enables fields like user card inlay with photo, e-mail status, part sizes, digital signatures, etc.

The PDS is a free digital signature that can be used for a user’s ID validation and automatic data encryption or decryption. This signature is a hexadecimal number of 64 characters in its complete version, or 44 characters in the “identity only” version.


 How it is created

The required data for the creation of a Persistent Digital Signature are the person’s full name, city of residence or birth, and a password (this password is only used to create the signature); these are combined in a certain way using algorithms like MD5, HMAC-SHA1 and CRC16 to generate the final number.


 Constitutive parts and nomenclatures

PDS Signature: Complete signature of 64 hexadecimal characters. It has a Self Integrity Checksum.

Example: 3ba58abdae32ad0fc19a1801e2d9b9d12651304dfa5a19a7cccfa21206c92b7a

PDS Identity: It corresponds with the first 44 signature characters and enables a user’s identification. This portion can be used in isolation from the full PDS and has a self integrity checksum of the portion as well.

Example: 3ba58abdae32ad0fc19a1801e2d9b9d12651304dfa5a

PDS Security: it is found in the following 16 characters and functions as a public key for information encryption or decryption. This portion can’t be used in isolation from the full PDS.

Example: 19a7cccfa21206c9


 Use of PDS in the HDMP Standard

The two main functions of the Persistent Digital Signatures are implemented in the e-mail protocol HDMP. This means that the user that receives an e-mail has the sender’s ID authentication through PDS Identity, and e-mail automatic decryption through PDS Security.
It is worth noting that in no case the Persistent Digital Signature or any of its parts is directly attached to an e-mail or contact card, but it is simply used locally to create a code known as PDS Checksum that is calculated using several specific points of an e-mail and the digital signature itself. This prevents signature theft through e-mail interception.