Evils of client-side SMTP (Re: Modern email library)

[Ben Rubinstein]

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.