> 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.
...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.
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.
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.
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.
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.
the EmailJS service is not a mail agent. It is not suitable for corporate correspondence; that is not its purpose. However, you can use the service to initiate the conversation.
Thanks for your feedback! In fact, there is no way we can prove to you that the content of the emails does not interest us. Over time, trust in our service will increase.
>you set up email services under your emailjs account one time
Do they ask for your email account password? It should really be a token authorization but I doubt personal email providers allow this sharing use case.
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
At 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.)
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?
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.
> 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).
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.
> 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.
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..
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.
So... a bold title saying something and then an explanation explicitly saying it was not true.