ایمیل سرورها همواره مورد هدف حملات سایبری از جمله فیشینگ و اسپم قرار میگیرند. در سالهای اخیر استانداردهای احراز هویت ایمیل مثل SPF، DKIM و DMARC برای پیادهسازی پروتکل SMTP و همچنین مقابله با حملاتی که در ارتباطات ایمیلی صورت میگیرند، معرفی شدند. اگرچه معرفی این سازوکارها به ارتقای امنیت ایمیل و پیشگیری از جعل کمک کرده اما در بعضی فرایندهای مهم و ضروری مثل پاسخ و فوروارد خودکار اختلالاتی ایجاد کرده است.
Axigen با حفظ قابلیتهای موجود (مثل فوروارد کردن) متعهد به تأمین و حفظ ایمنی مشتریانش است. به همین دلیل در نسخه 2 Axigen X3 و نسخههای بعد از آن قابلیتی به نام SRS یا Sender Rewriting Scheme ارایه شد تا مشکل عدم سازگاری فوروارد خودکار با استانداردهای احراز هویت مثل SPF حل شود. در این مطلب هر آنچه باید درباره SRS بدانید را به شما خواهیم گفت.
SRS چیست؟
هدف اصلی استانداردهای احراز هویت ایمیل، اثبات جعل نشدن ایمیل است یعنی اینکه ایمیل واقعاً از سمت همان فردی که ادعا شده ارسال شده است. این قابلیت بسیار کاربردی است مگر در مواقعی که سرورهای ایمیل نیاز به فوروارد ایمیلها دارند. قابلیت SRS طرحی برای بازنویسی [1]envelope sender جهت ارسال مجدد آن و دور زدن روشهای SPF برای جلوگیری از جعل آدرسهای فرستنده است. جعل آدرس فرستنده به عنوان جعل ایمیل نیز شناخته میشود.
فرض کنید که یک MTA ایمیلی را قبول میکند که مقصد آن یک صندوق ایمیل محلی نیست و نیاز به فوروارد کردن آن دارد. در این حالت معمولاً فرستنده یک پیام دفع[2] دریافت میکند. اگر پیام دفع به آدرس ایمیلی ارسال شود که یک سیاست SPF سختگیرانه برای احراز هویت دو مرحلهای دارد، تراکنش فوروارد کردن شکست خورده و ایمیل از دست میرود. قابلیت SRS با فراهم کردن امکان بازیابی آدرس پوششی اصلی، به پیشگیری از چنین سناریویی کمک میکند. به این ترتیب زمانی که پیام دفع شده به احراز هویت چند مرحلهای برخورد کند، امکان ارسال دوباره آن در مسیر معکوس با یک فیلد خالی برای فرستنده پوششی فراهم میشود.
SRS چگونه کار میکند؟
شکلگیری این طرح با استاندارد SPF شروع شد که به فرستندهها امکان میدهد آیپیهای مجاز به ارسال ایمیل برای یک دامنه خاص را مشخص کنند. اگر ایمیلی در بررسیهای SPF شکست بخورد یا به عنوان اسپم نشانهگذاری میشود یا توسط احراز هویت چند مرحلهای دریافت کننده پیام، رد خواهد شد. به ویژه اگر سیاست DMARC به صورت p=reject تعریف شده باشد و DKIM آن ایمیل را معتبر تلقی نکند. در سیاست p=reject، گیرنده همه ایمیلها از یک دامنه مشخص را رد میکند.
SPF یک قابلیت بسیار مفید است که به حفاظت از کاربران در برابر ایمیلهای ناخواسته کمک میکند اما از طرفی امکان فوروارد ایمیل به روش سنتی را فراهم نمیکند. برای مثال اگر سعی کنید ایمیلی را از یک دامنه میزبانی شده به آدرس جیمیل خودتان فوروارد کنید، ممکن است ایمیل یا به عنوان اسپم نشانهگذاری شود یا اصلاً به مقصد نرسد. از آنجا که استاندارد SPF توسط همه سیستمهای وب میل محبوب مثل جیمیل، هاتمیل، اوتلوک و یاهو پشتیبانی میشود (به خصوص در ترکیب با DMARC)، این مسئله میتواند مشکلآفرین شود.
با استفاده از SRS میتوانید آدرس فرستنده را تغییر دهید تا از دامنه خودتان استفاده کنید. در نتیجه کنترل رکوردهای SPF مربوطه را در اختیار میگیرید. به این ترتیب میتوانید مطمئن شوید که ایمیل فوروارد شده از بررسیهای SPF عبور کرده و به صندوق پیام جیمیل شما میرسد.
توجه: SRS آدرس فرستنده را بازنویسی میکند تا به نظر برسد از سرور ایمیل فوروارد کننده ارسال شده است. به این ترتیب ایمیل فوروارد شده میتواند بررسیهای SPF در سرور دریافت کننده را با موفقیت طی کند.
قابلیت SRS چه اهمیتی دارد؟
طرح بازنویسی فرستنده برای مواقعی که قصد دارید از یک آدرس ایمیل رسمی استفاده کنید (مثل info@company.com) اما میخواهید همه پیامهای دریافت شده را به آدرس ایمیل شخصی خودتان ارسال کنید (مثل david@yahoo.com) بسیار مفید است.
بدون وجود SRS امکان اعتبارسنجی منشأ ایمیل وجود ندارد بنابراین سیستم احراز هویت چند مرحلهای در مقصد (که در اینجا یاهو است) آن را اسپم در نظر میگیرد یا رد میکند چون از بررسی SPF با موفقیت عبور نکرده است. کسبکارهای کوچک مثل مشاغل یک نفره و ارایهدهندگان سرویسهای میزبانی کوچک معمولاً با این سناریو روبرو میشوند.
مزیت اصلی سرور ایمیلی با قابلیت SRS، بهبود قابلیت تحویل پیامهایی است که هنگام ارسال توسط فرستنده اصلی از مرحله SPF با موفقیت عبور میکنند اما پس از فوروارد شدن، در مقصد خارجی نهایی، در بررسی SPF شکست میخورند.
طرح بازنویسی فرستنده به چه صورت است؟
فرض کنید که قصد دارید تقاضای شغل خودتان را از آدرس ایمیل شخصی (john@gmail.com) به آدرس رسمی شرکت (info@company.com) ارسال کنید ولی در حساب شرکت، یک نفر فوروارد خودکار به یک آدرس ایمیل خارجی (david@yahoo.com) را فعال کرده است (اگر این کار طبق سیاستهای شرکت مورد نظر، مجاز و قابل انجام باشد).
در این صورت، SRS به این ترتیب خواهد بود:
|
پیام اصلی |
پیام فوروارد شده به صورت خودکار |
گیرنده |
info@company.com |
david@yahoo.com |
فرستنده پوششی |
john@gmail.com |
SRS0=Ec3y=5M=gmail.com=john@company.com |
هدر From |
john@gmail.com |
john@gmail.com |
SRS در Axigen
برای فعال کردن SRS در Axigen میتوانید پارامتر جدید کانتکست سرور enableSRS را تنظیم کرده و در همان کانتکست برای پارامتر srsSecretKey یک مقدار تعیین کنید.
در صورت فعال بودن SRS، ایمیل سرور Axigen از یک کلید خصوصی SRS تصادفی استفاده کرده یا آن را تولید میکند.
نکات
- ممکن است تغییر srsSecretKey باعث شود که Axigen نتواند SRS معکوس را برای ایمیلهای در حال انتقال با استفاده از رمز قدیمیتر تکمیل کند.
- در محیط کلاستر، sysadmin باید اطمینان حاصل کند که srsSecretKey بین همه اعضای کلاستر به اشتراک گذاشته شده است.
[1] envelope senderیا فرستنده پوششی همان آدرس برگشت است و به سرورهای ایمیل اعلام میکند پیام ایمیل را به کجا برگردانده یا در صورت عدم ارسال صحیح ایمیل، پیغام خطا را به آن آدرس برگشت بزند. این آدرس بصورت پنهان در ابتدای پیام ایمیل قرار دارد و سرورها با استفاده از آن تشخیص میدهند که پیام از طرف چه کسی ارسال شده و از چه نرمافزاری برای ایجاد آن استفاده شده است.
[2] پیامی خودکار از سامانه ایمیل برای فرستنده ارسال میشود و او را از عدم تحویل پیام پیشین مطلع میکند.
منبع: axigen