Results 1 to 2 of 2

Thread: VB6-JACMail2 Email Client

  1. #1

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,477

    VB6-JACMail2 Email Client

    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.
    Attached Files Attached Files
    Last edited by couttsj; Aug 23rd, 2014 at 09:06 AM.

  2. #2

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,477

    Re: VB6-JACMail2 Email Client

    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.

    J.A. Coutts

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width