Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #16308 > unrolled thread

Sending email with attachments

Back to article view | Back to comp.lang.javascript

Contents

  Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-01 22:49 -0700
    Re: Sending email with attachments Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-02 04:20 -0700
      Re: Sending email with attachments Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-02 05:16 -0700
        Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-02 07:10 -0700
          Re: Sending email with attachments Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-02 10:57 -0700
      Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-02 07:03 -0700
        Re: Sending email with attachments Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-02 10:50 -0700
          Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-02 11:16 -0700
            Re: Sending email with attachments dann90038@gmail.com - 2012-10-02 12:15 -0700
        Re: Sending email with attachments "Tom de Neef" <tdeneef@qolor.nl> - 2012-10-02 21:28 +0200
          Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-02 12:59 -0700
    Re: Sending email with attachments Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-02 22:26 +0200
      Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-03 20:04 +0100
      Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-06 02:07 +0100
        Re: Sending email with attachments Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-06 08:48 +0200
          Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-06 20:29 +0100
            Re: Sending email with attachments Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-06 21:49 +0200
              Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-07 08:13 +0100
                Re: Sending email with attachments Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-07 14:28 +0200
                  Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-08 00:43 +0100
                    Re: Sending email with attachments Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-08 03:26 +0200
                      Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-08 07:18 +0100
                        Re: Sending email with attachments Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-08 11:13 +0200
                          Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-08 18:57 +0100
                    Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-08 09:46 +0100
                      Re: Sending email with attachments Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-10-08 12:01 +0200
                        Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-08 19:16 +0100
                      Re: Sending email with attachments Gene Wirchenko <genew@ocis.net> - 2012-10-08 09:28 -0700
                        Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-08 18:34 +0100
            Re: Sending email with attachments Stefan Weiss <krewecherl@gmail.com> - 2012-10-07 12:46 +0200
              Re: Sending email with attachments Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-07 18:55 +0200
                Re: Sending email with attachments Stefan Weiss <krewecherl@gmail.com> - 2012-10-07 20:06 +0200
                  Re: Sending email with attachments Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-07 22:12 +0200
              Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-07 19:54 +0100
              Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-08 01:09 +0100
                Re: Sending email with attachments Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-08 13:10 +0200
                  Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-08 19:20 +0100
                OT: Mac vs PC for development  (Was: Sending email with attachments) Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-10-08 08:38 -0700
    Re: Sending email with attachments Dr J R Stockton <reply1240@merlyn.demon.co.uk.invalid> - 2012-10-03 19:49 +0100
      Re: Sending email with attachments Eli the Bearded <*@eli.users.panix.com> - 2012-10-03 23:08 +0000
        Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-04 02:46 +0100
          Re: Sending email with attachments Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-03 19:42 -0700
      Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-04 02:43 +0100
        Re: Sending email with attachments Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-03 19:54 -0700

Page 1 of 3  [1] 2 3  Next page →

#16308 — Sending email with attachments

I am writing a data collection application. It needs to run on as many
tablets and laptops as possible, so I'm writing it in HTML and
JavaScript. Although I cannot ask end users to buy a particular device,
I can ask them to install an up to date browser.

The ultimate destination of the data is a spreadsheet on a workstation
controlled by the person doing the data entry, or one of their associates.

The ideal, from my end users' point of view, would be a button they
could click that would send an e-mail to an address they enter with the
data attached in .csv format. I do understand that e-mail would not be
the best way of getting the data to a web server, but that is not the
objective. Forwarding the data from my web site to a user-specified
e-mail address would require anti-spam precautions, and be generally
undesirable.

I've done web searches, and the closest I've been able to get is to fold
the data into a mailto URL as the message body, not an attachment. I
would be length limited by the Internet Explorer 2083 char URL limit,
and I think I would also have to quote URL special characters.

Another option is to just display the data and invite the user to
select and copy. The data could then be pasted into the body of an
e-mail, or into a text file in an editor window. I believe that would
work, but involves more end user busy work than is ideal.

I am very new to JavaScript, so I'm really hoping there is a better way
of doing this that I have just not found.

Thanks for any ideas or pointers to web sites I should read.

Patricia

[toc] | [next] | [standalone]

#16310

Patricia Shanahan wrote:
> I am writing a data collection application. It needs to run on as many
> tablets and laptops as possible, so I'm writing it in HTML and
> JavaScript. Although I cannot ask end users to buy a particular device,
> I can ask them to install an up to date browser.
>
> The ultimate destination of the data is a spreadsheet on a workstation
> controlled by the person doing the data entry, or one of their associates.
>
> The ideal, from my end users' point of view, would be a button they
> could click that would send an e-mail to an address they enter with the
> data attached in .csv format. [ ... ]

I don't understand why you would choose email for this rather than a
web download.  Are the browsers working disconnected from the server
serving that content?  Is the server extremely limited?  If neither of
these is true, then you should be able to send the data to the server
to send back as a downloadable file.  That seems the most flexible
solution.  Does your infrastructure prevent this?

  -- Scott

[toc] | [prev] | [next] | [standalone]

#16311

Scott Sauyet wrote:
> Patricia Shanahan wrote:
>> I am writing a data collection application. It needs to run on as many
>> tablets and laptops as possible, so I'm writing it in HTML and
>> JavaScript. Although I cannot ask end users to buy a particular device,
>> I can ask them to install an up to date browser.
>
>> The ultimate destination of the data is a spreadsheet on a workstation
>> controlled by the person doing the data entry, or one of their associates.
>
>> The ideal, from my end users' point of view, would be a button they
>> could click that would send an e-mail to an address they enter with the
>> data attached in .csv format. [ ... ]
>
> I don't understand why you would choose email for this rather than a
> web download.  Are the browsers working disconnected from the server
> serving that content?  Is the server extremely limited?  If neither of
> these is true, then you should be able to send the data to the server
> to send back as a downloadable file.  That seems the most flexible
> solution.  Does your infrastructure prevent this?

I posted a proof of concept of this technique in a thread started by
this post:

    <news:QvydnWGOxc8p0N_WnZ2dnUVZ_tWdnZ2d@posted.isomediainc>

Google archived this thread at

    <https://groups.google.com/group/comp.lang.javascript/
browse_thread/thread/fbf0f310811f30b7/3b751ce8a7107c61>

  -- Scott

[toc] | [prev] | [next] | [standalone]

#16313

On 10/2/2012 5:16 AM, Scott Sauyet wrote:
> Scott Sauyet wrote:
>> Patricia Shanahan wrote:
>>> I am writing a data collection application. It needs to run on as many
>>> tablets and laptops as possible, so I'm writing it in HTML and
>>> JavaScript. Although I cannot ask end users to buy a particular device,
>>> I can ask them to install an up to date browser.
>>
>>> The ultimate destination of the data is a spreadsheet on a workstation
>>> controlled by the person doing the data entry, or one of their associates.
>>
>>> The ideal, from my end users' point of view, would be a button they
>>> could click that would send an e-mail to an address they enter with the
>>> data attached in .csv format. [ ... ]
>>
>> I don't understand why you would choose email for this rather than a
>> web download.  Are the browsers working disconnected from the server
>> serving that content?  Is the server extremely limited?  If neither of
>> these is true, then you should be able to send the data to the server
>> to send back as a downloadable file.  That seems the most flexible
>> solution.  Does your infrastructure prevent this?
>
> I posted a proof of concept of this technique in a thread started by
> this post:
>
>      <news:QvydnWGOxc8p0N_WnZ2dnUVZ_tWdnZ2d@posted.isomediainc>
>
> Google archived this thread at
>
>      <https://groups.google.com/group/comp.lang.javascript/
> browse_thread/thread/fbf0f310811f30b7/3b751ce8a7107c61>


I've looked at the thread. If I understand it correctly, it is about
getting the data to the web site serving the pages, not to an e-mail
inbox on a workstation outside that domain, my objective. I recognize
that there may be ways of forwarding the data, but I would prefer to
avoid that if there is any way of doing so.

Patricia

[toc] | [prev] | [next] | [standalone]

#16316

Patricia Shanahan wrote:
> Scott Sauyet wrote:
>> Scott Sauyet wrote:
>>> Patricia Shanahan wrote:
>>>> [ ... ]
>>>> The ultimate destination of the data is a spreadsheet on a workstation
>>>> controlled by the person doing the data entry, or one of their associates.
>
>>>> The ideal, from my end users' point of view, would be a button they
>>>> could click that would send an e-mail to an address they enter with the
>>>> data attached in .csv format. [ ... ]
>
>>> I don't understand why you would choose email for this rather than a
>>> web download.  Are the browsers working disconnected from the server
>>> serving that content?  Is the server extremely limited?  If neither of
>>> these is true, then you should be able to send the data to the server
>>> to send back as a downloadable file.  That seems the most flexible
>>> solution.  Does your infrastructure prevent this?
>
>> I posted a proof of concept of this technique in a thread started by
>> this post:
>
>>      <news:QvydnWGOxc8p0N_WnZ2dnUVZ_tWdnZ2d@posted.isomediainc>
>
>> Google archived this thread at
>
>>      <https://groups.google.com/group/comp.lang.javascript/
>> browse_thread/thread/fbf0f310811f30b7/3b751ce8a7107c61>
>
> I've looked at the thread. If I understand it correctly, it is about
> getting the data to the web site serving the pages, not to an e-mail
> inbox on a workstation outside that domain, my objective. I recognize
> that there may be ways of forwarding the data, but I would prefer to
> avoid that if there is any way of doing so.

You are correct.  This is an example of how you can do web downloads
from client-side code with a minimally cooperative server, not how to
do any email.  It will not work at all in an off-line environment, and
it does require that the users trust the server not to do anything
more with the data than to return it as a download.

I wish I had a suggestion that might help with your original problem,
but I don't know of anything.  My best suggestion would be to write
something that you could compile for each of your target
environments.  If you want client-side Javascript, you might try
something that supplies its UI over HTTP and then launch a browser
pointing to a local host, but even then you would need to write that
host in something that you could deploy natively to your target
machines.  Sorry.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#16312

On 10/2/2012 4:20 AM, Scott Sauyet wrote:
> Patricia Shanahan wrote:
>> I am writing a data collection application. It needs to run on as many
>> tablets and laptops as possible, so I'm writing it in HTML and
>> JavaScript. Although I cannot ask end users to buy a particular device,
>> I can ask them to install an up to date browser.
>>
>> The ultimate destination of the data is a spreadsheet on a workstation
>> controlled by the person doing the data entry, or one of their associates.
>>
>> The ideal, from my end users' point of view, would be a button they
>> could click that would send an e-mail to an address they enter with the
>> data attached in .csv format. [ ... ]
>
> I don't understand why you would choose email for this rather than a
> web download.  Are the browsers working disconnected from the server
> serving that content?  Is the server extremely limited?  If neither of
> these is true, then you should be able to send the data to the server
> to send back as a downloadable file.  That seems the most flexible
> solution.  Does your infrastructure prevent this?

It does make it much less desirable and appropriate than e-mail
transmission.

If there were a non-browser programming language and run time
environment that ran on all target devices, including iPad, I would be
writing an application in that language. The only reason for configuring
the application as a web site is the number of possible collection
devices that have browsers with JavaScript.

The data is not my data and is none of my business. Different people
will be doing the data collection, for different projects, in different
organizations. Each project will belong to some researcher who will
typically use a workstation behind a firewall to consolidate and process
the data and prepare reports based on it.

I would like to get the data as directly as possible from the data
collection device to that workstation. The end users are expert
spreadsheet users, so they know what to do with a .csv attachment, but
are not web developers and do not necessarily control a web server. My
lead user suggested e-mail as his ideal data delivery method.

Some of the data collection will have to be done offline. I'm looking at
marking pages and JavaScript files for offline use, but would like to
also offer the application in the form of a zip file that can be
downloaded and extracted on a collection device, and used locally. I
plan to store the data in the browser's local memory until the user has
network access. Transferring data collected by local pages to my web
site gets into cross-domain access issues.

Patricia

[toc] | [prev] | [next] | [standalone]

#16315

Patricia Shanahan wrote:
Scott Sauyet wrote:
>> Patricia Shanahan wrote:
>>> I am writing a data collection application. It needs to run on as many
>>> tablets and laptops as possible, so I'm writing it in HTML and
>>> JavaScript. Although I cannot ask end users to buy a particular device,
>>> I can ask them to install an up to date browser.
>
>>> The ultimate destination of the data is a spreadsheet on a workstation
>>> controlled by the person doing the data entry, or one of their associates.
>
>>> The ideal, from my end users' point of view, would be a button they
>>> could click that would send an e-mail to an address they enter with the
>>> data attached in .csv format. [ ... ]
>
>> I don't understand why you would choose email for this rather than a
>> web download.  Are the browsers working disconnected from the server
>> serving that content?  Is the server extremely limited?  If neither of
>> these is true, then you should be able to send the data to the server
>> to send back as a downloadable file.  That seems the most flexible
>> solution.  Does your infrastructure prevent this?
>
> It does make it much less desirable and appropriate than e-mail
> transmission.
>
> If there were a non-browser programming language and run time
> environment that ran on all target devices, including iPad, I would be
> writing an application in that language. The only reason for configuring
> the application as a web site is the number of possible collection
> devices that have browsers with JavaScript.

I see.  I did misunderstand the problem.  I don't think you will be
able to do what you would like.  Client-side Javascript has no
capability to email.  `mailto:` links are just ways to launch external
email programs, and there is no way that I know of to add attachments
to those emails.

I wish I had better news for you.  Best of luck,

  -- Scott

[toc] | [prev] | [next] | [standalone]

#16317

On 10/2/2012 10:50 AM, Scott Sauyet wrote:
> Patricia Shanahan wrote:
...
>> If there were a non-browser programming language and run time
>> environment that ran on all target devices, including iPad, I would be
>> writing an application in that language. The only reason for configuring
>> the application as a web site is the number of possible collection
>> devices that have browsers with JavaScript.
>
> I see.  I did misunderstand the problem.  I don't think you will be
> able to do what you would like.  Client-side Javascript has no
> capability to email.  `mailto:` links are just ways to launch external
> email programs, and there is no way that I know of to add attachments
> to those emails.
>
> I wish I had better news for you.  Best of luck,

Thanks. Even a negative result is very helpful. I would otherwise have
spent a lot of time web searching and experimenting looking for
something that does not exist. It is relatively easy to find how to do
something that can be done in an unfamiliar language. Being sure
something cannot be done is much harder.

I do have a fall-back position that would have to be used to in some
situations. I plan to provide a way to display the data in a text area,
ideally already selected, so that the user can copy it to the clipboard.
Once it is in the clipboard it can be pasted into an e-mail, Google docs
text file, text file on a thumb drive etc. etc.

I have to support that anyway for devices that do not have an e-mail
client, and for confidential data that should not be sent over the
Internet in unencrypted form.

Patricia

[toc] | [prev] | [next] | [standalone]

#16318

js or html cannot send an e-mail as an engine from the browser, true, however a mail-server on the server side can do the sending, if the webpage just provides the FORM with a method say method="post" and can also take file(s) <input type="file" ...> input to be send over on with enctype="multipar/form-data" in the FORM.  The only thing needed for all that will be the mail-server service on the server side and the script to process it.

<form action="SPREADSHEET_SENDER.pl" method="POST" enctype="multipart/form-data">
  <input type="file" name="data-collection">
  .....
</form>

    Danny

[toc] | [prev] | [next] | [standalone]

#16319

"Patricia Shanahan" <pats@acm.org> wrote:
>>> I am writing a data collection application. It needs to run on as many
>>> tablets and laptops as possible, so I'm writing it in HTML and
>>> JavaScript. Although I cannot ask end users to buy a particular device,
>>> I can ask them to install an up to date browser.
>>>
>>> The ideal, from my end users' point of view, would be a button they
>>> could click that would send an e-mail to an address they enter with the
>>> data attached in .csv format. [ ... ]
>>
> If there were a non-browser programming language and run time
> environment that ran on all target devices, including iPad, I would be
> writing an application in that language. The only reason for configuring
> the application as a web site is the number of possible collection
> devices that have browsers with JavaScript.
>
> I would like to get the data as directly as possible from the data
> collection device to that workstation. The end users are expert
> spreadsheet users, so they know what to do with a .csv attachment, but
> are not web developers and do not necessarily control a web server. My
> lead user suggested e-mail as his ideal data delivery method.

Forgive if I got it wrong: data is collected on devices with internet access 
and browser support.
This data is in the form of tables or files and needs to be sent to someone 
with an email account, where the account depends on the device/data under 
consideration. You would like to get it there 'as direct as possible'.

Suppose you had a web server. The person operating the collection device 
surfs to its URL. He gets a webpage with two selection 'fields': one to 
indicate where the data is (when it is a file) or to copy it into a text 
field (when it is a table). The other to select the email address of the 
target person. Any pre-processing (like getting the data in the right 
format) could be done by script on the page.
'Submit' could then result in an (encrypted) upload to the server, where the 
data is attached to an email which the server sends to the target.
Would that meet your requirements? It would be easy to implement.
Tom

[toc] | [prev] | [next] | [standalone]

#16321

On 10/2/2012 12:28 PM, Tom de Neef wrote:
> "Patricia Shanahan" <pats@acm.org> wrote:
>>>> I am writing a data collection application. It needs to run on as many
>>>> tablets and laptops as possible, so I'm writing it in HTML and
>>>> JavaScript. Although I cannot ask end users to buy a particular device,
>>>> I can ask them to install an up to date browser.
>>>>
>>>> The ideal, from my end users' point of view, would be a button they
>>>> could click that would send an e-mail to an address they enter with the
>>>> data attached in .csv format. [ ... ]
>>>
>> If there were a non-browser programming language and run time
>> environment that ran on all target devices, including iPad, I would be
>> writing an application in that language. The only reason for configuring
>> the application as a web site is the number of possible collection
>> devices that have browsers with JavaScript.
>>
>> I would like to get the data as directly as possible from the data
>> collection device to that workstation. The end users are expert
>> spreadsheet users, so they know what to do with a .csv attachment, but
>> are not web developers and do not necessarily control a web server. My
>> lead user suggested e-mail as his ideal data delivery method.
>
> Forgive if I got it wrong: data is collected on devices with internet access
> and browser support.
> This data is in the form of tables or files and needs to be sent to someone
> with an email account, where the account depends on the device/data under
> consideration. You would like to get it there 'as direct as possible'.

Typically, the data will be in the browser's local storage, where I can
put it from client-side JavaScript. However, the main point is that the
data will be somewhere accessible to my client side code.

>
> Suppose you had a web server. The person operating the collection device
> surfs to its URL. He gets a webpage with two selection 'fields': one to
> indicate where the data is (when it is a file) or to copy it into a text
> field (when it is a table). The other to select the email address of the
> target person. Any pre-processing (like getting the data in the right
> format) could be done by script on the page.
> 'Submit' could then result in an (encrypted) upload to the server, where the
> data is attached to an email which the server sends to the target.
> Would that meet your requirements? It would be easy to implement.

How safe would that be from spammers wanting to turn my web site into a
forwarding engine?

Patricia

[toc] | [prev] | [next] | [standalone]

#16322

Patricia Shanahan wrote:

> I am writing a data collection application. It needs to run on as many
> tablets and laptops as possible, so I'm writing it in HTML and
> JavaScript. Although I cannot ask end users to buy a particular device,
> I can ask them to install an up to date browser.
> 
> The ultimate destination of the data is a spreadsheet on a workstation
> controlled by the person doing the data entry, or one of their associates.
> 
> The ideal, from my end users' point of view, would be a button they
> could click that would send an e-mail to an address they enter with the
> data attached in .csv format.

You cannot do that client-side, so you will have to do it server-side.  That 
is, have a server-side application compile the .csv and send the e-mail.  
Usually that would be the same server-side application that generated the 
client-side application in the first place.

> I do understand that e-mail would not be the best way of getting the data
> to a web server, but that is not the objective. Forwarding the data from
> my web site to a user-specified e-mail address would require anti-spam
> precautions, and be generally undesirable.

If that is a concern, users of the application need to be authenticated 
before they can use that function (see also [OWASP]).

Only shifting the load from the server to the client is not a solution.  In 
fact, it has the potential to make matters worse.  Client computers 
(including mobile devices) are usually much less protected, thus more easily 
compromised, than servers.
 
> I've done web searches, and the closest I've been able to get is to fold
> the data into a mailto URL as the message body, not an attachment.

Technically, an e-mail attachment is a part of the message body of a multi-
part message, following a delimiter line, own header and usually a Base64-
encoded message-part body (see [RFC2046]); so, in theory, it could work.  
But I would not recommend it for production.  In fact, security measures 
might prevent it.
 
> I would be length limited by the Internet Explorer 2083 char URL limit,
> and I think I would also have to quote URL special characters.

Apparently there are exceptions for certain supported URI schemes, such as 
`data:'. [SO]  There might be one for `mailto:' as well.  However, a 
suitable MUA will need to be installed and configured at the client for this 
to work, which you should not make a requirement.
 
> Another option is to just display the data and invite the user to
> select and copy. The data could then be pasted into the body of an
> e-mail, or into a text file in an editor window. I believe that would
> work, but involves more end user busy work than is ideal.

Yes, in a Web application you should make best use of the *Web* first.
 
> I am very new to JavaScript, so I'm really hoping there is a better way
> of doing this that I have just not found.

Client-side there is nothing better than that, but it does not mean that it 
cannot be done using an ECMAScript implementation server-side.


HTH

PointedEars
___________
[OWASP]
The Open Web Application Security Project: Authentication Cheet Sheet. 
(updated: 2012-09-28) 
<https://www.owasp.org/index.php/Authentication_Cheat_Sheet>

[RFC2046]
Freed, N., Borenstein, N.: Multipurpose Internet Mail Extensions (MIME) Part 
Two: Media Types. November 1996. <http://tools.ietf.org/html/rfc2046>

[SO]
StackOverflow: What is the maximum length of a URL? (updated: 2012-07-12)
<http://stackoverflow.com/a/417184/855543>
-- 
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[toc] | [prev] | [next] | [standalone]

#16354

Thomas 'PointedEars' Lahn wrote:
> Patricia Shanahan wrote:
> 
...
> Technically, an e-mail attachment is a part of the message body of a multi-
> part message, following a delimiter line, own header and usually a Base64-
> encoded message-part body (see [RFC2046]); so, in theory, it could work.  
> But I would not recommend it for production.  In fact, security measures 
> might prevent it.
...

It does sound worth investigating.

>  
>> Another option is to just display the data and invite the user to
>> select and copy. The data could then be pasted into the body of an
>> e-mail, or into a text file in an editor window. I believe that would
>> work, but involves more end user busy work than is ideal.
> 
> Yes, in a Web application you should make best use of the *Web* first.
>  

I'm not writing a web application.

I'm writing an application that happens to be implemented in HTML and
JavaScript, and use a browser as the run time. If iPad had a suitable
Java runtime, and a less inconvenient development process, it would have
been a Java application. Because of the choice of languages, one way of
deploying it is to use HTTP to get the files from some server. For other
combinations of situation and device, it may be better to download the
application to the client file system.

Patricia

[toc] | [prev] | [next] | [standalone]

#16422

Thomas 'PointedEars' Lahn wrote:
> Patricia Shanahan wrote:
..
>> I've done web searches, and the closest I've been able to get is to fold
>> the data into a mailto URL as the message body, not an attachment.
> 
> Technically, an e-mail attachment is a part of the message body of a multi-
> part message, following a delimiter line, own header and usually a Base64-
> encoded message-part body (see [RFC2046]); so, in theory, it could work.  
> But I would not recommend it for production.  In fact, security measures 
> might prevent it.

I've done some more web searches and experiments. Unfortunately, the
comment about security measures seems to be correct.

RFC 6068, "The 'mailto' URI Scheme" says "Only a limited set of header
fields such as Subject and Keywords, as well as Body, are believed to be
both safe and useful in the general case."

I've tested with Firefox as browser and Thunderbird as mail client. The
content type header in the message as delivered is "text/plain;
charset=ISO-8859-1; format=flowed" regardless of my attempts to specify
a multi-part content type in the URI.

Patricia

[toc] | [prev] | [next] | [standalone]

#16424

Patricia Shanahan wrote:

> RFC 6068, "The 'mailto' URI Scheme" says "Only a limited set of header
> fields such as Subject and Keywords, as well as Body, are believed to be
> both safe and useful in the general case."
> 
> I've tested with Firefox as browser and Thunderbird as mail client. The
> content type header in the message as delivered is "text/plain;
> charset=ISO-8859-1; format=flowed" regardless of my attempts to specify
> a multi-part content type in the URI.

I had not considered the requirement for the main `Content-Type' header 
field of multi-part messages.

The question remains why it would be acceptable to send the data over the 
Internet via e-mail to an SMTP server, but not over the Internet to an HTTP 
server.


PointedEars
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

[toc] | [prev] | [next] | [standalone]

#16433

Thomas 'PointedEars' Lahn wrote:
...
> The question remains why it would be acceptable to send the data over the 
> Internet via e-mail to an SMTP server, but not over the Internet to an HTTP 
> server.

The difference is that most tablets already have access to an existing
SMTP server, and any SMTP server, without special configuration, can
forward e-mail to some mailbox that can be accessed from the workstation
where that particular data set will be processed.

On the other hand, organizations using the software are unlikely to have
an HTTP server set up with the right scripts. Typically, the department
that might use the software I'm writing will not have the sort of
control over a server that it takes to install new scripts on it.

I could install scripts in my personal domain, but I don't think users
would want their data to go through my domain.

Patricia

[toc] | [prev] | [next] | [standalone]

#16434

Patricia Shanahan wrote:

> Thomas 'PointedEars' Lahn wrote:
>> The question remains why it would be acceptable to send the data over the
>> Internet via e-mail to an SMTP server, but not over the Internet to an
>> HTTP server.
> 
> The difference is that most tablets already have access to an existing
> SMTP server, and any SMTP server, without special configuration, can
> forward e-mail to some mailbox that can be accessed from the workstation
> where that particular data set will be processed.
> 
> On the other hand, organizations using the software are unlikely to have
> an HTTP server set up with the right scripts. Typically, the department
> that might use the software I'm writing will not have the sort of
> control over a server that it takes to install new scripts on it.
> 
> I could install scripts in my personal domain, but I don't think users
> would want their data to go through my domain.

ACK.  Alternative approaches can be suggested if you describe your problem 
in more detail:

<http://www.catb.org/~esr/faqs/smart-questions.html#beprecise>


PointedEars
-- 
Sometimes, what you learn is wrong. If those wrong ideas are close to the 
root of the knowledge tree you build on a particular subject, pruning the 
bad branches can sometimes cause the whole tree to collapse.
  -- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>

[toc] | [prev] | [next] | [standalone]

#16439

Thomas 'PointedEars' Lahn wrote:
> Patricia Shanahan wrote:
> 
>> Thomas 'PointedEars' Lahn wrote:
>>> The question remains why it would be acceptable to send the data over the
>>> Internet via e-mail to an SMTP server, but not over the Internet to an
>>> HTTP server.
>> The difference is that most tablets already have access to an existing
>> SMTP server, and any SMTP server, without special configuration, can
>> forward e-mail to some mailbox that can be accessed from the workstation
>> where that particular data set will be processed.
>>
>> On the other hand, organizations using the software are unlikely to have
>> an HTTP server set up with the right scripts. Typically, the department
>> that might use the software I'm writing will not have the sort of
>> control over a server that it takes to install new scripts on it.
>>
>> I could install scripts in my personal domain, but I don't think users
>> would want their data to go through my domain.
> 
> ACK.  Alternative approaches can be suggested if you describe your problem 
> in more detail:
> 
> <http://www.catb.org/~esr/faqs/smart-questions.html#beprecise>

I cannot describe my current project in public until it is further
along. I'm not asking for general help with my program design. That's my
problem.

I just wanted to check whether a specific user requirement could be met
using only HTML and JavaScript, after I had failed to find a solution by
reading books, web searching, thinking, and experiments. As I indicated
in my first article, I was fully aware of server based solutions, but
they are not appropriate for my application.

I've got the answer to my question - I can only send text in an e-mail -
so I'm on to working with that answer.

I don't think it is a big enough problem to make me change strategy from
HTML + JavaScript to installable application implementations for each
major group of environments.

Thanks for your help,

Patricia

[toc] | [prev] | [next] | [standalone]

#16446

Patricia Shanahan wrote:

> I cannot describe my current project in public until it is further
> along.

You do not have to tell names in order to go into details.

> I'm not asking for general help with my program design.

But you did.

> That's my problem.

ISTM that your problem is that despite all your research you have made 
premature exclusions based on premature assessment based on limited 
experience.  Describing the context of the problem in more detail to many 
people will most certainly show whether your exclusions actually have been 
premature.
 
> I just wanted to check whether a specific user requirement could be met
> using only HTML and JavaScript, after I had failed to find a solution by
> reading books, web searching, thinking, and experiments. As I indicated
> in my first article, I was fully aware of server based solutions, but
> they are not appropriate for my application.
> 
> I've got the answer to my question - I can only send text in an e-mail -
> so I'm on to working with that answer.

Actually, you have presented e-mail as the ideal solution, and you have 
asked if there was a better way.  Due to your limited experience with 
client-side scripting, that initial assessment might have been wrong.
 
> I don't think it is a big enough problem to make me change strategy from
> HTML + JavaScript to installable application implementations for each
> major group of environments.

False dichotomy.
 
> Thanks for your help,

You are welcome.


PointedEars
-- 
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
  -- Richard Cornford, comp.lang.javascript, 2011-11-14

[toc] | [prev] | [next] | [standalone]

#16456

Thomas 'PointedEars' Lahn wrote:
...
> Actually, you have presented e-mail as the ideal solution, and you have 
> asked if there was a better way.  Due to your limited experience with 
> client-side scripting, that initial assessment might have been wrong.
...

Ah, I see the misunderstanding.

My primary question, reflected in the subject, was whether it is
possible to send e-mail with attachments from JavaScript. My own
research and experiments had suggest "No", but, recognizing my limited
experience with the language, I wanted to check my answer. My original
analysis was indeed correct, which is reassuring though disappointing.

Secondarily, I am also interested in alternative suggestions for a very
specific issue, getting tabular data I have in JavaScript data
structures in a browser on e.g. a tablet into a spreadsheet on a
workstation without transferring it through a specially set up server.
The server script approach is obvious, is discussed in many web pages I
have read, and is inappropriate for my situation.

Even if you distrust my judgment on the need to avoid server set-up, if
you are interested in the secondary question you can, if you like, think
of it as a hypothetical. Suppose a JS+HTML application were to exist
that had tabular data in JavaScript data structures, and needed to
transfer it to a spreadsheet on a workstation without using any special
server set-up. What would be the best ways to do it?

The simplest and most general solution I have thought of is to display
the data as CSV text, so that the user can select and copy it to the
clipboard. From there, they can do all sorts of things with it, subject
only to device limitations, including pasting it into the body of an
e-mail, or, pasting it into a text editor window and saving it, as a
.csv file, on a thumb drive.

Patricia

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web