Has anyone written a module that will facilitate account activation via an alternative method such as a captcha or some other “real person” identification mechanism?
I’m interested in perhaps allowing users to sign up with an active account as long as they, in some fashion, prove they’re not a bot.
I do still want users to be able to receive email alerts and such, but I don’t want to force activation via the email pipeline and instead use email as a secondary alert service for users if they want them.
Anyone done such a thing or is this something we’d have to build out ourselves?
The thought, so far, is to not force them to verify their email address, but to allow them to use their email to recover their account - but placing the onus on them for having submitted the correct email in the beginning, otherwise their account is lost (or would require support personnel intervention).
Sending anything other than a verification email initially to an account is really bad juju, the user can typo their email address or specify anything with no consequence.
Email verification can’t be disabled, it’s central to Discourse.
Sending anything other than a verification email initially to an account is really bad juju
Regardless of whether it’s bad juju, as @ylluminate said, the onus belongs to the user in this scenario. If they supply a garbage string as an email address, well, they shouldn’t have. If they are made aware of their responsibility in this, then the fault is solely theirs.
Email verification can’t be disabled, it’s central to Discourse.
So are you saying that it absolutely, unequivocally, 110% cannot be disabled? Or that it just shouldn’t be disabled? We’ve already gotten past shouldn’t so we need more specifics about whether or not it can be done. If it cannot, there should be an option to make it so.
Not really, the responsibility is on the site operator to ensure they have the right to send email to an address to begin with, verification is as much for the user as it is the site owner. Not doing so is a surefire way to see your mail relay flagged as a spammer when the wrong mailboxes begin to receive email they didn’t sign up for. There’s no reason for Discourse to engineer in features to make it easier for site operators to do unethical things and facilitate spam.
There are lots of data protection laws and legal precedents which put the responsibility on the site owner to establish the identity and consent of a mailbox owner before they can freely send anything to it.
Pretty much all mail-based communication apart from email verification and password resets can be disabled. The disable email option in /admin is there for tasks such as migration to avoid sending piles of unwanted notifications when bringing across posts, it isn’t intended for live sites and completely breaks the signup process as users will be unable to verify.
@thraddash I think we can implement this. It would make a nice plugin / extension for the system. Some folks may not like it or frown on it as is evident above, but hey, it’s software and we’re welcome to engineer it.
Yes, in my opinion, the system should be such that verification can be demoted to an optional task, not necessarily a mandatory task. Users can always unsubscribe from unwanted emails. If a plugin could be made which facilitates optional email verification instead of mandatory verification, that would be great.
I think you’re missing the point. This is not necessarily about users unsubscribing. It’s about the legitimate owner of an email address being harassed because others provided their email at sign-up, and you didn’t verify that the email was legit, and that it belonged to the user.
Worst case, I (as a hypothetical ill-intentioned person) could sign up an account using a targeted person’s email. Then, play with email notification settings a bit. They’d be getting spammed by every piece of activity on your site.
Worse, I could sign up another account, with a Junk email, and then send targeted spam/bullying as PMs.
Triple fun if I use two targeted emails, and make each think that they are being targeted by the other.
Tracking “evil me” down would be hard, and your forum or organization might end up taking the fall for any legal complications.
Yes, I messed up. I meant any email users can unsubscribe from unwanted emails. I am well aware of the hypothetical scenario which you are proposing and I’m not worried about it. I think optional verification is enough to address this issue, for which @ylluminate proposed a plugin if this is impossible in the vanilla system.
You’re saying that as long as a way to unsubscribe (opt out) is provided it obviates the requirement to have permission to send an email? i.e. subscribing, opting in.
Sounds like it would introduce the risk of having all emails put on a blacklist.
You successfully put together a way to do what you are proposing.
Your site gets put on a blacklist.
Instead of your code, it is Discourse that gets a bad reputation.
This results in a demonstrable loss of Discourse customers.
You are required to compensate for damages.
Not that this would happen. But would you be prepared to do so? In any case, I think it would be extremely unwise to facilitate such a “feature” in Core code.
And that’s the problem, it’s not a hypothetical scenario, particularly not now in 2018.
Earlier this year as the May 25th deadline for GDPR loomed, online publishers all over the world had to reach out to users to re-affirm their handling of email addresses. Nobody could have missed the droves of emails which went out asking users to confirm that email addresses were still current and that future communications were explicitly permitted. This was necessary for any site which hadn’t both verified emails and collected informed consent from the owner of the mailbox for any future communications.
Every online publisher has an obligation now to ensure that they only store accurate personal information, relevant for the processing purpose for which it was provided. Email addresses are the most fundamental piece of PII online, with the potential to expose not just identity in the sense of a name, but gender, age and location. Sites have no right to store an email address which might pertain to someone else.
As administrators, community managers and architects we can’t “not worry about it” - we’re legally obligated to do so. If someone provides an email address we have a responsibility to verify they are the owner, both to protect the sites we operate and the users who visit them.
In addition to various other points, this is just plain false. Sure they can click ‘unsubscribe’. Their email is still in your database, which, as @Mittineague pointed out, is illegal. Also, the abuser who entered it can just turn the emails back on through the bogus account profile. Two or three checkboxes, and they’re right back where they were.
