یک تیم محصول چگونه باید خطاهای احراز هویت ایمیل در Yahoo را به‌صورت امن عیب‌یابی کند؟

پیش از تغییر DNS، ماهیت خطا را روشن کنید

عبارت Yahoo mail authentication failed می‌تواند دو مشکل متفاوت را توصیف کند. ممکن است یک کلاینت ایمیل نتواند وارد حساب Yahoo شود، یا سیستم دریافت Yahoo یک ایمیل محصول را رد کند چون احراز هویت فرستنده برقرار نشده است. این راهنما به حالت دوم می‌پردازد: SPF، DKIM، DMARC و سیاست‌های مرتبط گیرنده در حین تحویل SMTP. صرفاً چون یک MX گیرنده ردی مرتبط با احراز هویت برگردانده، رمز عبور کاربران را بازنشانی نکنید، app password نسازید یا اعتبارنامه‌های ارسال production را نچرخانید. از شواهد دقیق شروع کنید. پاسخ کامل SMTP با کد پیشرفته را بدون کوتاه کردن متن عیب‌یابی آن ثبت کنید، به‌همراه hostname مربوط به MX راه دور، زمان، گیرنده، شناسه تلاش تحویل، IP ارسال، دامنه SMTP MAIL FROM، دامنه From قابل‌مشاهده طبق RFC 5322 و دامنه و selector هر امضای DKIM. در تیکت‌های مشترک، local-partها و محتوای پیام را redact کنید، مگر اینکه واقعاً لازم باشند. یک عبارت کپی‌شده بدون کد وضعیت و بافت هویتی آن برای یافتن راه‌حل امن کافی نیست.

پاسخ‌های موقت و دائمی Yahoo را دسته‌بندی کنید

Sender Hub در Yahoo پاسخ‌های SMTP با کد 421 را تعویق موقت و پاسخ‌های 553 یا 554 را مشکل دائمی تحویل دسته‌بندی می‌کند. راهنمای فعلی خطاهای آن شامل موارد موقتی است که نتایج احراز هویت به‌دلیل یک خطای گذرا قابل‌تعیین نبوده‌اند، و موارد دائمی که پیام در بررسی‌های سیاست DMARC یا DKIM دامنه فرستنده رد شده است. از پاسخ واقعی استفاده کنید، نه اینکه فرض کنید هر واژه مرتبط با احراز هویت یعنی همان وضعیت. برای پاسخ 4xx، پیام صف‌شده را نگه دارید و با exponential backoff محدود، jitter، حداکثر عمر صف و سقف تعداد تلاش دوباره تلاش کنید. برای پاسخ 5xx، تا زمانی که خطای پیکربندی یا محتوا روشن نشده، ارسال مجدد خودکار را برای آن گیرنده و هویت پیام متوقف کنید. کوبیدن مکرر روی یک رد دائمی، نویز و ریسک ارسال تکراری را افزایش می‌دهد بدون اینکه DNS را اصلاح کند. اگر نشست SMTP پیش از پاسخ نهایی به‌صورت مبهم پایان یافت، تلاش را نامشخص علامت بزنید و آن را تطبیق دهید، به‌جای اینکه فوراً یک پیام منطقی جدید بسازید.

زنجیره هویت را برای یک پیام کنترل‌شده ردیابی کنید

برای یک نمونه ناموفق کنترل‌شده، جدول فشرده‌ای از هویت‌ها بسازید. IP اتصال؛ نام reverse DNS؛ نام EHLO؛ دامنه SMTP MAIL FROM که SPF از آن استفاده می‌کند؛ دامنه From قابل‌مشاهده که DMARC از آن استفاده می‌کند؛ دامنه امضای d= و selector s= هر امضای DKIM؛ و دامنه‌هایی که در حال حاضر رکوردهای SPF، DKIM و DMARC را منتشر می‌کنند در آن بگنجانید. این نام‌ها را از DNS authoritative و دست‌کم دو resolver بازگشتی مستقل کوئری کنید. پاسخ‌ها، TTLها و پاسخ‌های منفی را همراه با زمان نگه دارید. سپس آن‌ها را با بایت‌ها و هدرهای دقیق نمونه ارسال‌شده مقایسه کنید. فقط وضعیت کلی دامنه در داشبورد فروشنده را آزمایش نکنید: ممکن است زیردامنه، selector، return path، جریان یا tenant دیگری در production باشد. پیام موفقی از ارائه‌دهنده یا قالب دیگر هم مسیر ناموفق را اثبات نمی‌کند. گیرنده را کنترل‌شده نگه دارید، در هر آزمون فقط یک متغیر را تغییر دهید و ضمن حفظ همان پیکربندی دامنه احرازهویت‌شده، از یک شناسه ردیابی جدید استفاده کنید.

مجوز SPF را بدون اشتباه گرفتن با هم‌راستایی From بررسی کنید

SPF ارزیابی می‌کند که آیا IP متصل‌شونده برای هویت SMTP مجاز است، که طبق قواعد پروتکل معمولاً دامنه MAIL FROM یا هویت HELO است. دامنه دقیقی را که در تلاش ناموفق استفاده شده کوئری کنید. تأیید کنید که یک رکورد SPF با سینتکس معتبر وجود دارد، همه مقصدهای include و redirect resolve می‌شوند، IP ارسال واقعی ارائه‌دهنده پوشش داده شده و ارزیابی DNS در محدوده پروتکل می‌ماند. صرفاً برای موفق شدن یک آزمون، رکورد TXT دومی کنار سیاست موجود کپی نکنید یا مکانیزمی بیش از حد گسترده اضافه نکنید. نتیجه مثبت SPF به‌تنهایی ممکن است وقتی دامنه احرازهویت‌شده آن با دامنه From قابل‌مشاهده هم‌راستا نیست، همچنان در DMARC رد شود. به همین ترتیب، forwarding می‌تواند IP متصل‌شونده را تغییر دهد و SPF را حتی وقتی فرستنده اصلی مجاز بوده از کار بیندازد. پیکربندی return-path یا ارائه‌دهنده مسئول را اصلاح کنید و سپس به‌جای اتکای صرف به یک ابزار بررسی DNS، یک پیام کنترل‌شده و شواهد Authentication-Results آن را بررسی کنید.

DKIM را روی همان پیامی که Yahoo ارزیابی کرده اعتبارسنجی کنید

همه هدرهای DKIM-Signature را در نمونه کنترل‌شده پیدا کنید. برای امضایی که قرار است فرستنده قابل‌مشاهده را احراز هویت کند، دامنه d=، selector s=، حالت‌های canonicalization، فهرست هدرهای امضاشده، hash بدنه، الگوریتم و هر timestamp یا زمان انقضا را استخراج کنید. selector را در s._domainkey.d کوئری کنید و تأیید کنید که کلید منتشرشده به‌روز، با قالب درست و از resolverهای خارجی در دسترس است. امضا را با بایت‌های اصلی پیام اعتبارسنجی کنید؛ کپی کردن بدنه در یک تیکت یا serialize مجدد MIME می‌تواند نمونه آزمایشی را نامعتبر کند. خطاهای رایج شامل امضا با دامنه غیرمنتظره، انتشار کلید با selector یا zone اشتباه، چرخش پیش از همگرایی کش‌ها، تغییر هدرهای امضاشده یا محتوای بدنه پس از امضا، و استفاده از قالب یا مسیر relay که امضا را دور می‌زند است. برای اصلاح یک جریان، سیاست DKIM را حذف نکنید یا همه امضاها را تضعیف نکنید. مشخص کنید کدام جزء پیام را ساخته یا تغییر داده و همان مسیر را اصلاح کنید.

موفقیت و هم‌راستایی DMARC را صریحاً ارزیابی کنید

DMARC از دامنه From قابل‌مشاهده استفاده می‌کند و یک موفقیت هم‌راستا در SPF یا DKIM را الزامی می‌داند. یک سازوکار احراز هویت می‌تواند از نظر فنی موفق باشد اما ناهم‌راستا بماند: SPF ممکن است دامنه return-path ارائه‌دهنده را احراز هویت کند، یا DKIM ممکن است با دامنه فروشنده‌ای که به From قابل‌مشاهده ربطی ندارد امضا کند. _dmarc را برای سیاست قابل‌اعمال در سطح سازمان یا زیردامنه کوئری کنید و تگ‌های فعلی را ثبت کنید. سپس نتیجه SPF و هم‌راستایی دامنه آن، نتیجه DKIM و هم‌راستایی دامنه هر امضا و نتیجه نهایی DMARC را ارزیابی کنید. الزامات فرستندگان Yahoo در حال حاضر می‌گوید همه فرستندگان دست‌کم به SPF یا DKIM نیاز دارند؛ فرستندگان انبوه به SPF و DKIM هر دو، یک سیاست DMARC معتبر دست‌کم با p=none، موفقیت DMARC و هم‌راستایی دامنه From با دامنه SPF یا DKIM نیاز دارند. این‌ها را الزامات فعلی Yahoo بدانید و صفحه رسمی را دوباره بررسی کنید. سیاست p=none نحوه برخورد را پایش می‌کند؛ پیام ناموفق را احرازهویت‌شده نمی‌کند و امتیازی برای تحویل نمی‌دهد.

از Authentication-Results به‌عنوان شاهد استفاده کنید، نه دستورالعمل

RFC 8601 فیلد هدر Authentication-Results را برای اینکه یک سرویس احراز هویت مورد اعتماد نتایج را اعلام کند تعریف می‌کند. نتیجه‌ای را که گیرنده یا یک gateway مورد اعتماد اضافه کرده بخوانید، از جمله روش، نتیجه، هویت ارزیابی‌شده و ویژگی‌های توضیحی. به هدر Authentication-Results که یک فرستنده غیرقابل‌اعتماد ارائه کرده یا از یک hop نامرتبط کپی شده اعتماد نکنید. پاسخ SMTP مربوط به Yahoo را با نتایج گیرنده کنترل‌شده خودتان و لاگ‌های ارائه‌دهنده مقایسه کنید و به یاد داشته باشید که گیرندگان مختلف ممکن است دید DNS، سیاست یا تغییرات پیام متفاوتی داشته باشند. هدرهای اصلی را برای تحلیل حادثه با کنترل دسترسی نگه دارید. یک نمونه دریافتی می‌تواند نشان دهد چرا همان نمونه موفق یا ناموفق شده است؛ نمی‌تواند درستی همه جریان‌های ارسال را ثابت کند. گزارش‌های تجمیعی DMARC می‌توانند الگوهای گسترده‌تر هم‌راستایی را آشکار کنند، اما با تأخیر و به‌صورت تجمیعی می‌رسند و به نگهداری آگاه از حریم خصوصی و مقصدهای گزارش مجاز نیاز دارند.

به‌صورت محدود اصلاح کنید و همگرایی DNS را آزمایش کنید

کوچک‌ترین تغییری را انتخاب کنید که هویت مشاهده‌شده را اصلاح می‌کند. برای مثال: افزودن منبع ارسال واقعی به سیاست SPF موجود، پیکربندی ارائه‌دهنده برای استفاده از یک return path سفارشی هم‌راستا، انتشار selector درست DKIM، فعال کردن امضا در جریانی که آن را جا انداخته، جلوگیری از تغییر محتوای امضاشده توسط یک relay، یا پیکربندی یک دامنه d= هم‌راستا. سینتکس و مالکیت DNS را بازبینی کنید، رکورد قبلی را نگه دارید، در تغییرات برنامه‌ریزی‌شده TTL را از قبل کاهش دهید و از کنترل‌های تغییر معمول استفاده کنید. هرگز secretها یا کلیدهای خصوصی را در تیکت یا رکورد DNS منتشر نکنید؛ DNS مربوط به DKIM فقط کلید عمومی را در بر دارد. پس از تغییر، سرورهای authoritative و چند resolver بازگشتی را تا زمانی که پاسخ موردنظر دیده شود کوئری کنید. چند پیام کنترل‌شده به گیرندگان آزمایشی جداگانه در Yahoo ارسال کنید، شواهد کامل SMTP و هدرها را نگه دارید و دقیقاً همان سازوکار تغییرکرده را بررسی کنید. تغییرات SPF، DKIM، DMARC، IP، قالب و حجم را در یک آزمون ترکیب نکنید، چون در صورت موفقیت معلوم نمی‌شود کدام تغییر مؤثر بوده است.

به‌آرامی از سر بگیرید و نتایج تحویل را جدا نگه دارید

وقتی پیام‌های کنترل‌شده احراز هویت شدند، فقط جریان آسیب‌دیده را تدریجاً افزایش دهید. تعویق‌های موقت، ردهای دائمی، برگشت‌های ارائه‌دهنده، سیگنال‌های گزارش اسپم، عمر صف و نتایج احراز هویت را بر اساس دامنه، selector، IP ارسال و نوع پیام پایش کنید. نشانی گیرندگان و محتوای پیام را از معیارها دور نگه دارید؛ از شناسه‌های محدود یا آمار تجمیعی کلی استفاده کنید. بهترین شیوه‌های Yahoo علاوه بر احراز هویت، نرخ پایین گزارش اسپم، DNS مستقیم و معکوس معتبر برای IPهای ارسال و ایمیل منطبق با RFC را الزامی می‌دانند، در حالی که الزامات فرستندگان انبوه شامل رفتار لغو اشتراک آسان است. بنابراین نتیجه احراز هویت اصلاح‌شده، پذیرش هر پیام توسط سرور گیرنده، رسیدن به صندوق ورودی یا تعامل را وعده نمی‌دهد. پذیرش ارسال توسط ارائه‌دهنده، پذیرش SMTP توسط Yahoo، شواهد تحویل بعدی، قرار گرفتن در پوشه صندوق و اقدام کاربر را از هم تفکیک کنید. اگر نرخ رد دوباره بالا رفت، به‌جای انتقال ترافیک احرازهویت‌نشده به IP یا دامنه دیگر، گروه آسیب‌دیده را متوقف کنید. این نوع دور زدن، علت ریشه‌ای را پنهان می‌کند و می‌تواند آسیب اعتبار را گسترش دهد.

از مستندات دامنه و DNS ‏SendHQ استفاده کنید

برای پیکربندی ویژه SendHQ، مستندات کنونی Domains و DNS را دنبال کنید که هویت‌های فرستنده، DNS، SES، انتشار و وضعیت‌های تعمیر را پوشش می‌دهد.

پرسش‌های متداول

منابع

• الزامات و توصیه‌های Yahoo برای فرستندگان — Yahoo
• کدهای خطای SMTP در Yahoo — Yahoo
• RFC 7208: چارچوب سیاست فرستنده (SPF) — RFC Editor
• RFC 6376: امضاهای DomainKeys Identified Mail (DKIM) — RFC Editor
• RFC 9989: احراز هویت، گزارش‌دهی و انطباق پیام مبتنی بر دامنه (DMARC) — RFC Editor
• RFC 8601: فیلد هدر پیام برای نمایش وضعیت احراز هویت پیام — RFC Editor
• RFC 5321: پروتکل ساده انتقال ایمیل (SMTP) — RFC Editor