Sending email directly from the browser without needing a backend server is now possible using SMTP.js. SMTP.js is a JavaScript SMTP client library...
For further actions, you may consider blocking this person and/or reporting abuse
Exposing your SMTP username and password to front-end sounds like a terrible idea. For quick prototyping, maybe. But for production? Your credentials will be used to send spam in no time.
You can create the email form dynamically from a strongly encrypted js script.
That reduces dammatically the risk.
Please I know, nothing is it 100% secure, neither great firms.
True, Thanks
What is strongly encrypted js script? You mean minified?
No, truly obfuscated, look here : Obfuscator.
I am using smtp.js in production without any spams.
But it's still client side code. It still be in memory on user's device. It'll still be in javascript runtime.
Plus, you can easily reverse any obfuscation. Here is one for obfuscator.io:
obf-io.deobfuscate.io/
Yes, indeed...
But all is not lost :-)
Try this : DecryptMe
Hint : before IBM :-)
From PageCrypt
Everyone has their own poison, wouldn't you agree?
For the ones who are afraid to use it client side :
You can create the email form dynamically from a strongly encrypted js script.
That reduces dammatically the risk.
Thanks
Hy Scofield,
Thank you for this post.
I use smtp.js in my work, it's indeed a great library.
In order to prevent spamming, I create the contact form dynamically.
Cool!!
I have a few questions about this librery. I do not think anyone should use this in production. This is maybe a great way to teach your self about e-mail and Javascript.
Issues:
SPF will never be correct. E-mail's will never be delivered on scale. SPF (Sender Policy Framework) is designed to authenticate the sending IP address against the domain used in the email's "From" address. When you send email directly from the client's IP address, it is highly unlikely that this IP will be listed in the SPF record of the sending domain, resulting in SPF validation failure. This makes your emails more likely to be marked as spam or rejected altogether.
IP's get blacklisted and ISP do not clean them. ISPs typically don't proactively remove IPs from blacklists. Once an IP is blacklisted, it requires a manual delisting process, and there is no guarantee of success.
Username and password for an e-mail address in browser. Storing the username and password for an email address in the client-side JavaScript code exposes these credentials to anyone who can inspect the code. This is a major security risk that could lead to unauthorized access to the email account, allowing for a wide range of malicious activities including but not limited to sending spam or phishing emails, reading existing email, and potentially gaining access to other services tied to that email for password recovery.
While this library may have some useful educational purposes, it's important to be aware of the potential drawbacks you highlighted if considering production use cases. There are tradeoffs to evaluate with any email sending approach. Thanks for sharing your thoughtful analysis
I would never use this on the client in prod.
Sending emails isn't easy and neutral. You need to make sure that you're not getting marked as spam, that users are opening your emails, especially your transactional emails, eg password resets. You need to verify email addresses you're sending to, and ensure that you're not repeatedly sending to dead mail boxes.
If you don't do these things, you will get marked as a source of spam, and places like google will send your mails to the spam folder. I can't see how you would do any of this important stuff on the client in any way that wasn't serious.
This is all before you start worrying about SPF or a bunch of other things.
Please, don't use this in the client on prod. There are email sending businesses for a reason. Bootstrap without buying their services, send from your own servers if you're being super cheap, but after you've got a thousand users giving you money, buy a service. Its worth it. imo.
All of this is for educational base only. How you use it is left for each user to determine.
I think spam will be there even with paid service and more sophisticated platforms.
For anyone who know what they are doing they will be able to figure it all out.
Thanks and best regards.
It also needs proper rendering, which is known as full-featured representation of MVP The whole point of using MVP is to see how your product functions in an environment where people would be using it regularly. App Development Company In Kerala This goes on to help create the focus required for a sustainable business model or Process Driven Development (PDD).
I guess you are just trying to push the link, however, I have a better idea on creating simple to advance content that would rank and give visibility through Learnhub
Does this really keep user credential unexposed?
Plus, I cannot access to npm package and unpkg CDN.
Yes, the documentation says so.
According to smtpjs.com/, seems like you need encrypted 'secure token' instead of putting username and password to script visible to client as described in this post.
It was deprecated and going forward, tokens were introduced, I think SMTP does not have good documentation to transition users.
Cool! Great for quick prototyping! 🥳 Thank you! 🙏
If i put the password and username as environment variables, is that good enough?
how does that compares to obfusticating the javascript file?
Thanks