I'm a bit confused, Richard.
FWIW, my long-time use-case is an app that runs unattended on a regular
schedule on a faceless VM, doing a whole bunch of data processing and updating
databases, and sends alerts by email if something goes wrong. When the app is
installed, it has to be set up with server, account, credentials etc in order
to be able to send those emails; the details of the emails are configured by
scripts (not LiveCode scripts, XML configs) which are checksummed and won't be
run if modified. The tool I'm working on now will also be running unattended
on a schedule, but in this case the emails, rather than being confirmation
that it has done its work are the point of the work; it's going to generate
reports and distribute them to colleagues.
You seem to be making two points: that an app which can send emails without
human intervention will inevitably given enough time become a spambot; and
that users should be able to review an email in their mail client before it is
sent.
Obviously in the cases mentioned above the latter isn't an option.
In relation to the spambot concern, I don't understand how having a sendmail
script on a server adds security (it certainly adds another point of failure,
which is one reason I'd rather not do it). But as far as I can see it also
adds another vector for hijacking. I would think it's a great deal easier to
hack a script on a server on the internet, than it is an app running on a
local network. But if the app uses an external script, then the attacker can
get the same effect by hacking either, so they have the choice!
In relation to an email being sent without being reviewed by the user, is your
concern that the email will contain the user's private data? or that it will
be used to impersonate the user? To be honest I don't get it in either case.
An app exfiltrating data from the user's machine has many options, and can do
so at least as easily by posting to... err... a script on a server.
As for impersonating the user (of course setting the envelope sender can be
done anyhow anyway, so I assume this would be about more convincingly
impersonating the user by sending through their regular server): since sending
an email requires the cooperation of an SMTP server, of which I don't imagine
there are any open ones remaining, any such app will either require the
developer to bake in the details of an account they control, or to ask the
user to enter those details. Exactly the same applies to using a sendmail
script on a server. So either it's nothing to do with the user's email; or the
app has had to ask the user to enter their email account details, and they
presumably understand at that time why their doing it.
I can see why, as a user, you might be uncomfortable about giving your email
account details to an app so that it can send emails in your name, invisibly
and unreviewed by you. Quite right too! And if you're developing software for
consumers, you need to take that into account. But I don't understand why as a
developer who knows why you want the feature you'd be uncomfortable (except
from a marketing perspective, as per the start of this para).
Can you explain your concern further?
Ben
On 30/11/2016 17:49, Richard Gaskin wrote:
There are many. But hopefully they're an explicit decision by the user, and
require the user to supply their own SMTP credentials.
Bob Sneidar wrote:
I can provide you with scenarios where client side SMTP is a must.
On 30/11/2016 16:42, Richard Gaskin wrote:
Personally, I've never been comfortable relying on client-side SMTP. I figure
that any device configured to allow any app to send arbitrary emails without
explicit user intervention will eventually become a spambot, so my hope is
that it's only a matter of time before the OS provider puts an end to that.
For most systems I prefer to use the "mailto:"; protocol to open a message in
the user's own email client, so they can review it and decide whether they
actually want to send it.
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
