eMail attachment: best practice?

[Richard Gaskin]

Matthias wrote:

> Am 27.06.2024 um 02:48 schrieb Richard Gaskin>:
>> I wouldn't make anyone fill out anything. I'd just present
>> a window for them to review, and POST it to my web site.
>> The receiving CGI can do whatever I need. 
> 
> I would say this always depends on the purpose the app is
> supposed to fulfill.

Every good app does. :)


> In my private projects I am using quite often Livecode Server
> as the backend for my LC apps, but I had some customer projects
> in the past where the customer wanted an app to send out e-mails
> with special  attachments, like logfiles or reports or whatever
> and it had to be without user interaction. 

I think we're on the same page. I tend to prefer open disclosure for users to review data before sending from their local machine to a server, but it's not functionally necessary.  Most apps don't bother, and of course a POST command can be sent without any user interaction.


> In the days before tsNET I either used Shao Sean's e-mail
> library, Chip Walter's altEmailHarness or I called command
> line tools using shell function to get this done. 

If the final reciever *needs* to be an email client, nearly any method will require a mime wrapper for the payload.

The nice thing about doing that for sendmail on the server, rather than for whatever the user uses for email on the client, is we don't know what the user is using.  Things can get tricky with all the possible options one might discover a need to support (native email apps, webmail like GMail or Nextcloud, gawdonlyknows what special handling may be needed for monsters like Office 365, etc.).  Sendmail gives us one one well-documented compatibility target to build for and test against. And it's already available; I don't need to set up half a dozen client email options just to get started.

But the other benefit with POSTing to the server is you can change your mind easily about how you want to handle it.

Maybe today the reciever is a support person's email In Box, but if so that's really an intermediary place, where the final destination will be some form of issue tracking DB.

So one can go ahead and use sendmail to get the info to support in email today, and later revise the CGI handler to post directly into the issue tracker DB API, saving the payroll cost and error rate that comes with rote human intermediation.


Another consideration is trust, esp. when the method used requires users to enter their server credentials.

With a simple POST, no interaction is needed, no information the app doesn't already have in the course of normal use is obtained.  The situation is trustless, in the sense of trust not being a requirement to proceed.

The moment any app asks me for any server credentiails, I need to stop and consider the implications.  If the app is my email client, of course I expect that, and I only use email clients I already trust.  With anything else I'm going to think it through carefully, and probably contact the vendor to seek a different method, if I bother continuing using the product at all.

Imagine if you went to a web site and the Contact form required your server creds.  Would you hand those over?

Do your users know you intimately enough to have complete confidence they can give you the keys to their kingdom in an app form?

I can imagine maybe some enterprise environments where that level of trust *might* be available.  But the same security awareness that makes the environment trustable probably wouldn't ask for server credentials.  Good IT staff regard all networks as hostile, even LAN.


In short:

- POST requires no more work for mime-wrapping the payload than client email;

- sendmail on the server is a simpler target than all possible email clints;

- can have a UI or not, as desired;

- leaves the door open for easy re-routing later on if needed;

- requires no trust from the user beyond what they might expect with any web form.


--
Richard Gaskin
FourthWorld.com