Is there a location where one can get the latest version of XCALL EMAILX, and the corresponding documentation?

I know this is only available to those who've purchased the license, so perhaps sharing via OneDrive, DropBox, Google Drive could make it easier to supply these updates?

Good point. I'm going to pass this to Ty to set up one of those directories and send the links to the people with licenses. Hopefully that will happen today sometime. If you need it faster, I can email it to you.

The version we have is 5.1(122). If there's a newer one; please go ahead and email it.

Does this version of EMAILX support MX_PWCRYPT mode=3?

You need version 5.1(128) or higher for that. I've just emailed it to you while Ty and I figure out a place to post it.

Thank you Jack

Sorry if I'm missing something obvious.

I'm writing a utility to Encrypt/Decrypt the password with MX_PWCRYPT mode=3. The only way I can get the decryption to work is by specifying my own non-null Seed and Key; otherwise, I get back from MX_PWCRYPT.

How does one use MX_PWCRYPT mode=3 in emailx.cfg.

I tested by encrypting my password with MX_PWCRYPT a null seed/key, and Gmail SMTP errors with bad password. It works with an unencrypted password.

Is there a way to specify the seed/key in the .CFG file.

* Ping *

Sorry, somehow missed this one.

I guess I need to add that feature to EMAILX. As it stands, it uses an internal seed/key, the same one that is used for other passwords (like the ATE login). Obviously I can't very well publish it.

Either we can add on option to the CFG, as you suggest. Or we could add an SBX hook to the EMAILX decrypt routine allowing you to supply your own logic.

I'm on the road thru Wed and am unsure whether I'll have time to do this before then, but if you let me know your preference perhaps I can squeeze it in. Otherwise it would be Thursday or Friday.

At the moment I just need to get this working, and using your seed/key is fine. Mode 3 encryption is drastically better stored in the .CFG file than plaintext, even without control of the seed/key.

I just can't seem to create an encrypted password string with my utility that will work with EMAILX. i.e. (not setting a seed/key).

Do you have a utility for creating these password strings, or any tips on creating one.

Thanks, and have a safe trip.

I remember documenting that somewhere, but must admit that it's not very clear in the AshRef. Maybe it was the 6.2.1385 Release Notes Entry

In any case, in theory, it should be a standard MX_PWCRYPT call for a mode 3 encryption, with the one trick being that the seed should be set to the SMTP user name, and the key not specified.

Unfortunately there is no way to test the decryption independently (for the reason previously mentioned), so you can only do it by trying to use it with an email.

The other trick to watch out for is that the encrypted string starts with a chr(3), which needs to be there. VUE can deal with it, but it's easy to see it getting lost or corrupted in some kind of text editing operation if not careful.

That should work. Thanks

I was able to get a MX_PWCRYPT mode=3 password working by using the SMTP username for the seed. Thanks for that.

Also, I was able to get mode=3 to decrypt a password with null seed & key. This requires not actually passing the key variable to the XCALL when not using a key. The seed can be passed regardless of whether or not it's null.

Ty/Jack: Jack gave me an updated EMAILX.SBX the other day. I installed on my clients but now the SIGNATURE is no longer working. I am assuming the MAP has changed. Can I get the location of where to pick up the latest updates for EMAILX, please?

Here's a zip containing the latest EMAILX.DEF (symbol definitions) and a couple of sample programs... emailx133.zip

But I have my doubts about the problem being related to a MAP change. The signature is specified as a discrete string parameter (or via the CFG file), so it shouldn't be affected by any changes in the other parameters, MAPs, etc.

If it doesn't clear up on a second look, let me know what you have for a signature and perhaps I can investigate it here.

Using EMAILX.SBX 5.1(133) the EM'SIGNATURE variable I use is getting clobbered and always ending up as blank with no signature applied to the email. I load it with a file name (SIGNTR.TXT) and by the time it gets to the XCALL EMAILX it is blank. And it is not my program doing it.

So, I went back to EMAILX.SBX 5.1(124) and ran the same program untouched and my signature is now in my log file and on the email.

Additional info for you regarding Signature issues between 5.1(124) and 5.1(133):

A-Shell/32/Windows Ver. 6.4.1547.0
Release Date: 17-Mar-2017
Licensed to: Jack Rupert
Serial # 5698

EMAILX SBX 24 365-474-211-730 5.1(124) DSK0:[7,6]
EMAILX_NEW SBX 27 440-355-336-244 5.1(133)

MAP1 EMAIL'VARS
MAP2 EM'OPFLAGS,F,6,0
MAP2 EM'CFGFILE,S,64,"GMSSYS:EMAILX.CFG"
MAP2 EM'SERVER,S,64,""
MAP2 EM'HOST,S,64,""
MAP2 EM'FROM,S,64,""
MAP2 EM'TO,S,512
MAP2 EM'ENTRY,S,80,""
MAP2 EM'HEADER,S,512
MAP2 EM'BODY,S,1024
MAP2 EM'SIGNATURE,S,64,""
MAP2 EM'ERRMSG,S,256,""
MAP2 EM'STATUS,F
MAP2 EM'SOCKET,F
MAP2 EM'SNDMSG,S,80,""
MAP2 EM'USERNAME,S,50,"" ! [103]
MAP2 EM'PASSWORD,S,50,"" ! [103]
!
MAP1 EM'ATTACHMENTS
MAP2 ATT'COUNT,B,2,0
MAP2 ATTX(10)
MAP3 ATT'FILE,S,128
MAP3 ATT'CONTENT'TYPE,S,127
MAP3 ATT'ENCODING,B,1


XCALL EMAILX,EM'OPFLAGS,EM'CFGFILE,EM'TO,EM'HEADER,EM'BODY,EM'STATUS, &
EM'FROM,EM'ATTACHMENTS,EM'SIGNATURE,EM'ERRMSG,EM'SOCKET, &
EM'SERVER,EM'HOST,EM'USERNAME,EM'PASSWORD

JRR-OWNER) type emlcfg.grp
;EMAILX.SBX configuration file
WAIT = 10
;SERVER = mail.rupertimage.com
SERVER = smtpout.secureserver.net:3535
HOST = rupertimage.com
DOMAIN = rupertimage.com
AUTH = LOGIN
USERNAME = jackr@rupertimage.com
PASSWORD = jrrpersonal
;RTNADDR = return@microsabio.com ; return
;REPLYTO = replyto@microsabio.com ; default
SIGNATURE = GMSEML:SIGNTR.TXT
LOGFILE = GMSEML:EMAILX.GRP
LOGLVL = 2
JRR-OWNER) log
Current login is DSK1:[74,20]
Ersatz name is GMSEML:

You're right - there's definitely something messed up with the signature. Am investigating...

Ok, found the problem. Looks like in edit 129 while doing a little modernization I accidentally deleted a critical line of code, and then failed to take note of it either in testing or in revision control. Bad bad bad on my part. Sorry for wasting your time!

The fix is in 5.1(134) ... emailx134.zip

Glad you found it so quickly. Thank you. I shall pick this up and move forward.

I'm having another issue with a MODE 3 password. Are there any traces I can enable to see what decrypted password is being used in the authentication process?

The .CFG file already contains LOGLVL = 5

I figured out the bad decryption, but I'm going to reply further in an encrypt email.

I'm not sure if you figured it out or inadvertently worked around another problem, but I just discovered that the 135 update does have systematic problem with the encrypted SMTP authentication. I believe it's fixed in version 6.4.136...

emailx136.zip

Authentication is working fine for me now that I remembered the seed has to be trimmed when creating the encrypted password for EMAILX. This version; however, does not fix the duplicate body issue I emailed about yesterday after we talked.

As an aside, here's a link to the .LIT utility I created for creating encrypted password for .CFG files. PWCRYPT.LIT (102) if anyone wants to use it.

pwcrypt/? should help you figure out how to encrypt the password (and conversely decrypt to verify)., and you can copy it from the trace.print in the debug window.

Ok, I see the problem now. It doesn't occur when the body param is passed as a file, but does when it is passed as a string. Will be fixed momentarily...

Ok, let's try again...

emailx137.zip

It looks like this resolves the issue.

Thanks