
read receipts
چرا ایمیلی که برای خودتان فوروارد کردید در اسپم فرود آمد
شما اشتباه نکردید. SPF این کار را کرد. این مکانیزمی است که هیچ کس از ارائهدهندهی سرویس شما آن را توضیح نمیدهد.
اگر فوروارد خودکار از حساب قدیمیتان به حساب جدید تنظیم کنید، بخشی از آن ایمیلها به آرامی در اسپم ناپدید خواهند شد — نه به این دلیل که ارائهدهندهی سرویس شما خراب است، بلکه به این دلیل که فوروارد کننده کسی را که پیام را ارسال میکند بازنویسی میکند بدون اینکه اثبات رمزنگاری را بازنویسی کند. SPF سرور غلط را بررسی میکند، نتیجهی DMARC به شکست تبدیل میشود، و ایمیل مشروعی که خودتان برای خودتان ارسال کردید قرنطینه میشود. این راهحل نام دارد: ARC، که در RFC 8617 در سال ۲۰۱۹ تعریف شد.
چرا فوروارد کردن باعث شکست SPF میشود؟
زیرا SPF آخرین سروری را که پیام را منتقل کرد بررسی میکند، و فوروارد کردن آن سرور را تغییر میدهد. SPF — Sender Policy Framework — یک رکورد DNS است که فهرستی IPهای مجازی برای ارسال پیام برای یک دامنه را دارد. وقتی bank.com برای شما یک رسید ارسال میکند، سرور دریافتکننده بررسی میکند: آیا این پیام از IPای دریافت شده است که bank.com مجاز کرده است؟ بله. تایید میشود.
اکنون آن رسید را از Gmail خودتان به آدرس جدید فوروارد کنید. سرورهای گوگل آن را به جلو منتقل میکنند. سرور دریافتکننده نهایی بررسی SPF را اجرا میکند و میپرسد: آیا گوگل برای bank.com ارسال کردن مجاز است؟ خیر، نیست. SPF شکست میخورد. مستندات خود گوگل Workspace این را به وضوح بیان میکند — پیامهای فوروارد شده به SPF ناکام میشوند زیرا سرور فوروارد کننده در رکورد SPF دامنهی اصلی وجود ندارد. هیچ کلاهبرداری نشد. بررسی فقط به امتیاز اشتباه نگاه میکند.
پس چرا این آن را به اسپم میفرستد؟
DMARC. قبلاً شکست SPF تنهایی قابل تحمل بود؛ DMARC آن را به یک نتیجه تبدیل کرد. DMARC، SPF و DKIM را به هم میبندد و به گیرندگان میگوید چه باید کنند وقتی هر دو شکست بخورند: کاری نکنند، قرنطینه کنند، یا رد کنند. تا سال ۲۰۲۴، فرستندگان بزرگ هیچ گزینهای نداشتند — گوگل و یاهو شروع کردند به الزام DMARC برای هر کسی که بیش از ۵۰۰۰ پیام در روز برای کاربرانشان ارسال میکند.
DKIM، ستون دیگر، امضائی است که در پیام گنجانده شده است. تئوریکی، این از فوروارد کردن جان سالم به در میبرد، زیرا محتوا را امضا میکند، نه مسیر را. عملاً، هرچیز که به پیام دست زند آن را میشکند. یک لیستهای پیامرسانی که پایصفحهی «شما اشتراک دارید، لغو اشتراک» اضافه میکند، سروری که خط موضوع را بازنویسی میکند، حتی تغییری در نحوهی بستهبندی خط — امضا دیگر مطابقت نمیکند، و DKIM هم شکست میخورد. اکنون هر دو ستون فرو میریزند، DMARC میگوید شکست، و رسید خودتان در پوشهی spam است.
ARC چیست و آیا واقعاً این را تعمیر میکند؟
ARC — Authenticated Received Chain، RFC 8617 — اجازه میدهد به فوروارد کنندهی صادق که تضمین کند پیام قبل از اینکه به آن دست زند از احرازهویت گذشته است. سرور فوروارد کننده پیام را با رکورد مختوم مهر میکند و میگوید «وقتی این به من رسید، SPF و DKIM معتبر بودند — کلام من را برای بخشی که نمیتوانی تأیید کنی باور کن.» گیرندهی نهایی، اگر این فوروارد کننده را باور کند، میتواند شکست DMARC را نادیده بگیرد و تحویل دهد.
مصیبت در «اگر باور کند» است. ARC یک رمز عبور نیست؛ یک سیستم شهرت است. گیرنده وزن میکند که آیا ARC sealer یک اپراتور شناختهشدهی خوشرفتار است. گوگل هم سرصحافتهای ARC را مهر میکند و هم آنها را از فرستندگانی که به آنها اعتماد میکند احترام میگذارد، به همین دلیل است که فوروارد Gmail به Gmail معمولاً جان سالم به در میبرد در حالی که فوروارد از طریق برخی relayهای دانشگاهی قدیمی چنین نیست.
اگر شما خود فوروارد کنندگی را اجرا میکنید، دو اقدام عملی کمک میکند. از Server-Side Redirect / بازنویسی SRS استفاده کنید اگر میزبان شما آن را ارائه دهد، که فرستندهی پاکت را بازنویسی میکند تا SPF بررسی کند در برابر فوروارد کنندهی شما به جای دامنهی اصلی. و فوروارد کردن بین ارائهدهندگانی را ترجیح دهید که هر دو ARC را پشتیبانی میکنند. اگر حسابهایتان را یکپارچه میکنید و میخواهید مقصد فقط برای شما این درهمآمیختگی احرازهویت را حل کند، این دقیقاً نوع لولهکشی است که پلتفرم ایمیل AI برای جذب آن ساخته شده است.
چه زمانی باید از تقصیر ارائهدهندهی سرویس خودتان دست بردارم؟
وقتی الگو این است که «فقط پیامهای فوروارد شده شکست میخورند،» ارائهدهندهی سرویس کار خود را به درستی انجام میدهد — مسئله پروتکل است. نشانه این است: پیام گمشدهی را باز کنید و به خط Authentication-Results نگاه کنید. اگر spf=fail را کنار IP فرستندگیای دیدید که متعلق به فوروارد کننده است نه فرستندهی اصلی، این SPF بررسی کردن امتیاز غلط است. اگر dkim=fail روی پیامهایی ظاهر شود که از لیستی یا relayای گذشتند که پیامها را ویرایش میکنند، این امضای خرابشده است، نه تقلب.
حقیقت ناخوشایند این است که احرازهویت ایمیل لایه به لایه، در طول دو دهه، بر روی سیستمی الصاق شده است که هرگز فرض نمیکرد کسی دروغ میگوید. SPF در سال ۲۰۰۶ آمد، DKIM در سال ۲۰۰۷، DMARC در سال ۲۰۱۵، ARC در سال ۲۰۱۹ — هر یک سوراخی را که یکی قبلی باز کرد وصله میکرد. فوروارد کردن تهی است که هر چهار تا در برابر یکدیگر مالیدند، و صندوق ورودی شما جایی است که تو اصطکاک را احساس میکنی.
@@END@@منابع
- IETF RFC 8617 — Authenticated Received Chain (ARC) specification, 2019
- Google Workspace Admin Help — SPF, forwarding and authentication for forwarded mail
- Google Email sender guidelines — 2024 bulk sender DMARC requirements and 5,000/day threshold