دو تغییر مایکروسافت ۳۶۵ در یک فصل از راه می‌رسند و هر دو سراغ دستگاه‌های بی‌سروصدایی می‌روند که تا وقتی از کار نیفتند، کسی در دفتر به آن‌ها فکر نمی‌کند. تیم Exchange در ۱ اکتبر ۲۰۲۶ نوشت که «کنارگذاشتن EWS در Exchange Online از امروز شروع میشود». تا ۲۱ اکتبر هم تأیید کرد که بازنشستگی «در جریان است» و EWS در برخی tenantها خاموش شده است. بعد، در پایان دسامبر ۲۰۲۶، احراز هویت Basic برای SMTP AUTH در tenantهای موجود بهطور پیشفرض غیرفعال میشود. این همان ورود با نام کاربری و رمز عبوری است که بیشتر اسکنرها و برنامه‌های تجاری قدیمی برای ارسال ایمیل از طریق smtp.office365.com به کار می‌برند.
برای یک شرکت کوچک در دبی یا ریاض که از دامنهٔ خودش ایمیل می‌فرستد، نشانه‌ها کسل‌کننده و پرهزینه‌اند. اسکن به ایمیل متوقف میشود. فاکتورها هیچ‌وقت به دست مشتری نمی‌رسند. کاربر مک هر ده دقیقه یک بار پنجرهٔ رمز عبور می‌بیند. در ادامه: چه چیزی کی تغییر میکند، چطور دستگاه‌های درگیر را زودتر پیدا کنید، و چطور هر کدام را بدون افتادن در اسپم منتقل کنید.
دقیقاً چه چیزی تغییر میکند
EWS: خاموشی tenant به tenant
Exchange Web Services یک API قدیمی است که برنامه‌ها با آن صندوق ایمیل و تقویم را می‌خوانند. طبق پست کنارگذاری اکتبر ۲۰۲۶ مایکروسافت، True کردن EWSEnabled دیگر به‌تنهایی کافی نیست: حالا یک فهرست مجاز به نام EWSAllowedAppIDs باید تک‌تک برنامه‌هایی را که اجازهٔ استفاده از EWS دارند نام ببرد. مایکروسافت این فهرست را در ۱۰ و ۱۱ اکتبر برای tenantهایی پر کرد که EWS را صریحاً فعال کرده بودند. tenantهایی که هیچ‌وقت به این تنظیم دست نزده‌اند، یک هشدار ۷ روزه در Message Center می‌گیرند. بعد از آن، مایکروسافت فهرست مجاز را بر اساس مصرف ۶۰ روز گذشته پر میکند و EWSEnabled را False میکند.
پست عیب‌یابی تیم Exchange نرم‌افزارهایی را که بیشترین احتمال خرابی دارند نام می‌برد: Apple Mail و Calendar در macOS، نسخهٔ کلاسیک Outlook برای مک، برخی افزونه‌های Outlook دسکتاپ، نسخههای قدیمی Outlook در ویندوز، و ابزارهای شخص ثالث مثل برنامه‌های پشتیبان‌گیری. مدیرها می‌توانند EWS را دوباره روشن کنند، اما فقط برای مدتی. به گفتهٔ خود مایکروسافت، «فعال‌سازی دوبارهٔ EWS از آوریل ۲۰۲۷ دیگر کار نمی‌کند.»
SMTP AUTH: احراز هویت Basic از پایان دسامبر بهطور پیشفرض خاموش
این مهلت قبلاً هم جابه‌جا شده است. اعلامیهٔ آوریل ۲۰۲۴ مایکروسافت قرار بود رد کردن ارسال‌های Basic را از ۱ مارس ۲۰۲۶ شروع کند و در ۳۰ آوریل ۲۰۲۶ به رد ۱۰۰٪ برسد. مایکروسافت در ژانویهٔ ۲۰۲۶ برنامه را بازنگری کرد: تا دسامبر ۲۰۲۶ تغییری نیست، در پایان دسامبر Basic برای tenantهای موجود بهطور پیشفرض غیرفعال میشود ولی مدیرها هنوز می‌توانند روشنش کنند، tenantهایی که بعد از دسامبر ساخته شوند بهطور پیشفرض Basic ندارند، و تاریخ حذف نهایی در نیمهٔ دوم ۲۰۲۷ اعلام میشود.
پس دسامبر تغییر پیشفرض است، نه پایان کار. اما روشن‌کردن دوباره فقط وقتی کمک میکند که کسی بداند اسکنر به آن وابسته است و اواخر دسامبر سر کار باشد. اعلامیهٔ ۲۰۲۴ مایکروسافت پاسخی را که کلاینت هنگام رد شدن Basic میگیرد ثبت کرده است: 550 5.7.30 Basic authentication is not supported for Client Submission. اگر این خط در لاگ یک دستگاه یا صفحهٔ خطای یک برنامه دیده شد، علت را پیدا کرده‌اید.
در یک دفتر کوچک معمولاً چه چیزی خراب میشود
بر اساس نرم‌افزارهایی که مایکروسافت نام برده و آنچه در محل مشتری‌ها می‌بینیم:
- پرینترها و اسکنرهای چندکاره‌ای که با smtp.office365.com، پورت 587 و رمز یک صندوق ایمیل تنظیم شده‌اند.
- نرم‌افزارهای حسابداری، ERP یا فاکتور الکترونیک که فاکتور و صورت‌حساب را از یک آدرس مشترک مثل [email protected] می‌فرستند.
- فرم‌های تماس وب‌سایت و افزونه‌های SMTP وردپرس که با رمز واقعی یک صندوق وارد می‌شوند.
- کاربران مک روی Apple Mail یا Outlook کلاسیک مک، از طریق EWS.
- ابزارهای پشتیبان‌گیری، بایگانی و مهاجرت که صندوق‌ها را از طریق EWS می‌خوانند.
گروه SMTP ریسک تحویل بیشتری دارد، چون راه‌حل معمول مسیر خروج ایمیل‌های شما را عوض میکند (گام ۳).
گام ۱: هر دستگاه و برنامه‌ای را که به این‌ها وابسته است پیدا کنید
برای SMTP AUTH از Exchange admin center شروع کنید. اعلامیهٔ اولیهٔ مایکروسافت گفته بود گزارش SMTP AUTH Clients Submission از نیمهٔ اکتبر ۲۰۲۴ نشان می‌دهد Basic استفاده میشود یا OAuth، پس این گزارش میگوید کدام حساب‌ها هنوز با رمز عبور ارسال میکنند. بعد تنظیمات را در Exchange Online PowerShell بررسی کنید. هر دو دستور از مستندات SMTP AUTH مایکروسافت آمده‌اند:
Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled
Get-CASMailbox -ResultSize unlimited | where {$_.SmtpClientAuthenticationDisabled -eq $false}اولی تنظیم کل سازمان را نشان می‌دهد. دومی صندوق‌هایی را فهرست میکند که SMTP AUTH در آن‌ها صریحاً فعال است، و در یک tenant کوچک معمولاً همان صندوق‌های مشترکی است که اسکنرها و برنامه‌ها با آن وارد می‌شوند. تنظیم سطح صندوق بر تنظیم سازمان مقدم است.
برای EWS، در Message Center دنبال «EWS will be disabled in your tenant in 7 days» یا «EWS has been disabled in your tenant» بگردید. این دو عنوانی است که تیم Exchange به مدیرها میگوید دنبالش باشند. بعد اجرا کنید:
Get-OrganizationConfig | Fl EWSEnabled
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Fl EwsAllowedAppIDsدستور دوم برنامه‌هایی را فهرست میکند که مایکروسافت در ۶۰ روز گذشته در tenant شما دیده است. برنامه‌ای که به آن متکی هستید و در این فهرست نیست، با محدود شدن EWS از کار می‌افتد. طبق پست کنارگذاری، تغییر EWSEnabled معمولاً ظرف یک ساعت اعمال میشود و ممکن است تا ۴ ساعت طول بکشد، اما تغییر فهرست مجاز ۲۴ ساعت زمان می‌برد. پشتیبانی مایکروسافت نمیتواند آن را برایتان دوباره فعال کند؛ فقط مدیر tenant میتواند.
گام ۲: برای هر فرستنده یک جایگزین انتخاب کنید
راهنمای مایکروسافت برای پرینترها، اسکنرها و برنامه‌های تجاری گزینه‌ها را شرح می‌دهد. بهطور خلاصه:
| روش | به چه کسانی می‌رسد | محدودیت‌های اعلام‌شدهٔ مایکروسافت | مناسب برای |
|---|---|---|---|
| SMTP AUTH با OAuth، smtp.office365.com پورت 587 | داخل و خارج شرکت | ۱۰٬۰۰۰ گیرنده در روز، ۳۰ پیام در دقیقه | دستگاه‌ها و برنامه‌هایی که firmware یا نسخهٔ فعلی‌شان OAuth را پشتیبانی میکند |
| High Volume Email، پورت 587 | فقط گیرندگان داخلی | بدون محدودیت تعداد گیرنده یا نرخ پیام | گزارش‌ها و هشدارهای داخلی |
| Azure Communication Services Email | داخل و خارج | طبق سرویس Azure | برنامه‌هایی که OAuth ندارند ولی باید به مشتری ایمیل بزنند |
| SMTP relay از طریق inbound connector، نقطهٔ MX شما روی پورت 25 | داخل و خارج | «محدودیت‌های معقول» | دستگاه‌های دفتر با IP ثابت و اختصاصی یا با گواهی |
| Direct Send، نقطهٔ MX شما روی پورت 25 | فقط گیرندگان داخلی | محدودیت استاندارد ایمیل ناشناس | آخرین گزینه |
نظر ما: هر جا firmware سازنده OAuth را پشتیبانی میکند از OAuth استفاده کنید، اسکنرهای قدیمی را پشت یک connector relay از IP ثابت دفتر بگذارید، و برای برنامه‌های ابری که به مشتری ایمیل می‌زنند یک سرویس ارسال احراز هویت‌شدهٔ جدا در نظر بگیرید. ما هیچ چیز تازه‌ای را روی Direct Send بنا نمی‌کنیم. صفحهٔ خود مایکروسافت میگوید این روش برای «مشتریان پیشرفته» است، نمیتواند به آدرسهای Gmail یا Yahoo تحویل بدهد، و مایکروسافت «روی گزینهای برای غیرفعال‌کردن پیشفرض Direct Send کار میکند».
یک نکته از همان صفحه حدس‌زدن را کم میکند: اگر دستگاهی «پورت TCP 465 را پیشنهاد میکند یا پیش‌فرضش است، نسخههای لازم TLS را پشتیبانی نمی‌کند» و برای client submission مناسب نیست. چنین اسکنری firmware تازه، یک relay یا تعویض لازم دارد.
گام ۳: مطمئن شوید مسیر جدید از SPF و DKIM و DMARC رد میشود
با SMTP AUTH، ایمیل از سرورهای مایکروسافت خارج می‌شد و include:spf.protection.outlook.com فعلی شما آن را پوشش می‌داد. با connector relay، راهنمای مایکروسافت میگوید باید IP دفتر را «به‌عنوان منبع پیام در رکورد SPF» اضافه کنید، وگرنه پیام‌ها ممکن است در Junk بیفتند. اگر برنامه‌ای را به سرویس ارسال دیگری ببرید، سرورهای فرستنده باز هم عوض می‌شوند.
راهنمای فرستندگان گوگل از همهٔ کسانی که به Gmail ایمیل می‌فرستند می‌خواهد SPF یا DKIM داشته باشند، DNS رفت و برگشت (PTR) معتبر نگه دارند، از TLS استفاده کنند و نرخ اسپم گزارش‌شده در Postmaster Tools را زیر ۰٫۳٪ نگه دارند. بالای ۵٬۰۰۰ پیام در روز به Gmail، DMARC هم لازم است و دامنهٔ From باید با SPF یا DKIM هم‌راستا باشد. Outlook.com هم قواعد خودش را برای فرستندگان پرحجم دارد که در راهنمای ما دربارهٔ خطای 550 5.7.515 توضیح داده‌ایم.
رکوردهای فعلی‌تان را از هر ترمینالی بررسی کنید:
dig +short TXT yourcompany.ae
dig +short TXT _dmarc.yourcompany.ae
dig +short CNAME selector1._domainkey.yourcompany.aeاولی باید یک رکورد که با v=spf1 شروع میشود برگرداند؛ راهنمای SPF مایکروسافت میگوید برای هر دامنه فقط یک رکورد SPF داشته باشید. دومی باید سیاست DMARC شما را نشان دهد. اگر امضای DKIM را در مایکروسافت ۳۶۵ روشن کرده باشید، سومی باید به یک نام میزبان مایکروسافت اشاره کند، با همان CNAMEهای selector1 و selector2 که مایکروسافت شرح داده است. بعد از افزودن IP یک relay، رکورد SPF شبیه نمونهٔ خود مایکروسافت میشود:
v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -allتعداد includeها را بشمارید. بخش 4.6.4 از RFC 7208 ارزیابی SPF را به ۱۰ عبارتِ نیازمند پرس‌وجوی DNS محدود میکند، و هر include: به‌همراه includeهای تودرتوی داخلش شمرده میشود. دو یا سه سرویس بیرونی به رکورد اضافه کنید و ممکن است از سقف رد شوید؛ آن وقت SPF برای همهٔ پیام‌ها خطای دائمی برمی‌گرداند، حتی پیام‌هایی که قبلاً رد می‌شدند.
بعد آزمایش کنید: از هر دستگاه منتقل‌شده به یک آدرس Gmail و یک آدرس Outlook.com که در اختیار دارید ایمیل بفرستید و هدرهای کامل را باز کنید. باید در خط Authentication-Results برای دامنهٔ خودتان spf=pass و dkim=pass و dmarc=pass ببینید. در پیام‌هایی که مایکروسافت دریافت میکند، همان هدر نتیجهٔ compauth را هم دارد که در مرجع هدرهای ضداسپم مایکروسافت توضیح داده شده است. بعد از تغییر، نرخ اسپم دامنه را در Google Postmaster Tools زیر نظر بگیرید، و اگر حالا از IP دفتر خودتان ارسال می‌کنید، Microsoft SNDS را هم.
همهٔ تاریخ‌ها در یک جا
- اکنون: مایکروسافت EWS را tenant به tenant غیرفعال میکند و ۷ روز قبل در Message Center هشدار می‌دهد (منبع).
- پایان دسامبر ۲۰۲۶: SMTP AUTH Basic برای tenantهای موجود بهطور پیشفرض غیرفعال میشود و tenantهای ساخته‌شده بعد از دسامبر بهطور پیشفرض آن را ندارند (منبع).
- آوریل ۲۰۲۷: امکان فعال‌سازی دوبارهٔ EWS از کار می‌افتد (منبع).
- نیمهٔ دوم ۲۰۲۷: مایکروسافت تاریخ حذف نهایی SMTP AUTH Basic را اعلام میکند (منبع).
اگر این ماه فقط یک کار می‌کنید، گزارش SMTP AUTH را خروجی بگیرید، کنار هر حساب بنویسید کدام دستگاه یا برنامه است، و جایگزین هر چیزی را که به مشتری ایمیل میزند آزمایش کنید. اسکنر میتواند صبر کند. سیستم صورت‌حسابی که در ژانویه بی‌صدا ارسال فاکتور را متوقف کند، نه.
ایمیل خودمیزبان کجای این ماجراست
بعضی تیم‌ها این تغییرات را دلیلی برای راه‌اندازی سرور ایمیل خودشان می‌دانند. تا حدی حق دارند. روی سرور خودتان، سیاست احراز هویت اسکنرها دست شماست: می‌توانید ورود با رمز را فقط از شبکهٔ دفتر مجاز کنید، و هیچ فروشنده‌ای آن را طبق تقویم خودش بازنشسته نمی‌کند. ولی گیرنده‌ها همان قواعدی را که برای مایکروسافت اعمال میکنند برای شما هم اعمال میکنند: SPF، DKIM، DMARC، DNS معکوس و یک IP تمیز. فن‌میل، محصول ایمیل سازمانی فنپینو که بر پایهٔ Stalwart Mail Server ساخته شده، به‌صورت مدیریت‌شده یا خودمیزبان ارائه میشود و این رکوردها از روز اول تنظیم شده‌اند. اگر گزینه‌ها را مقایسه می‌کنید، مقایسهٔ فن‌میل با Google Workspace و Zoho Mail هزینه و کنترل داده را پوشش می‌دهد و مطلب ما دربارهٔ آخرین به‌روزرسانی ESU برای Exchange به شرکت‌هایی می‌پردازد که هنوز Exchange را روی سرور خودشان اجرا میکنند.
پرسش‌های متداول
آیا اسکنر من از ۱ ژانویهٔ ۲۰۲۷ دیگر ایمیل نمیفرستد؟
ممکن است. مایکروسافت میگوید SMTP AUTH Basic در پایان دسامبر ۲۰۲۶ برای tenantهای موجود بهطور پیشفرض غیرفعال میشود. مدیر میتواند دوباره روشنش کند تا وقتی مایکروسافت تاریخ حذف نهایی را اعلام کند، که برنامه دارد در نیمهٔ دوم ۲۰۲۷ این کار را بکند.
آیا این روی Outlook لپتاپ و گوشی کارکنان اثر میگذارد؟
بیشتر نه. مایکروسافت حذف Basic از بقیهٔ پروتکلهای Exchange Online را اواخر ۲۰۲۲ تمام کرد. استثناها Outlook کلاسیک مک و نسخههای خیلی قدیمی ویندوز هستند که از EWS استفاده میکنند.
میتوانم اسکنر را به Direct Send وصل کنم؟
فقط اگر به افراد داخل شرکت ایمیل میزند. Direct Send نمیتواند به آدرسهای بیرونی تحویل بدهد، مایکروسافت آن را فقط برای مشتریان پیشرفته توصیه میکند و روی گزینهای برای خاموشکردن پیشفرض آن کار میکند.
کاربران مک ما مدام پنجرهٔ رمز عبور می‌بینند. این همان تغییر EWS است؟
به احتمال زیاد، اگر از Apple Mail یا Outlook کلاسیک مک استفاده میکنند. توصیهٔ مایکروسافت رفتن به Outlook جدید مک است که تحت تأثیر نیست. برای Outlook کلاسیک، شناسهٔ برنامهٔ «Microsoft Office» باید در فهرست EWSAllowedAppIDs باشد.
اگر کمتر از ۵٬۰۰۰ ایمیل در روز میفرستیم، DMARC لازم داریم؟
Gmail زیر این حجم فقط SPF یا DKIM را الزامی میداند. ما باز هم DMARC را منتشر میکنیم، با p=none شروع، چون همین است که جلوی ارسال دیگران به نام دامنهٔ شما را میگیرد.
منابع: پست‌های تیم Exchange مایکروسافت در ۱ اکتبر ۲۰۲۶، ۲۱ اکتبر ۲۰۲۶، ژانویهٔ ۲۰۲۶ و آوریل ۲۰۲۴؛ Microsoft Learn دربارهٔ ارسال از دستگاه‌ها و برنامه‌ها، SMTP AUTH، SPF و DKIM؛ راهنمای فرستندگان گوگل؛ RFC 7208.
