Are all the same email address, spammers can use one gmail address to make unlimited accounts easily.
Blocking an address with wildcards like below I believe would be a good solution: e*x*a*m*p*l*e*@gmail.com
I don’t necessarily think that all registrations using these gmail address variations should be blocked, just that it would be useful that if a gmail address is blocked, all variations are blocked too or that we can manually add a wildcard gmail to the email blacklist.
Yes it’s an actual problem I’m experiencing, I have spammers regularly making tens of thousands of accounts per single gmail account with the dot method and a sufficient pool of IPs.
I’m only seeing the dot trick being used, not 100% sure about if the + method works also. Last I checked it was possible to register using email addresses with + characters, so that trick should work too.
Can make 16,777,216 unique email addresses using the dot method only and essentially unlimited using the + method. Makes it super efficient for spammers. Domain blacklist isn’t viable seeing it’s gmail.
If this was actually implemented with a wildcard-like approach (instead of being handled automatically by Discourse), you’d probably want to be much more specific than e*x*a*m*p*l*e*@gmail.com. Doing it that way could result in blocking innocent people, especially if the spammer’s email address is relatively short. Looking specifically for . and + would probably be much safer.
I don’t understand your math. You can add only a single dot between characters, so each N-character address is good for only 2*n addresses. You could probably have a plugin that saved or compared against the dot-removed address and disallowed +addresses.
@pfaffman - I was just going off the figures given from Gmail Dot Trick Generator which is for every additional character above 2 the amount of addresses is doubled (it freezes at about 8k though).
I think 2*n, if I understand what you mean by this (as in a 26 character address would have 52 combinations?) would be too low. As they can add multiple dots throughout the address.
E.g: constantinehamilton1337x@gmail.com con.stantinehamilton1337.x@gmail.com co.nst.antineh.amilton1.3.37x@gmail.com constantineh.a.m.ilto.n13.37x@gmail.com c.o.nsta.ntinehamil.ton1337x@gmail.com
Anyhow, whatever the exact figure is, it’s a lot. Yeah, your suggested solution would make sense!
أعتقد أن التنفيذ السابق الذي أنشأته لا يزال مفيدًا جدًا كميزة إضافية لمكافحة البريد العشوائي؛ فقد عمل بشكل مذهل خلال الفترة القصيرة التي كانت فيها متاحة ومفعلة (مفعل افتراضيًا).
بخلاف ذلك، لا يزال بإمكان مرسلي البريد العشوائي إنشاء حسابات جماعية باستخدام عنوان Gmail واحد قبل أن يلاحظها مشرف أو مدير. على سبيل المثال: إنشاء الحسابات دون نشر أي شيء فورًا.
سيحتاج المدراء والمشرفون إلى البحث يدويًا عن كل حساب على حدة وفتحه لحظره أو حذفه. وقد يكون هذا أمرًا شاقًا للغاية، خاصةً عندما يتمكن أحد مرسلي البريد العشوائي من إنشاء مئات أو آلاف الحسابات باستخدام عنوان Gmail واحد قبل أن يتم حظره. كما أن البحث عن عناوين البريد الإلكتروني صعب، مثل: j.ohan.2.1@gmail و jo.ha.n21@gmail.
إذا لم يتم اصطيادهم يدويًا، فسيحتفظ مرسلو البريد العشوائي بمخزون كبير من الحسابات للعب لعبة “ضرب الخلد”، بينما يحتاجون فقط إلى استنفاد حساب Gmail واحد للحصول عليها.
@سام، فقط للمتابعة بعد مزيد من الاختبار الميداني، أعتقد أن التنفيذ السابق الذي تم إلغاؤه كان بالتأكيد أكثر فعالية في مواجهة مرسلي البريد المزعج المتحمسين. لا أزال أحصل على عدد كبير من التسجيلات باستخدام هذه الحيل المعتمدة على تمويه عناوين Gmail.
أنا ممتن جدًا لتطبيق الحماية الحالية، التي أثبتت فعاليتها الكبيرة. ومع ذلك، أعتقد أن السماح بإنشاء حسابات غير محدودة باستخدام نفس البريد الإلكتروني حتى يتم ملاحظتها تحديدًا وحظرها يدويًا يمثل ثغرة. هذا يشكل عبئًا إضافيًا على المشرفين (الذين لا يمكنهم رؤية عناوين البريد الإلكتروني للحسابات افتراضيًا ما لم يتم تمكين ذلك، كما أعتقد)، خاصة في غياب أدوات إزالة الحسابات بالجملة (مثل تحديد عدة حسابات من قائمة البحث في الحسابات باستخدام مربعات الاختيار وحظرها/إزالتها جميعًا). وهذا يعني أن المشرف سيضطر للتنقل يدويًا إلى كل حساب على حدة لإزالته/حظره. وهذا أمر صعب بشكل خاص عند البحث عن حسابات تستخدم عناوين بريد إلكتروني مُعدَّلة.
نظرًا لأن التنفيذ السابق كان اختياريًا (مفعلًا افتراضيًا)، وقد تم تطويره بالفعل وعمل كما هو مُتوقع، ثم تم إزالته. يبدو فقط أنه من المؤسف عدم توفره بعد للمجتمعات التي ترغب في استخدامه للحصول على حماية إضافية ضد مرسلي البريد المزعج المتحمسين.
لهذا السبب قلت إنه يجب منع بعض الأحرف تمامًا من عناوين البريد الإلكتروني (اختياريًا). وتحديدًا الأحرف التي تتيح ما يُعرف بـ sub-addressing كما هو موضح في Email address - Wikipedia مثل علامة الزائد (+)، والنقطة (.)، والشرطة (-)، وما إلى ذلك. وباستخدام التعبير النمطي (regex) يمكن منعها حسب الخدمة أيضًا، مثل: “لا يُسمح بأي بريد إلكتروني يحتوي على علامة زائد وينتهي بـ @gmail.com” على سبيل المثال. cc @sam
التنفيذ السابق كان لا يزال يسمح بـ +addressing مع الحفاظ على عنوان واحد قياسي لكل حساب (وهو ما أعتقد أنه ربما أكثر أمانًا).
لذا، يمكنك التسجيل كـ sam+discourse-meta@gmail.com وهو أمر مفيد لقواعد Gmail الداخلية التي تعمل لديك. ولكن بعد ذلك سيتم حظر حسابات جديدة من sam@gmail.com أو sam+1@gmail.com.
لست ضد إضافة قائمة مسموحة، لكنني أعتقد أن فرض العناوين القياسية مفيد جدًا لحالة Gmail ولا يمثل افتراضًا سيئًا.
الأمان ليس هو الهدف الحقيقي هنا. الموقع المعني يحتاج إلى حل أكثر تطرفًا نظرًا لنطاق المشكلة التي يواجهها. طالما أن الأمر اختياري (أضف “نظام حماية البريد الإلكتروني” الخاص بك)، فإنه يبدو آمنًا تمامًا بالنسبة لي، حيث يمكن للمواقع التي تحتاج إلى ذلك اختيار تفعيل وضع القفل الكامل.
لكن ضبط التعبير النمطي (regex) بشكل صحيح أمر مزعج بعض الشيء نظرًا لكل عمليات الهروب المطلوبة. أشعر بالقلق إزاء تقديم خيارات كهذه، لأن احتمالية أن يقوم الأشخاص بكتابة التعبير النمطي بشكل صحيح وبما يتوافق مع النية ضئيلة جدًا. فهم بحاجة إلى تذكر هروب النقاط والعلامة الموجبة.
.*\+.*@gmail\.com
يمكننا على الأرجح استخدام نمط مبسط غير قائم على التعبيرات النمطية يقوم فقط بتوسيع * و?.
إذا تم إعادة إضافة التنفيذ السابق كخيار، فأعتقد أن هذا سيحل مشكلة Gmail بالكامل. على الأقل في حالتي. إنه مثالي جدًا في رأيي ويضيف تكاليف موارد كافية للمحتالين لجعل مكافحتهم قابلة للإدارة. سيكون هذا بالفعل الفرق بين الحاجة إلى إشراف مكثف بدوام كامل لمدة 24 ساعة وعدم الحاجة إليه.
لقد قمت بحظر عدة نطاقات تسمح بممارسات مشابهة وتستخدم قائمة نطاقات البريد الإلكتروني المسموح بها. المشكلة هي أن الأشخاص يمكنهم إنشاء العديد من الحسابات قبل أن يتم حظر/منع أحد حساباتهم (مما ينشط حظر تباديل عنوان Gmail هذا للحسابات الجديدة، لكن الحسابات القائمة تبقى دون تغيير). مما يجعل الأمر عبئًا كبيرًا على الإدارة ومجهدًا لتنظيف كل حساب على حدة لاحقًا.
على سبيل المثال، كان لدي موضوع يحتوي على حوالي 200 رد، باستخدام منشور واحد لكل حساب، وجميعها تم إنشاؤها باستخدام عنوان Gmail واحد. هناك العديد من الحالات المماثلة. هذه أمثلة حيث يسهل العثور على الحسابات، حيث أن البحث عنها عبر تباديل عنوان Gmail الأصلي صعب جدًا كبديل. بعض المحتالين يزرعون أعدادًا كبيرة من الحسابات باستخدام عدد قليل من عناوين Gmail ولا ينشرون فيها إلا بعد أشهر.
بالنسبة للحل باستخدام حجب التعابير النمطية (regex)، فإن حجب علامة الزائد (+) سيكون غير ضار إلى حد كبير، بينما حجب النقاط (.) من المرجح أن يحجب عددًا كبيرًا من عناوين البريد الإلكتروني المشروعة مثل john.smith@gmail.com. حجب العناوين التي تحتوي على أكثر من نقطة واحدة قد يتسبب في أضرار جانبية ضئيلة، رغم أنه سيظل يسمح بعدة تباديل لعنوان Gmail، لكن أقل بكثير مقارنة بـ نقطتين أو أكثر.
في رأيي، التنفيذ السابق هو الأمثل وليس غير معقول لتنفيذه كإجراء حماية اختياري، حيث أن معظم مواقع التواصل الاجتماعي الشهيرة لا تسمح بالتسجيل باستخدام عدة تباديل لـ Gmail بسبب استغلالها بكثافة من قبل المحتالين.
@sam، أشعر بقوة بأنه يجب السماح للمواقع بتنفيذ هذا المستوى الاختياري من تقييد عناوين البريد الإلكتروني باستخدام التعابير النمطية إذا كانت تحتاج إليه. وإلا فإننا سنخالف أحد المبادئ الأساسية لمنصة Discourse، وهو أن تكون “آمنة افتراضيًا”.
يمكننا إنجاز هذا للإصدار القادم، إلا أنني ما زلت أؤمن بتنفيذتي الأصلية، حيث إن التطبيع هو الحل الأكثر ودية لمشغلي المواقع؛ فأنت تفعل خانة واحدة وتنتهي المشكلة. أما مع التعبيرات النمطية، فتتعلم التعبيرات النمطية (مما يستغرق 5 ساعات) وتنتهي بحل يسمح بحسابات البريد العشوائي بالتسلل أو يكون معادياً للمستخدم (بدون نقاط، بدون علامات زائد) أو يكون حل وسط.
ومع ذلك، بالتأكيد يمكننا إدراج دعم التعبيرات النمطية للإصدار القادم.
لا، الأمر سهل حقًا، يكفي أن نقول: «لا يُسمح برسائل البريد الإلكتروني التي تحتوي على علامة زائد أو نقطة»، وهو ما يُعترف به كقيود صارمة جدًا، وبشكل واضح لا نرغب في تفعيله افتراضيًا. لكن الأمر يشبه مسألة «باموار»: سيظل هناك دائمًا عدد كافٍ من الفاعلين الخبيثين مما يفرض وجود زر الإطلاق النووي، حتى لو لم نرغب في استخدامه.
إنه يشبه الحرب النووية. بمجرد وضع القنابل النووية على الطاولة، لم تعد الخيارات «الصديقة للمستخدم» ممكنة بعد الآن، ويصبح عليك فقط أن تأمل في أن لا تحتاج إلى اللجوء إليها في معظم الأوقات.
عذرًا على التأخير في الرد!