The thing is forcing canonical emails is effectively the same except that it is far less user hostile.
No Sam.sam@gmail.com is allowed Sa.msam+123@gmail.com is already registered
Anyway we can do regex next release
إعجابَين (2)
Yeah, but it’s useless in actual practice, which is why we’re having this discussion… once they have nukes, you need nukes too.
“User hostile” is a meaningless concept once your audience has nukes and is willing to use them.
I disagree with this, the solution worked perfectly for @markersocial, and then I reverted the change cause my hand was forced
There are no known gaps with the canonicalization approach I implemented and reverted, it solves the above gmail problem 100%
3 إعجابات
Well, I disagree, because that put the code and effort burden on our side, rather than their side. “Normalizing” emails is quite complicated, varies per email provider, and I don’t want to be in that business.
In other words, let them build and handle the nuclear devices on their own; we don’t need to ship proto-nukes to every country and in every installation of Discourse “just in case”.
(Plus being able to blocklist emails via regex is quite powerful, especially since email = identity in Discourse.)
إعجاب واحد (1)
We could let them normalise with their own regex rules as some sort of middle ground, then we are not in the business of normalisation
That said yes regex blocking or at least wildcard blocking will happen for the next release
6 إعجابات
I can confirm that the previous implementation worked perfectly and entirely solved the gmail issue. The email domain allow list and disallow list both are quite effective nukes. But it’s just not viable to block gmail.
@codinghorror I can see the point of view against normalising for different email providers. But I think it would make sense to be able to cover at least gmail (~43% of all email addresses apparently in 2020, 53% for the US) in a non-destructive way. It might be comparable to supporting oauth from large providers out of the box.
@sam ^ This is a great idea for an alternative. 
Maybe this, with an example for the gmail/googlemail match could be quite user friendly and powerful.
إعجابَين (2)
Have a user right now that has made several thousand accounts with a single gmail address (using periods) and spamming promoting their competing site to siphon off users. Will be upgrading to 2.8 and blocking all emails that contain a period or plus symbol as soon as it’s released. I do wish the previous implementation was available, but appreciate that this is being addressed and a solution will be available. It’s going to make a massive difference, thank you 
إعجاب واحد (1)
So have thought about this a bit and thought of a solution that could maybe make sense.
There could be an admin option to process and store a normalised version of the email (only processing the username part i.e. username@…)
But only apply this for domains that are specified by the admin.
So a list somewhat like the email domain allow/block lists, with two checkboxes per domain:
- Strip + string
- Strip periods
Then use these records as a reference for disallowing additional registrations using alternative versions of that email (without affecting the primary email record, which can still have + and periods).
This way, the burden of selecting which domains to store a normalise record for and how to normalise them can be on the admin only, allowing them to respond to problematic email domains as they emerge.
Anyhow, just dropping this here so it can perhaps be considered at some point.
Cheers.
لقد قمت بدمج طلب السحب:
إنه يضيف إعداد موقع جديد normalize emails والذي سيزيل النقاط والجزء +… من البريد الإلكتروني ثم يتحقق من تفردها. على سبيل المثال، إذا كان هناك مستخدم test+1@gmail.com وحاول test+2@gmail.com التسجيل، فلن يُسمح لهم إذا تم تمكين إعداد الموقع.
7 إعجابات
رائع، أعتقد أن هذا يحل مشكلة @markersocial بنسبة 100% وهو إعداد رائع لتمكينه إذا كنت هدفًا لهذا الهجوم المحدد.
أخبرنا كيف تسير الأمور يا @markersocial
4 إعجابات
شكراً جزيلاً لتنفيذ هذا، إنه انتصار كبير - أنا سعيد جداً بإضافة هذا. لقد قمت بتفعيله بالأمس وأقوم بالمراقبة.
حتى الآن، يبدو أنه يعمل بنسبة 100% كما هو مقصود ويحل هذه المشكلة بالكامل. لا يزال بإمكان الأشخاص التسجيل بفواصل في رسائل البريد الإلكتروني الخاصة بهم (ويفترض أنهم يستخدمون علامة +، لم أر هذه التسجيلات مؤخراً). ولكن لا يمكنهم الاستمرار في إنشاء حسابات بنسخ مختلفة من نفس البريد الإلكتروني. من خلال قراءة المناقشة على GitHub، كان بالتأكيد أفضل خيار للحفاظ على البريد الإلكتروني الأصلي كما هو.
لذلك، مع أخذ ذلك في الاعتبار، سأترك اقتراحات هنا أعتقد أنها ستحسن هذه الميزة دون أن تصبح معقدة للغاية:
بدلاً من وجود مربع اختيار لتمكين/تعطيل تطبيع رسائل البريد الإلكتروني. قم بإنشاء قائمتين، على غرار نمط قائمة حظر نطاقات البريد الإلكتروني.
- قائمة النطاقات لتطبيق تطبيع الفواصل
- قائمة النطاقات لتطبيق تطبيع علامة +
على سبيل المثال:
يقوم المسؤول بإضافة gmail.com إلى كلتا قائمتي تطبيع النطاقات.
e.mai.l+123@gmail → email@gmail.com
يقوم المستخدم بإضافة outlook.com إلى قائمة تطبيع علامة + (فقط):
us.er+123@outlook.com → us.er@outlook.com
تعتبر رسائل البريد الإلكتروني us.er@email.com و user@email.com نفس العنوان/الحساب خاصة ببعض مقدمي الخدمة وليست قياسية حقاً. في حين أن علامة + تبدو قياسية (لأي مزود خدمة يسمح بها).
سيسمح هذا للمسؤولين بتطبيق هذه القواعد بشكل انتقائي على نطاقات البريد الإلكتروني الإشكالية بشكل فردي عند ظهورها بدلاً من تطبيق التطبيع (من كلا النوعين) على جميع نطاقات البريد الإلكتروني.
ليس لدي أي توقعات لما سبق، فقط أترك الاقتراح في حال كان مفيداً.
على أي حال، شكراً مرة أخرى، أنا ممتن جداً لتنفيذ هذا. إنه يغير قواعد اللعبة.
إعجابَين (2)
أتساءل مع ذلك ما إذا كانت هذه مشكلة نظرية مقابل مشكلة في العالم الحقيقي. أفهم الرغبة في الدقة، لكنني أفضل سماع بعض الحالات المحددة التي تسبب فيها هذه المشكلة.
المشكلة في إدخال إعداد كهذا ستكون إعادة تطبيق قواعد التطبيع عند العبث بقائمة السماح بالمواقع، مما يجعلها تغييرًا معقدًا للغاية.
نقوم الآن بالتطبيع بشكل غير مشروط (بغض النظر عن إعداد الموقع) لذا فإن تشغيله فوري وينطبق على السجل بأكمله.
رائع 
كل الشكر لـ @nbianca
4 إعجابات
رائع! لم أدرك أن ذلك سيُطبق بأثر رجعي. كنت أعتقد أنه سيتم حفظ عنوان مُطبع فقط للتسجيلات الجديدة.
نعم، الخطر الرئيسي للمشكلة سيكون في حالات عناوين البريد الإلكتروني التي تسمح بأسماء مستعارة + ولكنها لا تعتبر الفواصل في مواضع مختلفة متماثلة.
يمكن التعامل مع جميع حالات + في رسائل البريد الإلكتروني بنفس الطريقة دون أي مشكلة، حيث يتم التعامل معها بنفس الطريقة لجميع المزودين الذين يسمحون بذلك على حد علمي. الفواصل هي الوحيدة التي يوجد بها بعض الاختلاف بين المزودين.
إذا كنت أتذكر بشكل صحيح، أعتقد أن رسائل البريد الإلكتروني الخاصة بالعمل من Google (باستخدام نطاقات مخصصة) و Yandex و Outlook ستعتبر مواضع الفواصل المختلفة عناوين مختلفة، ولكن لا يزال من الممكن استخدام الأسماء المستعارة +.
لذلك، ستكون الحالات الوحيدة مثل وجود theirs@email.com سيمنع the.irs@email.com من التسجيل (عندما يكون هذان حسابين/عنوانين فريدين بالفعل وفقًا لنطاق/مزود البريد الإلكتروني هذا). وهو ما يجب أن يكون نادرًا جدًا في العالم الحقيقي. 
إعجابَين (2)
تم إغلاق هذا الموضوع تلقائيًا بعد 16 ساعة. لم يعد يُسمح بالردود الجديدة.