TheSwamp

Code Red => AutoLISP (Vanilla / Visual) => Topic started by: Marc'Antonio Alessi on November 20, 2019, 05:23:58 AM

Title: Send an email in background and then delete it
Post by: Marc'Antonio Alessi on November 20, 2019, 05:23:58 AM
With this function (for example) it is possible to send an email in the background:
Code: [Select]
; 2015
;; Outlook Message  -  ronjonp (modified slightly by Lee Mac :-) )
;; rcp - [str] Email address (separate multiple with semi-colon)
;; sub - [str] Subject
;; bdy - [str] Body of email
;; att - [lst] List of filenames to attach
;; snd - [bol] T=Send email; nil=Open email to edit
;
(defun rjp-outlookmessage ( rcp sub bdy att snd / atm msg out rtn )
    (if (setq out (vlax-get-or-create-object "outlook.application"))
        (progn
            (setq rtn
                (vl-catch-all-apply
                   '(lambda nil
                        (setq msg (vlax-invoke-method out 'createitem 0)
                              atm (vlax-get msg 'attachments)
                        )
                        (vlax-put msg 'to rcp)
                        (vlax-put msg 'subject sub)
                        (foreach fnm att
                            (if (setq fnm (findfile fnm))
                                (vlax-invoke atm 'add fnm)
                            )
                        )
                        (if snd
                            (vlax-invoke msg 'send)
                            (vlax-invoke msg 'display :vlax-true)
                        )
                        t
                    )
                )
            )
            (foreach obj (list atm msg out)
                (if (= 'vla-object (type obj))
                    (vlax-release-object obj)
                )
            )
            (if (vl-catch-all-error-p rtn)
                (prompt (vl-catch-all-error-message rtn))
                rtn
            )
        )
    )
)
Questions:
Is it possible to send an email in background and then delete it after send?
Is it possible to use any application available on the PC?

Title: Re: Send an email in background and then delete it
Post by: MP on November 20, 2019, 09:11:20 AM
Is it possible to send an email in background?

Yes (http://www.theswamp.org/index.php?topic=55486.msg596647#msg596647).

Is it possible to delete it after send?

Everything's possible but I believe trying to perform this task without direct access to the mail server would be challenging, acknowledging I'm no email expert. There may be a service that allows you to specify an email's deletion if not read within a specified time frame. That said, ummm why?
Title: Re: Send an email in background and then delete it
Post by: Marc'Antonio Alessi on November 20, 2019, 09:17:04 AM
... That said, ummm why?

Yes, I confess it's an unhealthy idea, I wanted to see which users use certain functions...
Title: Re: Send an email in background and then delete it
Post by: MP on November 20, 2019, 09:23:39 AM
You could gather, tally and send once a week. i.e. maybe selective (sending) frequency is the pragmatist’s solution.
Title: Re: Send an email in background and then delete it
Post by: Marc'Antonio Alessi on November 20, 2019, 09:27:37 AM
Yes, that's what I thought, but the user sees my mail in the sent mail basket… :knuppel2:
Title: Re: Send an email in background and then delete it
Post by: MP on November 20, 2019, 09:30:03 AM
Not if you use the function I specified (in my use).

You could also just write to a network resident file the users have access to but wouldn't necessarily think to view - or be able to view - work with your sys admin.
Title: Re: Send an email in background and then delete it
Post by: Marc'Antonio Alessi on November 20, 2019, 09:34:51 AM
can you be less mysterious? or it is a delicate matter (google transl.)…  :blink:
Title: Re: Send an email in background and then delete it
Post by: MP on November 20, 2019, 09:50:24 AM
wat
Title: Re: Send an email in background and then delete it
Post by: Marc'Antonio Alessi on November 20, 2019, 09:58:35 AM
WAT > What About Trash? 

if yes, you can take the risk, it's usually full of hundreds of emails and it's hard to see inside.
Title: Re: Send an email in background and then delete it
Post by: MP on November 20, 2019, 10:03:33 AM
Trashless in my experience. Did you try it or are you speculating?
Title: Re: Send an email in background and then delete it
Post by: Marc'Antonio Alessi on November 20, 2019, 10:14:38 AM
it's an idea that I had today (sorry but I'm not sure I understand correctly what you say about speculation and in general) :oops: :embarrassed2:
Title: Re: Send an email in background and then delete it
Post by: JohnK on November 20, 2019, 10:15:46 AM
MP, I don't believe post #5 was understood (-i.e. network file). And #8 was a guess/question as to what `WAT' means.

Marc'Antonio Alessi, If these people are on your network (or you have access to a server facing the internet) I would write to a network file instead of using email.
Title: Re: Send an email in background and then delete it
Post by: Marc'Antonio Alessi on November 20, 2019, 10:20:58 AM
MP, I don't believe post #5 was understood (-i.e. network file). And #8 was a guess/question as to what `WAT' means.

Marc'Antonio Alessi, If these people are on your network (or you have access to a server facing the internet) I would write to a network file instead of using email.
Thanks… sorry now I see post #5    <<  YES >>.    (old age makes bad jokes)  :tickedoff:
Thanks again.
Title: Re: Send an email in background and then delete it
Post by: MP on November 20, 2019, 10:33:00 AM
Thanks for babel-fishing John. re: “wat” it was the capping response in a legendary, infamous 4chan exchange. Disturbing, hilarious & NSFW.
Title: Re: Send an email in background and then delete it
Post by: Marc'Antonio Alessi on November 20, 2019, 10:39:59 AM
Trashless in my experience. Did you try it or are you speculating?
Apologizes for the misunderstanding.   :-)
Title: Re: Send an email in background and then delete it
Post by: MP on November 20, 2019, 10:49:20 AM
No worries my friend - I’m just a nerd trying to help. :uglystupid2:
Title: Re: Send an email in background and then delete it
Post by: snownut2 on November 21, 2019, 09:21:06 PM
Have you seen this....

------------------------------------------------------
|
|   Product   - SwithMail
|   Version   - 2.2.3.0
|   Author    - Tim Bare
|   Copyright - 2012-2018 - Tim Bare
|
|   Website   - https://www.tbare.com
|   Project   - https://swithmail.tbare.com
|
|   Description:
|      SwithMail is an application
|      that allows you to send SSL/TLS SMTP
|      email silently from command line (CLI),
|      or a batch file using Exchange, Gmail,
|      Hotmail, Yahoo! Plus, or Any custom server
|       - for FREE!
|
------------------------------------------------------

Usage:

SwithMail.exe [/s] [/to "..."] [/CC "..."] [/from "..."] [/name "..."] [/sub "..."] [/Body "..."] [/HTML] [/Attachment "C:\Path\To\File.txt"]
   [/Param1 "value"] [/enc "..."] [/rr] [/drnl] [/log "C:\Path\To\Log.txt"] [/priority "high"]


---------------------
Sample Usage:

SwithMail.exe /s /x "C:\path\to\settings.xml" /btxt "c:\path\to\bodyText.txt" /p1 "Mr. Smith" /enc "iso-8859-1"


---------------------
Error Codes:
When running silently from command line (or more specifically a batch file), Swithmail now supports error codes.
0 - No error - email delivered
1 - Error - something went wrong

Example usage in a .bat file:
@echo off
rem ...
set errorlevel=
C:\SwithMail\SwithMail.exe /s /x "SwithMailSettings.xml"
IF %errorlevel% ==0 GOTO SUCCESS
IF %errorlevel% ==1 GOTO ERROR

:SUCCESS
echo Success!
GOTO END

:ERROR
echo Error!
GOTO END

:END


---------------------
Parameters:

/Silent -- [also '/s' and '/q'] send an email without any prompt.
/XML -- [also '/x'] "C:\Path\To\Settings.xml"
/FromAddress -- [also '/from'] email address
/FromName -- [also '/name'] name displayed
/Server -- server address - no port specified
/Port -- [also '/p'] server port - needed if /Server is used
/Username -- [also '/u'] specified different username to use when logging in with SSL / TLS
/Password [also '/pass'] password - in plain text
/SSL -- [also '/TLS'] "true" or "false" depending on if SSL / TLS is enabled
/ToAddress -- [also '/to'] email address(es); multiple separated by ';' or ','
/CC -- email address(es); multiple separated by ';' or ','
/BCC -- email address(es); multiple separated by ';' or ','
/ReplyTo -- [also '/rt'] address to set as the "Reply To" address
/Subject -- [also '/sub'] subject "in quotes"
/Body -- [also '/b'] email body "in quotes" - html tags allowed when /HTML=true
/BodyTxt -- [also '/btxt'] full path of a text file to be used as the message body.
/HTML -- "true" or "false" depending on if HTML tags are allowed in the body
/Attachment -- [also '/a'] "C:\Path\To\File.txt|C:\PathTo\2.txt" - separate with pipe (|) symbol
/Param{1-9} -- [also '/p{1-9}'] use %Param1% in subject or body, && replace it with this value
/Test -- use when testing from CLI. Message will appear with errors or success
/Encoding -- [also '/enc'] Specify different charset to be used (UTF8 by default)
/ReadReceipt -- [also '/rr'] Request Read Receipt (where the client acknowledges and agrees)
/DontReplace -- [also '/drnl'] Don't replace New Line with '<br />' on HTML email
/Log -- [also '/l'] Path to Log file with success and failures. Logs Date, ToAddress, and Subject
   If no path is specified, the log file will be in the directory from where SwithMail is running.
/Priority -- "high" or "low" - flags message priority. Default is "normal" (no flag)
/MessageID -- [also '/mid'] Generate email header Message-ID
---------------------
Global variables (use in email subject & body):

%now% - displays current date & time
%computername% - displays computer name
%username% - displays username of account running SwithMail


---------------------
History:

Revision: v2.2.3.0
========================
-Bug Fix - Message Priority header fix -- added additional priority headers for different email account types
-Bug Fix - %ParamX% now replaced in Text File Body message when sending test email through GUI -- was working through CLI prior
-Minor Bug Fix - relabel "TSL" to "TLS" -- too many acronyms in my head. keeping "/tsl" argument for legacy support for people.
-Minor Tweak - rearrange main window in GUI to make slightly smaller.


Revision: v2.2.2.0
========================
-Bug Fix - "Reply-To" issue resolved.

Revision: v2.2.1.0
========================
-Enhancement - Increased number of Parameters that can be passed from 5 to 9
-Minor bug fixes

Revision: v2.2.0.0
========================
-Updated .NET Framework version to 4.6.2

Revision: v2.1.9.0
========================
-Enhancement - Added "Generate Message-Id" functionality
-Tweak - updated Donation link to "https://www.tbare.com/donate/prod=swithmail"

Revision: v2.1.8.0
========================
-Enhancement - Added CC, BCC, and Attachments to Logging file

Revision: v2.1.7.0
========================
-Enhancement - Added /Log and /Priority options

Revision: v2.1.6.0
========================
-Bug Fix - Resolve issue with Outlook replacing extension with ".dat"

Revision: v2.1.5.0
========================
-Enhancement / Bug Fix - Added fix for Wildcard attachments that doesn't ignore text before the asterisk.

Revision: v2.1.4.0
========================
-Enhancement - Added option to not auto replace new lines with '<br/>' for html email (fixes .html file body text files)
-Enhancement - Added alternate "plain text" view for HTML emails to help reduce SPAM score.


Revision: v2.1.3.0
========================
-Enhancement - Added Support for wildcards on attachments ("c:\path\to\files\*.csv" will attach all .csv files in the folder -- NOTE: You must specify the file extension -- *.* will not work).


Revision: v2.1.2.0
========================
-Enhancement - Added /ReadReceipt (or /rr) to request a read receipt (where the client acknowledges and agrees)


Revision: v2.1.1.1
========================
-Bug Fix - fixed encoding issues when using non-US characters in ANSI text file for /bodytxt


Revision: v2.1.1.0
========================
-Enhancement - Added /Encoding (or /enc) argument - Specify different charset to be used (UTF8 by default)
-Enhancement - Updated GUI to allow for /BodyTxt file selection and /Encoding field
-Enhancement - Updated XML to hold /BodyTxt and /Encoding arguments


Revision: v2.1.0.0
========================
-Enhancement - Added /BodyTxt (or /btxt) argument - specify a text file to be used as the message body. (%Param1% - %Param5% CAN be used in the text file and be replaced by arguments.


Revision: v2.0.9.0
========================
-Enhancement - Added Exit Codes ('0' for success, '1' for error) for batch file use


Revision: v2.0.8.0
========================
-Bug Fix- Fixed hang when running as scheduled task as different user


Revision: v2.0.7.0
========================
-Added "Username" field - now you can specify a different "Username" other than the send from email address


Revision: v2.0.6.0
========================
-Added "Reply To" field - now you can specify a different "Reply To" address


Revision: v2.0.5.0
========================
-Removed Colon (:) and Equal sign (=) separator for CLI arguments - was causing issue when those characters were in the strings behind them.


Revision: v2.0.4.0
========================
-Bug Fix - fixed /sub argument string changing to "true" when using the long CLI form.


Revision: v2.0.3.0
========================
-Added option to Obscure password in XML file from the GUI


Revision: v2.0.2.0
========================
-Added global variables %now%, %computername%, and %username%


Revision: v2.0.1.0
========================
-Fixed error where CLI string would clear from clipboard when program closed


Revision: v2.0 (Changes from v1.5)
========================
- Removed settings from saving "in-app" - now all settings are saved to an XML file, and the XML file is called from the command line
- Added support for multiple file attachments - up to 4 in-app, unlimited** in XML file and in command line
- Added support for generating CLI string for you, taking the guess work out of your arguments
- Changed Usage screen to be slightly easier to read
- Changed Settings screen to be tab-based, allowing for smaller screen, and more settings
- Several other minor tweaks and enhancements


** "Unlimited" means that SwithMail will try to deliver all attachments - email providers may have limits not enforced by SwithMail - If that limit is exceeded, emails may fail to send.


---------------------
Disclaimer:
Title: Re: Send an email in background and then delete it
Post by: Marc'Antonio Alessi on November 22, 2019, 02:13:08 AM
For Outlook (as someone privately suggested) also exists:
Code: [Select]
MailItem.DeleteAfterSubmit property (Outlook)
Returns or sets a Boolean value that is True if a copy of the mail message is not saved upon being sent, and False if a copy is saved in Sent Items folder. Read/write.

Syntax
expression. DeleteAfterSubmit

expression A variable that represents a MailItem object.
does not work with Gmail and similar.
Title: Re: Send an email in background and then delete it
Post by: jtoverka on November 22, 2019, 10:35:27 AM
This code is really old and I don't use it anymore, however, I used to record metrics on my program usage. It creates a file exportable to excel to review metrics. It is completely inconspicuous and designed to not throw errors. The files were generated on the network.

Code: [Select]
(defun JO:metricStart (path / fnam1 file1)
 (vl-load-com)
 (if (and (= 'STR (type path))(vl-file-directory-p path))
  (progn
(setq fnam1 (strcat (getvar "tempprefix") "metricTemp1.log"))
(if (setq file1 (open fnam1 "w"))
(write-line (strcat (menucmd "M=$(edtime,$(getvar,date),M/D/YYYY)") "\t" (menucmd "M=$(edtime,$(getvar,date),HH:MM:SS )")) file1)
)
(if file1 (close file1))
  )
 )
(princ)
)
(defun JO:metricEnd (strCommand path / fnam1 fnam2 fnam3 fnam4 file1 file2 file3 file4 line1)
 (vl-load-com)
 (if (and (= 'STR (type path))(vl-file-directory-p path))
  (progn
(setq fnam1 (strcat path (getvar "loginname") ".log"))
(setq fnam2 (strcat path strCommand ".log"))
(setq fnam3 (strcat path "CAD" ".log"))
(setq fnam4 (strcat (getvar "tempprefix") "metricTemp1.log"))

(if (findfile fnam1)
(progn
(setq file1 (open fnam1 "a"))
)
(progn
(if (setq file1 (open fnam1 "w"))
(write-line "Command\tDate\tTime Start\tTime End" file1)
)
)
)
(if (findfile fnam2)
(progn
(setq file2 (open fnam2 "a"))
)
(progn
(if (setq file2 (open fnam2 "w"))
(write-line "Date\tTime Start\tTime End" file2)
)
)
)
(if (findfile fnam3)
(progn
(setq file3 (open fnam3 "a"))
)
(progn
(if (setq file3 (open fnam3 "w"))
(write-line "User\tCommand\tDate\tTime Start\tTime End" file3)
)
)
)

(if (findfile fnam4)
  (progn
(if (setq file4 (open fnam4 "r"))
(setq line1 (read-line file4))
)

(if file1 (write-line (strcat strCommand "\t" line1 "\t" (menucmd "M=$(edtime,$(getvar,date),HH:MM:SS)")) file1))
(if file2 (write-line (strcat line1 "\t" (menucmd "M=$(edtime,$(getvar,date),HH:MM:SS)")) file2))
(if file3 (write-line (strcat (getvar "loginname") "\t" strCommand "\t" line1 "\t" (menucmd "M=$(edtime,$(getvar,date),HH:MM:SS)")) file3))

(vl-file-delete fnam4)
  )
)

(if file1 (close file1))
(if file2 (close file2))
(if file3 (close file3))
(if file4 (close file4))
  )
 )
(princ)
)
(princ)
Title: Re: Send an email in background and then delete it
Post by: VovKa on November 22, 2019, 02:53:53 PM
i'd rather send some data directly to the server than mess with an email client
it is faster and does not require any extra software
Title: Re: Send an email in background and then delete it
Post by: Marc'Antonio Alessi on November 22, 2019, 05:09:17 PM
Sometimes I don't know the name of the server, the port, etc...
Title: Re: Send an email in background and then delete it
Post by: VovKa on November 22, 2019, 05:37:06 PM
Sometimes I don't know the name of the server, the port, etc...
how can you not know your own server address?
Title: Re: Send an email in background and then delete it
Post by: snownut2 on November 22, 2019, 06:32:34 PM
I don't think this is for his server, it seems like he wants to have a program that someone is using, no matter where they are surreptitiously send him an email with some data in it about what they are doing.  That's why  the deletion aspect is required, to cover his tracks, not sure this is such a good idea.  Maybe he's spying on his wife, but I doubt it.  That's why Trump has red listed Huewai ......
Title: Re: Send an email in background and then delete it
Post by: VovKa on November 22, 2019, 07:00:55 PM
I don't think this is for his server, it seems like he wants to have a program that someone is using, no matter where they are surreptitiously send him an email with some data in it about what they are doing.
yeah i got that
what i'm telling is that it is not necessarily has to be an email
it is easier to use http to send some data to a server which could be a private one running 24/7 at Marco's home or a cloud based one
or even smth as simple as forms.office.com (i once tried)

Maybe he's spying on his wife, but I doubt it.  That's why Trump has red listed Huewai ......
Huewai... hmm... strange name for a wife :)

ps spying's no good
Title: Re: Send an email in background and then delete it
Post by: huiz on November 23, 2019, 07:06:13 AM
A simple call to a webpage with Google Analytics is very effective.


If I would notice an app that sends a mail and deletes it afterwards, I'll see that as spyware. Maybe it is even illegal to use a customer's mail software in the background without asking for permit.
Title: Re: Send an email in background and then delete it
Post by: snownut2 on November 23, 2019, 07:43:53 AM
A simple call to a webpage with Google Analytics is very effective.

I was on the same line of thinking, have a Google Sheet that keeps getting appended to, for example.  (ZOHO forms does this) And I have a function that allows users to access their data from the sheet.  One could even have a sheet for each user of required.....
Title: Re: Send an email in background and then delete it
Post by: JohnK on November 23, 2019, 12:40:09 PM
This thread is treading on ethics-thin-ice. Why would an autolisp developer care how often a user uses his/her application? I have a far better idea; instead of focusing on creative spying techniques, focus on making a better application or methods. Rinse and repeat for the next "great idea".

First of all: email servers don't work that way. Just because you delete from the client side doesn't mean it is deleted on the exchange side.

Second: Client-side communications--within more complicated/robust setups--which frequent dead-end sites/higher then "normal" bandwidth/etc. can get flagged/throttled. ...Have you ever heard of SNORT, for example?

Third: Stop making security holes in peoples networks/setups/etc..

Focus your time on better programming not spying methods.
Title: Re: Send an email in background and then delete it
Post by: MP on November 23, 2019, 01:57:01 PM
This thread is treading on ethics-thin-ice.

I agree, tho the issue is not exclusive, nor is it indicative, of code driven email transmittal.

We use auto email transmittal to inform engineers a group of drawings has been plotted to pdf and ready for digital authentication. I also selectively code driven email when beta testing software with my beta group testers to give me instant stats on program performance etc. so I can more quickly review, revise candidate solutions. I have no reservations about leveraging email for these activities, noting all of them are internal.

For external use going the email route is ill advised for most uses. It's an abuse of access IMO. Alternatively, should a program(mer) have access to data / stats relevant to program execution, say to a web server yada? Depends. It's a non trivial discussion that spans the universe from solo dev trying to make a program more efficient to large corp licensing and big brother surveillance.

Long story short: I'd err on the side of honouring user rights rather than "programmer" rights.

Finally, assume the best of Marc'Antonio Alessi. In decades of participation on various discussion forums I have never ever observed anything to suggest he has anything but the most honourable of intentions. In the end I would bet money every time for him to do "the right thing".
Title: Re: Send an email in background and then delete it
Post by: JohnK on November 23, 2019, 02:32:24 PM
Not, necessarily, questioning anyone’s specific ethics; I’m concerned about a thread/method laying out the specific methods for a person(s) that may not have as strong a moral compass.

Title: Re: Send an email in background and then delete it
Post by: MP on November 23, 2019, 03:04:01 PM
The number of solutions hosted by the swamp that could be used for nefarious purposes dwarfing email abuse is too high to tally. And forget swamp membership exclusivity, the swamp is bot scraped so many times daily it’s disturbing.
Title: Re: Send an email in background and then delete it
Post by: Marc'Antonio Alessi on November 25, 2019, 08:48:46 AM
First of all, I apologize for the delay and I thank Michael for what he wrote about me (actually I've been attending for more
than twenty years Autolisp and surroundings), I apologize also for my poor English (Google translator) who sometimes
creates misunderstandings.

I confirm what I wrote in my post #2 "Yes, I confess it's an unhealthy idea, I wanted to see which users use certain functions ..."
since I care a lot about my reputation I wanted to be more detailed in my idea.


My intent is NOT fraudulent but simply this (example):

Alfa, Beta and Gamma are three of my clients and have been using some of my programs for many years.
I state that I am not a real programmer but I have created a standard for for the design of stainless
steel catering in cruise ships environments (kitchens, bars, refrigerator rooms, etc.) with special functions
which force users to draw according to pre-established rules (Layers, styles, dimstyles, etc.).

Every user of Alfa, Beta and Gamma can use my programs by authorizing them through a special command
which creates an email in which there is the name of the user, hard disk serial number, CAD serial, etc.
I reply to this email by sending a custom activation file.

All this sometimes makes me lose a lot of time because if a user changes the PC, the PC changes user or for some reason
the authorization doesn't work I have to answer in a short time to make sure that the operator can use my functions
without the interruptions that are foreseen when using the program in a free way.

Lately for the Gamma customer, for not having multiple activation requests,
I created a command that allows the authorization an autonomous and unlimited way without asking anything
but that should only be used in the Gamma company.

It has been a while since the UserX of Gamma client goes to work to the Alfa client (for example) and theoretically could
copy my programs to activate them at that client or at any other.

My simple need was to check who was using my programs and with which client.

However, I believe I will abandon the way to delete the generated message so that it remains a trace
to those who sent it so as not to generate doubts also about my activity with the customer.

I hope I have translated it correctly so as not to generate incorrect interpretations.

Thank you all.

Marco
Title: Re: Send an email in background and then delete it
Post by: VovKa on November 25, 2019, 07:37:13 PM
All this sometimes makes me lose a lot of time because if a user changes the PC, the PC changes user or for some reason
the authorization doesn't work I have to answer in a short time to make sure that the operator can use my functions
without the interruptions that are foreseen when using the program in a free way.
why bother with all the emails?
create a simple site with a script that will check/generate activation data and send it back to the user automatically
i've just tried
it took me only an hour and half to find a free hosting, create an account, register a domain, read some general info on how php scripts work, create a simple script that reads parameters from the url and generates a reply


the only thing you need to do is to write your own secure reply generation function

if you need a step by step guide just ask
Title: Re: Send an email in background and then delete it
Post by: Marc'Antonio Alessi on November 26, 2019, 02:53:32 AM
All this sometimes makes me lose a lot of time because if a user changes the PC, the PC changes user or for some reason
the authorization doesn't work I have to answer in a short time to make sure that the operator can use my functions
without the interruptions that are foreseen when using the program in a free way.
why bother with all the emails?
create a simple site with a script that will check/generate activation data and send it back to the user automatically
i've just tried
it took me only an hour and half to find a free hosting, create an account, register a domain, read some general info on how php scripts work, create a simple script that reads parameters from the url and generates a reply
http://vlisp.epizy.com/register.php?name=test&hd=123&mac=456

the only thing you need to do is to write your own secure reply generation function
Thanks!  :-)   ..."I state that I am not a real programmer..."
Quote
if you need a step by step guide just ask
I will surely appreciate it and I will try to use your advice.
Grazie.

P.S.: the link http://vlisp.epizy.com/register.php?name=test&hd=123&mac=456  get only:  "e23f73f986bcfcfb04ee97f0ad4801e6"
Title: Re: Send an email in background and then delete it
Post by: VovKa on November 26, 2019, 04:05:42 AM
P.S.: the link http://vlisp.epizy.com/register.php?name=test&hd=123&mac=456  get only:  "e23f73f986bcfcfb04ee97f0ad4801e6"
heh
now it returns nothing :)
probably i've chosen not the best hosting server

i've got the message "Your account was taken down because you have exceeded the usage limits for free hosting or because of abuse."

i know nothing about web hosting may be i've done smth wrong
but this is not a problem there are lots of others
http://vlisp.eu5.org/register.php?name=test1&hd=123&mac=4513
Title: Re: Send an email in background and then delete it
Post by: VovKa on November 26, 2019, 04:44:09 AM
I will surely appreciate it and I will try to use your advice.
ok here's the deal
1. find a hosting server. let's try https://www.freewebhostingarea.com/
2. in 'Free SubDomain Hosting' enter the desired subdomain name
3. register the account
4. you will be provided with a page with usernames and passwords for your ftp and control panel, save it
5. go to your site's 'Control panel' and enable php
6. go to your site's 'File manage' (it is an ftp server) and upload the attached file
that's all
Title: Re: Send an email in background and then delete it
Post by: Marc'Antonio Alessi on November 26, 2019, 07:33:11 AM
I will surely appreciate it and I will try to use your advice.
ok here's the deal
1. find a hosting server. let's try https://www.freewebhostingarea.com/
2. in 'Free SubDomain Hosting' enter the desired subdomain name
3. register the account
4. you will be provided with a page with usernames and passwords for your ftp and control panel, save it
5. go to your site's 'Control panel' and enable php
6. go to your site's 'File manage' (it is an ftp server) and upload the attached file
that's all
Grazie mille. If I have any problems I'll come back here, have a nice day.  :-)
Title: Re: Send an email in background and then delete it
Post by: JohnK on November 26, 2019, 05:10:56 PM
I'm very happy you got a good solution for your problem! :)

Also, thinking along the great idea Vovka provided, if you wanted to add in some "per customer" type of automation, you can use that "LiFP" tool I created; you could build in some ID generation--or something along those lines--into each users program version and have a `per customer/user' solution. You can use LiFP to generate any text based file so you can build a simple webpage, lisp(s), php script, etc. with a customer/user ID with a simple BATCH script.

https://www.theswamp.org/index.php?topic=37700.0
Title: Re: Send an email in background and then delete it
Post by: Marc'Antonio Alessi on November 27, 2019, 04:22:29 AM
I'm very happy you got a good solution for your problem! :)

Also, thinking along the great idea Vovka provided, if you wanted to add in some "per customer" type of automation, you can use that "LiFP" tool I created; you could build in some ID generation--or something along those lines--into each users program version and have a `per customer/user' solution. You can use LiFP to generate any text based file so you can build a simple webpage, lisp(s), php script, etc. with a customer/user ID with a simple BATCH script.

https://www.theswamp.org/index.php?topic=37700.0
Grazie ancora. I had read something about "LiFP" but I thought it was out of my reach, now there's another reason to run my old brain  :gum:  to see if I can get something.
Have a nice day.  :-)
Marco
Title: Re: Send an email in background and then delete it
Post by: jtoverka on November 27, 2019, 12:17:36 PM
This thread is treading on ethics-thin-ice. Why would an autolisp developer care how often a user uses his/her application? I have a far better idea; instead of focusing on creative spying techniques, focus on making a better application or methods. Rinse and repeat for the next "great idea".

It's not just autolisp developers, but developers in general.

Personally, this is on the bottom of my priority list, however, it is still on my list. The code I posted creates data that is mostly useless. I have since removed this from my applications. I would rather see if there are errors thrown and what kind of errors. Most users don't report this, if it doesn't work, they just don't use it. This data is very important on making a better application. Especially when a user will use the application in ways not intended by the developer.
Title: Re: Send an email in background and then delete it
Post by: JohnK on November 27, 2019, 02:36:10 PM
But I specifically asked about AutoLisp -i.e. an interpreted language, vs a compiled one. AutoLisp is a very small market and therefore I was questioning the amount of money to be made from such a small niche market--and the need to actually care as much about this aspect of development. In other words, what is the return on investment--time and effort for the payoff--and is/would it be better to just accept a loss factor for the sake of time and effort. Obviously, there are plenty of solutions to the problem--as anyone can read from the thread--but the question is still valid as far as I'm concerned (interpreted language in a niche market). If you put in the time and effort into a program, and make a few dollars on it, great! However, at the end of the day you have to remind yourself that your time and effort are far more valuable then a concern about someone "stealing your code, etc.".

If a person can parse error/crash reports and improve the program and still make money, then that's great! I assume updates to the program would be paid for then?

This thread is treading on ethics-thin-ice. Why would an autolisp developer care how often a user uses his/her application? I have a far better idea; instead of focusing on creative spying techniques, focus on making a better application or methods. Rinse and repeat for the next "great idea".

It's not just autolisp developers, but developers in general.

Personally, this is on the bottom of my priority list, however, it is still on my list. The code I posted creates data that is mostly useless. I have since removed this from my applications. I would rather see if there are errors thrown and what kind of errors. Most users don't report this, if it doesn't work, they just don't use it. This data is very important on making a better application. Especially when a user will use the application in ways not intended by the developer.