jMailRPC : email-based remote procedure executor -- or-- email-based FTP

Changes

1. Initial Version

Installation

Notes

jMailRPC is the world's slowest RPC processor or the world's slowest email-based FTP server.

There can be two responses to an email request: a reply and a reply with a zip file.

A reply is just text in the body of the email message. The zip, if present, is attached to the email.

The zip file is password protected. This provides two benefits:

1. it provides a small amount of security (zip file password protection is weak)
2. firewall protection lets encrypted zips go through

You will need to add the executable 7za.exe to your path or make sure it is within the same directory as jmailrpc.bat.

Extending jMailRPC

• find the %gCommandMap initialization sequence and add a reference to your new command:

      $gCommandMap{'abc'} = \&cmd_abc;
    

  where 'abc' is the command you put in the email request.
• create a new subroutine that will handle the incoming command, e.g. cmd_abc. Use cmd_get or cmd_dir as templates. The command handlers accept three parameters:
  • $replyaddr : the incoming email address (i.e. the email address you sent the request from)
  • $cmd : the first non-blank sequence of characters on the first line of the body of the email
  • $parms : all subsequent lines of the email, ending with the line with a '.' as the first character.

Security

Security and Extensions

If you decide to extend jMailRPC's command repetoire by adding the ability to type any command, you are wide open and on your own. Right now all of the commands are read-only. The commands in jMailRPC do not modify anything on your hard drive. Adding commands that have the ability to write to your hard drive should be done with extreme caution.

More Security

If someone finds out the email address you are using, you have no protection (except for the weak zip file encryption): they can send an email to the address and get files from your hard drive.

They can find out this email address in a couple of places:

• On your server (where you're running jMailRPC). The email addresses, passwords, accounts, etc. are right there on your hard drive ready for anyone to see.
• On your client (where you initiated the email request to jMailRPC). The email address of the server is in the reply email in the email headers. I added the $cfg{ReplyAddress} to help combat this, but your ip address and other information is still in the email headers.
• In the ethernet stream. Everything is currently sent back and forth in clear text (i.e. not encrypted). There are individuals who have the legitimate and illigitimate means of sniffing the ethernet packets and seeing exactly what is in your email requests and replies.

More Security : zip encryption

The zip file encryption is weak. Do a google "zip encryption" to see sites that have software that will crack the zip encryption (ostensibly to recover the zip contents in case you've forgotten the password).

Also, the zip encryption scheme encrypts at file level. This means you can open the zip and the file names are there for anyone to see. If the files are named "MyFinancialInfo.txt", that is an open invitation for someone to concentrate on cracking that zip file.

More Security : solution?

To make jMailRPC much more secure, the outgoing email (from client to server) should be encrypted and the reply email (from server to client) should be encrypted as well.