يجب اتّخاذ إجراءات أمان إضافية أو يُنصح بها لتأمين الإجراءات المضمّنة:
HTTPS: يجب التعامل مع جميع الإجراءات من خلال عناوين URL التي تستخدم HTTPS، ويجب أن تكون شهادات خادم SSL الصالحة مثبّتة على المضيفين.
رموز الدخول: يُنصح بأن يضمّن المرسلون الذين يستخدمون الإجراءات رموز الدخول ذات الاستخدام المحدود في عناوين URL الخاصة بالإجراءات، وذلك لحماية أنفسهم من هجمات إعادة الإرسال. هذه ممارسة جيدة بشكل عام لأي عنوان URL مضمّن في صفحات الويب أو الرسائل الإلكترونية التي قد يكون لها أي آثار جانبية عند استدعائها.
تفويض حامل الأذونات: يُنصح بأن تتحقّق الخدمات التي تعالج طلبات الإجراءات من عنوان Http "Authorization" في طلب HTTPS. سيحتوي هذا العنوان على سلسلة "رمز مميّز لحامل الإذن"، ما يثبت أنّ مصدر الطلب هو google.com وأنّ الطلب مخصّص للخدمة المحدّدة. يجب أن تستخدم الخدمات مكتبة البرامج المفتوحة المصدر التي توفّرها Google من أجل التحقّق من رمز Bearer Token.
تأمين أنماط الوصول إلى الرسائل الإلكترونية في الحالات القصوى
يتعامل Gmail مع أشكال مختلفة من إعادة توجيه الرسائل الإلكترونية وأنماط الوصول إليها من أجل تأمين الإجراءات في الرسائل الإلكترونية. يتم إجراء القياسات التالية بالإضافة إلى المقاييس المذكورة أعلاه:
نمط الوصول
إجراءات الأمان الإضافية
إعادة التوجيه اليدوي: يفتح المستخدم رسالة إلكترونية ويعيد توجيهها إلى المزيد من المستلمين
تؤدي عملية إعادة التوجيه هذه دائمًا إلى تعطّل توقيعات DKIM، كما أنّ المُرسِل لم يعُد مسجّلاً في الخدمة. يتم رفض الإجراءات في الرسالة الإلكترونية.
إعادة التوجيه التلقائي إلى Gmail: ينشئ المستخدم قاعدة إعادة توجيه في صندوق البريد user@acme.com إلى صندوق بريد Gmail الخاص به.
يتأكّد Gmail من أنّ المستخدم يمكنه الإرسال باسم user@acme.com (يُعدّ المستخدم هذا الإعداد يدويًا). يتم قبول الإجراءات في الرسالة الإلكترونية.
استرداد رسائل Gmail باستخدام بروتوكول POP: يقدّم المستخدم كلمة المرور الخاصة بحساب user@acme.com إلى Gmail، ويسترد Gmail جميع الرسائل الإلكترونية من هذا الحساب عبر بروتوكول POP إلى صندوق وارد Gmail.
يتم الحفاظ على تواقيع DKIM وسلامة المحتوى. أثبت المستخدم إمكانية الوصول إلى user@acme.com. تم قبول الإجراءات في الرسالة الإلكترونية.
الوصول إلى رسائل Gmail الإلكترونية باستخدام تطبيقات تابعة لجهات خارجية: يستخدم مستخدم Gmail تطبيقًا تابعًا لجهة خارجية (مثل Outlook أو Thunderbird) للوصول إلى رسائل Gmail الإلكترونية، أو يعيد توجيه رسائل Gmail الإلكترونية إلى مزوّد خدمة بريد إلكتروني آخر.
قد يستخدم تطبيق أو خدمة تابعان لجهة خارجية المعلومات المضمّنة. ومع ذلك، لن يتمكّن من إنشاء رموز مميّزة لمصادقة حامل البطاقة تتطابق مع رموز Google، ما يتيح للمرسِلين فرصة رفض طلبات الإجراءات هذه. يمكن للمرسِلين اختيار رفض الإجراءات أو قبولها بدون رموز مميّزة لحامل الإذن، وذلك حسب حساسية الإجراء. يُرجى العلم أنّه يتم إنشاء رمز التحقّق من صحة بيانات حامل البطاقة باستخدام تكنولوجيات مفتوحة المصدر عادية، ما يتيح لجميع مقدّمي خدمات البريد والتطبيقات إنشاء هذه الرموز باستخدام مفاتيحهم الخاصة.
تاريخ التعديل الأخير: 2025-08-29 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-08-29 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# Securing Actions\n\nThis page document how Gmail secures the delivery and execution of actions.\n\nSecurity Measures enforced by Google\n------------------------------------\n\nThe following conditions must hold for schemas embedded in email:\n\n- **Registration** : Sender must [Register with Google](../registering-with-google).\n- **SPF** or **DKIM** : Emails with schema markup **must** arrive from [SPF or DKIM authenticated domains](https://support.google.com/mail/answer/180707)\n\nAdditional Measures required for In-Line Actions\n------------------------------------------------\n\nExtra security measures are required or encouraged to secure inline actions:\n\n- **HTTPS** : All actions **must** be handled via HTTPS URLs. Hosts must have valid SSL server certificates installed.\n- **Access Tokens** : It is **encouraged** that senders using actions embed [Limited-Use Access Tokens](/workspace/gmail/markup/actions/limited-use-access-tokens) in the action URLs, to protected themselves against [Replay Attacks](http://en.wikipedia.org/wiki/Replay_attack). This is a generally good practice for any URL embedded in webpages or emails that might have any side-effects when invoked.\n- **Bearer Authorization** : It is **encouraged** that services handling action requests verify the Http \"Authorization\" header in the HTTPS request. That header will contain a \"Bearer Token\" string, proving that the source of the request is google.com, and that the request is intended for the specified service. Services should use the Google-provided open source library to [Verify the Bearer Token](/workspace/gmail/markup/actions/verifying-bearer-tokens).\n\n| **Note:** Bearer tokens in authorization headers are not sent by default. If you require a bearer token token to be sent, request it when [registering with Google](/workspace/gmail/markup/registering-with-google).\n\nSecuring Edge-Case Email Access Patterns\n----------------------------------------\n\nThere are various variants of email forwarding and access patterns that Gmail handles in order to secure actions in emails. These following measurements are performed **IN ADDITION** to the measures above:\n\n| Access Pattern | Additional Security Measures |\n|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| **Manual Forwarding** - User opens an email and forwards it to more recipients | Such forwarding always breaks DKIM signatures, and the sender is no longer registered with the service. Actions in the email are **rejected**. |\n| **Auto Forwarding to Gmail** - User creates a forwarding rule on mailbox user@acme.com to her gmail mailbox. | Gmail verifies that the user can send as user@acme.com (user sets this up manually). Actions in the email are **accepted**. |\n| **Gmail POP fetching** - User gives Gmail the password for user@acme.com and Gmail fetchers all emails there via POP to the Gmail inbox. | DKIM signatures and content integrity is preserved. User has proven access to user@acme.com. Actions in the email are **accepted**. |\n| **Accessing Gmail emails with 3rd party applications** - Gmail user uses a 3rd party application (e.g. Outlook or Thunderbird) to access Gmail emails, or forwards her Gmail emails to another email provider. | 3rd party application or service may use embedded information. However, it won't be able to produce bearer authentication tokens that match Google's, giving senders the opportunity to reject such action requests. Senders may choose whether they reject or accept actions without bearer tokens, depending on the sensitivity of the action. Note that the bearer authorization token is created using standard open source technologies making it possible to all mail providers and apps to produce them using their own keys. |"]]
