Apologies in advance, as i will most likely be trolling this quiet side of the bbs as i work through some of the pros/cons of different approaches.

For today's topic: maintaining smtp password in raw file.

I am using save.type=3 to erase the pdf when complete. I was thinking to save the raw text file on the server for future history and processing but w/o the password. Since it changes ever 60 days anyway, it would be better to not keep it hanging around anyways...

I can use encrypted option, but why? If i don't store in the raw file?

Also, although it might look odd, is it possible to place the password at the very end of the raw file? Would the parser care? My thoughts are a week later the user determines the email wasn't delivered, and wants to click "re-send". I could just append the password to the end of the file and send to the pdf driver.

Better ideas?

Thanks.

I think main reason for the encrypted password was so that you could store it in a text file without worrying too much about it getting compromised. (The type 3 encryption is pretty good, and would be useful outside of A-Shell/PDFX, so it wouldn't be of much use to someone else.)

Note however that even if you aren't "storing" the source file, it's going to exist on disk for a short time between creating it and submitting it to "print", and may also travel across your LAN, so you should use the encrypted password in any case.

But if the password is going to expire anyway, there wouldn't be much point in archiving it with the source file.

And yes, you can append the //PDFX,Email.SMTP.Password statement to very end of the file, so you plan to tack the current password on to the end of the archived file for re-sending purposes seems good to me.

Thanks for the reply.

Not trying to be obtuse here but I am trying to walk through the methodology...

Do i write a program locally to encrypt the password, then port that over to the user server to be picked up and added to the source file?

OR do i have a routine running on the user server that encrypts the PW before adding to the source file? In this case, doesn't the un-encrypted PW have to reside somewhere on the same server in a txt file or other file? Stored as a string? If so it can just be dumped and read...

OR do i have to write a routine that allows the user to enter it on the screen then encrypts and saves it to a text file and said raw PW never exists anywhere in a data file?

PS: I am thinking since if using mode=3 we need to seed the routine with the username, it can't be really and end user process unless the program prompts for the seed as well...

Ideally, at least in terms of best practices, I would opt for the latter. Store it encrypted on the server, and append it to the email source text file as the last step in sending it from the server to the PC client which generates the PDF and emails it.

Ok thanks.. i guess the best thing do is write something that prompts for the seed and password and creates a string output to a file that can be used to add to the outgoing pdf.

Note that for PDFX, the seed is the SMTP username.

PDFX - SMTP Authentication

Followup:

Nice to know when something works right?

I wrote a quick program to create the tokenized password from the actual pw and username seed to a data file. I plugged this into the smtp.password command and it worked like a charm.

Thanks for all the assistance.

Uhh, what's the catch? :rolleyes:

Dunno - is it rare that

a) things work as advertised? or

b) Someone lets you know?

:rolleyes:

PS: Unrelated side note, i was happy to see that the following is legal:

//PDFX,Email.LogFile,%atecache%\receipt.log

Decided to archive the log with the email file on the local server, and this helps the logs to not grow too large on the PC side and cleans them up after exit from ATE.

Both in your case, Frank :rolleyes:

Ouch!

Only joking, Frank. I didn’t have my tapioca and have been in a bad mood