-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Send out magic links #2
Comments
As discussed, sendmail should send always html message. Please make sure that when feeding message to the sendmail client the message is in html form. For example, |
Will do something like
|
This is probably none of my business but I feel very strongly about mail being plain-text (or at least multipart with a plain text) so I can't resist to say that I feel sending html-only mails is a bad idea. Feel free to ignore ;) |
The mail is multipart , we could include both plaintext and html. html by default will be shown though in the 'modern' mail clients ;) . @dirkroorda , as long as the sending function gets pure html text, it should work fine. As suggested by @proycon , you can include the plain text version as well. The mail function can contain both plain and html. |
@proycon These mails are used to send a clickable link, and after the click they can discard the mail. Just curious: what users would have a disadvantage if they would receive an html only link? |
It's primarily a matter of principle regarding security/privacy. HTML mails with links and images are often used to obfuscate trackers or even malicious links (phishing etc). HTML mails very rarely have much added value compared to plain text (exception are cases where rich media/formatting is essential, but that is seldom the case), they add a huge amount of complexity. Don't get me wrong, I think it's fine to send out both html and plain/text, that way each users gets what he/she prefers, just don't force html upon users. Plain-text may be boring and lacking many features, but its simplicity has advantages. Parsing and rendering is much easier everywhere (though clients will have to do url detection and make them 'clickable'), albeit limited. |
Then my question is: Suppose user N follows a principled approach, and has an email client that does not render HTML. Will N be disadvantaged if we send him an HTML only link? Are there email clients that do not support html mail? The other question is: maybe every major email client will make a link in a plain text email clickable. If the latter is the case, then the principle of minimalism steers us into sending plain text mails. |
I should have read this first: https://useplaintext.email |
Ha right, very good resource indeed, that explains it way better than I can and I fully agree with what they say there.
I doubt you'll encounter many users/mail clients that can't render HTML mail. I'm that principled user from your use-case, but even my neomutt can (by calling an external tool like w3m to convert html to text) visualize it fine for me. In worst case you can always open it in a browser. So I wouldn't be disadvantaged functionally, only in my principled sensibilities perhaps ;) |
When inviting users that are not yet known to the system, a magic link will be sent to such a user by email.
This link contains a secret that is stored in the user table.
Somehow the possession of the link should enable a new user, after registering, to fulfill a certain role.
I imagine that the user table will have entries without user details but with the token in a magic link.
When a user registers and presents the token, his details will be stored in the record that contains the magic link.
in this way, admins and editors can put non-existing users already in particular roles.
The text was updated successfully, but these errors were encountered: