Protecting against gmail dot trick in Discourse

لا أدري يا @sam، يبدو لي أن الأمر يتطلب إضافة مكون CAPTCHA لإنشاء المستخدمين؟ لا أشعر أن “منع النقاط والعلامات الزائدة” يعالج المرض الجذري، بل إنه يتعامل فقط مع أعراض المشكلة؟ :thinking:

تاريخيًا، كان الاتجاه نحو زيادة نسبة المرسلين المزعجين البشريين بنسبة 100% مع مرور الوقت. أعني أنهم يملؤون ملفات المستخدمين ويرفعون صورًا للملف الشخصي، وكل شيء. لم يكن المرسلون المزعجون الآليون (باستثناء bamwar) مشكلة كبيرة في Discourse لأننا صعبون جدًا في الأتمتة كوننا تطبيقًا يعتمد كليًا على JavaScript. لاحظ أن معظم تعليقاتك يا @neounix تقع ضمن الفئة الموصوفة في جملتي السابقة — فمن الصعب جدًا برمجة موقعنا لأننا معقدون للغاية مقارنة بموقع HTML 1.0 من حقبة عام 1999. رفع مستوى الصعوبة بهذا القدر يلغي معظم المشكلة، بناءً على ما لاحظناه مع عملائنا وهنا في meta.

على أي حال، باختصار: لست بالضرورة معارضًا لإعداد بسيط مثل “منع أحرف معينة في عناوين البريد الإلكتروني”، لكن في أعماقي لا أعتقد أن أي شيء باستثناء CAPTCHA سيساعد كثيرًا في هذه الحالة؟ يمكننا القيام بكليهما؟

5 إعجابات

لكن بعض المستخدمين (بما في ذلك أنا) يستخدمون علامة (+) لفرز رسائل البريد الإلكتروني فعليًا في عميل البريد الإلكتروني الخاص بهم.

3 إعجابات

لا تقلق، لن يكون هذا مفعّلاً افتراضيًا، بل هو وضع “قفل الهجوم” عبر إعدادات الموقع.

7 إعجابات

@neounix أسطوري. شكرًا على النصائح، نقدرها كثيرًا — لقد دفعتني في رحلة مطاردة للرسائل المزعجة. قمت بتفعيل وضع “أنا تحت الهجوم” في Cloudflare مؤقتًا (وهو ما أوقف عمليات التسجيل الخاصة بهم — كانوا ينشئون حسابًا جديدًا كل دقيقة إلى دقيقتين)، ثم تفحصت سجلات جدار الحماية في Cloudflare لعناوين IP كانوا يستخدمونها، ولاحظت أن كل زائر يتم تحديّه أو تسجيله. وكانوا يستخدمون بالفعل نفس useragent بشكل متطابق.

أضفت قاعدة جدار حماية لتحدي المستخدمين الذين يحملون ذلك الـ useragent، وقمت بإيقاف وضع “أنا تحت الهجوم” في Cloudflare. لا أعتقد أن العديد من المستخدمين الأبرياء قد تم تحديهم بهذه الطريقة، وقد أوقفت تمامًا عمليات التسجيل المزعجة الخاصة بهم.

ثم اكتشفت ميزة حظر رقم النظام المستقل (ASN) التي يوفرها Cloudflare، وقمت بإعداد قواعد جدار حماية إضافية لحظر عدد كبير منهم، مع الاستناد إلى سجلات حظر الـ useragent. بالتأكيد هناك حلول بديلة لهذا، وأنا متأكد من أنك تعرفها، لكنها تتطلب منهم تكلفة موارد وجهد إضافيين.

:content:

@codinghorror أتفق معك في أن كابتشا (CAPTCHA) ستكون مفيدة. أعتقد أن الهدف الجيد لمنع الرسائل المزعجة بشكل أساسي هو زيادة التكاليف الإجمالية للموارد المطلوبة من قبل مرسلي الرسائل المزعجة.

ستساهم كابتشا في ذلك. حوالي 2 دولار تقريبًا لكل ألف حل لكابتشا (باستخدام واجهة برمجة تطبيقات لحل الكابتشا مثل https://anti-captcha.com). بالإضافة إلى التعقيدات الإضافية المطلوبة لبرامج الروبوت الخاصة بهم.

ملاحظة جانبية: توفر Anti-captcha إضافة متصفح لحل الكابتشا تلقائيًا، وهي تعمل بشكل جيد وتعتبر رفاهية ممتعة. :goodnews:

عناوين البريد الإلكتروني عادة ما تكون تكلفة موارد أخرى لإنشاء الحسابات بالجملة. لكن هذا لا ينطبق عندما يتمكن مستخدم واحد من إنشاء عدد غير محدود عمليًا من الحسابات باستخدام عنوان Gmail واحد. تكلفة إنشاء 1000 حساب Gmail مرتفعة جدًا، لذا غالبًا ما يلجأون إلى مزودين آخرين أقل صرامة أو نطاقات catchall. ومع ذلك، فإن هذا لا يزال يكلفهم موارد، كما يسهل تحديد هذه الحسابات على أنها رسائل مزعجة.

أعتقد أن الأمر حقًا يتعلق بأن “المزيد هو المزيد”. لا توجد دفاعية واحدة ستكون قوية بما يكفي، بل إن زيادة كمية الموارد والجهد المطلوب من مرسلي الرسائل المزعجة بشكل عام هي خطوات في الاتجاه الصحيح. في أفضل السيناريوهات، يكون من أكثر جهدًا على مرسلي الرسائل المزعجة إرسال رسائل مزعجة إلى منتديات Discourse مقارنةً بما يتطلبه الأمر من المشرفين لحظرها وإزالة أي شيء يتسلل إليها بشكل جماعي.

@itsbhanusharma أعجبني حقًا إمكانية استخدام علامة +، لكن هذا هو السبب في أننا لا نستطيع الحصول على أشياء لطيفة ههه. سيكون من الجيد وجود خيار لتمكين حظرها إذا لزم الأمر لمكافحة مرسلي الرسائل المزعجة.

إعجابَين (2)

بعد التفكير في الأمر، أميل إلى الموافقة معك في هذا الشأن.. @sam هل يمكننا إعطاء أولوية لإعداد قفل البريد الإلكتروني هذا للأسبوع القادم؟

5 إعجابات

تمت مناقشة هذه المسألة إلى حد كبير أعلاه، في هذا الموضوع نفسه.
من المرجح أن “منع” استخدام النقاط والعلامة + سيسبب بعض المشاكل (على الأقل لبعض المستخدمين). كانت الفكرة هي تخزين نسخة “قياسية” من البريد الإلكتروني (نسخة “منقّحة”)، ومنع تسجيل مستخدمين إضافيين يحملون نفس النسخة القياسية لبريد Gmail (وهو في الواقع نفس البريد الإلكتروني تمامًا، بفضل حيل Gmail).

قد يكون هذا هو ما يقصده سام عندما يقول:

ربما يكون هذا ما تقصده أيضًا أنت @codinghorror، وليس حقًا “منع” استخدام . و +.
لكنني أتفق معك في أن هذا لن “يحل” المشكلة إلا لبريد Gmail (وليس على سبيل المثال استخدام عنوان “Catch-all” مع نطاق معين).

هل سيحل كابتشا (CAPTCHA) أي شيء حقًا عندما تقول بنفسك:

[quote=“codinghorror, post:61, topic:22627”]
كان الاتجاه نحو منتشرين بشريين بنسبة 100% مع مرور الوقت. أعني أنهم يملؤون ملفات المستخدمين، ويحمّلون صورًا للملف الشخصي، وكل شيء
[/quote]؟

يبدو أننا قد أغفلنا خطوة ما.

فرض استخدام البريد الإلكتروني الأساسي قد يكون إشكاليًا، لكن منع أكثر من حساب واحد لكل بريد إلكتروني أساسي بشكل افتراضي يعتبر معقولًا إلى حد كبير.

معظمنا يمتلك أكثر من عنوان بريد إلكتروني إذا احتجنا إلى حساب اختباري. ولن يخلق ذلك مشكلة كبيرة هناك، خاصةً إذا كان الإعداد افتراضيًا، فلا نحتاج حينها إلى توعية المستخدمين بتفعيله بعد وقوع إساءة الاستخدام.

إعجاب واحد (1)

يمكن التعامل مع علامات الزائد (+) في رسائل البريد الإلكتروني إلى حد كبير بنفس الطريقة عبر جميع نطاقات البريد الإلكتروني، وأعتقد أن ذلك لن يسبب مشاكل كبيرة.

بالنسبة لبريد إلكتروني مثل sp.a.mmer.king@gmail.com أو s.pa.mmerking@gmail.com، في حالة Gmail، فإنهما يعتبران نفس البريد الإلكتروني. لكن بالنسبة لبعض مزودي الخدمة الآخرين، قد لا يكون الأمر كذلك، وقد يُعتبر كل بريد منهما مستخدمًا فريدًا.


أعتقد أن التنفيذ الجيد على المدى الطويل سيكون شبيهًا بميزة قائمة النطاقات السوداء لبريد الإلكتروني.

إضافة نطاق مخصص ترغب في منع حيل التسجيل المكرر معه. ثم السماح بتفعيل أو تعطيل منع هذين النوعين من التسجيلات المكررة بشكل منفصل. أي: منع تكرار التسجيل باستخدام حيلة الزائد (+) كخيار منفصل، ومنع تكرار التسجيل باستخدام حيلة النقطة (.) كخيار منفصل.

يتم تخزين البريد الإلكتروني المسجل كما هو (من حيث تسجيل دخول المستخدم والعنوان الذي تُرسل إليه الرسائل)، مع منع أي تسجيلات إضافية يُحدد أنها لنفس البريد الإلكتروني.

شيء آخر قد يجعل الحل أكثر فعالية قليلاً هو وضع عدة نطاقات في سجل نطاق مخصص واحد، بحيث تُعامل كنطاق واحد. على سبيل المثال: gmail.com وgooglemail.com. وبالتالي، قد يتم منع شخص ما من التسجيل مرتين باستخدام مثلاً example@gmail.com وexample@googlemail.com. هناك بعض المزودين الآخرين الذين لديهم نطاقات متعددة قابلة للتبادل، وقد أرسلت بعض الأمثلة إلى سام. قد يضيف هذا القليل من الحماية الإضافية، ولكن بشكل عام، المشكلة الرئيسية القابلة للاستغلال هي التسجيلات باستخدام حيل الزائد والنقطة.


بديلًا عن ذلك، قد يكون التنفيذ الأبسط مشابهًا لما سبق، ولكن الخيارات المتاحة لكل نطاق بريد إلكتروني مخصص ستكون منع جميع التسجيلات التي تحتوي على علامات زائد (+) و/أو نقاط. إذا سجل مستخدم بريده الإلكتروني باستخدام ذلك النطاق مع وجود علامة زائد أو نقطة، فسيظهر له خطأ يطلب منه إزالة النقاط و/أو علامات الزائد من بريده الإلكتروني (وربما يتم ذلك تلقائيًا له) والمحاولة مرة أخرى. هذا الحل ليس مثاليًا، لكنه سيكون فعالًا جدًا.

صحيح، وهذا هو السبب في أننا سنقوم بتبسيط البريد الإلكتروني إلى الصيغة القياسية (canonical) لضمان عدم تكرار المستخدمين. تم تغطية ذلك أعلاه. ومع ذلك، لا يمكننا تخزين البريد الإلكتروني القياسي كعنوان بريدهم الإلكتروني لأنه ليس العنوان الذي قدموه.

قوائم الحجب للنطاقات موجودة بالفعل، لكننا لا يمكننا افتراض أنه بمجرد إمكانية الوصول إلى مستخدم عبر عنوان Googlemail أو Gmail، يجب رفض أحدهما أو الآخر. ومن هنا نعود إلى الإشارة إلى “البريد الرئيسي” القياسي.

هناك مواقع اليوم يستخدم فيها المستخدمون بشكل شرعي تمامًا ميزة العناوين مع علامة الجمع (+) والنقاط. الهدف ليس إزعاج الممارسات المشروعة، بل فقط الحد من الآثار الجانبية غير المعقولة مثل وجود مستخدمين لعنوان قياسي واحد.

إذا كان مطلوبًا توفير البريد الإلكتروني بعد إزالة النقاط وعلامة الزائد أثناء عملية التسجيل، من جانب العميل وبموافقة المستخدم (شبه التحقق من صحة النموذج)، فإن تخزينه كبريد إلكتروني للحساب سيكون مقبولاً.

ليس هذا الحل مثاليًا أو كاملاً، لكنه قد يكون أبسط وربما يستحق المفاضلة في بعض الحالات حيث يكون الخيار بين إزعاج عدد قليل من المستخدمين أو إزعاج منتدى بأكمله بسبب البريد المزعج.

هناك حسابات Gmail يكون فيها البريد الإلكتروني القياسي الأساسي يحتوي على نقاط. هؤلاء هم المستخدمون الأكثر تأثرًا وإرباكًا بسبب الإزالة القسرية للنقاط أثناء التسجيل.

لا أعتقد أن هذا سيكون أفضل تنفيذ، وبالتأكيد لن يكون الخيار الافتراضي الملائم.

صحيح، ما قصدته هو وجود قائمة خيارات مشابهة لقائمة حظر نطاقات البريد الإلكتروني الموجودة بالفعل، لإدخال النطاقات التي يجب أن تتأثر، والمعايير التي يجب استخدامها أو عدم استخدامها لتحديد ما إذا كان عنوان البريد الإلكتروني فريدًا أم قياسيًا، كما يُناقش في هذا الموضوع. وربما أيضًا تحديد النطاقات التي يجب اعتبارها نفس المضيف، مثل gmail و googlemail.

بخصوص gmail و googlemail، أعتقد أننا متفقان. وكذلك الأمر فيما يتعلق بالنقاط وعلامات الزائد.

باختصار، اسمح بالتسجيل الأول للمرور، لكن لا تسمح للمستخدم بإنشاء حسابات متعددة باستخدام نفس البريد الإلكتروني. أو على الأقل قلل ذلك إلى الحد المعقول.

john@googlemail.com يسجل أولاً → يُقبل
john@gmail.com يسجل لاحقًا → يُرفض

matthew+{randomstring}@gmail.com يسجل أولاً → يُقبل
matthew@gmail.com يسجل لاحقًا → يُرفض
matthew@googlemail.com يسجل لاحقًا → يُرفض
m.att.he.w@gmail.com يسجل لاحقًا → يُرفض
matthew+{randomstring}@gmail.com يسجل لاحقًا → يُرفض
m.a.tt.ew+{randomstring}@googlemail.com يسجل لاحقًا → يُرفض

مسألة googlemail مقابل gmail (وغيرها من مقدمي الخدمة الذين لديهم نطاقات بديلة متعددة) أقل أهمية بكثير من مشاكل النقاط وعلامات الزائد في العناوين. ومع ذلك، سيكون من الجيد معالجة هذه الحالات أيضًا.

هذا تغيير معادي للمستخدم تمامًا وغير ضروري. السبب في وجود هذه الميزات من الأساس هو تحديد مصدر البريد الإلكتروني. إذا سجلت باستخدام عنوان البريد الإلكتروني stephen+meta@gmail.com، يمكنني تكوين قاعدة تسمح بتوسيم أي بريد إلكتروني يُرسل إلى ذلك العنوان. إذا تم اختراق خدمة Meta ووصلت رسائل غير مرغوب فيها إلى عنوان بريدي عبر هذا الاسم المستعار، فسأعرف حينها مكان حدوث الاختراق. تقييد طريقة استخدامي للبريد الإلكتروني ليس الحل؛ فاختصار عنوان بريدي الإلكتروني إلى نسخة قياسية للمقارنة يحقق نفس النتيجة النهائية دون إحداث أي إزعاج للمستخدم.

صحيح، وهذا مرتبط بمفهوم العنوان القياسي. إذا تم تنفيذ الميزة كما نوقش في الأصل، فسنستفيد حقًا من القدرة على ربط النطاقات. سيتم مقارنة كل تبديل للنقطة وعلامة الزائد وكل اختلاف في النطاق بـ “البريد الإلكتروني الحقيقي الوحيد” لذلك صندوق البريد دون التسبب في أي احتكاك.

طالما أننا لا نخلق أي متاعب للمستخدمين، فلا يوجد سبب يمنع إطلاق هذه الميزة افتراضيًا.

أتفق، الحل غير المثالي = غير مثالي. لقد ذكرت ذلك فقط كبديل قد يكون أسهل في التنفيذ. هذا هو الجزء الأخير من منشوري، عُرض كبديل للاقتراحات الأساسية التي أدليت بها، والتي تتفق مع الكثير من النقاشات في هذا الموضوع، بالإضافة إلى السماح بعلامات ‘+’ والنقاط، لكن ليس بحسابات مكررة.

مع ذلك، فإن المستخدمين الشرعيين الذين يستخدمون ‘+’ في عناوين البريد الإلكتروني على المنتديات/المواقع غير التقنية يُعد عمومًا حالة هامشية مما رأيته.

يبدو حقًا رائعًا. :content:

كان منشوري يركز بشكل أساسي على كيفية حساب العناوين القياسية لنطاقات بريد إلكتروني مختلفة. لذا فهو لا يقتصر على الاستخدام مع Gmail/GoogleMail فقط. كنت أحاول في الأساس القول إنه يمكن أن يكون تنفيذًا جيدًا على المدى الطويل توفير خيارات للمستخدمين حول كيفية حساب العناوين القياسية على أساس كل نطاق على حدة.

بعض الموردين الآخرين يسمحون بـ ‘+’ لكن لا يسمحون بتبديلات النقاط، على سبيل المثال. مما يعني أن تبديلات النقاط تعتبر عناوين بريد إلكتروني فريدة.

ومع ذلك، فإن التنفيذ المخصص لـ Gmail/GoogleMail فقط سيكون رائعًا، ولا أرى أي أسباب تمنع إطلاقه افتراضيًا أيضًا.

هل يمكنك تقديم مثال على ذلك؟ أسأل لأن غالبية مستخدمي Gmail غير مدركين لحيلة النقطة. فقد قاموا بالتسجيل بعنوان يحتوي على النقطة، ويعطون الجميع هذا الإصدار من بريدهم الإلكتروني، وسيصبحون مرتبكين للغاية إذا أُخبروا بأن “بريدهم الإلكتروني” غير صالح.

نادراً ما أصادف أشخاصاً يدركون حتى أن اسمهم المستعار بدون النقاط سيصل إليهم.

إعجاب واحد (1)

بالتأكيد، سأرسل لك مثالاً الآن عبر الرسائل الخاصة كما أرسلته إلى سام. فقط لأنني لست متأكداً مما إذا كان من الجيد نشر هذا علناً في موضوع بهذا العنوان، حيث يبدو أن الكثير من المرسلي الرسائل المزعجة لا يزالون لا يعرفون عنه لحسن الحظ.

نعم، أتفق، سيكون هذا هو الارتباك الرئيسي للمستخدمين العاديين مع هذا الحل غير المثالي.

لا يوجد أي احتمال لنخوض في نهج معقد كهذا. لن نقوم بـ “تطبيع” عناوين البريد الإلكتروني.

إما أنك في وضع قفل البريد الإلكتروني، والذي يمنع تمامًا بعض الأحرف المشكلة في عنوان البريد الإلكتروني (حسب نطاق البريد الإلكتروني الثابت مسبقًا، وربما) أو أنك لست كذلك.

هذا كل شيء. مفتاح تبديل منطقي. وضع قفل البريد الإلكتروني، نعم/لا؟

3 إعجابات

لـ:

تم إكمال هذا الآن.

استخدم إعداد الموقع enforce_canonical_emails (الافتراضي: false) لتمكين هذه الحماية.

بمجرد تفعيله، سنمنع التسجيلات المكررة للأشخاص الذين يستخدمون حيلة . في googlemail.com وgmail.com وحيلة + على نطاق عالمي.

الإصلاح آمن جدًا ولا يؤثر على الإطلاق عند إخراجه من الصندوق وهو معطل.

أحد الآثار الجانبية للتنفيذ هو مرور حساب مكرر واحد إضافي بمجرد تفعيل الإعداد، حيث أننا لا نخزن عناوين البريد الإلكتروني بالصيغة القياسية في جدول بريد المستخدمين إلا إذا قمت بتفعيل الإعداد. وهذا مقبول تمامًا في رأيي، لأنني عمومًا غير قادر على العثور على حالات لهذا النوع الدقيق من الإساءة عبر عدد كبير من المواقع التي نضيفها.

8 إعجابات

إن تخزين الشكل القياسي على الإطلاق أمر مشكل. ما هي الصيغة التي يتخذونها؟

المواصفات موجودة هنا:

إذا لم تكن إعدادات الموقع مفعلة، فلا يحدث شيء… صفر، لا شيء.

5 إعجابات

شكرًا لك على كلماتك الطيبة @markersocial

عذرًا عن التأخر في الرد، كنت مشغولًا بمهام أخرى… أحاول الآن اللحاق بالأعمال المتعلقة بالبيانات الوصفية (meta):

كشف البريد المزعج، والتسجيلات الوهمية، وهجمات حجب الخدمة الموزعة (DDOS)، والاختراقات، والوعي الظرفي في الفضاء السيبراني بشكل عام، بالإضافة إلى جميع الفئات المماثلة من مشاكل الأمن السيبراني التي تركز على الكشف ودمج البيانات من مستشعرات متعددة، هي من مواضيعي المفضلة، كما يبدو أنك تعرف ذلك :slight_smile:

وبما أنني كنت في الخطوط الأمامية وشاركت في العديد من المعارك السيبرانية “عمليًا” في الوقت الفعلي، دعني أعطيكِ تلميحَين إضافيين عند التعرض لهجوم كهذا:

(1) الكشف غالبًا ما يكون فنًا أكثر منه علمًا بحتًا. والسبب في ذلك هو أن كلما زاد معرفة المهاجمين بخوارزميات وتقنيات الكشف والتخفيف لديك، زادت قدرتهم على التحور والتكيف مع دفاعاتك.

(2) ولا تنسي أبدًا “حلقة OODA”. الملاحظة - التوجيه - القرار - الفعل. فمن يستطيع الدخول داخل حلقة OODA الخاصة بالخصم في المعركة السيبرانية، سيكون هو الفائز عمومًا.

يسعدني أن أقرأ أنك تستمتعين بالدفاع السيبراني وتنظرين إلى الصورة الأكبر. يبدو أن كل شيء تحت سيطرتك (بناءً على ما قرأته سريعًا في ملخص هذه المناقشة)، وأن فريق Meta الموقر قد قام أيضًا بتغيير مفيد لك.

إذا تعرضتِ لهجوم واحتجتِ إلى أي مساعدة، فلا تترددي في التواصل معي. لقد تقاعدتُ منذ زمن طويل من عالم السعي وراء الأرباح وملء الخزائن (الحمد لله!)، لذا لا توجد أي رسوم للاستشارة معي. مساعدة الآخرين الذين يواجهون مشاكل تقنية مثيرة للاهتمام، خاصة في مجال الأمن السيبراني والحرب السيبرانية، تمثل أولوية أعلى لدي من تراكم المزيد من الثروة.

أنا هنا من أجلك إذا احتجتِ إلى شخص لمناقشة الأفكار معه، ومن خلال ما قرأته من ردودك الأخيرة، يبدو أن الأمور تحت سيطرتك.

عمل رائع!

5 إعجابات

@codinghorror تفكيري هنا هو أن هذا التغيير غير مجدٍ، وعليّ فقط التراجع عن تعديلي.

لا تطلب أي من مواقعنا المستضافة ذلك، ولا حتى وضعيات حظر البريد الإلكتروني القصوى. لا يمثل أي من هذا مشكلة في الممارسة العملية، لأننا نقوم بحذف الحسابات غير النشطة على أي حال، ونقوم بفحص الملفات الشخصية بحثًا عن الرسائل المزعجة.

يمكن للمُرسل للرسائل المزعجة ببساطة تشغيل خادم SMTP، وهو أسهل من أتمتة Gmail، وبهذه الطريقة سيكون لديهم وصول إلى عدد لا نهائي من عناوين البريد الإلكتروني.

بالإضافة إلى ذلك، فإن العنونة تُستخدم على نطاق واسع بطرق شرعية.

المشكلة الأكثر شيوعًا المتعلقة بالنقاط في Gmail ليست الرسائل المزعجة، بل أخطاء الكتابة في عناوين البريد الإلكتروني.

أظن أن التغيير الوحيد الذي أدعمه في النواة هو توسيع قائمة البريد المحظور لحظر عناوين البريد الإلكتروني المعيارية (Canonical)، على الأقل هذا يُعد تحسينًا لميزة حظر البريد الإلكتروني ويحل مشكلة صاحب الموضوع الأصلي (OP).

على سبيل المثال: إذا قمت بحظر Jane@gmail.com، فسيتم حظر j.ane+1@gmail.com أيضًا.

أي تغييرات أخرى يمكن أن توضع في الإضافات.

هل يبدو هذا مقبولاً؟

7 إعجابات