يبدو أن بعض المرسلي البريد العشوائي الذين تم حظر حسابات Gmail الخاصة بهم ما زالوا يتسللون عبر استخدام تباينات النقاط، رغم حظر النسخة القياسية من بريدهم الإلكتروني.
يبدو أن الحظر لا يزال يعمل، لكن ليس بشكل كامل، إذ ما زلت أرى تطابقات منتظمة مع السجل في السجلات → البريد الإلكتروني المفلتر، لكن ليس لجميع التوليفات. تمكنت هذه المستخدم من إنشاء مئات الحسابات اليوم باستخدام نفس حساب Gmail المحظور.
يبدو أن تباينات النقاط التي يستخدمونها تتراوح بين 6 و14 نقطة، وطول البريد الإلكتروني هو 19 حرفًا (قبل @)، ولا يستخدمون تباينات علامة الجمع (+) (أو أن جميع تلك التباينات محظورة بنجاح).
قد يكون من ذي صلة، أنني قمت بضبط مسافة ليفينشتاين لبريد المرسلي العشوائي على 3 (الافتراضي هو 2). تم تحديث Discourse مؤخرًا من الإصدار 2.6.x إلى 2.7.1 المستقر.
حسناً، لقد نسيت أين توقفنا في هذه النقطة يا @سام، ولكن من المحتمل أن يكون ذلك خطأً، حيث أنك قلت:
هذا يعني أنه إذا تم حظر evil.person+77@gmail.com، فسوف ن proced بحظر evilperson@gmail.com بدلاً من ذلك. ثم عندما يحاول e.v.i.l.person@gmail.com التسلل، سيتم حظره بسبب المطابقة القياسية.
إذًا، ماذا يحدث عندما يقوم sara.hanson@ بشيء فظيع، ويُوقع sarah.anson@ في مرمى النيران؟ الأمر يشبه تمامًا عدم تأكدي من أنه يمكن اعتبار joe98@ وjoe99@ عنواني بريد إلكتروني متطابقين. أعتقد أن هذا يعتمد على عضوية المجتمع وعلى مستوى التقدير اليدوي المستخدم في عملية المطابقة.
أما “العنوان الإضافي” (Plus addressing) فيشير على الأقل إلى مجلد تابع لصندوق بريد نفس عنوان البريد الإلكتروني (بافتراض أن كل ما قبل علامة “+” هو نفسه).
ربما يكون الحل هو منع التسجيل بناءً على نطاق عناوين IP؟ كل هذا يعتمد على مدى تطور المتطفلين. وقد أتينا من مجتمع Let’s Encrypt، حيث يوجد موضوع متابعة هناك يوضح بعض تكتيكات الإزعاج الواسعة النطاق التي تم محاولة تنفيذها. بل إننا شهدنا أشخاصًا قدموا مساعدة تقنية فعلية قبل أن يقوموا بالإزعاج بعد أسابيع.
مثير للاهتمام. لم أكن أدرك أن غوغل بريد يضع هذا التمييز. تعلمت اليوم أكثر من مجرد بضع نقاط جديدة. أتساءل لماذا يفعلون ذلك؟ يبدو أن ذلك سيستهلك مساحة كبيرة. هل عناوين غوغل بريد هي القلق الوحيد هنا؟
أعتقد أننا اتفقنا على: “أنا غير مرتاح للمكان الذي انتهى بنا إليه الأمر، لأنه كابوس للدعم ولن يختفي أبدًا :)”.
أشعر أنه إذا كان موقع ما يمثل ناقلًا للرسائل غير المرغوب فيها، فيجب السماح له بقول “اجعل جميع بريدي الإلكتروني أساسيًا”، ولا أهتم بالسلبيات.
وهذا يعني أن هذين البريد الإلكترونيين سيكون لهما البريد الأساسي samsam@somewhere.com:
sam.sam@somewhere.com
samsam+11@somewhere.com
إذا تم تسجيل sam.sam@somewhere.com، فلن يُسمح بتسجيل samsam+11@somewhere.com بعد ذلك.
كان هذا هو الحل الأصلي الذي قمتُ به، والذي قمتُ في النهاية بإلغائه (على الرغم من أنه كان يستثني جوجل بشكل خاص - وهو ما كان غير قاسٍ بما يكفي في retrospect).
أشعر أنه يجب علينا ببساطة تجاوز هذا الأمر بإضافة إعداد موقع جديد لـ:
“يا إلهي، أنا ناقل ضخم للرسائل غير المرغوب فيها، فعّل وضع التغليف القصدير العملاق”
بشأن الخطأ، يمكن أن تتسلل الأمور بسهولة الآن إذا انتظرت حتى تقوم بالحظر. إنها حاليًا عملية تفاعلية بنسبة 100%.
وهذا يعني أن هذا يعمل بشكل جيد (لا تتردد في الاختبار في وحدة التحكم يا @markersocial):
./launcher enter app
rails c
ScreenedEmail.block('examplemailaddress@gmail.com')
ScreenedEmail.should_block?('e.x.a.m.pl.e.m.ai.lad.dre.ss@gmail.com')
# true
المشكلة هي:
# تم إنشاء مئات الحسابات
ScreenedEmail.block('examplemailaddress@gmail.com')
# لا تزال مئات الحسابات موجودة
أعتقد أن كل هذا يعود إلى رغبة @markersocial في ميزة (الكانونيكي القسري كما قمت بتنفيذها في الأصل) لا يبدو أن أيًا من آلاف عملائنا المستضافين يحتاج إليها.
يمكننا الاستمرار في تحسين الميزة التفاعلية (البحث عن الكانونيكي عند الحظر وإخطار المسؤول بحذف حسابات الضوضاء). ومع ذلك، سأفضل سماع شكاوى متكررة أولاً.
من المؤكد أن الحظر القائم على التعبيرات النمطية (Regex) لن يعمل مع @markersocial، لكنني سعيد لو قام بتأكيد ذلك.
ليس لدي أي دليل تكراري للمشكلة المذكورة في المنشور الأصلي، وأشتبه بشدة في أن حسابات المشكلة تم إنشاؤها قبل إضافة الحظر.
يمكنني تأكيد أن الإصلاح الأصلي عمل بشكل مثالي وحل هذه المشكلة مع عناوين Gmail. سيكون منقذًا للحياة حقًا إذا تم إعادة هذا الوضع الاختياري.
يتعلم المرسِلون للبريد العشوائي باستمرار تقنيات جديدة ولا يزالون ينجحون في خداع لاعبين كبار مثل فيسبوك وإنستغرام وتويتر. هذا يجعل معظم الأماكن الأخرى ‘سهلة’. إنه عمل بدوام كامل للكثيرين منهم، لذا يصبح الأمر في الأساس:
إذا كان قابلاً للاستغلال و (الموارد المطلوبة < الأرباح المحققة)، فسيتم استغلاله.
يمكنهم تجاوز أي إجراء تقريبًا، والأمل الوحيد هو زيادة تكاليف القيام بذلك إلى نقطة لا تكون مربحة ماليًا.
القدرة على إرسال البريد العشوائي بكميات كبيرة باستخدام رسائل بريد إلكتروني/حسابات شبه غير محدودة (قبل الكشف ومنع البريد الإلكتروني الأساسي من قبل مشرف/مدير وإزالة مشاركاتهم يدويًا) فعالة من حيث التكلفة. أكثر من ذلك إذا لم يكن هناك فريق من المراقبين على مدار الساعة طوال أيام الأسبوع.
تستمر تكلفة تجاوز إجراءات مكافحة البريد العشوائي في الانخفاض. مثال واحد هو بروكسيات 4G/5G، حيث يمكن للأشخاص مقابل حوالي 30-50 دولارًا شهريًا الحصول على وصول إلى عناوين IP حقيقية غير محدودة تقريبًا من مزودي خدمة الإنترنت/الشبكات المستقلة الشرعيين التي يتم تدويرها تلقائيًا/يدويًا ويتم مشاركتها من قبل مدن/ولايات بأكملها من المستخدمين الشرعيين من مزودي خدمة الإنترنت الكبار. يتم مشاركة عناوين IP الخاصة بـ 4G/5G من قبل العديد من المستخدمين في نفس الوقت.
إن حظر هذه المزودين/الشبكات المستقلة أو عناوين IP غير مناسب (لا يمكن حظر الجميع الذين يستخدمون Verizon، AT&T، إلخ). عادةً ما يستخدمون عنوان IP مرة واحدة ثم يتخلون عنه. كما أن عناوين IP الفردية المحظورة من هذا ستحظر أيضًا المستخدمين الشرعيين الذين يشاركون عنوان IP هذا بشكل عشوائي. أصبح حظر عناوين IP ممارسة قديمة ببطء (باستثناء شبكات ASNs لشركات الاستضافة المعروفة). يمكنك رؤية طرف الجبل الجليدي على هذه المنتديات:
أعتقد أن مرسلي البريد العشوائي هم مزيج من البوتات التي تم تطويرها يدويًا بالكامل أو جزئيًا والبريد العشوائي اليدوي. مع زيادة حصة Discourse في السوق، والتي تنمو بشكل رائع بوضوح، سأكون مندهشًا إذا لم تصبح هدفًا للبوتات المتاحة تجاريًا.
في كل مرة يبدأ فيها Xrumer في دعم أحدث إصدار من reCAPTCHA، أود القول إن معظم مالكي المواقع على المنتديات القديمة يلاحظون ارتفاعًا كبيرًا في البريد العشوائي بسبب انخفاض تكلفة إرسال البريد العشوائي (لم يعد هناك حاجة لاستخدام واجهة برمجة تطبيقات لحل reCAPTCHA، وهي بالفعل رخيصة جدًا لكل 1000 حل):
http://botmasterlabs.net/buy1/
يمكن للأشخاص بالفعل إنشاء إضافات/سكريبتات خاصة بهم لدعم أي منصة تقريبًا باستخدام Xrumer. ولكن إذا قاموا بدعم Discourse مباشرةً في يوم من الأيام:
لا يمكنني المطالبة بالحياد في هذا، نظرًا لأنني في حاجة مباشرة إلى إجراءات مكافحة البريد العشوائي. تم إنشاء المشاركة الأصلية حول خدعة النقطة في Gmail من قبل شخص آخر في عام 2014، ويبدو أن مستخدم آخر حل هذه المشكلة من خلال طلب الموافقة على أول عدد معين من المشاركات، لذا ربما تكون هناك على الأقل ثلاثة تقارير مستخدم؟
آسف على الخروج عن الموضوع، العودة إلى المسار.
بخصوص الحظر القائم على التعابير النمطية للبريد الإلكتروني، نعم أنت محق. إنه حل جزئي، لكنه ليس مثاليًا للأسباب التالية:
إذا تم حظر جميع عناوين Gmail التي تحتوي على نقطة واحدة أو أكثر قبل @:
سيتم حتمًا حظر مستخدمين حقيقيين شرعيين لـ Gmail لديهم إما نقطة واحدة أو أكثر في بريدهم الإلكتروني، وهو أمر شائع جدًا.
لا يزال بإمكان مرسلي البريد العشوائي إنشاء الكثير من التباينات بنقطة واحدة. على سبيل المثال، الحد الأقصى لطول عنوان Gmail هو 30 حرفًا، على سبيل المثال: 12345678901234567890123456789.0@gmail.com سيكون لديه 30 تركيبة قابلة للاستخدام بنقطة واحدة.
حظر جميع عناوين Gmail التي تحتوي على نقطتين أو أكثر قبل @:
يتم حظر عدد أقل من عناوين Gmail الشرعية، لكنه لا يزال سيحظر مستخدمين شرعيين لـ Gmail لديهم أكثر من نقطة واحدة في بريدهم الإلكتروني.
يمكن لمرسلي البريد العشوائي إنشاء الكثير من التباينات أكثر مع عنوان Gmail واحد بطول 30 حرفًا. أعتقد حوالي 842 تركيبة أو نحو ذلك.
يمكنني تأكيد أن الحسابات الجديدة ظهرت بعد تفعيل الحظر، حيث أن تاريخ إنشاء الحظر هو 1 فبراير. كنت أراقب إنشاء حسابات جديدة أمس بينما كنت أرى كلا الحالتين لقاعدة الحظر حيث كان هناك تطابقات جديدة حديثة بالإضافة إلى تسجيلات جديدة تدخل باستخدام تباينات نفس البريد الإلكتروني (النقاط فقط).
لقد قمت بتعطيل التسجيلات طوال الليل وأعدت تفعيلها هذا الصباح. لقد قاموا بإنشاء 104 حسابات جديدة حتى الآن اليوم مع تباديل ذلك العنوان Gmail ويستمرون في تسجيل المزيد. يمكنني تأكيد أنه بمجرد إزالة النقاط من عناوين البريد الإلكتروني لهذه الحسابات، يكون هناك تطابق تام مع سجل البريد الإلكتروني المحظور في Screened Emails.
لقد حاولت اختبار الحظر في rails c كما هو موصوف، وهنا يصبح الأمر غريبًا بعض الشيء.
يبدو إذن أن بعض السجلات تعيد ‘true’ كما هو مقصود، وبعضها يعيد ‘false’ حتى لو كان البريد الإلكتروني المختبر مطابقًا تمامًا للبريد الإلكتروني الأساسي المحظور. بالنسبة للسجلات التي تعيد ‘true’، عملت تمامًا كما هو مقصود وعادت ‘true’ لجميع التباينات التي اختبرتها. لكن البريد الإلكتروني الذي يعيد ‘false’، جميع التباينات التي اختبرتها أعادت ‘false’ أيضًا.
كنت أحاول العثور على أي ارتباطات. يمكنني تأكيد أن هذه غير مرتبطة (أو على الأقل ليست مرتبطة بشكل متسق):
طول البريد الإلكتروني (قبل @)
البريد الإلكتروني الذي يحتوي على أحرف وأرقام
التطابقات (عدد مرات الحظر)
تاريخ التطابق
يبدو أن هناك ارتباطًا بتاريخ إنشاء الحظر، حيث أن الأقدم أقل عرضة للعمل (يعيد ‘false’). السجلات التي تم إنشاؤها قبل 9 أيام عادت بمزيج من ‘true’/‘false’، وجميع السجلات التي اختبرتها حتى الآن والتي تم إنشاؤها قبل ذلك (من 1 ساعة إلى 8 أيام) تعيد ‘true’.
ربما يمكن أن يكون ذلك مرتبطًا بـ ‘أقصى عمر للبريد الإلكتروني غير المطابق’؟ أعتقد أن هذا الخيار جديد إلى حد ما، وقد قمت بتعيينه على القيمة الافتراضية وهي 365 يومًا.
حسنًا، إذا تمكّنتم من تقديم خطوات تكرار مفصلة لخطأ ما، فسنقوم بإصلاحه بالتأكيد.
max age unmatched emails ليس إعدادًا جديدًا — فإلى جانب max age unmatched ips، يُعدّ هذان الخياران أداة لتنظيف الإدخالات القديمة جدًا في قوائم عناوين IP والبريد الإلكتروني التي تم فحصها، وهي الإدخالات التي لم تتطابق مع أي شيء خلال عام.
أفهم ما تقصده، وأعتقد أن اعتراضًا رئيسيًا لدى @codinghorror بشأن التنفيذ الأصلي كان أننا كنا نحمل منطقًا خاصًا بـ Google. وهذا جعل جيف غير مرتاح إلى حد كبير.
أعتقد أن تحسين فكرة “كل شيء يُحوّل إلى صيغة قياسية، بغض النظر عن النطاق” يخفف من هذا القلق إلى حد ما.
على سبيل المثال:
sam+982@sam.com → يُسمح بالتسجيل… أولًا sam@sam.com s.a.m.@sam.com → غير مسموح بالتسجيل… في المرة الثانية لاحظت sam@sam.com وأن الصيغة القياسية مسجلة بالفعل.
قد يعود هذا الوضع في يوم من الأيام، فنحن فقط بحاجة إلى اكتشاف سوء الاستخدام هذا في مكان آخر. في المرة الأخيرة التي قمت فيها بالتحقيق، لم نصادف هذا النوع من سوء الاستخدام في استضافتنا.
لدي وقت قصير فقط للنشر اليوم، لكنني أردت مشاركة بعض المعلومات الإضافية قبل الرد بشكل أكثر تفصيلاً.
لقد وجدت أن حذف سجل يعيد قيمة false من السجلات → البريد الإلكتروني المفلتر (السماح)، ثم حظر البريد الإلكتروني مرة أخرى (عن طريق حذف المستخدم + حظره في صفحة إدارة المستخدم) جعل قاعدة فشلت سابقًا تعود بقيمة true بشكل متسق الآن للمطابقة المباشرة والتباينات.
يبدو أن هذا يتوافق مع ملاحظة أن المشكلة تتعلق بالسجلات الأقدم. سأحتاج إلى إجراء المزيد من الاختبارات.
يبدو أن ذلك سيستهلك مساحة كبيرة. هل عناوين غوغل بريد هي القلق الوحيد هنا؟
