صفحه معرفی · سرویس SMTP relay گوگل

یک تیم محصول هنگام انتخاب سرویس SMTP relay گوگل چه مواردی را باید ارزیابی کند؟

SMTP relay در Google Workspace را فقط زمانی انتخاب کنید که مدل مدیریتی، هویتی و سهمیه آن با بار کاری شما سازگار باشد. مشخص کنید مالک دامنه Workspace و تنظیمات Admin console کیست، آیا برنامه می‌تواند از یک IP عمومی پایدار در allowlist یا از احراز هویت SMTP محافظت‌شده با TLS استفاده کند، کدام فرستندگان envelope مجازند و TLS چگونه اعمال می‌شود. پیش از راه‌اندازی، محدودیت‌های فعلی Google به ازای هر کاربر، هر مشتری و هر تراکنش را مدل‌سازی کنید. خطاهای موقت و دائمی را آزمایش کنید، پاسخ‌های SMTP را نگه دارید، فرستنده قابل‌مشاهده را با SPF، DKIM و DMARC احراز هویت کنید و پذیرش، تحویل به سرور گیرنده و رسیدن به صندوق ورودی را نتایج جداگانه نگه دارید.

با تناسب بار کاری و مدیریت شروع کنید

سرویس SMTP relay گوگل یک مسیر مدیریتی در Google Workspace برای برنامه‌ها، دستگاه‌ها و سرورهای ایمیلی است که از طریق smtp-relay.gmail.com ارسال می‌کنند. آن را بخشی از مرز Workspace و امنیت ایمیل سازمان ارزیابی کنید، نه یک endpoint عمومی و ناشناس SMTP. مالک super-admin در Workspace، دامنه‌های حساب، سیستم‌های مبدأ، IPهای عمومی خروجی، نشانی‌های فرستنده، انواع پیام، حجم گیرندگان در اوج و روزانه، الگوی پیوست‌ها و مسئول حوادث را مشخص کنید. تعیین کنید بار کاری تراکنشی، عملیاتی داخلی، نوشته‌شده توسط کاربر، انبوه با اشتراک یا تولیدشده توسط دستگاه است. این انواع را جدا نگه دارید، چون نیازهای مجوز، رضایت، توقف ارسال، ممیزی و اعتبار آن‌ها متفاوت است. مطمئن شوید محیط‌های پایین‌تر نمی‌توانند از مسیرهای محیط عملیاتی یا نشانی‌های مشتریان استفاده کنند. یک relay می‌تواند پیام مجاز را منتقل کند؛ تصمیم نمی‌گیرد که رویداد کسب‌وکار مشروع است، گیرنده رضایت داده است یا وضعیت برنامه در مراحل بعد باید پیش برود.

مجوزدهی مبتنی بر IP را با احراز هویت SMTP مقایسه کنید

تنظیمات فعلی Google به مدیران اجازه می‌دهد پذیرش relay را به نشانی‌های IP عمومی مشخص محدود کنند، احراز هویت SMTP روی TLS را الزامی کنند یا طبق تنظیمات مستند، گزینه‌های سیاستی را ترکیب کنند. مجوزدهی با IP پایدار می‌تواند برای دیتاسنترهای کنترل‌شده یا gatewayهای خروجی ثابت مناسب باشد، اما پشت NAT ابری متغیر، چند region، سرویس‌های failover یا شبکه‌های شخص ثالث شکننده می‌شود. احراز هویت SMTP یک حساب Workspace و دامنه ارسال را شناسایی می‌کند، اما چرخه عمر اعتبارنامه، وضعیت کاربر، تعامل با احراز هویت چندعاملی و سیاست‌ها و یک الزام قطعی برای TLS را به همراه دارد. هرگز از یک اعتبارنامه گسترده برای چند tenant یا برنامه‌های نامرتبط استفاده نکنید. برای هر گزینه مستند کنید چه کسی می‌تواند IP یا حساب اضافه کند، تغییرات چگونه بازبینی می‌شوند، نفوذ چگونه شناسایی می‌شود، دسترسی چگونه لغو می‌شود و failover چه می‌کند. بازه‌های IP مجاز را تا حد ممکن کوچک نگه دارید و نشانی خروجی عمومی را از محیط اجرای واقعی بررسی کنید، نه اینکه یک نشانی داخلی را کپی کنید.

فرستندگان مجاز و هویت دامنه را تعریف کنید

تنظیم relay در Admin console مشخص می‌کند کدام فرستندگان مجازند. Google گزینه‌هایی مرتبط با کاربران ثبت‌شده Apps و نشانی‌های دامنه‌های متعلق به سازمان و همچنین یک گزینه گسترده‌تر برای هر نشانی را مستند کرده است که در معرض سوءاستفاده بودن را افزایش می‌دهد. محدودترین گزینه‌ای را انتخاب کنید که بار کاری می‌تواند با آن کار کند. فرستنده envelope در SMTP را مستقل از فیلدهای From و Reply-To قابل‌مشاهده فهرست کنید. Google اشاره می‌کند که وقتی فرستنده خارج از دامنه‌های حساب است، SMTP AUTH یا دامنه‌ای که در HELO یا EHLO ارائه می‌شود می‌تواند بر نحوه شناسایی یا بازنویسی فرستنده envelope اثر بگذارد. به بازنویسی به‌عنوان جایگزین مدل فرستنده متعلق به خودتان تکیه نکنید. یک نگاشت تأییدشده از برنامه، tenant، نوع پیام، فرستنده envelope، دامنه From قابل‌مشاهده و return path را الزامی کنید. پیش از اتصال به Google، هدرهای دلخواه ارائه‌شده توسط کاربر، تزریق newline و نشانی‌های From متعلق به tenant دیگر را مسدود کنید. مسیریابی برگشت ایمیل‌ها و پیام‌های out-of-office، از جمله فرستنده envelope خالی را آزمایش کنید، بدون اینکه کل تنظیمات را تضعیف کنید.

امنیت انتقال را آگاهانه الزامی کنید

راهنمای فعلی relay در Google، سیستم‌های on-premise دارای TLS را به smtp-relay.gmail.com روی پورت 587 هدایت می‌کند و توضیح می‌دهد که احراز هویت SMTP به TLS نیاز دارد. تنظیمات Admin همچنین می‌تواند TLS را برای اتصال‌های سرور فرستنده الزامی کند. TLS الزامی را برای محیط عملیاتی فعال کنید، مگر اینکه یک محدودیت قدیمی مستند، استثنایی با مهلت مشخص داشته باشد. نام سرور، زنجیره گواهی، سیاست پروتکل و cipherهای پشتیبانی‌شده، مذاکره STARTTLS و رفتار هنگام خطا را اعتبارسنجی کنید. اگر TLS الزامی برقرار نشود، کلاینت باید اتصال را قطع کند (fail closed)؛ بازگشت بی‌صدا به متن ساده، سیاست را بی‌اثر می‌کند. اعتبارنامه‌های SMTP را در یک secret store مدیریت‌شده محافظت کنید و آن‌ها را از خط فرمان، URLها، کد منبع، لاگ‌ها، analytics، گزارش‌های crash و تیکت‌ها دور نگه دارید. TLS در لایه انتقال از hop تا Google محافظت می‌کند، نه از کل چرخه عمر پیام یا صندوق ایمیل. محتوای حساس ممکن است به کنترل‌های سطح برنامه، حداقل‌سازی داده، سیاست نگهداری و تصمیم‌های جداگانه برای رمزنگاری سرتاسری نیاز داشته باشد.

پیش از انتخاب relay، سهمیه‌های فعلی را مدل‌سازی کنید

مستندات فعلی راه‌اندازی SMTP relay گوگل می‌گوید هر کاربر می‌تواند در یک دوره 24 ساعته حداکثر 10,000 پیام و به حداکثر 10,000 گیرنده یکتا ارسال کند و محدودیت‌های دوره آزمایشی ممکن است کمتر باشد. همچنین سقف 100 گیرنده در هر تراکنش SMTP و کنترل‌های اضافی در سطح مشتری، اوج و روزانه را مستند می‌کند. این‌ها را سقف‌های مستند فعلی بدانید، نه هدف ظرفیت یا قراردادی دائمی. پیش از راه‌اندازی، صفحه رسمی را برای حساب و بار کاری خود دوباره بررسی کنید. تعداد گیرندگان را محاسبه کنید، نه فقط پیام‌ها را، آن هم در To، Cc، Bcc، تلاش‌های مجدد و fan-out. کنترل‌های نرخ، هم‌زمانی، عمر صف و عدالت بین tenantها را در سطح برنامه پایین‌تر از محدودیت‌های Google قرار دهید. برای شتاب گرفتن مصرف و ظرفیت باقی‌مانده هشدار بگذارید. در واکنش به یک محدودیت، ترافیک را بین حساب‌های غیرمجاز تقسیم نکنید، فرستندگان envelope را چرخشی عوض نکنید و اتصال‌های کنترل‌نشده باز نکنید. بار کاری‌ای که مرتباً به مرز یک Workspace مشترک نزدیک می‌شود، ممکن است به ارزیابی یک لایه انتقال اختصاصی نیاز داشته باشد.

یک گردش‌کار ارسال پایدار بسازید

کلاینت SMTP را پشت یک worker یا صف سمت سرور مجاز قرار دهید. برای هر پیام خروجی یک job پایدار ذخیره کنید که شامل کلید پایدار رویداد کسب‌وکار، tenant، نوع پیام، نسخه قالب، فرستنده و گیرندگان تأییدشده، مبنای رضایت یا ضرورت، تصمیم توقف ارسال و تاریخچه تلاش‌ها باشد. آن job را یک بار claim کنید، محتوا را رندر و اعتبارسنجی کنید و سپس به endpoint پیکربندی‌شده Google وصل شوید. تعداد گیرندگان در هر تراکنش و اندازه پیام را طبق محدودیت‌های فعلی و سیاست محصول محدود کنید. پاسخ کامل SMTP، کد وضعیت پیشرفته، میزبان راه دور، زمان و شناسه تلاش را ثبت کنید، بدون اینکه اعتبارنامه‌ها یا محتوای غیرضروری را لاگ کنید. اگر relay تراکنش DATA را پذیرفت، فقط مرحله پذیرش توسط ارائه‌دهنده یا relay را علامت بزنید. اگر کلاینت پس از ارسال داده اما پیش از دریافت پاسخ نهایی دچار timeout شد، وضعیت تلاش را نامشخص نگه دارید و پیش از ارسال مجدد آن را تطبیق دهید. SMTP کلید idempotency در سطح برنامه ارائه نمی‌کند، بنابراین کنترل ارسال تکراری بر عهده صف و مدل رویداد محصول است.

خطاهای relay را دسته‌بندی کنید، نه اینکه همه را دوباره تلاش کنید

صفحه خطاهای SMTP relay گوگل وضعیت‌های متمایزی را مستند می‌کند، از جمله رد شدن relay، اعتبارنامه یا شناسایی دامنه نامعتبر برای relay، عبور از محدودیت روزانه، تعویق موقت به‌دلیل محدودیت اوج و تعداد زیاد گیرندگان در یک تراکنش. پاسخ دقیق را ثبت کنید و آن را به یک دسته داخلی مشخص نگاشت کنید. خطاهای پیکربندی، دامنه فرستنده، اعتبارنامه، IP و تعداد گیرندگان در هر تراکنش را پیش از ارسال مجدد اصلاح کنید. پس از اتمام محدودیت روزانه، کار را متوقف یا دوباره زمان‌بندی کنید. خطاهای موقت اوج یا انتقال را که واجد شرایط‌اند با exponential backoff، jitter، سقف تعداد تلاش و محدودیت عمر صف دوباره تلاش کنید. هرگز یک پاسخ دائمی را بی‌پایان دوباره تلاش نکنید. اگر خطا از یک IP ثبت‌نشده نام می‌برد، به‌جای گسترش allowlist، نشانی خروجی عمومی واقعی محیط اجرا و تنظیم درست Workspace را بررسی کنید. شمارش‌های تجمیعی با حداقل داده را بر اساس سیستم مبدأ، نسخه پیکربندی، دامنه فرستنده، دسته وضعیت و زمان نگه دارید. برای پاسخ‌های جدید و جهش‌های خطای احراز هویت هشدار بگذارید، چون ممکن است نشانه انحراف سیاست، لغو اعتبارنامه، تغییر NAT یا سوءاستفاده باشند.

فرستنده را فراتر از دسترسی به relay احراز هویت کنید

اجازه استفاده از relay گوگل با احراز هویت فرستنده در برابر گیرنده یکی نیست. یک سیاست SPF منتشر کنید که مسیر ارسال واقعی را برای هویت envelope مجاز کند، امضای DKIM را با دامنه‌ای تحت کنترل سازمان و هم‌راستا با DMARC پیکربندی کنید و یک سیاست DMARC بازبینی‌شده برای دامنه From قابل‌مشاهده منتشر کنید. پیام خام دریافت‌شده را از صندوق‌های خارجی کنترل‌شده بررسی کنید. نتیجه و دامنه SPF، نتیجه DKIM، دامنه d= و selector، دامنه From قابل‌مشاهده، هم‌راستایی و نتیجه DMARC را ثبت کنید. یک امضای ارائه‌دهنده یا Workspace که از نظر فنی معتبر است، ممکن است با یک دامنه From سفارشی هم‌راستا نباشد. forwarding هم می‌تواند شواهد SPF را تغییر دهد. فقط برای موفق شدن یک آزمون، رکورد SPF دوم اضافه نکنید یا DMARC را در کل سازمان تضعیف نکنید. مدیران DNS و ایمیل را هماهنگ کنید، رکوردهای قبلی را نگه دارید، پاسخ‌های authoritative و recursive را آزمایش کنید و هر بار فقط یک تغییر هویت را منتشر کنید.

مشاهده‌پذیری و یک مسیر خروج آزموده‌شده را الزامی کنید

از جستجوی لاگ ایمیل در Google Admin و لاگ‌های سمت relay در صورت وجود استفاده کنید، اما دفتر ثبت ارسال‌های خروجی متعلق به محصول را مرجع تصمیم نگه دارید. عمر صف، پذیرش، پاسخ‌های موقت و دائمی، مصرف محدودیت‌ها، سیگنال‌های برگشت ایمیل و گزارش اسپم، احراز هویت و تأخیر را بر اساس نوع پیام و دامنه فرستنده پایش کنید. دسترسی را محدود کنید و در معیارهای روزمره از نشانی‌های کامل یا محتوا پرهیز کنید. تغییر IP مبدأ، چرخش اعتبارنامه، خطای TLS، غیرفعال شدن تنظیمات Admin، تعلیق کاربر، اتمام محدودیت، fan-out گیرندگان، تغییرات DNS و قطعی ارائه‌دهنده را آزمایش کنید. یک rollback تعریف کنید که بتواند گروه آسیب‌دیده را بدون از دست رفتن jobهای پایدار متوقف کند. برای مهاجرت، فیلدهای SMTP مخصوص ارائه‌دهنده را در یک adapter جدا کنید و کلیدهای رویداد کسب‌وکار، وضعیت توقف ارسال، مجوز فرستنده و تاریخچه تلاش‌ها را حفظ کنید. relay دوم نباید به راه دور زدن خودکار ردهای دائمی سیاست یا گیرنده تبدیل شود. سازگاری به آزمون‌هایی در سطح فیلد و خطا نیاز دارد، نه فقط تغییر یک hostname.

SendHQ چگونه جای می‌گیرد

SendHQ یک API ایمیل در سطح فضای کاری برای ارتباط موردانتظار محصول است که ارسال با دامنه تأییدشده، ایمیل ورودی، قالب‌های میزبانی‌شده، رویدادهای تحویل، موارد توقف ارسال و یک داشبورد وب دارد. آن را با Google Workspace SMTP relay از طریق مستندات کنونی و آزمون‌های کنترل‌شده برای مرزهای حساب و tenant، اعتبارنامه‌ها و چرخش، اعمال فرستنده مجاز، هویت‌های envelope و قابل‌مشاهده، شکست TLS، محدودیت‌های گیرنده، پاسخ‌های موقت و دائمی، پیامدهای مبهم، موارد توقف ارسال، بازخوانی رویداد و مهاجرت مقایسه کنید.

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

Google Workspace برای SMTP relay از چه hostname‌ای استفاده می‌کند؟

راهنمای فعلی راه‌اندازی Google از smtp-relay.gmail.com استفاده می‌کند. پورت و رفتار TLS را بر اساس دستورالعمل‌های رسمی و سیاست امنیتی اعمال‌شده در سازمان انتخاب کنید.

آیا می‌توان SMTP relay گوگل را بر اساس IP مبدأ محدود کرد؟

بله. تنظیمات Admin می‌تواند فقط نشانی‌های IP عمومی مشخص‌شده را بپذیرد. بازه‌ها را محدود نگه دارید و نشانی خروجی (egress) واقعی محیط اجرا و رفتار failover را بررسی کنید.

آیا احراز هویت SMTP در این relay بدون TLS کار می‌کند؟

راهنمای فعلی Google می‌گوید احراز هویت SMTP به TLS نیاز دارد. کلاینت‌های محیط عملیاتی باید در صورت ناموفق بودن مذاکره TLS الزامی یا اعتبارسنجی گواهی، اتصال را قطع کنند (fail closed).

یک تراکنش SMTP relay حداکثر چند گیرنده می‌تواند داشته باشد؟

Google در حال حاضر سقف 100 گیرنده را برای هر تراکنش smtp-relay.gmail.com مستند کرده است. صفحه رسمی زنده را دوباره بررسی کنید، چون محدودیت‌های ارائه‌دهنده و شرایط حساب ممکن است تغییر کنند.

آیا خطای محدودیت اوج relay را باید دوباره تلاش کرد؟

Google اتمام محدودیت اوج را موقت توصیف می‌کند. همان job پایدار را نگه دارید و به‌جای fan-out فوری، از backoff محدود، jitter، سقف تعداد تلاش و محدودیت عمر صف استفاده کنید.

آیا پذیرش توسط relay یعنی گیرنده ایمیل را دریافت کرده است؟

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

آیا دسترسی به relay گوگل می‌تواند جایگزین SPF، DKIM و DMARC شود؟

خیر. مجوز relay استفاده از سرویس Google را کنترل می‌کند. احراز هویت در برابر گیرنده و هم‌راستایی DMARC به هویت‌های ارسال درست، رکوردهای DNS، امضاها و بررسی پیام دریافت‌شده نیاز دارد.

آیا این صفحه ثابت می‌کند SendHQ با SMTP relay گوگل سازگار است؟

خیر. قابلیت‌های مستندشده SendHQ را با نیازهای Google Workspace SMTP relay مقایسه کنید و برای احراز هویت، TLS، سهمیه‌ها، خطاها و بازخوانی رویداد تحویل از آزمون‌های کنترل‌شده استفاده کنید.

منابع

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

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