JACMail Version 2 is very similar to Version 1 on the surface. Under the hood however, there have been substantial changes. JACMail is an Email Client Program designed to allow fast and efficient recovery of email from a POP3 server, and the sending of email through an SMTP server. It is primarily oriented towards text based messaging with attachments, and does not directly support highly formatted HTML based email or embedded objects. It receives and stores both text/plain and text/html messages, and Web based emails (HTML) can be sent to your default browser for viewing. It also supports Plain Authentication based POP3 and multiple mailboxes. The mailboxes are stored in an Access database utilising ODBC.
The code uses IP Version independent system calls, so it will only work on Windows systems that actively support both IPv4 and IPv6. That more or less restricts it to Windows Vista or later. It has been tested on Windows Vista, Win 7, and Win 8.1, and utilises the following standard components and references:
RICHED32.DLL
RICHTX32.OCX
COMDLG32.OCX
MSSTDFMT.DLL
MSBIND.DLL
MSADODC.OCX
MSDATGRD.OCX
which the user must have available in order to compile the program.
Unlike Version 1, this version is Unicode compatible. It is NOT Unicode compliant. Email still requires ASCII.
Version 2 supports message encryption. Although any JACMail2 Client can receive and decrypt messages sent by JACMail2, the sending of encrypted messages requires a server component (posted as a separate item).
J.A. Coutts
Updated (08/23/2014): See next post for details.
Last edited by couttsj; Aug 23rd, 2014 at 09:06 AM.
JACMail2 sent the Message-ID in clear text to the Key Server. If a man-in-the-middle was able to obtain the original encrypted message, he/she would be in possession of the ID and could monitor network traffic for that ID. The hacker could then intercept the returning packet with the encrypted key. He/she would then have all the necessary ingredients to decrypt the original message, and we would be none the wiser.
Consequently, the JACMail2 and JACMailSvc programs have been changed to provide protection against this type of attack. The following points in the orginal post have been changed to reflect that, as well as the downloads themselves:
6. At this point, both the sender and the receiver possess the encrypted message and the sender possesses the encrypted key. The receiver then connects with the Message-ID Domain Name on a specified port, and sends the Exchange Public Key with the Message-ID embedded in it. The Message-ID server doesn't necessarily have to be the actual server that sent the message, but it must have access to the encrypted Random Key and the Message-ID.
7. The sender server looks up the Message-ID, and recovers the associated encrypted Random Key. It then encrypts the Random Key with the Exchange Public Key, and sends it back to the receiver. It then saves the IP address and date/time used to recover the key. This step provides protection against the contents of the message being modified. Subsequent requests from non-authorized addresses are ignored.
8. The receiver uses the Exchange Private Key to decrypt the Random Key. He/she then hashes the encrypted/encoded message, derives a key from the hash, and uses it to decrypt the Random Key. The receiver then decodes and decrypts the message, and saves the encrypted Random Key.
This has required the addition of two new routines to the clsCrypt Class; ExportSessionKey and ImportSessionKey.
The reason for using the Exchange Key Pair is that it is automatically generated by the Operating System and requires no user intervention. This still aligns with the original target of not having to manage keys.
A DNS cache can be poisoned to point a user to different site than the intended one. For the truly paranoid security buff, the Key Server location can be programmed into the HOSTS file on the Client machine to protect against this. It also has the advantage of being much faster and allowing a server on a dynamically assigned IP address to be more easily adjusted for.