3 ms·
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 mi
by 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 agoI 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.