المشكلة هي أن فرض عناوين البريد الإلكتروني القياسية يعادل الأمر نفسه تقريبًا، لكنه أقل عدائية تجاه المستخدم بكثير.
لا يُسمح بـ Sam.sam@gmail.com بينما Sa.msam+123@gmail.com مسجل بالفعل.
على أي حال، يمكننا استخدام التعابير النمطية (regex) في الإصدار التالي.
نعم، لكنه غير مفيد في الممارسة الفعلية، وهذا هو السبب في أننا نناقش هذا الأمر. بمجرد أن يمتلكون الأسلحة النووية، ستحتاج إلى أسلحة نووية أيضًا.
“عدائي للمستخدم” هو مفهوم بلا معنى بمجرد أن يكون جمهورك يمتلك أسلحة نووية ومستعدًا لاستخدامها.
أختلف مع هذا الرأي، فقد نجح الحل بشكل مثالي مع @markersocial، ثم قمت بإعادة التغيير لأنني أجبرت على ذلك.
لا توجد ثغرات معروفة في نهج التوحيد القياسي الذي طبقته ثم ألغيته، فهو يحل مشكلة Gmail المذكورة أعلاه بنسبة 100%.
حسناً، أنا أختلف مع ذلك، لأن هذا يضع عبء كتابة الكود والجهد على جانبنا بدلاً من جانبهم. “تطبيع” عناوين البريد الإلكتروني أمر معقد جداً، ويختلف باختلاف مزود الخدمة، ولا أريد الانخراط في هذا المجال.
بعبارة أخرى، دعهم يبنون ويتعاملون مع الأجهزة النووية بأنفسهم؛ فلا داعي لنا لتزويد كل دولة وكل تثبيت من نظام Discourse بـ “بروتو-نوكلية” “فقط في حال”.
(بالإضافة إلى أن القدرة على حجب عناوين البريد الإلكتروني عبر التعبيرات النمطية (regex) أمر قوي جداً، خاصةً لأن البريد الإلكتروني يساوي الهوية في نظام Discourse.)
يمكننا السماح لهم بتطبيع المدخلات باستخدام قواعد التعابير النمطية (regex) الخاصة بهم كحل وسط من نوع ما، وبالتالي لن نكون طرفًا في عملية التطبيع.
ومع ذلك، نعم، سيتم تطبيق حظر التعابير النمطية أو على الأقل حظر الأحرف البدئية (wildcard) في الإصدار القادم.
يمكنني تأكيد أن التنفيذ السابق عمل بشكل مثالي وحل مشكلة Gmail تمامًا. تعد قوائم السماح وقوائم المنع لنطاقات البريد الإلكتروني أسلحة فعالة للغاية. لكن حظر Gmail ببساطة ليس خيارًا عمليًا.
@codinghorror أستطيع فهم وجهة النظر المعارضة لتوحيد تنسيق عناوين البريد الإلكتروني لمختلف مقدمي الخدمات. لكنني أعتقد أنه سيكون من المنطقي تغطية Gmail على الأقل (حوالي 43% من جميع عناوين البريد الإلكتروني في عام 2020، و53% في الولايات المتحدة) بطريقة غير مدمرة. قد يكون هذا قابلًا للمقارنة مع دعم OAuth من مقدمي الخدمات الكبار بشكل افتراضي.
@sam ^ هذه فكرة رائعة كبديل. 
ربما تكون هذه الفكرة، مع تقديم مثال لمطابقة gmail/googlemail، خيارًا وديًا للمستخدم وقويًا في نفس الوقت.
هناك مستخدم حالياً قام بإنشاء آلاف الحسابات باستخدام عنوان بريد إلكتروني واحد من Gmail (باستخدام النقاط) وإرسال رسائل بريد مزعج للترويج لموقع منافس لسحب المستخدمين. سنقوم بالترقية إلى الإصدار 2.8 وحظر جميع عناوين البريد الإلكتروني التي تحتوي على نقطة أو علامة زائد فور صدورها. أتمنى لو كانت النسخة السابقة متاحة، لكنني أقدر أن هذه المشكلة قيد المعالجة وسيتم توفير حل قريباً. هذا سيحدث فرقاً كبيراً، شكراً لك
لقد فكرتُ في هذا الأمر قليلاً ووجدتُ حلاً قد يكون منطقياً.
يمكن إضافة خيار للمسؤول لمعالجة وتخزين نسخة موحدة من البريد الإلكتروني (معالجة جزء اسم المستخدم فقط، أي username@..).
ولكن يُطبَّق هذا فقط على النطاقات التي يحددها المسؤول.
أي قائمة تشبه قوائم السماح/منع نطاقات البريد الإلكتروني، مع مربعي اختيار لكل نطاق:
ثم تُستخدم هذه السجلات كمرجع لمنع تسجيلات إضافية باستخدام نسخ بديلة من ذلك البريد الإلكتروني (دون التأثير على سجل البريد الإلكتروني الأساسي، الذي يمكن أن يظل يحتوي على البادئة + والنقاط).
بهذه الطريقة، تكون مسؤولية اختيار النطاقات التي سيتم تخزين سجل موحد لها وكيفية توحيد هذه السجلات موكلة للمسؤول فقط، مما يسمح له بالاستجابة لنطاقات البريد الإلكتروني المشكلّة كما تظهر.
على أي حال، فقط أضع هذا هنا ليُؤخذ في الاعتبار في وقت ما.
مع أطيب التحيات.
لقد قمت بدمج طلب السحب:
إنه يضيف إعداد موقع جديد normalize emails والذي سيزيل النقاط والجزء +… من البريد الإلكتروني ثم يتحقق من تفردها. على سبيل المثال، إذا كان هناك مستخدم test+1@gmail.com وحاول test+2@gmail.com التسجيل، فلن يُسمح لهم إذا تم تمكين إعداد الموقع.
رائع، أعتقد أن هذا يحل مشكلة @markersocial بنسبة 100% وهو إعداد رائع لتمكينه إذا كنت هدفًا لهذا الهجوم المحدد.
أخبرنا كيف تسير الأمور يا @markersocial
شكراً جزيلاً لتنفيذ هذا، إنه انتصار كبير - أنا سعيد جداً بإضافة هذا. لقد قمت بتفعيله بالأمس وأقوم بالمراقبة.
حتى الآن، يبدو أنه يعمل بنسبة 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 نفس العنوان/الحساب خاصة ببعض مقدمي الخدمة وليست قياسية حقاً. في حين أن علامة + تبدو قياسية (لأي مزود خدمة يسمح بها).
سيسمح هذا للمسؤولين بتطبيق هذه القواعد بشكل انتقائي على نطاقات البريد الإلكتروني الإشكالية بشكل فردي عند ظهورها بدلاً من تطبيق التطبيع (من كلا النوعين) على جميع نطاقات البريد الإلكتروني.
ليس لدي أي توقعات لما سبق، فقط أترك الاقتراح في حال كان مفيداً.
على أي حال، شكراً مرة أخرى، أنا ممتن جداً لتنفيذ هذا. إنه يغير قواعد اللعبة.
أتساءل مع ذلك ما إذا كانت هذه مشكلة نظرية مقابل مشكلة في العالم الحقيقي. أفهم الرغبة في الدقة، لكنني أفضل سماع بعض الحالات المحددة التي تسبب فيها هذه المشكلة.
المشكلة في إدخال إعداد كهذا ستكون إعادة تطبيق قواعد التطبيع عند العبث بقائمة السماح بالمواقع، مما يجعلها تغييرًا معقدًا للغاية.
نقوم الآن بالتطبيع بشكل غير مشروط (بغض النظر عن إعداد الموقع) لذا فإن تشغيله فوري وينطبق على السجل بأكمله.
رائع 
كل الشكر لـ @nbianca
رائع! لم أدرك أن ذلك سيُطبق بأثر رجعي. كنت أعتقد أنه سيتم حفظ عنوان مُطبع فقط للتسجيلات الجديدة.
نعم، الخطر الرئيسي للمشكلة سيكون في حالات عناوين البريد الإلكتروني التي تسمح بأسماء مستعارة + ولكنها لا تعتبر الفواصل في مواضع مختلفة متماثلة.
يمكن التعامل مع جميع حالات + في رسائل البريد الإلكتروني بنفس الطريقة دون أي مشكلة، حيث يتم التعامل معها بنفس الطريقة لجميع المزودين الذين يسمحون بذلك على حد علمي. الفواصل هي الوحيدة التي يوجد بها بعض الاختلاف بين المزودين.
إذا كنت أتذكر بشكل صحيح، أعتقد أن رسائل البريد الإلكتروني الخاصة بالعمل من Google (باستخدام نطاقات مخصصة) و Yandex و Outlook ستعتبر مواضع الفواصل المختلفة عناوين مختلفة، ولكن لا يزال من الممكن استخدام الأسماء المستعارة +.
لذلك، ستكون الحالات الوحيدة مثل وجود theirs@email.com سيمنع the.irs@email.com من التسجيل (عندما يكون هذان حسابين/عنوانين فريدين بالفعل وفقًا لنطاق/مزود البريد الإلكتروني هذا). وهو ما يجب أن يكون نادرًا جدًا في العالم الحقيقي. 
تم إغلاق هذا الموضوع تلقائيًا بعد 16 ساعة. لم يعد يُسمح بالردود الجديدة.