Re: Modern email library

[William Prothero]

Folks,
In case anybody wants to look at my version of email with attachments, sent 
using a remote email server, you can download a sample stack at:
http://es.earthlearningsolutions.org/SoftwareForEducation 

It uses php on the server side.
Bill


> On Nov 30, 2016, at 12:24 PM, Ben Rubinstein  wrote:
> 
> On 30/11/2016 17:07, Matthias Rebbe wrote:
>> have a look at the sample stack Charles Warwick provided
>> https://downloads.techstrategies.com.au/tsnet/LCMail.livecode
>> 
>> It contains functions to create  smtp header and body (including 
>> attachments).
> 
> Thanks Matthias, I've grabbed that and will take a look.
> 
> Is there some more documentation somewhere about tsNet (beyond the dictionary 
> entries), or pointers to sample stacks (I can't list the directory this 
> sample comes from) - did I miss an posting about this during the great 
> use-list bounce wars?
> 
> thank you,
> 
> Ben
> 
> ___
> 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

___
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

Re: Modern email library

[Ben Rubinstein]

On 30/11/2016 17:07, Matthias Rebbe wrote:

have a look at the sample stack Charles Warwick provided
https://downloads.techstrategies.com.au/tsnet/LCMail.livecode

It contains functions to create  smtp header and body (including attachments).


Thanks Matthias, I've grabbed that and will take a look.

Is there some more documentation somewhere about tsNet (beyond the dictionary 
entries), or pointers to sample stacks (I can't list the directory this sample 
comes from) - did I miss an posting about this during the great use-list 
bounce wars?


thank you,

Ben

___
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

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

[Richard Gaskin]

Ben Rubinstein wrote:

> 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.

Sounds like we're on the same page.


> 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?

I think you covered it well above.

Many of these sorts of discussion in our community relate to use in 
consumer apps, often on the desktop and sometimes even on a phone.  And 
for the reasons you outlined so well above, such use cases are highly 
undesirable.


Beyond that, what an experienced developer wants to do on the machines 
they admin is of course entirely up to them.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

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.


___
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

Re: Modern email library

[Richard Gaskin]

Bob Sneidar wrote:

> I can provide you with scenarios where client side SMTP is a must.

There are many.  But hopefully they're an explicit decision by the user, 
and require the user to supply their own SMTP credentials.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

Re: Modern email library

[Matthias Rebbe]

It always depends on how you use such libraries or externals.

The new tsNET external allows us for example to send notification emails from 
our scheduled unattended maintenance tools using our own in-house mailserver. 
Our mailserver requests authentication from our apps  before sending out to 
external addresses. 
This works really smooth. What other possibilities would we have? We could 
create a web service to which we would post the notifications and then let the 
web service send out the emails for us using the web servers smtp. We did so in 
the past.
But tsNet is much better.

Matthias


> Am 30.11.2016 um 17:42 schrieb Richard Gaskin :d
> 
> 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.
> 
> I do have some monitoring systems that provide notification, but I don't 
> usually install email on a server designed for any other purpose.
> 
> So instead I maintain one server on one of my shared hosting accounts as a 
> notification center (it's not used often enough to warrant a VPS, but if you 
> expect heavy load VPSes are cheap these days).  It runs an LC CGI that 
> accepts a compressed encoded array containing the email elements (to, from, 
> subject, body, etc.), and it formats it for use by sendmail, which it then 
> calls from the command line.
> 
> The advantages with using an external server to do the actual sending are:
> 
> - I'm not dependent on a local SMTP client implementation, which I
>  hope for security's sake won't always be available.
> 
> - It uses a simple one-line call to a server, so it's easy to
>  add email support in any client app wherever I need it.
> 
> - The CGI is relatively simple to set up (Lesson examples available
>  for using sendmail with LC CGI).
> 
> - The server is reasonably protected (nothing is *absolutely*
>  protectable) by virtue of only accepting the LC-specific LSON
>  (encoded array) format, which is also encrypted before sending,
>  and transmitted over HTTPS.
> 
> By no means perfect (nothing is a magic pony), but easy to set up, convenient 
> to use, and at least as secure as most alternatives.
> 
> I don't currently send attachments, but the MIME format is well documented 
> and LC provides the raw materials needed (good text handling and base64 
> encoding), so even if a current library isn't readily available it shouldn't 
> take long to package up an attachment with the body.


___
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

Re: Modern email library

[Matthias Rebbe]

Ben,

have a look at the sample stack Charles Warwick provided
https://downloads.techstrategies.com.au/tsnet/LCMail.livecode 


It contains functions to create  smtp header and body (including attachments).

Matthias


> Am 30.11.2016 um 14:16 schrieb Ben Rubinstein :
> 
> I've one app that's been in existence for over a decade, which uses Shao 
> Sean's libSmtp. It works fine.
> 
> Now I find myself wanting to send email from a new stack I'm working on. I 
> could just drag that library out again, but I suspect that a more modern way 
> is to use tsNet.
> 
> AFAICT tsNet handles the protocol of communicating with the server to 
> transmit a message (i.e. the SMTP part), but doesn't offer any assistance 
> with putting the message together (formatting with attachments etc).
> 
> What do modern people use for this? Obviously I could rip the relevant parts 
> out of libSMTP; or I recall that Sarah Reichelt had a library; is there a 
> default answer among those who've sent email in the last ten years?
> 
> TIA,
> 
> Ben
> 
> ___
> 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

___
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

Re: Modern email library

[Bob Sneidar]

I can provide you with scenarios where client side SMTP is a must. Embedded 
systems which send alerts, such as managed switches, routers, UPS systems, etc. 
REQUIRE client side SMTP to work. Further, software systems like a managed AV 
system or a centralized backup system which sends reports to the IT manager 
cannot wait to have someone come and "approve" each email it wants to send. 
Even further, busimess management systems like the one we use can often use a 
client side SMTP or a Mailto: method, but we use the workstations mail client 
and when working with Outlook, it becomes a bit cumbersome.

SMTP Clients are not the issue, unauthenticated/unencrypted SMTP SERVERS are.

Bob S


On Nov 30, 2016, at 08:42 , Richard Gaskin 
mailto:ambassa...@fourthworld.com>> 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.

___
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

Re: Modern email library

[Bob Sneidar]

Hmmm... I am logged in but I cannot seem to find any files to DL here. I may 
misunderstand.

Bob S


On Nov 30, 2016, at 05:44 , Peter TB Brett 
mailto:peter.br...@livecode.com>> wrote:

As part of the LiveCode for FM project, Monte has been developing a MIME 
library for constructing e-mail bodies.  We plan to include it in LiveCode 9.  
But you can grab it ahead of time here:

https://github.com/livecode/livecode/pull/4840

   Peter

--
Dr Peter Brett mailto:peter.br...@livecode.com>>
LiveCode Technical Project Manager

___
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

Re: Modern email library

[Richard Gaskin]

Ben Rubinstein wrote:

> I've one app that's been in existence for over a decade, which uses
> Shao Sean's libSmtp. It works fine.
>
> Now I find myself wanting to send email from a new stack I'm working
> on. I could just drag that library out again, but I suspect that a
> more modern way is to use tsNet.
>
> AFAICT tsNet handles the protocol of communicating with the server to
> transmit a message (i.e. the SMTP part), but doesn't offer any
> assistance with putting the message together (formatting with
> attachments etc).
>
> What do modern people use for this? Obviously I could rip the
> relevant parts out of libSMTP; or I recall that Sarah Reichelt had
> a library; is there a default answer among those who've sent email
> in the last ten years?

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.


I do have some monitoring systems that provide notification, but I don't 
usually install email on a server designed for any other purpose.


So instead I maintain one server on one of my shared hosting accounts as 
a notification center (it's not used often enough to warrant a VPS, but 
if you expect heavy load VPSes are cheap these days).  It runs an LC CGI 
that accepts a compressed encoded array containing the email elements 
(to, from, subject, body, etc.), and it formats it for use by sendmail, 
which it then calls from the command line.


The advantages with using an external server to do the actual sending are:

- I'm not dependent on a local SMTP client implementation, which I
  hope for security's sake won't always be available.

- It uses a simple one-line call to a server, so it's easy to
  add email support in any client app wherever I need it.

- The CGI is relatively simple to set up (Lesson examples available
  for using sendmail with LC CGI).

- The server is reasonably protected (nothing is *absolutely*
  protectable) by virtue of only accepting the LC-specific LSON
  (encoded array) format, which is also encrypted before sending,
  and transmitted over HTTPS.

By no means perfect (nothing is a magic pony), but easy to set up, 
convenient to use, and at least as secure as most alternatives.


I don't currently send attachments, but the MIME format is well 
documented and LC provides the raw materials needed (good text handling 
and base64 encoding), so even if a current library isn't readily 
available it shouldn't take long to package up an attachment with the body.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

Re: Modern email library

[Peter TB Brett]

On 30/11/2016 13:16, Ben Rubinstein wrote:

I've one app that's been in existence for over a decade, which uses Shao
Sean's libSmtp. It works fine.

Now I find myself wanting to send email from a new stack I'm working on.
I could just drag that library out again, but I suspect that a more
modern way is to use tsNet.

AFAICT tsNet handles the protocol of communicating with the server to
transmit a message (i.e. the SMTP part), but doesn't offer any
assistance with putting the message together (formatting with
attachments etc).

What do modern people use for this? Obviously I could rip the relevant
parts out of libSMTP; or I recall that Sarah Reichelt had a library; is
there a default answer among those who've sent email in the last ten years?


As part of the LiveCode for FM project, Monte has been developing a MIME 
library for constructing e-mail bodies.  We plan to include it in 
LiveCode 9.  But you can grab it ahead of time here:


https://github.com/livecode/livecode/pull/4840

Peter

--
Dr Peter Brett 
LiveCode Technical Project Manager

lcb-mode for Emacs: https://github.com/peter-b/lcb-mode

___
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

Modern email library

[Ben Rubinstein]

I've one app that's been in existence for over a decade, which uses Shao 
Sean's libSmtp. It works fine.


Now I find myself wanting to send email from a new stack I'm working on. I 
could just drag that library out again, but I suspect that a more modern way 
is to use tsNet.


AFAICT tsNet handles the protocol of communicating with the server to transmit 
a message (i.e. the SMTP part), but doesn't offer any assistance with putting 
the message together (formatting with attachments etc).


What do modern people use for this? Obviously I could rip the relevant parts 
out of libSMTP; or I recall that Sarah Reichelt had a library; is there a 
default answer among those who've sent email in the last ten years?


TIA,

Ben

___
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