6 ms·

Send Email Directly from JavaScript

25 points by omarfarooq 5y ago

Canada 5y ago
This allows anyone to use the mail service account to send spam.
- omarfarooq 5y ago
  From the site: > All email services require some sort of authentication to send the emails on your behalf. That makes it a really bad idea to use them directly from client-side – revealing your password or your secret keys will allow anyone to send emails on your behalf. EmailJS keeps your authentication details on the server-side, and the client-side code just triggers a predefined email template, similarly to how any client-server application is working. also, > Additionally, we've also developed various tools to prevent abuse – for instance, we have IP based rate limits to prevent bots from spamming, the whitelist of origin, and also support reCAPTCHA tests to make sure that a human is sending the email (although it's up to the developer to turn this feature on).
  - ealexhudson 5y ago
    The homepage claim is that no server-side code is required to integrate it - so this seems to allow anyone to rock up on your website, call into the EmailJS service, and trigger an email? Given that EmailJS doesn't send email directly - it only sends through the accounts (e.g. Gmail) you've connected - this feels like a recipe for getting your email account shut down rapidly. If your template allows a variable destination (i.e. you can set To: from client-side) and there's enough latitude in the template, I don't see anything stopping people spamming through this service beyond the "abuse measures" like IP rate limiting.
    - omarfarooq 5y ago
      They say so themselves: > Personal email services allow connecting personal email providers that offer basic email functionality – an email address and an inbox. These include providers like Gmail, Fastmail, Outlook 365, etc'. Personal email services are useful in EmailJS when you need to send a small number of emails to yourself, or need to send emails to other people from your personal email account. Note, your personal email account could be blocked if you go over the daily limit of the email provider, and your email address could be flagged as spam if you send unsolicited emails to multiple recipients. Our general recommendation is to use personal email services only for development purposes or for very low volume usage. Source: https://www.emailjs.com/docs/tutorial/adding-email-service/ https://www.emailjs.com/docs/tutorial/adding-email-service/
      - ealexhudson 5y ago
        Yeah, but they state it in quite non-obvious terms: "you might hit the rate limit", or "you could be flagged as spam if you send to multiple recipients". The real risk is that someone finds this script on your website, open, and abuses it for themselves. Which is exactly what spammers already do, from the old sendmail.pl scripts to current vulnerable Wordpress extensions. If an external actor finds this and abuses it, that will be a world of pain. Worse, if someone was specifically trying to target you for some hurt, the ability to send emails they control directly from your personal account?! There is so much damage you could do with that ability..
- q-rews 5y ago
  So just like any contact form? The API does not expose a “to” field, did you even open the page?
  - Aeolun 5y ago
    If the API does not expose a to field, what exactly is the point? Seems like you need to use a template field to modify the ‘to’ field, but that would still require you to pass the template value in the request.
    - mnahkies 5y ago
      It seems like this is aimed at use cases like a contact form hosted on something like GitHub pages - where you're limited to a static site, and assuming you don't want to run your own server side handler. I have one site that is generated by Gatsby that could conceivably use this instead of the php script I currently have setup to handle the contact form.
- emailjs 5y ago
  This is a misconception.
aaaaaaaaaaab 5y ago
What would be a use case for this? E.g. sending verification emails from the client is a bit hare-brained, as I can just as easily steal the verification link from the dev console…
- Rockslide 5y ago
  Adding a contact form to a statically generated website - that's what I use it for (all email goes to a single predefined account)
  - aaaaaaaaaaab 5y ago
    Why don’t you use a mailto: URL instead?
thunderbong 5y ago
I was really intrigued so I signed up. Essentially, this is a service which connects to different email accounts of your choosing - Yahoo, Outlook, Gmail etc. and then sends email via those. I haven't tested it all the way, but in many scenarios when emails are sent via an application, the server essentially does the same thing, except that, IMHO, it takes a bit more knowhow. In this case, you set up email services under your emailjs account one time and then everything is handled via Javascript on the front end via their servers. Quite nice, come to think of it. Except the privacy aspect, of course! When we set up it up like this on our servers, the only parties that can read it are the recipients, the service provider and us. In this case, emailjs also gets to have a look at the emails.
- primitivesuave 5y ago
  This is pretty much what makes it an increasingly difficult sell as an application scales up, and untenable for me personally - at some point, something mission critical like emails cannot be in the hands of a third party, let alone in the hands of a client-side library.
  - albertgoeswoof 5y ago
    How are you sending emails if not via a 3rd party?
    - primitivesuave 5y ago
      I should clarify that statement to - I don't wish to involve a 3rd party I don't trust (e.g. small startup) in handling transactions with 3rd parties I trust (e.g. Amazon SES, Mailgun, Sendgrid, etc). I don't mean to imply that the proprietors of this service are not fully capable of creating a great system, however I am fairly certain that most decision makers on using something like this would take pause where I did.
      - hirako2000 5y ago
        You are putting a lot of trust in mailgun, sendgrid and Amazon. Beside, when integrity and confidentiality is critical, the solution is crypto signature and encryption. Not the trust in supposedly reputable 3rd parties.
genezeta 5y ago
> not as a service that allows you to send email from Javascript, but rather as a service that allows you to create a predefined set of emails via the dashboard, and then just trigger the emails from the Javascript. This is quite similar to how emails are usually sent via a proprietary server code So... a bold title saying something and then an explanation explicitly saying it was not true.
- omarfarooq 5y ago
  ...is this or is this not triggering email from JS? Your paste is also in context to the extent of abuse that can happen to the connected email services.
  - genezeta 5y ago
    The claim in the title is not "use JS to trigger the sending of an email from a server" but "send email directly from JavaScript".
  - bellyfullofbac 5y ago
    "Launch nuclear missile directly from JavaScript"...
oefrha 5y ago
On the server side, I suppose you can use this, but it usually makes sense to use a vendor SDK directly rather than rely on and hand user data to yet another middle man that might disappear at any time. I guess bridging personal email providers is an interesting idea, but it doesn’t make sense to use a personal email account when you’re beyond the free tier of a few emails a day anyway. On the client side, unless you want to authorize spam sent from your account to any recipient of an attacker’s choosing, you can only use this service to send emails to fixed recipients, so most use cases of transactional email (e.g. user authentication, notification, marketing) are out of question. Sending emails on behalf of users to yourself on a contact page is the sole use case I can think of, but that market is crowded as is with more focused and less confusing offerings. Any other use cases I missed?
- emailjs 5y ago
  I think that you have an overestimated opinion about the vendors' SDK, not all of them have acceptable quality, but let's leave it to the discretion of the developers themselves. What is really important for our clients who use the EmailJS service from the back-end is flexibility and freedom of choice. If vendor "X" suddenly stops working for you or if there are any problems, the migration to another vendor will take several days. With the EmailJS service, about 10 minutes: add another service and move your traffic to it. Indeed, someone could copy your code, but they will only be able to send your templates, with your content, and will not be able to send a custom email with their own content (spam). Which is absolutely not interesting for attackers.
thepangolino 5y ago
How is this different from SmtpJS.com ?
junon 5y ago
Send email directly from a commercial SaaS product*
- mike_hock 5y ago
  Thank god. I thought there was another default security hole in browsers that I'd have to plug or opt out of.
colinclerk 5y ago
Congrats on the launch! There’s a strong shift of devtools from the backend to the frontend, and services are often jumping through hoops to 1) remain secure, and 2) allow client-only integration. For example, Stripe offers a client-only integration with similar limitations - the product catalog must be defined within the stripe dashboard. https://stripe.com/docs/payments/checkout/client https://stripe.com/docs/payments/checkout/client At https://clerk.dev https://clerk.dev (disc: founder), we do all of sign up, sign in, and user profile management from just the client. We’re able to keep it secure because we also do session/cookie management, so can tell who is signed in. Emailjs has an interesting concept here. It’s definitely on-trend, though I personally wouldn’t like users being able to trigger emails to other users, which seems possible today (correct me if I’m wrong?) Have you considered an option to require a signed JWT with requests, which could contain the user’s email address? That would make it so users can only trigger spam to themselves (except in cases of xss), but retain a mostly client-only experience. (Generating the jwt requires a backend, but developers may already have one available if they’re using another service like Hasura that follows a similar pattern.)

25 points by omarfarooq 5y ago

Canada 5y ago

This allows anyone to use the mail service account to send spam.

omarfarooq 5y ago
From the site: > All email services require some sort of authentication to send the emails on your behalf. That makes it a really bad idea to use them directly from client-side – revealing your password or your secret keys will allow anyone to send emails on your behalf. EmailJS keeps your authentication details on the server-side, and the client-side code just triggers a predefined email template, similarly to how any client-server application is working. also, > Additionally, we've also developed various tools to prevent abuse – for instance, we have IP based rate limits to prevent bots from spamming, the whitelist of origin, and also support reCAPTCHA tests to make sure that a human is sending the email (although it's up to the developer to turn this feature on).
- ealexhudson 5y ago
  The homepage claim is that no server-side code is required to integrate it - so this seems to allow anyone to rock up on your website, call into the EmailJS service, and trigger an email? Given that EmailJS doesn't send email directly - it only sends through the accounts (e.g. Gmail) you've connected - this feels like a recipe for getting your email account shut down rapidly. If your template allows a variable destination (i.e. you can set To: from client-side) and there's enough latitude in the template, I don't see anything stopping people spamming through this service beyond the "abuse measures" like IP rate limiting.
  - omarfarooq 5y ago
    They say so themselves: > Personal email services allow connecting personal email providers that offer basic email functionality – an email address and an inbox. These include providers like Gmail, Fastmail, Outlook 365, etc'. Personal email services are useful in EmailJS when you need to send a small number of emails to yourself, or need to send emails to other people from your personal email account. Note, your personal email account could be blocked if you go over the daily limit of the email provider, and your email address could be flagged as spam if you send unsolicited emails to multiple recipients. Our general recommendation is to use personal email services only for development purposes or for very low volume usage. Source: https://www.emailjs.com/docs/tutorial/adding-email-service/ https://www.emailjs.com/docs/tutorial/adding-email-service/
    - ealexhudson 5y ago
      Yeah, but they state it in quite non-obvious terms: "you might hit the rate limit", or "you could be flagged as spam if you send to multiple recipients". The real risk is that someone finds this script on your website, open, and abuses it for themselves. Which is exactly what spammers already do, from the old sendmail.pl scripts to current vulnerable Wordpress extensions. If an external actor finds this and abuses it, that will be a world of pain. Worse, if someone was specifically trying to target you for some hurt, the ability to send emails they control directly from your personal account?! There is so much damage you could do with that ability..
q-rews 5y ago
So just like any contact form? The API does not expose a “to” field, did you even open the page?
- Aeolun 5y ago
  If the API does not expose a to field, what exactly is the point? Seems like you need to use a template field to modify the ‘to’ field, but that would still require you to pass the template value in the request.
  - mnahkies 5y ago
    It seems like this is aimed at use cases like a contact form hosted on something like GitHub pages - where you're limited to a static site, and assuming you don't want to run your own server side handler. I have one site that is generated by Gatsby that could conceivably use this instead of the php script I currently have setup to handle the contact form.
emailjs 5y ago
This is a misconception.

aaaaaaaaaaab 5y ago

What would be a use case for this? E.g. sending verification emails from the client is a bit hare-brained, as I can just as easily steal the verification link from the dev console…

Rockslide 5y ago
Adding a contact form to a statically generated website - that's what I use it for (all email goes to a single predefined account)
- aaaaaaaaaaab 5y ago
  Why don’t you use a mailto: URL instead?

thunderbong 5y ago

I was really intrigued so I signed up. Essentially, this is a service which connects to different email accounts of your choosing - Yahoo, Outlook, Gmail etc. and then sends email via those. I haven't tested it all the way, but in many scenarios when emails are sent via an application, the server essentially does the same thing, except that, IMHO, it takes a bit more knowhow. In this case, you set up email services under your emailjs account one time and then everything is handled via Javascript on the front end via their servers. Quite nice, come to think of it. Except the privacy aspect, of course! When we set up it up like this on our servers, the only parties that can read it are the recipients, the service provider and us. In this case, emailjs also gets to have a look at the emails.

primitivesuave 5y ago
This is pretty much what makes it an increasingly difficult sell as an application scales up, and untenable for me personally - at some point, something mission critical like emails cannot be in the hands of a third party, let alone in the hands of a client-side library.
- albertgoeswoof 5y ago
  How are you sending emails if not via a 3rd party?
  - primitivesuave 5y ago
    I should clarify that statement to - I don't wish to involve a 3rd party I don't trust (e.g. small startup) in handling transactions with 3rd parties I trust (e.g. Amazon SES, Mailgun, Sendgrid, etc). I don't mean to imply that the proprietors of this service are not fully capable of creating a great system, however I am fairly certain that most decision makers on using something like this would take pause where I did.
    - hirako2000 5y ago
      You are putting a lot of trust in mailgun, sendgrid and Amazon. Beside, when integrity and confidentiality is critical, the solution is crypto signature and encryption. Not the trust in supposedly reputable 3rd parties.

genezeta 5y ago

> not as a service that allows you to send email from Javascript, but rather as a service that allows you to create a predefined set of emails via the dashboard, and then just trigger the emails from the Javascript. This is quite similar to how emails are usually sent via a proprietary server code So... a bold title saying something and then an explanation explicitly saying it was not true.

omarfarooq 5y ago
...is this or is this not triggering email from JS? Your paste is also in context to the extent of abuse that can happen to the connected email services.
- genezeta 5y ago
  The claim in the title is not "use JS to trigger the sending of an email from a server" but "send email directly from JavaScript".
- bellyfullofbac 5y ago
  "Launch nuclear missile directly from JavaScript"...

oefrha 5y ago

On the server side, I suppose you can use this, but it usually makes sense to use a vendor SDK directly rather than rely on and hand user data to yet another middle man that might disappear at any time. I guess bridging personal email providers is an interesting idea, but it doesn’t make sense to use a personal email account when you’re beyond the free tier of a few emails a day anyway. On the client side, unless you want to authorize spam sent from your account to any recipient of an attacker’s choosing, you can only use this service to send emails to fixed recipients, so most use cases of transactional email (e.g. user authentication, notification, marketing) are out of question. Sending emails on behalf of users to yourself on a contact page is the sole use case I can think of, but that market is crowded as is with more focused and less confusing offerings. Any other use cases I missed?

emailjs 5y ago
I think that you have an overestimated opinion about the vendors' SDK, not all of them have acceptable quality, but let's leave it to the discretion of the developers themselves. What is really important for our clients who use the EmailJS service from the back-end is flexibility and freedom of choice. If vendor "X" suddenly stops working for you or if there are any problems, the migration to another vendor will take several days. With the EmailJS service, about 10 minutes: add another service and move your traffic to it. Indeed, someone could copy your code, but they will only be able to send your templates, with your content, and will not be able to send a custom email with their own content (spam). Which is absolutely not interesting for attackers.

thepangolino 5y ago

How is this different from SmtpJS.com ?

junon 5y ago

Send email directly from a commercial SaaS product*

mike_hock 5y ago
Thank god. I thought there was another default security hole in browsers that I'd have to plug or opt out of.

colinclerk 5y ago

Congrats on the launch! There’s a strong shift of devtools from the backend to the frontend, and services are often jumping through hoops to 1) remain secure, and 2) allow client-only integration. For example, Stripe offers a client-only integration with similar limitations - the product catalog must be defined within the stripe dashboard. https://stripe.com/docs/payments/checkout/client https://stripe.com/docs/payments/checkout/client At https://clerk.dev https://clerk.dev (disc: founder), we do all of sign up, sign in, and user profile management from just the client. We’re able to keep it secure because we also do session/cookie management, so can tell who is signed in. Emailjs has an interesting concept here. It’s definitely on-trend, though I personally wouldn’t like users being able to trigger emails to other users, which seems possible today (correct me if I’m wrong?) Have you considered an option to require a signed JWT with requests, which could contain the user’s email address? That would make it so users can only trigger spam to themselves (except in cases of xss), but retain a mostly client-only experience. (Generating the jwt requires a backend, but developers may already have one available if they’re using another service like Hasura that follows a similar pattern.)