مقدمه

در این مقاله به بررسی سه تکنولوژی برتر احراز هویت ایمیل شامل DKIM ، SPF، MARC و جنبه­ های مختلف استقرار هر یک از آنها پرداخته می­شود. چندین ساختار معماری ایمیل به همراه دستوالعمل ­های پیاده ­سازی آنها در محصولات امنیت ایمیل سیسکو ارایه شده است. با توجه به اینکه این مقاله به صورت یک راهنمای عملی ارایه شده است، از بیان برخی موارد پیچیده اجتناب شده است. همچنین در صورت لزوم برخی مفاهیم بشکل ساده و فشرده ارایه شده است.

 پیش نیازها

خواننده این مقاله برای درک مطالب آن ملزم به آگاهی از ابزارهای امنیت ایمیل سیسکو است. علاوه ­بر­این خواننده می­بایست آگاهی لازم در خصوص DNS و SMTP و فرآیندهای آنها و اصول اولیه SPF، DKIM و DMARC داشته باشد.

بررسی اجمالی راهکارهای احراز هویت ایمیل

 پالیسی مبتنی بر فرستنده

چارچوب پالیسی­های مبتنی بر فرستنده برای اولین بار در سال 2006 با عنوان RFC4408 منتشر شد. نسخه کنونی RFC7208 است که در نسخه RFC7372 بروزرسانی شده است. در حقیقت، ساده­ ترین روش برای صاحبان دامنه به منظور ارسال ایمیل ­های معتبر به گیرندگان استفاده از DNS است. اگر چه SPF به­ صورت پیش­فرض مسیر بازگشت (mail from) را بررسی می­کند؛ توصیه می­شود مکانیزیمی جهت احراز هویت آرگومان­های HELO/EHLO، SMTP (FQDN گیت­وی فرستنده در زمان انتقال SMTP ارسال می­شود) وجود داشته باشد. SPF با استفاده از رکوردهای DNS از نوع TXT از ترکیبات ساده­ای چون مورد زیر استفاده می­کند:

[symple_box color=”black” fade_in=”false” float=”left” text_align=”left” width=”100%”] spirit.com    text = “v=spf1 mx a ip4:38.103.84.0/24 a:mx4.spirit.com include:spf.protection.outlook.com~all”[/symple_box]

رکورد Spirit Airlines به ایمیل­هایی با آدرس فرستنده حاوی @spirit.com که از آدرسی مشخصی با سابنت 24/ اجازه عبور می­دهد، دو مکانیزم بر حسب FQDN و محیط Microsoft’s Office365 تعریف شده است. عبارت “~all” گیرنده را ملزم به فرض حالت Soft Fail، یکی از دو وضعیت SPF، در ارتباط با ایمیل­ های سایر منابع قرار می­دهد. توجه داشته باشید که فرستندگان از نحوه عملکرد گیرندگان در قبال پیام­ های Fail شده اطلاعی نخواهند داشت، تنها از میزان Fail آنها آگاه خواهند شد.

شرکت پایه ریزان فناوری هوشمند توانایی ارائه مشاوره و راه اندازی راهکارهای احراز هویت ایمیل با استفاده Cisco ESA را دارد، جهت مشاوره با کارشناسان ما تماس بگیرید

Delta طرح SPF متفاوتی را مورد استفاده قرار داده است:

Delta.com     text = “v=spf1 a:smtp.hosts.delta.com include:_spf.vendor.delta.com –all”

Delta به منظور به حداقل رساندن تعداد DNS queries، رکورد “A” حاوی لیست کلیه گیت­وی SMTP ایجاد کرده است، همچنین رکورد SPF مجزا برای فروشندگان ایجاد شده است، “_spf.vendor.delta.com”. دستوالعمل­ هایی در خصوص Hard Fail پیام­هایی که از طریق SPF احراز هویت نمی­شوند، ارایه شده است (عبارت “-all”). توضیحات تکمیلی در ارتباط با رکورد SPF فروشندگان به شرح زیر است:

_spf.vendor.delta.com text = “v=spf1 include:_spf-delta.vrli.com include:_spf-ncr.delta.com a:delta-spf.niceondemand.com include:_spf.airfrace.fr include:_spf.qemailserver.com include:skytel.com include:epsl1.com ?all”

بنابراین ایمیل ­هایی که از منبع @delta.com ارسال می­شوند؛ به صورت قانونی به عنوان مثال از گیت­وی ایمیل Air France عبور می­کند. United از طرح SPF ساده ­تری استفاده می­کند:

united.com            text = “v=spf1 include:spf.enviaremails.com.br include:spf.usa.net include:coair.com ip4:161.215.0.0/16 ip4:209.87.112.0/20 ip4:74.112.71.93 ip4:74.209.251.0/24 mx ~all”

علاوه بر گیت­وی ایمیل شرکت خود، ارایه ­دهندگان تجاری ایمیل (به عنوان مثال “usa.net” و “enviaremail.com.br”)، گیت، به همراه کلیه رکوردهای MX (مکانیزم “MX”) بهره می­برند. توجه داشته باشید که MX (گیت­وی ایمیل ورودی برای یک دامنه) مشابه خروجی نخواهد بود. در حالی­که معمولا شرکت­های کوچک معمولا گیت­وی ورودی و خروجی یکسان دارند، لیکن شرکت­های بزرگ زیرساخت مجزایی برای بررسی ایمیل­ های ورودی و خروجی استفاده می­کنند.

لازم به ذکر است که در نمونه ­های فوق از ارجاعات DNS بیشتر (مکانیزم “include”) استفاده شده است. با این­حال برای عملکرد بهتر، مشخصات SPF مجموع جستجوی DNS مورد نیاز جهت دریافت رکورد نهایی تا سطح 10 را محدود می­کند. کلیه جستجوی­های SPF با سطح DNS recursion بالای 10 رد خواهند شد.

DKIM

DKIM مشخص­ شده در RFCs، 5585، 6376 و 5863 ترکیبی از دو طرح Yahoo’s Domain Keys و Cisco’s Identified Internet Mail است؛ که برای ارسال­ کنندگان پیام راهکار ساده­ای جهت رمزنگاری امضا پیام خروجی شامل signatures (به همراه سایر بازبینی­ها در metadata) در DKIM-Signature) email header) قرار داده است. ارسال­ کنندگان پیام کلید عمومی خود را در DNS منتشر می­کنند، بنابراین هر گیرنده­ای به راحتی می­تواند کلید را دریافت و امضا آن را تایید کند. DKIM، امکان احراز هویت منبع فیزیکی پیام را ندارد، ولی با تکیه بر این واقعیت که منبع کلید خصوصی سازمان فرستنده را دارا است، بصورت ضمنی اجازه ارسال پیام تحت مالکیت آنها را دارد.

برای پیاده ­سازی DKIM، سازمان ارسال­ کننده چندین کلید عمومی تولید و در DNS به ­صورت رکورد TXT منتشر می­کند. هر جفت کلید توسط یک “selector” ارجاع داده می­شود، بنابراین DKIM امکان تمایز میان کلیدها را خواهد داشت. پیام خروجی امضا شده و هدر DKIM-Signature وارد می­شود:

[symple_box color=”black” fade_in=”false” float=”left” text_align=”left” width=”100%”]DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=united; d=news.united.com;h=MIME-Version:Content-Type:Content-Transfer-Encoding:Date:To:From:Reply-To:Subject:List-Unsubscribe:Message-ID; i=MileagePlus@news.united.com; bh=IBSWR4yzI1PSRYtWLx4SRDSWII4=; b=HrN5QINgnXwqkx+Zc/9VZys+yhikrP6wSZVu35KA0jfgYzhzSdfA2nA8D2JYIFTNLO8j4DGmKhH1MMTyYgwYqT01rEwL0V8MEY1MzxTrzijkLPGqt/sK1WZt9pBacEw1fMWRQLf3BxZ3jaYtLoJMRwxtgoWdfHU35CsFG2CNYLo=[/symple_box]

فرمت امضا قالب ساده­ای دارد. برچسب “a” الگوریتم مورد استفاده به منظور امضا، برچسب “c” مشخص ­کننده طرح­های نرمال­سازی (جهت کسب اطلاعات بیشتر در مورد طرح­های نرمال­ سازی به بخش DKIM canonicalization مراجعه شود.) مورد استفاده، برچسب “s” سلکتور و یا مرجع کلید و “d” دامین امضا کننده است. سایر بخش­های باقی­مانده هدر DKIM-Signature خصوصیات پیغام را مشخص می­کند: “h” لیست هدرهای امضا شده، “i” هویت امضای کاربران و در نهایت هدر به دو هش مجزا ختم می­شود: “bh” مخلوطی از هدرهای امضا شده، در حالی­که “b” مقدار هش برای متن پیام است.

زمانی­که پیغام DKIM-signed دریافت می­شود، گیرنده کلید عمومی را از طریق DNS query جستجو می­کند:

<selector>._domainkey.<signing domain>

همانطور که در هدر DKIM-Signature نیز نشان داده شده است. در مثال بالا Query به صورت “united._domainkey.news.united.com” خواهد بود:

united._domainkey.news.united.com   text = “g=*\; k=rsa\; n=” “Contact” “postmaster@responsys.com” “with” “any” “questions” “concerning” “this” “signing” “\;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/Vh/xq+sSRLhL5CRU1drFTGMXX/Q 2KkWgl35hO4v6dTy5Qmxcuv5AwqxLiz9d0jBaxtuvYALjlGkxmk5MemgAOcCr97GlW7Cr11eLn87
qdTmyE5LevnTXxVDMjIfQJt6OFzmw6Tp1t05NPWh0PbyUohZYt4qpcbiz9Kc3UB2IBwIDAQAB\;”

رکوردی که بازگردانده می­شود حاوی کلید و سایر پارامترهای اختصاصی است.

مشکل اصلی در DKIM، عدم اجازه انتشار استفاده فرستنده از DKIM در مقدار مشخصه اولیه است. بنابراین چنانچه پیامی که حاوی امضا نباشد، دریافت شود، گیرنده راهی برای درک این موضوع نداشته و در این صورت به احتمال بالا تایید هویت نخواهد شد. امکان تشخیص دامنه DKIM-enabled، در شرایطی که یک سازمان قادر به استفاده از چندین سلکتور است، وجود ندارد. استاندارد مجزایی به منظور پوشش این مساله، Author Domain Signing Practice، منتشر شد ولی در سال 2013 به دلیل عدم استقبال، استفاده از آن منسوخ شد.

احراز هویت پیام مبتنی بر دامین، ارایه گزارش و سازگاری آنها

DMARC ، جدیدترین پروتکل احراز هویت است که به منظور رفع نواقص سایر روش­های احراز هویت SPF و DKIM ارایه شده است. برخلاف دو روش دیگر، DMARC بخش Header From پیام را اعتبارسنجی کرده و ارتباطی میان آن سایر فاکتورهای بررسی شده توسط دو پروتکل دیگر برقرار می­کند. DMARC در RFC7489 تعریف شده است.

مزیت­های DMARC نسبت به روش­های SPF و DKIM شامل موارد زیر است:

1. اطمینان از هم ­ترازی (مطابقت کامل و یا تابعیت آن) کلیه مشخصه­ های موجود (HELO، MAIL FROM، DKIM signing domain) با From header
2. صاحب دامنه ارسال­ کننده پیام، امکان ایجاد پالیسی­های امنیتی برای گیرنده پیام جهت تصمیم ­گیری در ارتباط با برخورد با پیام­های fail را خواهد داشت.
3. صاحب دامنه ارسال­ کننده پیام، امکان دریافت فیدبک لازم در خصوص پیغام­های fail را خواهد داشت؛ بنابراین امکان شناسایی حملات phishing و یا هر گونه خطایی در پالیسی­های SPF/DKIM/DMARC را خواهد داشت.

DMARC از یک مکانیزم ساده پالیسی مبتنی بر توزیع DNS استفاده می­کند:

_dmarc.aa.com text = “v=DMARC1\; p=none\; fo=1\; ri=3600\; rua=mailto:american@rua.agari.com,mailto:dmarc@aa.com\; ruf=mailto:american@ruf.agari.com,mailto:dmarc@aa.com”

تنها بر چسب الزامی در تعیین پالیسی­های DMARC، “p” است، که نحوه برخورد با پیام­های fail را تعیین می­کند؛ که یکی از سه روش none، quarantine و reject در ارتباط با این قبیل پیام­ها اتخاذ می­شود. ارایه گزارش در بسیاری از این پارامترها الزامی است: “rua” معرف آدرس URL (یا به صورت mailto و یا آدرس http:// URL با استفاده از روش POST) که به منظور ارسال گزارش­های تجمیعی در ارتباط با پیام­های Fail از یک دامنه مشخص است. “ruf” معرف URL به منظور ارایه گزارشات فوری در ارتباط با کلیه پیام­های Fail است.

با توجه به ویژگی­های تعریف شده گیرنده پیام ملزم به مطابقت با پالیسی ­های اعلام شده است. چنانچه گیرنده رویکرد متفاوتی را در پیش بگیرد گزارش کاملی به صاحب دامنه ارسال­ کننده پیام ارسال می­شود. یکی از مفاهیم اصلی DMARC هماهنگی شناسه است. هماهنگی شناسه معرف نحوه عبور پیام از تایید هویت DMARC را نمایش می­دهد. SPF و DKIM به صورت مجزا تنظیم شده، و پیام به منظور تامین الزامات DMARC ملزم به تایید کلیه این مراحل است. پالیسی­ های DMARC بگونه ­ای است که فرستنده امکان درخواست ارایه گزارش failure در مواردی که یکی از تنظیمات صحیح و بقیه fail باشند را نیز دارد. این مساله در مثال بالا از طریق بر چسب “fo” که مقدار “1” به آن اختصاص داده شده است مشخص  می­شود.

دو روش جهت تایید هماهنگی شناسه پیام حالت­های DKIM و SPF وجود دارد که شامل وضعیت­های strict و relaxed است. پیوستگی Strict به معنی FQDN بخش Header From ملزم به تطبیق کامل با شناسه امضای دامنه (بر چسب “d”) از امضا DKIM و یا FQDN مربوط به دستور MAIL FROM SMTP برای SPF است. از سوی دیگر پیوستگی Relaxed بخش Header From FQDN به صورت زیر دامنه موارد فوق قرار می­گیرد. این موارد هنگام ارسال ترافیک به 3^rd party اهمیت ویژه­ای می­یابد.

 الزامات استقرار SPF

SPF برای گیرنده

SPF جزو جدایی­ ناپذیر در پیکربندی سیسکو Email Security Appliance) ESA) و Cloud Email Security virtual appliance است. در ادامه این مقاله هرگونه ارجاعی مرتبط با ESA شاملCisco Email Security) CES) نیز است.

اعتبارسنجی SPF در پالیسی­های Mail Flow تبیین شده است؛ ساده ­ترین راه برای اجرای آن فعال کردن آن در بخش Default Policy Parameters مرتبط با listener مناسب است. چنانچه listener مشابهی برای ایمیل­ های دریافتی و ارسالی استفاده می­کنید، از غیر فعال بودن اعتبارسنجی SPF در پالیسی­های جریان ایمیل حاصل کنید.

باتوجه به اینکه SPF اجازه تایید پالیسی را نمی­دهد، اعتبارسنجی SPF (مشابه DKIM) تنها به تایید پیام و ورود مجموعه­ ای از هدرها برای هر بخش بررسی شده SPF می­پردازد:

Received-SPF: Pass (mx1.hc4-93.c3s2.smtpi.com: domain of
united.5765@envfrm.rsys2.com designates 12.130.136.195 as
permitted sender) identity=mailfrom;
client-ip=12.130.136.195; receiver=mx1.hc4-93.c3s2.smtpi.com;
envelope-from=”united.5765@envfrm.rsys2.com”;
x-sender=”united.5765@envfrm.rsys2.com”;
x-conformance=sidf_compatible; x-record-type=”v=spf1″
Received-SPF: None (mx1.hc4-93.c3s2.smtpi.com: no sender
authenticity information available from domain of
postmaster@omp.news.united.com) identity=helo;
client-ip=12.130.136.195; receiver=mx1.hc4-93.c3s2.smtpi.com;
envelope-from=”united.5765@envfrm.rsys2.com”;
x-sender=”postmaster@omp.news.united.com”;
x-conformance=sidf_compatible

توجه کنید در این پیام دو مشخصه توسط SPF تایید شده ­اند: “mailfrom” به عنوان یک حکم و “helo” به عنوان یک پیشنهاد توسط مشخصه­ ها ارایه شده است.

این پیام SPF را عبور خواهد زیرا تنها پیغام قبلی الزامات SPF را تامین می­کند لیکن برخی از گیرندگان فرستنده را به نداشتن رکورد SPF در شناسه HELO ملزم میدارند.

بنابراین قرار دادن نام­های گیت­وی میزبان ایمیل خروجی در رکوردهای SPF روش مناسبی خواهد بود.

زمانی­که پالیسی Mail flow پیامی را تایید می­کند، تصمیم­ گیری در ارتباط با اتخاذ واکنش مناسب به مدیران محلی واگذار شده است.

این کار با استفاده از قوانین فیلترینگ پیام  spf-status (ایجاد فیلترهای پیام فراتر از محدوده این مقاله بوده و برای دریافت اطلاعات بیشتر به بخش AsyncOS for Email مراجعه کنید.)، یا توسط ساخت یک فیلتر محتوای ورودی و اعمال پالیسی ایمیل ورودی انجام می­شود.

فیلترهای توصیه شده موجب متوقف کردن پیام­های  all ) Fail- در رکورد SPF) ، قرنطینه پیام­های all ) Softfail~ در رکورد SPF) در Policy Quarantine  میشود، در حالی­که این مساله با توجه به الزامات امنیتی سازمان­ها تغییر می­کند.

برخی گیرندگان پیام تنها بر چسب پیغام Fail را قرار داده و یا عملی انجام نداده و تنها گزارشی به ادمین ارسال می­کنند.

اخیرا محبوبیت SPF افزایش یافته است ولی بسیاری از دامنه­ ها رکوردهای SPF نادرست و یا ناقص منتشر کرده­اند. توصیه میشود به منظور حفظ امنیت، خواستار قرنطینه کلیه پیام­های SPFfailing باشید، و همه پیام­های قرنطینه را برای مدت محدودی پایش کرده تا از احتمال “false positive” آنها اطمینان حاصل شود.

 چنانچه سرویس ایمیل را برای سایر دامنه­ها و یا 3^rd party ارایه می­دهید

چنانچه سرویس ارسال ایمیل، سرویس­های hosting برای 3^rd party ارایه می­کنید، ملزم به افزودن نام میزبان و IP برای ارسال پیام­ها به رکوردهای SPF آنها هستید. ساده­ ترین راه برای ارایه ­دهندگان سرویس ایجاد رکورد SPF “umbrella” است و مشتریان ملزم به استفاده از مکانیزم “include” در رکورد SPF خود هستند.

suncountry.com text = “v=spf1 mx ip4:207.238.249.242 ip4:146.88.177.148 ip4:146.88.177.149
ip4:67.109.66.68 ip4:198.179.134.238 ip4:107.20.247.57 ip4:207.87.182.66 ip4:199.66.248.0/22
include:cust-spf.exacttarget.com ~all”

همانطور که مشاهده می­کنید Sun Country برخی از ایمیل­ هایش را تحت مدیریت سازمان خود درآورده ولی بازاریابی از طریق ایمیل خود را به 3^rd party برون­سپاری کرده است. توسعه رکوردهای ذکر شده لیستی از آدرس­های IP مورد استفاده توسط ارایه­ دهندگان سرویس بازاریابی از زریق ایمیل را نشان می­دهد:

cust-spf.exacttarget.com              text = ” v=spf1 ip4:64.132.92.0/24 ip4:64.132.88.0/23
ip4:66.231.80.0/20 ip4:68.232.192.0/20 ip4:199.122.120.0/21 ip4:207.67.38.0/24
ip4:207.67.98.192/27 ip4:207.250.68.0/24 ip4:209.43.22.0/28 ip4:198.245.80.0/20
ip4:136.147.128.0/20 ip4:136.147.176.0/20 ip4:13.111.0.0/18 -all”

این انعطاف­پذیری قابلیت توسعه ارایه سرویس ایمیل بدون نیاز به دسترسی و ویرایش رکورد DNS هر یک از مشتریان را در اختیار شما قرار می­دهد.

چنانچه از سرویس­های ایمیل 3^rd party استفاده می­کنید

مشابه بخش قبل چنانچه شما از هر گونه سرویس ایمیل 3^rd party استفاده می­کنید و مایل به ایجاد روند احراز هویت ایمیل SPF هستید، ملزم به داشتن رکوردها SPF آنها هستید.

jetblue.com descriptive text “v=spf1 include:_spf.qualtrics.com ?all”

JetBlue، از سرویس تحلیل­ های Qualtrics استفاده می­کند، بنابراین تنها کافی است تا آنها رکوردهای SPF معتبر از Qualtrics را در اختیار داشته باشند. به صورت مشابه بسیاری از Email service provider) ESPs) رکوردهای SPF برای مشتریان فراهم می­کنند.

چنانچه ESP یا email marketer رکوردهای SPF را ارایه ندهد، ملزم به تنظیم لیست گیت­وی ایمیل­ های خروجی … هستید.

با این حال مسئولیت بروزرسانی و حفظ رکوردها بر عهده شماست و چنانچه ارایه­ دهنده سرویس تغییری در IP، Hostname و افزودن گیت­وی جدید دهد، جریان ایمیل شما تحت تاثیر قرار خواهد گرفت.

خطرات دیگر 3^rd party فارغ از SPF ناشی از منابع اشتراکی است: چنانچه ESP از آدرس IP مشابهی جهت ارسال ایمیل­ های چند مشتری استفاده کند، یک مشتری امکان ایجاد پیام با SPF معتبر متعلق به مشتریان دیگر را دارد؛ به همین علت پیش از قرار دادن محدودیت­های SPF پالیسی­ های امنیتی Managed Service Provider) MSP) و احراز هویت ایمیل قرار داده می­شود.

چنانچه پاسخگوی سوالات شما در ارتباط با اینکه چگونه SPF یکی از مکانیزم­های Trust در اینترنت است، نباشد توصیه می­شود در انتخاب MSP خود تجدیدنظر کنید.

این مساله تنها در ارتباط با امنیت نیست، ارسال­ کننده معمولا از هر چهار روش SPF، DKIM، DMARC و سایر روش­ ها به همراه اعمال MSPs به منظور تضمین ارسال پیام استفاده می­کند.

چنانچه MSP مطابق آنها نباشد قابلیت اطمینان آنها را پایین آورده و پیام توسط سیستم­های گسترده­ای با تاخیر و یا حتی خطر مسدود شدن، مواجه می­شود.

زیردامنه ­هایی فاقد ترافیک ایمیل

امروزه اغلب سازمان­ها از چندین دامنه با هدف بازاریابی استفاده کرده ولی معمولا از یک دامنه فعال برای ایمیل­های تجاری استفاده می­کنند. حتی اگر SPF به صورت صحیح پیاده ­سازی نشده باشد، سوء­استفاده ­کنندگان از سایر دامنه­های غیر فعال به­ منظور Email spoofing از اطلاعات هویتی یک سازمان استفاده می­کنند.

SPF برای جلوگیری از این موضوع از رکورد SPF در حالت “deny all” استفاده می­کنند، برای هر یک از دامنه­ ها و زیر دامنه­ هایی که ترافیک ایمیل ایجاد نمی­کنند در DNS دستور “v=spf1 –all” را منتشر کنید. بهترین نمونه از این مطلب وبسایت شورای SPF با نام openspf.org است.

با توجه به اینکه SPF delegation تنها در یک دامنه معتبر است، استفاده از رکورد SPF بصورت “deny all” برای هریک از زیر دامنه­ ها صحیح نبوده و حتی ممکن است این رکورد در دامنه­ ای که ترافیک ایمیل تولید نمیکند استفاده شود.

حتی چنانچه production domain رکورد SPF به صورت “regular” داشته و تلاش مضاعفی به منظور افزودن رکورد “deny all” به زیردامنه فاقد ترافیک ایمیل صورت گرفته باشد. حتما توجه داشته باشید که دریافت ایمیل معادل ارسال آن نیست: یک دامنه می­تواند دریافت ­کننده ایمیل خوبی بوده ولی هرگز منبع آن نباشد.

این مساله در ارتباط با دامنه ­های با اهداف بازاریابی کوتاه­ مدت (به عنوان مثال حوادث، تبلیغاتی با محدوده زمانی مشخص، عرضه کالاهای جدید و …)، ایمیل­های ورودی به این دامنه­ ها از production domain ارسال شده و هرگونه پاسخی به این ایمیل­ ها از همین دامنه ارسال می­شود.

این دامنه­ های کوتاه مدت تنها یک رکورد MX معتبر داشته ولی ملزم به دارا بودن رکورد SPF نیز هست که آنها را به عنوان یک منبعی که حاوی ترافیک ایمیل نیست، مطرح میکند.

 الزامات پیاده­ سازی DKIM

 DKIM  برای گیرندگان

پیکربندی احراز هویت DKIM در ESA مشابه SPF است. در پالیسی­ های پیش­فرض اعمالی به Mail Flow تنها کافیست اعتبارسنجی DKIM را در حالت “on” قرار دهید. با­توجه به اینکه DKIM مجوزpolicy specification را نمی­دهد، بنابراین این گزینه تنها به تایید امضا و اعمال هدر “Authentication-Results” می­پردازد:

Authentication-Results: mx1.hc4-93.c3s2.smtpi.com; dkim=pass (signature verified)
header.i=MileagePlus@news.united.com

هرگونه اقدامی براساس اعتبارسنجی DKIM براساس فیلترهای محتوا صورت می­گیرد:

برخلاف SPF که رویکرد ساده­ای دارد، DKIM اصل پیام را مدیریت کرده و بنابراین برخی پارامترها محدود خواهند شد. امکان ایجاد پالیسی دلخواه متناسب با سازمان و اختصاص پروفایل­های اعتبارسنجی متفاوت به Mail Flow Policies وجود دارد.

این مساله امکان محدودکردن سایز کلید امضاهای مورد پذیرش، تعریف اقدامات بازیابی در صورت نامعتبر بودن کلید و پیکربندی میزان اعتبارسنجی DKIM را در اختیار شما قرار می­دهد.

زمانی­که پیام از چندین گیت­وی عبور می­کند، امکان وجود چندین امضا حین عبور از این گیت­وی وجود دارد. پیامی که به صورت DKIM اعتبارسنجی می­شود نیاز به تایید هر یک از این امضاها دارد. به صورت پیش­فرض ESA قابلیت تایید اعتبار تا پنج امضا را دارد.

با توجه به اینکه به صورت تاریخی SMTP و ایمیل ساختار آشکاری دارند و سیستم اینترنت به صورت کلی در مقابل تغییرات-هر چند مثبت- مقاومت بالایی دارد، بنابراین موقعیت­ هایی که امضا DKIM به صورت قانونی Fail شوند، وجود خواهد داشت؛ به عنوان مثال زمانیکه پیام ها در عوض تغییر به پیام جدید و یا ارسال بصورت پیوست مستقیما فوروارد میشوند.

به همین دلیل در بسیاری از حالت­های failing DKIM شایسته است پیام قرنطینه یا بر چسب­ گذاری شده و رها نشود.

 فراهم کردن امضا به­ وسیله  DKIM

پیش از فعال کردن  امضا DKIM  در RELAYED Mail Flow Policy، ملزم به تولید/ورود کلیدها، ایجاد پروفایل امضاDKIM  و انتشار کلید عمومی آن در DNS هستید.

چنانچه از چندین دامین مجزا امضا دریافت شده باشد، روند پیچیده ­تری به وجود خواهد آمد. در این حالت شما دو راه پیش­رو خواهید داشت:

1. برای ثبت ­نام در تمامی دامنه­ ها از پروفایل امضا واحدی استفاده کنید. تنها یک کلید عمومی در DNS دامین “master” نگهداری کنید و امضا DKIM به این کلید ارجاع داده شود. این روش قبلا در ESPs مورد استفاده قرار می­گرفت و امکان امضا در مقیاس­ های بالا بدون نیاز به هیچ­گونه تعاملی با فضای DNS مشتریان را فراهم می­کرد(این روش مبتنی بر این واقعیت است که در اصل DKIM منبع پیام را همانطور که در Mail From و یا Header From بیان شده است تایید نمیکند. این مساله تنها تایید کننده صحت شناسه دامنه امضاکننده و وجود کلید عمومی در آن میزبان است ( پارامتر “d” در امضا DKIM و “domain name” در پروفایل امضا). اصالت فرستنده از طریق بررسی وجود هدر امضا “from” تایید میشود. فقط از وجود کلیه دامنه­ ها  و زیردامنه­ ها در بخش “profile users” اطمینان حاصل کنید.).
2. یک پروفایل امضا مجزا برای هر یک از دامین­ هایی که امضا کرده ­اید، ایجاد کنید. این مساله الزامات پیکربندی پیچیده­ تری دارد ولی انعطاف­پذیری بیشتری دارد. برای هر یک از دامنه­ ها یک جفت کلید ایجاد کرده و پروفایل ویژه­ای برای هر یک از دامنه­ ها در بخش “Profile Users” ساخته (شامل زیر دامنه­ ها نیز خواهد بود) و کلید عمومی مرتبط با آن دامین را در DNS مرتبط با آن منتشر می­کنیم.

اگرچه گزینه a ساده ­تر خواهد بود ولی در نهایت احتمال شکست DMARC وجود دارد، زیرا نیاز به هماهنگی شناسه Signing Domain و Header From است؛ بنابراین احتمال عدم هماهنگی میان شناسه و DKIM وجود دارد. برای رفع این مشکل نیاز به پیکربندی صحیح SPF و تطبیق شناسه SPF به­ منظور تایید DMARC است.

از طریق استقرار گزینه b، دیگر نیازی به نگرانی در خصوص DMARC نیست و ابطال و پیکربندی مجدد سرویس امضا برای یک تک دامین بسیار ساده خواهد بود. همچنین چنانچه سرویس ایمیلی برای دامین 3^rd party ارایه می­کنید، ملزم به دریافت کلید (و ورود آن به ESA خود) از آنها هستید. این کلید مختص به آن دامنه بوده بنابراین باید پروفایل مجزایی برای آن ساخته شود.

 چنانچه از سرویس های ایمیل 3^rd party استفاده می­کنید

چنانچه از امضا DKIM استفاده کرده و بخشی از فرآیندهای پردازش ایمیل خود ( مانند بازاریابی از طریق ایمیل) را به 3^rd party واگذار کرده­اید، قطعا شما تمایلی به استفاده آنها از کلیدهای مشابه خود ندارید. این مساله یکی از دلایل اصلی وجود سلکتور در DKIM است. در عوض ملزم به ایجاد یک جفت کلید جدید و انتشار آن در DNS خود و ارسال کلید خصوصی به سایرین هستید. به این ترتیب شما به سرعت امکان ابطال آن کلید در شرایط خاص بدون هرگونه تغییر در زیرساخت DKIM خود را دارید.

اگر چه ساخت زیر دامنه مجزا برای هر ایمیل مرتبط با 3^rd party در DKIM (پیام­های مرتبط با یک دامنه مشابه امکان امضا توسط کلیدهای چندگانه متفاوت را دارند) ضروری نیست، ولی بهتر است دامنه ­های مجزا مورد استفاده قرار گیرند. این روش موجب ردیابی ساده ­تر پیام­ها و پیاده­ سازی ساده­تر DMARC می­شود. به عنوان مثال پنج هدر DKIM-Signature از پیام­های چندگانه Lufthansa را در نظر بگیرید:

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa;
d=newsletter.milesandmore.com;
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa2; d=newsletter.lufthansa.com;
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa3; d=lh.lufthansa.com;
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa4; d=e.milesandmore.com
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa5; d=fly-lh.lufthansa.com;

همان­گونه که مشاهده می­کنید، Lufthansa از پنج کلید متفاوت (سلکتور) که در پنج زیر دامنه مجزا از دو production     lufthansa.com) domain و milesandmore.com) تقسیم شده است. این به­ معنی امکان کنترل مستقل و برون­ سپاری هر یک به ارایه ­دهندگان سرویس متفاوت است.

 ادامه دارد…

برای مطالعه بخش دوم راهکارهای احراز هویت ایمیل با استفاده Cisco ESA اینجا کیلیک کنید.