تنظیم ایمیل ServiceDesk Plus با Microsoft 365؛ دریافت، ارسال و آزمون OAuth

راهنمای تکمیلی آزمون ایمیل ServiceDesk Plus ــ On-Premises | پیش‌نیاز: کاربران، تکنسین‌ها و نقش‌ها | فهرست راهنماهای ایمیل و اعلان

کاربر ایمیل می‌فرستد و تیکت ایجاد می‌شود. کارشناس پاسخ می‌دهد، اما چیزی به کاربر نمی‌رسد. تیم می‌گوید «ایمیل وصل است»؛ درحالی‌که فقط نیمی از مسیر کار می‌کند. در این درس، تنظیم ایمیل ServiceDesk Plus را به سه آزمون جدا تبدیل می‌کنیم: ورود پیام، خروج پاسخ و برگشت پاسخ کاربر به همان مکالمه.

سناریو برای صندوق آزمایشی Microsoft 365 در محیط تجاری عمومی و روش IMAPS به‌همراه SMTP با OAuth است. این تنظیمات را به Gmail، Exchange داخلی، محیط‌های ملی Microsoft یا روش Microsoft Graph تعمیم ندهید. برای روش Graph، راهنمای مستقل اتصال Microsoft Graph را ببینید. پیش از اجرا، پشتیبانی Build و مجازبودن پروتکل‌ها در سیاست سازمان را کنترل کنید. این مقاله راهنمای غیرفعال‌کردن سیاست‌های امنیتی برای عبور از خطا نیست.

پیش از اتصال صندوق واقعی

یک صندوق اختصاصی آزمایش تهیه کنید که فقط پیام‌های تمرینی داشته باشد. مسئول صندوق، مدیر مجاز ثبت برنامه، نشانی نهایی ServiceDesk و مسئول نگهداری اعتبارنامه برنامه باید مشخص باشند. صندوقی با سال‌ها مکاتبه واقعی را بدون برنامه انتقال به نصب آزمایشی وصل نکنید.

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

گام اول: ثبت برنامه برای OAuth

در Admin → Mail Server Settings نشانی Redirect برنامه را بردارید. مدیر مجاز در Microsoft Entra، از App registrations → New registration برنامه را ثبت می‌کند و Redirect URI از نوع Web را مطابق آن قرار می‌دهد. Application Client ID، نشانی‌های authorization و token و مقدار Value مربوط به Client Secret در تنظیمات ServiceDesk قرار می‌گیرند؛ Secret ID جای Value نیست. اعتبار زمانی Secret و مسئول تمدید را ثبت کنید. مجوزها و Consent باید متناسب با پروتکل و سیاست Tenant تأیید شوند. جزئیات ثبت برنامه در راهنمای آماده‌سازی OAuth آمده است؛ Scopeها را متناسب با IMAPS و SMTP این سناریو انتخاب کنید، نه Scopeهای Graph.

برای انتخاب مقادیر این دو پروتکل، تنظیم IMAPS و تنظیم SMTP در Microsoft 365 را بررسی کنید. دسترسی Microsoft Graph، Scope مربوط به IMAP و تنظیم SMTP سه نام قابل جایگزینی نیستند. مجوز اضافی را صرفاً برای آزمون‌وخطا به برنامه ندهید.

گام دوم: ایمیل ورودی

با SDAdmin، بخش Incoming Mail Server Settings را باز کنید. برای این سناریو، روش IMAPS و احراز هویت OAuth را انتخاب کنید، نام صندوق و اطلاعات برنامه را وارد کنید و نشانی Redirect را با نشانی واقعی بازشده در مرورگر تطبیق دهید. پس از Save، ورود و Consent باید با حساب متناظر تنظیمات صندوق انجام شود. دوره دریافت پیام را مشخص کنید و از Fetch a sample mail برای آزمون اتصال استفاده کنید؛ این آزمون می‌تواند قدیمی‌ترین پیام صندوق را دریافت کند. جزئیات در راهنمای ایمیل ورودی مدانت آمده است.

طبق جدول تنظیمات ایمیل سازنده، مقادیر این سناریو عبارت‌اند از میزبان outlook.office365.com، پورت 993 و TLS فعال. Scope ورودی https://outlook.office365.com/IMAP.AccessAsUser.All,offline_access است. این مقادیر را با نوع محیط Microsoft 365 خود تطبیق دهید؛ پسوندهای محیط‌های ملی متفاوت‌اند. ^[۳]

گام سوم: ایمیل خروجی

در Outgoing Mail Server Settings، روش SMTP و OAuth را انتخاب کنید. سرور، نام نمایشی، نشانی فرستنده، حساب صندوق، TLS و اطلاعات برنامه را تکمیل کنید. پس از ذخیره و تأیید مجوزها، با Send a sample mail به یک گیرنده آزمایشی پیام بفرستید. تنظیمات فرستنده باید با مجوز ارسال حساب هماهنگ باشد؛ نوشتن یک آدرس دیگر در فرم، مجوز استفاده از آن آدرس ایجاد نمی‌کند. روش کامل در راهنمای ایمیل خروجی آمده است.

در جدول رسمی یادشده، برای SMTP محیط عمومی Microsoft 365، میزبان smtp.office365.com، پورت 587 و TLS فعال آمده است؛ Scope مربوط https://outlook.office365.com/SMTP.Send,offline_access است. اگر سیاست صندوق یا Tenant این مسیر را مجاز نمی‌داند، ابتدا مدیر ایمیل باید روش مورد تأیید سازمان را تعیین کند؛ تغییر تصادفی پورت یا حذف TLS راه‌حل نیست. ^[۳]

آزمون پذیرش: یک مکالمه کامل

ورود: از حساب درخواست‌کننده آزمایشی، ایمیلی با عنوان یکتا و یک پیوست غیرحساس کوچک بفرستید. زمان ارسال، رسیدن به صندوق و ایجاد درخواست را ثبت کنید. نام درخواست‌کننده، متن فارسی و پیوست را در تیکت بررسی کنید. رسیدن پیام به صندوق، هنوز اثبات تبدیل درست آن به درخواست نیست.

خروج: کارشناس از داخل همان درخواست پاسخ بدهد. در صندوق درخواست‌کننده، فرستنده، متن، پیوست و موضوع را بررسی کنید. پیام ممکن است ارسال شده باشد ولی در پوشه دیگری قرار گرفته باشد؛ نتیجه را با مشاهده واقعی گیرنده ثبت کنید، نه صرفاً ناپدیدشدن پیام از صف ارسال.

برگشت: درخواست‌کننده به همان پیام پاسخ دهد، بدون اینکه شناسه‌ها و موضوع را عمداً تغییر دهد. بررسی کنید پاسخ به مکالمه همان تیکت اضافه شده و درخواست ناخواسته جدیدی ایجاد نشده است. رفتار واقعی باید با تنظیمات مکالمه و سیاست سازمان تطبیق داده شود.

چهار نقطه برای عیب‌یابی هدفمند

اگر OAuth به خطای Redirect می‌رسد، نشانی دقیق ثبت‌شده و نشانی مرورگر را مقایسه کنید. اگر Consent انجام نمی‌شود، حساب استفاده‌شده و سیاست تأیید مجوزها را بررسی کنید. اگر دریافت موفق و ارسال ناموفق است، تنظیمات خروجی را مستقل آزمون کنید. اگر اتصال موفق است ولی تیکت ساخته نمی‌شود، سیاست پذیرش فرستنده و پردازش پیام را بررسی کنید؛ همه خطاها مربوط به رمز نیستند.

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

هنگام تحویل گزارش، زمان، مرحله شکست و متن خطا کافی‌تر از چند تصویر نامرتب است. Client Secret، Access Token و Refresh Token را در تصویر، تیکت عمومی یا گزارش آموزشی قرار ندهید. داده حساس لاگ نیز پیش از اشتراک باید کنترل شود.

از اتصال ایمیل تا توزیع درخواست

پس از قبولی این سه آزمون، به سراغ مسیردهی درخواست با Email-to-Ticket و گروه‌ها بروید. قواعد توزیع را قبل از تثبیت مسیر پایه ایمیل پیچیده نکنید. مالک پیگیری انقضای Secret و خطاهای دریافت را نیز در سند بهره‌برداری مشخص کنید؛ راه‌اندازی امروز بدون مسئول نگهداری، مسئله فرداست.

مطالب مرتبط

آماده‌سازی OAuth و Graph | ایمیل ورودی | ایمیل خروجی | قواعد اعلان | فیلتر پیام و اعلان | فهرست راهنماهای ایمیل

سخن پایانی مدانت

ایمیل زمانی وصل است که یک گفت‌وگوی واقعی بتواند سالم رفت‌وبرگشت کند. سه چراغ جدا برای دریافت، ارسال و ادامه مکالمه داشته باشید؛ روشن‌بودن یکی، تاریکی دو مسیر دیگر را جبران نمی‌کند.

منابع

1. ManageEngine — Configure Azure as Authentication Server؛ آماده‌سازی OAuth.
2. ManageEngine — Incoming Mail Server Settings؛ دریافت پیام.
3. ManageEngine — Default Mail Server Configurations؛ مقادیر IMAPS و SMTP.
4. ManageEngine — Outgoing Mail Server Settings؛ ارسال پیام.
5. Microsoft — OAuth for IMAP, POP and SMTP؛ احراز هویت پروتکل‌های ایمیل.

این مطلب، آموزش تکمیلی مدانت است و جدا از شمارش مدخل‌های مستقل Help نگهداری می‌شود. آخرین بازبینی پیوندها: ۱۹ سپتامبر ۲۰۲۶.