Gmail تقرأ إيصالاتك قبل أن تقرأها أنت، والمحتالون يعرفون ذلك

تلك البطاقة الأنيقة في أعلى صندوق الوارد الخاص بك والتي توضح أن طلب Amazon الخاص بك سيصل يوم الخميس لم تُستحضر بواسطة ذكاء اصطناعي يقرأ أفكارك. عثرت Gmail على كتلة من علامات schema.org التي أخفاها المُرسل في HTML البريد الإلكتروني، وحللتها، ورسمت البطاقة لك. وهذا يعني أن المحتال الذي يلصق نفس العلامات يمكنه جعل الطلب المزيف يبدو محقَّقاً تماماً مثل الطلب الحقيقي.

كيف تعرف Gmail أن طرداً قادم قبل أن تقرأ البريد الإلكتروني؟

المُرسل يخبرها، باستخدام لغة قابلة للقراءة الآلية تطلب منهم Gmail التحدث بها. وثائق مطوري Google الخاصة بعلامات البريد الإلكتروني واضحة: تُدمج بائعات التجزئة والخطوط الجوية بيانات منظمة باستخدام مفردات schema.org، إما بصيغة JSON-LD أو microdata، داخل HTML الرسالة. يحتوي تأكيد الطلب على كائن Order بحقول مثل orderNumber و orderStatus، مع ParcelDelivery متداخل يحتوي على expectedArrivalUntil و tracking URL. تحتوي الرحلة الجوية على FlightReservation مع مطار المغادرة والمعلومة والوقت المخصص للصعود.

يقرأ محلل Gmail تلك الحقول ويعيد تصييرها كنقاط بارزة في أعلى الصندوق وداخل الرسالة. لا يوجد ذكاء اصطناعي "يفهم" خطط سفرك. إنه يقرأ بيانات مسمَّاة بالطريقة التي يقرأ بها المتصفح حقل العنوان. الذكاء موجود بالكامل تقريباً في HTML المُرسل، وليس في صندوق Google الأسود.

لماذا يجعل ذلك الطلبات المزيفة أكثر إقناعاً وليس أقل؟

لأن العلامات مجرد نص، والنص ينسخ. لا توجد علاقة تشفيرية بين "هذه البطاقة تقول أن طلبك شُحِن" و"هذا الطلب حقيقي." تتحقق عملية تسجيل schema في Google من حجم المُرسل والتنسيق قبل تفعيل بطاقات غنية بالمحتوى على نطاق واسع، لكن JSON-LD الأساسي يجلس في رؤية عادية في كل تأكيد شرعي استقبلته من قبل. افتح واحداً، واعرض المصدر، وهناك يكون.

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

ما الذي يفصل فعلاً بين تأكيد حقيقي وآخر مزيف؟

ليس البطاقة. رؤوس المصادقة تحتها. ثلاث فحوصات تقرر ما إذا كان المُرسل هو من يدّعيه: SPF يؤكد أن خادم الإرسال مصرح به للمجال، DKIM هو توقيع تشفيري على نص الرسالة، و DMARC يخبر المستقبلين بما يجب فعله عندما يفشل SPF أو DKIM. جعلت Google و Yahoo ذلك إجبارياً لأي شخص يرسل أكثر من 5,000 رسالة يومياً لمستخدميهم بدءاً من فبراير 2024. سيتم رفض أو إرسال المرسلين الضخمين بدون DMARC صحيح إلى البريد المزعج.

تلك هي الطبقة التي تستحق الثقة، وهي الطبقة التي لا توضحها أي بطاقة لك. في Gmail، افتح الرسالة، واضغط على قائمة النقاط الثلاث، واختر "إظهار الأصل،" وابحث عن PASS في SPF و DKIM و DMARC. سيفشل بريد إلكتروني "تم شحن الطلب" المزيف الذي ينتحل شخصية بائع تجزئة حقيقي عادةً في DKIM أو سيأتي من مجال لا يتوافق. البطاقة الجميلة لا تستطيع الكذب عن تواريخ التسليم؛ رؤوس البيانات لا تستطيع الكذب عن من أرسلها. الأدوات التي تقرأ تلك الرؤوس من أجلك، بما في ذلك كشف الرسائل المزعجة في البريد الإلكتروني بالذكاء الاصطناعي مثل xmail، تتحقق من نفس الشيء، فقط أسرع مما ستفعله بيدك.

ما الذي يجب أن تفعله عندما تظهر بطاقة طرد مفاجئة؟

ثق في التتبع الذي بدأته أنت، وليس التتبع الذي وصل بدون إخطار. إذا كانت البطاقة تؤكد تسليماً لا تتذكر طلبه، فلا تضغط على رابطها. رابط التتبع الموجود داخل العلامات المزيفة هو القصة برمتها، وغالباً ما يؤدي إلى صفحة "ادفع هذه رسوم جمارك" أو "أكد عنوانك" تجمع تفاصيل البطاقة. لقد حذرت U.S. Postal Inspection Service و FTC مراراً بشأن نصوص وبرائد بريد إلكتروني مزيفة للتسليم تفعل بالضبط ذلك.

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