اصطلاح · جزئیات SMTP در Office 365

جزئیات SMTP در Office 365 چیست و چه تأثیری بر ایمیل اپلیکیشن دارد؟

جزئیات SMTP ‏Office 365 یک host و رمز عبور همگانی نیست. Microsoft چند الگوی اپلیکیشن و دستگاه را مستند می‌کند، از جمله client submission احرازشده از طریق smtp.office365.com، SMTP relay مبتنی بر connector از طریق endpoint ‏MX tenant و Direct Send به گیرندگان داخلی Microsoft 365. این الگوها در احراز هویت، TLS، پورت‌ها، هویت فرستنده، پشتیبانی از گیرنده خارجی، مجوزهای استفاده، محدودیت‌ها و راه‌اندازی مدیریتی متفاوت‌اند. الگو را بر اساس workload و مرز اعتماد انتخاب کنید، جایی که client submission اعمال می‌شود از OAuth استفاده کنید، SMTP AUTH را محدود فعال نگه دارید، هویت‌های دقیق envelope و From را آزمایش کنید و پذیرش relay را از تحویل نهایی یا رسیدن به صندوق ورودی جدا بدانید.

جزئیات SMTP ‏Office 365 چند مسیر را شرح می‌دهند

مستندات Microsoft 365 و Office 365 بین ارسال کلاینت از طریق SMTP، SMTP relay و Direct Send تمایز قائل می‌شود. ارسال کلاینت به‌عنوان یک صندوق ایمیل Exchange Online احراز هویت می‌کند و از طریق smtp.office365.com ارسال می‌کند. SMTP relay اپلیکیشن یا دستگاه را یک سرور ایمیل سازمانی در نظر می‌گیرد و اتصال را با یک inbound connector احراز هویت می‌کند. Direct Send برای گیرندگان درون سازمان، به‌صورت ناشناس به endpoint مربوط به MX در Microsoft 365 همان tenant ارسال می‌کند. این‌ها از نظر عملیاتی محصولاتی متفاوت پشت فرمان‌های SMTP مشابه‌اند. بدون تصمیم درباره مسیر موردنظر، hostname و پورت را از یک انجمن کپی نکنید. ابتدا tenant، دامنه‌های پذیرفته‌شده (accepted domains)، مدیر، بار کاری، هویت‌های فرستنده، شبکه مبدأ، دامنه گیرندگان، روش احراز هویت، سیاست TLS، حجم و مسئول خطا را ثبت کنید. انتقال SMTP رویداد کسب‌وکاری مبدأ را مجاز نمی‌کند، رضایت گیرنده را اثبات نمی‌کند و صف اپلیکیشن را ماندگار نمی‌کند.

تنظیمات ارسال کلاینت از طریق SMTP

راهنمای فعلی راه‌اندازی Microsoft، smtp.office365.com را نام DNS برای ارسال کلاینت اعلام می‌کند و می‌گوید نباید یک نشانی IP را جایگزین آن کرد. این راهنما پورت TCP 587 را توصیه می‌کند، پورت 25 را در سناریوی مستند مجاز می‌داند و TLS 1.2 یا TLS 1.3 را با STARTTLS فعال الزامی می‌کند. اپلیکیشن به‌عنوان یک صندوق ایمیل دارای لایسنس Microsoft 365 یا Office 365 احراز هویت می‌کند و می‌تواند در چارچوب محدودیت‌های مستند به گیرندگان داخلی و خارجی ارسال کند. از نشانی صندوق ایمیل به‌عنوان هویت صریح استفاده کنید و وقتی From قابل‌مشاهده متفاوت است، مجوزهای Send As را آزمایش کنید. اعتبارنامه‌ها یا توکن‌ها را در یک secret manager سمت سرور نگه دارید. ورود موفق به حساب ثابت نمی‌کند که From قابل‌مشاهده مجاز است، گیرنده معتبر است یا پیام به صندوق ورودی خواهد رسید. ارسال کلاینت مسیری در سطح صندوق ایمیل است؛ بنابراین تعلیق کاربر، تغییر لایسنس، تصمیم‌های conditional access و تنظیمات SMTP AUTH می‌توانند اپلیکیشنی را که هیچ تغییری نکرده متوقف کنند.

از OAuth استفاده کنید و SMTP AUTH را محدود فعال کنید

Microsoft برای ارسال کلاینت از طریق SMTP، احراز هویت مدرن (Modern authentication) با OAuth را توصیه می‌کند. مستندات OAuth آن scope مربوط به SMTP.Send و قالب SASL XOAUTH2 را تعریف می‌کند و جریان‌های delegated و مبتنی بر اپلیکیشن، مشروط به ثبت در Microsoft Entra و مجوزهای Exchange هستند. توکن‌های access و refresh را راز در نظر بگیرید، فقط مجوزهای لازم را درخواست کنید، اتصال به tenant و صندوق ایمیل را اعتبارسنجی کنید، اعتبارنامه‌های اپلیکیشن را بچرخانید و مجوزهای بلااستفاده را حذف کنید. Microsoft همچنین توصیه می‌کند SMTP AUTH را برای سازمان Exchange Online غیرفعال کنید و فقط برای صندوق‌هایی که هنوز به آن نیاز دارند فعال کنید. هم یک تنظیم در سطح سازمان و هم یک تنظیم جایگزین در سطح صندوق ایمیل وجود دارد و تنظیم صندوق ایمیل می‌تواند اولویت داشته باشد. Security defaults، SMTP AUTH را غیرفعال می‌کند. فقط برای حفظ یک دستگاه قدیمی، خط پایه امنیتی کل tenant را غیرفعال نکنید. وقتی بار کاری نمی‌تواند الزامات OAuth و TLS را برآورده کند، connector، یک کلاینت مدرن پشتیبانی‌شده، relay درون‌سازمانی (on-premises) یا سرویس مستند دیگری را ترجیح دهید.

محدودیت‌های ارسال کلاینت بر طراحی اپلیکیشن اثر می‌گذارند

مقایسه فعلی Microsoft محدودیت (throttling) ارسال کلاینت از طریق SMTP را 10,000 گیرنده در روز و 30 پیام در دقیقه اعلام می‌کند. این‌ها را محدودیت‌های فعلی سرویس بدانید که ممکن است تغییر کنند و با دیگر محدودیت‌های Exchange Online تداخل داشته باشند. گیرندگان را بشمارید، نه فقط پیام‌ها را؛ در To، Cc، Bcc، تلاش‌های مجدد و ارسال گسترده (fan-out). کنترل‌های نرخ اپلیکیشن، عدالت بین tenantها، هم‌زمانی، تعداد تلاش و عمر صف را پایین‌تر از سقف سرویس تنظیم کنید. مسیر صندوق ایمیل مشترک می‌تواند بین استفاده انسانی و خودکار رقابت ایجاد کند، در حالی که یک اعتبارنامه که بسیاری از اپلیکیشن‌ها از آن استفاده می‌کنند مالکیت را پنهان می‌کند. نرخ و فضای باقی‌مانده گیرندگان را پایش کنید، اما هرگز با چرخاندن صندوق‌های ایمیل یا دامنه‌های فرستنده از محدودیت فرار نکنید. اگر بار کاری مرتباً به محدودیت‌های ارسال صندوق ایمیل نزدیک می‌شود، با استفاده از راهنمای فعلی Microsoft، connector relay، High Volume Email برای ترافیک داخلی واجد شرایط، Azure Communication Services Email برای تحویل اپلیکیشن یا سازوکار انتقال اختصاصی دیگری را ارزیابی کنید.

جزئیات SMTP relay مبتنی بر connector

SMTP relay در Microsoft 365 به‌جای smtp.office365.com از endpoint مربوط به MX در tenant و یک inbound connector که سیستم ارسال سازمان را شناسایی می‌کند استفاده می‌کند. Microsoft توصیه می‌کند connector را با یک گواهی TLS احراز هویت کنید و نشانی IP ثابت عمومی را روش مستند دیگری برای شناسایی می‌داند. اپلیکیشن روی پورت TCP 25 وصل می‌شود و می‌تواند از نشانی‌های یک accepted domain ارسال کند، بدون اینکه برای هر فرستنده به یک صندوق ایمیل دارای لایسنس نیاز باشد. این الگو برای سرورهای ایمیل، appliance‌ها یا gatewayهای کنترل‌شده با مالکیت پایدار گواهی و شبکه مناسب است. این الگو مدیریت بیشتری می‌طلبد: دامنه connector، چرخه عمر گواهی، تغییرات IP عمومی، DNS معکوس، سیاست accepted domain، جلوگیری از سوءاستفاده و پایش لیست سیاه. هرگز open relay ایجاد نکنید. محدود کنید که gateway کدام سیستم‌های داخلی، tenantها، فرستندگان، گیرندگان و کلاس‌های پیام را بپذیرد. connector اتصال را سازمانی تشخیص می‌دهد؛ مشروع بودن ورودی دلبخواهی اپلیکیشن را تأیید نمی‌کند.

Direct Send برای تحویل به گیرندگان داخلی است، نه relay عمومی

Direct Send بدون احراز هویت به‌عنوان صندوق ایمیل یا connector، به‌صورت یک سرور SMTP خارجی به endpoint مربوط به MX در tenant ارسال می‌کند. Microsoft آن را برای تحویل به گیرندگان درون سازمان Microsoft 365 یا Office 365 مستند کرده است، نه به‌عنوان مسیری به نشانی‌های خارجی دلبخواهی. دستگاه یا اپلیکیشن به دسترسی به پورت TCP 25 نیاز دارد و باید از فرستنده‌ای در یک accepted domain استفاده کند. چون این مسیر از دید سرویس رو به اینترنت ناشناس است، اعتبار فرستنده، DNS، IP مبدأ و تصمیم‌های ضدجعل اهمیت دارند. gateway مربوط به Direct Send را در معرض شبکه‌های غیرقابل‌اعتماد قرار ندهید و از آن برای دور زدن احراز هویت صندوق ایمیل استفاده نکنید. گزارش‌های عدم تحویل و مسئولیت پشتیبانی را مدل کنید، چون ممکن است یک چاپگر یا اپلیکیشن نتواند پیام‌های برگشت را به‌طور ایمن دریافت کند. اگر تحویل خارجی لازم است، پس از ارزیابی هویت و حجم، ارسال کلاینت، connector relay، Azure Communication Services Email یا روش پشتیبانی‌شده دیگری را انتخاب کنید.

هویت envelope، From قابل‌مشاهده و احراز هویت را جدا نگه دارید

هر مسیر یک فرستنده envelope در SMTP و فرمان‌های گیرنده به‌علاوه هدرهای قابل‌مشاهده RFC 5322 را حمل می‌کند. فرستنده envelope برگشت‌های انتقال و اغلب هویت SPF را کنترل می‌کند؛ From قابل‌مشاهده آنچه خوانندگان می‌بینند را کنترل می‌کند و هویت اصلی DMARC است. احراز هویت صندوق ایمیل با OAuth، هویت connector یا پذیرش بر اساس IP مبدأ به‌طور خودکار هم‌راستایی SPF، DKIM یا DMARC را برای هر دامنه From سفارشی ایجاد نمی‌کند. MAIL FROM، From، Reply-To، دامنه d= و selector مربوط به DKIM و IP متصل‌شونده را دقیقاً روی نمونه‌های دریافت‌شده کنترل‌شده فهرست کنید. یک سیاست SPF معتبر برای دامنه مربوط منتشر کنید، در صورت پشتیبانی امضای DKIM را پیکربندی کنید و هم‌راستایی DMARC را ارزیابی کنید. برای اصلاح یک دستگاه، رکورد SPF دوم اضافه نکنید یا سیاست DMARC سازمان را سست نکنید. در مدل‌های وضعیت، پذیرش توسط Microsoft، پذیرش توسط سرور مقصد، برگشت بعدی، فیلترینگ صندوق ایمیل، رسیدن به صندوق ورودی و اقدام انسانی را از هم جدا کنید.

یک مرز ماندگار در اپلیکیشن پیاده‌سازی کنید

SMTP در Microsoft 365 را پشت یک worker سرور مجاز یا relay کنترل‌شده قرار دهید. پیش از اتصال، یک رویداد کسب‌وکاری ذخیره کنید که شامل کلید idempotency پایدار، tenant، کلاس پیام، نسخه قالب، فرستنده و گیرندگان تأییدشده، مبنای رضایت یا ضرورت، وضعیت توقف ارسال و سابقه تلاش‌ها باشد. پیش از تولید فرمان‌های SMTP، قوانین فرستنده و گیرنده را به ازای هر tenant اعمال کنید. اندازه پیام، گستره گیرندگان، پیوست‌ها و مقادیر هدر را محدود کنید. توکن‌ها، رمزهای عبور، کلیدهای خصوصی گواهی و مدیریت connector را بیرون از کد منبع، لاگ‌ها، analytics، تیکت‌ها و promptها نگه دارید. timeoutهای محدود تنظیم کنید و با استفاده از پیام عیب‌یابی پیشرفته کامل و راهنمای Microsoft، پاسخ‌های 4xx را نامزد تلاش مجدد محدود و پاسخ‌های 5xx را برای آن تلاش دائمی دسته‌بندی کنید. قطع اتصال پس از DATA اما پیش از پاسخ نهایی مبهم است؛ پیش از ارسال دوباره، تلاش را نگه دارید و آن را تطبیق دهید. SMTP هیچ تضمین exactly-once در سطح محصول ندارد.

پیش از انتشار، پیکربندی و حالت‌های خطا را آزمایش کنید

از گیرندگان کنترل‌شده اختصاصی و یک شبکه مبدأ مشابه محیط عملیاتی استفاده کنید. resolve شدن DNS، دسترسی به پورت، مذاکره STARTTLS، hostname و زنجیره گواهی، دریافت توکن OAuth و scope آن، تنظیمات SMTP AUTH در سطح سازمان و صندوق ایمیل، مجوز Send As، تطبیق connector، accepted domainها و انتخاب endpoint مربوط به MX را بررسی کنید. نمونه‌های متن ساده، HTML، پیوست، Unicode، برگشت و حجم موردانتظار را ارسال کنید. هدرهای خام، Authentication-Results مورد اعتماد، پاسخ‌های SMTP، شناسه‌های trace و شواهد message trace را بدون نگه داشتن محتوای مشتری ثبت کنید. آزمون‌های منفی باید توکن‌های باطل‌شده، گواهی‌های منقضی connector، تغییر IP عمومی، غیرفعال بودن SMTP AUTH صندوق ایمیل، Security defaults، From نامعتبر، گیرنده خارجی از طریق Direct Send، محدودیت‌های دقیقه‌ای و گیرنده، تعویق موقت، رد دائمی و قطع اتصال حوالی DATA را پوشش دهند. توقف بار کاری و انتقال jobهای ماندگار را بدون دور زدن سیاست‌های دائمی یا خطاهای گیرنده تمرین کنید.

از راهنمایی کنونی Microsoft استفاده کنید و tenant خود را آزمایش کنید

پیکربندی SMTP ‏Microsoft 365 به سیاست‌ها، هویت‌ها، connectorها و محیط شبکه tenant بستگی دارد. پیش از اتکا به مسیر انتخاب‌شده برای ایمیل محیط عملیاتی، از مستندات کنونی Microsoft Learn استفاده کنید و آن را در tenant خود آزمایش کنید.

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

hostname مربوط به SMTP کلاینت در Microsoft 365 چیست؟

Microsoft در حال حاضر smtp.office365.com را برای ارسال کلاینت احرازهویت‌شده مستند کرده است و می‌گوید به‌جای یک نشانی IP ثابت سرویس، از نام DNS استفاده کنید.

ارسال کلاینت از طریق SMTP باید از کدام پورت استفاده کند؟

Microsoft پورت TCP 587 را توصیه می‌کند و پورت 25 را برای سناریوی پشتیبانی‌شده ارسال کلاینت مستند کرده است؛ STARTTLS و TLS 1.2 یا TLS 1.3 الزامی است.

آیا ارسال کلاینت در Microsoft 365 از OAuth پشتیبانی می‌کند؟

بله. Microsoft استفاده از OAuth را توصیه می‌کند و scope مربوط به SMTP.Send به‌علاوه SASL XOAUTH2 را مستند کرده است. ثبت tenant، مجوزها، نگهداری توکن و اتصال به صندوق ایمیل همچنان به پیکربندی دقیق نیاز دارد.

تفاوت SMTP relay و Direct Send چیست؟

connector relay یک سیستم ایمیل سازمانی را احراز هویت می‌کند و می‌تواند از گیرندگان خارجی پشتیبانی کند. Direct Send بدون آن connector از endpoint مربوط به MX در tenant استفاده می‌کند و برای گیرندگان داخلی در نظر گرفته شده است.

آیا SMTP AUTH باید برای همه صندوق‌های ایمیل فعال باشد؟

خیر. Microsoft توصیه می‌کند آن را در سطح سازمان غیرفعال کنید و فقط برای صندوق‌هایی که هنوز به آن نیاز دارند فعال کنید و احراز هویت مدرن و جایگزین‌های پشتیبانی‌شده را ترجیح دهید.

آیا پذیرش توسط SMTP در Office 365 یعنی تحویل به صندوق ورودی؟

خیر. پذیرش نتیجه‌ای محدود به همان مرحله انتقال است. تحویل بعدی، عدم تحویل، فیلترینگ گیرنده، قرار گرفتن در پوشه صندوق ایمیل و تعامل انسانی شواهدی جداگانه باقی می‌مانند.

آیا اپلیکیشن می‌تواند برای ارسال کلاینت در Microsoft از پورت 465 استفاده کند؟

طبق راهنمای فعلی Microsoft، دستگاهی که به‌طور پیش‌فرض از پورت 465 استفاده می‌کند، از نسخه‌های TLS موردنیاز برای ارسال کلاینت (client submission) در این مسیر Microsoft 365 پشتیبانی نمی‌کند.

پیکربندی SMTP ‏Microsoft 365 را کجا باید تأیید کنم؟

از مستندات کنونی Microsoft Learn استفاده کنید و پیش از اتکا به مسیر انتخاب‌شده برای ایمیل محیط عملیاتی، آن را در tenant خود آزمایش کنید.

منابع

ادامه یادگیری

چگونه یک سرویس SMTP relay را ارزیابی کنیمسرویس‌های SMTP relay را بر اساس امنیت ارسال، احراز هویت، صف‌ها، رفتار تلاش مجدد، محدودیت‌ها، رویدادهای تحویل، فهرست توقف ارسال، جداسازی و تناسب برای مهاجرت ارزیابی کنید.راهنمای ارزیابی سرویس SMTP relay گوگلSMTP relay در Google Workspace را بر اساس مدل مجوزدهی، TLS، هویت فرستنده، سهمیه‌ها، مدیریت خطا، احراز هویت، مشاهده‌پذیری و ریسک مهاجرت ارزیابی کنید.پروتکل ایمیل SMTP: ایمیل اپلیکیشن چگونه جابه‌جا می‌شودببینید ارسال (submission) در SMTP، relay، envelopeها، کدهای پاسخ، TLS، تلاش‌های مجدد و محتوای پیام چگونه گردش‌کار ایمیل اپلیکیشن را شکل می‌دهند.پورت‌های SMTP یعنی 25، 465 و 587: راهنمای عملیپورت مناسب SMTP را بر اساس نقش و حالت TLS انتخاب کنید و سپس خطاهای اتصال، handshake، احراز هویت و پذیرش پیام را عیب‌یابی کنید.چگونه یک سرویس تحویل‌پذیری ایمیل را ارزیابی کنیمسرویس‌های تحویل‌پذیری ایمیل را بر اساس دامنه کار، شواهد، احراز هویت، حلقه‌های بازخورد، فهرست توقف ارسال، حریم خصوصی، قابلیت انتقال و تناسب عملیاتی ارزیابی کنید.