صفحه معرفی · سرویس SMTP رایگان
یک تیم محصول هنگام انتخاب سرویس SMTP رایگان چه چیزهایی را باید ارزیابی کند؟
سرویس SMTP رایگان را یک وابستگی محدود در محیط عملیاتی ارزیابی کنید، نه یک نام هاست بی‌هزینه. بررسی کنید که آیا پیشنهاد یک سطح رایگان دائمی است یا دوره آزمایشی منقضی‌شونده؛ کدام پیامها، گیرندگان، بایتها، لاگها، رویدادها و پشتیبانی در محدودیتها حساب می‌شوند؛ هنگام رسیدن به سقف چه اتفاقی می‌افتد؛ و آیا اطلاعات پرداخت یا مصرف مازاد خودکار لازم است. سپس TLS اجباری، اعتبارنامههای با دسترسی محدود، دامنه‌های فرستنده تأییدشده، SPF، DKIM، همراستایی DMARC، رفتار پذیرش جزئی گیرندگان، پاسخ‌های 4xx و 5xx، برگشت‌ها، گزارش‌های اسپم، فهرست توقف ارسال، نگهداری داده، خروجی گرفتن و حذف را آزمایش کنید. هزینه مهاجرت را پیش از راه‌اندازی مدل کنید و هرگز پذیرش در سطح رایگان را با تحویل یا رسیدن به صندوق ورودی یکی ندانید.
«رایگان» را بر اساس قرارداد زنده تعریف کنید
واژه «رایگان» میتواند به سهمیه دائمی، دوره آزمایشی زمان‌دار، اعتبار اولیه، آزمایش فقط با گیرندگان تأییدشده یا پلن پولی با اعتبار موقت اشاره کند. قیمت‌گذاری و شرایط فعلی ارائهدهنده را در روز ارزیابی بخوانید. واحد پول، region، مالیات، نیاز به کارت پرداخت، انقضای دوره آزمایشی، واحدهای شامل‌شده، رفتار مصرف مازاد، رفتار تعلیق و قابلیت‌هایی را که با کاهش پلن حذف می‌شوند ثبت کنید. به خلاصه‌های نتایج جست‌وجو، پست‌های مقایسه‌ای قدیمی، اسکرین‌شات‌ها یا گفتگو با فروش بدون ارجاع پایدار به قرارداد تکیه نکنید. AWS SES، Resend و Mailgun مدل‌های قیمت‌گذاری و قابلیت‌های شامل‌شده متفاوتی را در صفحات رسمی خود منتشر میکنند؛ نباید هیچ‌کدام را جایگزین‌پذیر فرض کرد. نشانی صفحه بازبینی‌شده و تاریخ ثبت را به تصمیم پیوند دهید و پیش از راه‌اندازی یک بازبینی مجدد تعیین کنید، زیرا پیشنهادهای ارائه‌دهندگان میتواند تغییر کند. هزینه دریافت رایگان، هزینه‌های مهندسی، DNS، پایش، حریم خصوصی، رخداد و مهاجرت را از بین نمی‌برد.
بار کاری را در واحدهای صورتحساب و عملیاتی مدل کنید
پیامها، گیرندگان، پیوستها، بایتها، درخواستهای API یا SMTP، تحویل رویدادها، ایمیل ورودی، محتوای ذخیره‌شده، نگهداری لاگ، دامنهها، اعضای تیم و محیطها را برآورد کنید. پیامی با چند گیرنده ممکن است سهمیه را متفاوت از یک تراکنش تک‌گیرنده مصرف کند. تلاش‌های مجدد، ترافیک آزمایشی، گرم‌کردن، برگشت‌ها و تکرار وب‌هوک‌ها می‌توانند حجم را افزایش دهند. تقاضای میانگین، اوج دقیقه‌ای، اوج ساعتی، روزانه، ماهانه و فصلی را به‌علاوه حاشیه رشد و رخداد محاسبه کنید. کنترل‌های نرخ اپلیکیشن را زیر سقف‌های ارائهدهنده نگه دارید و tenantها را از یکدیگر محافظت کنید. بپرسید وقتی واحدی باقی نمی‌ماند چه اتفاقی می‌افتد: رد قطعی، تعویق، صورتحساب خودکار، کاهش قابلیت‌ها یا از دست رفتن بی‌صدای لاگها. سطح رایگانی که فراخوانی‌های ارسال را پوشش می‌دهد اما تاریخچه قابل‌استفاده رویدادها، پشتیبانی یا خروجی فهرست توقف ارسال را شامل نمی‌شود، ممکن است از نظر عملیاتی از یک پلن پولی کوچک گران‌تر باشد. پیش از محیط عملیاتی، شمارنده‌های مشاهده‌شده حساب را با ترافیک کنترلشده اعتبارسنجی کنید.
ارسال امن SMTP را الزامی کنید
یک سرویس SMTP برای محیط عملیاتی باید submission محافظت‌شده، پورت‌های پشتیبانی‌شده، رفتار TLS، سازوکارهای احراز هویت، انتظارات گواهی، دامنه دسترسی اعتبارنامه و چرخش آن را مستند کند. TLS اجباری را ترجیح دهید و در صورت نبود STARTTLS، خطای گواهی، عدم تطابق نام هاست یا پروتکل پشتیبانی‌نشده، اتصال را قطع کنید (fail closed). اعتبارنامه‌ها را در یک سیستم مدیریت اسرار ذخیره کنید، هرگز در کد مرورگر، اپلیکیشن‌های موبایل، کد منبع، ایمیج‌ها، لاگها، URLها، analytics، تیکت‌ها یا promptها. اختیارات محیط عملیاتی، آزمایشی، tenant و مدیریتی را از هم جدا کنید. بررسی کنید آیا سطح رایگان اعتبارنامه‌ها، IPهای مبدأ، دامنهها، regionها یا اتصال‌های هم‌زمان را محدود میکند. RFC 8314 توصیه میکند پروتکل‌های متن آشکار به نفع TLS برای submission و دسترسی کنار گذاشته شوند، در حالی که RFC 4954 احراز هویت SMTP را یک افزونه پروتکل تعریف میکند، نه مجوزدهی در سطح محصول. اپلیکیشن همچنان باید پیش از باز کردن اتصال SMTP، مجوز رویداد کسب‌وکار، فرستنده، tenant، گیرنده، قالب و دسته پیام را بسنجد.
هویت فرستنده و مالکیت DNS را تأیید کنید
یک دامنه From متعلق به سازمان و یک فرایند مستند تأیید دامنه را الزامی کنید. SMTP MAIL FROM یا return path، From قابل‌مشاهده، دامنه d= و selector در DKIM، IPهای ارسال و نحوه رسیدگی به پاسخ‌ها را فهرست کنید. یک سیاست SPF معتبر منتشر کنید که مسیر واقعی را شامل شود، امضای DKIM را با کلیدهای محافظت‌شده پیکربندی کنید و همراستایی DMARC با دامنه From قابل‌مشاهده را ارزیابی کنید. تأیید ارائهدهنده شاهدی است بر اینکه یک بررسی راه‌اندازی موفق بوده است؛ رضایت گیرنده، مسیریابی درست در محیط عملیاتی، اعتبار یا رسیدن به صندوق ورودی را ثابت نمی‌کند. بدانید کدام رکوردهای DNS در اختیار ارائهدهنده است و کدام در zone معتبر سازمان باقی می‌ماند. مقادیر قبلی و مراحل بازگشت را نگه دارید. برای هویت محیط عملیاتی از دامنه From متعلق به ارائهدهنده پرهیز کنید، زیرا قابلیت انتقال را تضعیف میکند و ممکن است همراستایی DMARC یا تداوم برند را به فروشنده وابسته کند. پیام‌های خام دریافت‌شده را در همه جریان‌ها و محیطها آزمایش کنید.
نتایج مفید در سطح هر گیرنده را مطالبه کنید
سرویس باید میان پذیرش SMTP یا API، رد شدن برای هر گیرنده، تعویق موقت، شکست دائمی، برگشت بعدی، گزارش اسپم، لغو اشتراک و توقف ارسال از سوی ارائهدهنده تمایز بگذارد. بررسی کنید این نتایج در سطح رایگان چگونه تحویل، احراز هویت، تلاش مجدد، مرتب، نگهداری و خروجی گرفته می‌شوند. وب‌هوک‌ها را پیش از parse احراز هویت کنید، کنترل‌های تازگی و تکرار را اعمال کنید، رویدادها را پیش از تأیید دریافت بهطور پایدار ثبت کنید و آنها را با تلاش‌های متعلق به اپلیکیشن مرتبط کنید. دامنه گیرندگان پذیرفته‌شده و ردشده را جداگانه ذخیره کنید. خطاهای موقت واجد شرایط را با backoff محدود، jitter، سقف تعداد تلاش و محدودیت سن صف دوباره امتحان کنید. پس از شکست دائمی نشانی، گزارش اسپم یا لغو اشتراک، ارسال‌های خودکار را در دامنه مربوط متوقف کنید. داشبوردی بدون شواهد قابل‌خروجی، وابستگی عملیاتی ایجاد میکند. رویداد delivered ارائهدهنده اغلب پذیرش توسط سرور مقصد را توصیف میکند، نه پوشه نهایی صندوق ایمیل. بازشدن‌ها و کلیک‌ها ابزار سنجش تعامل‌اند و ممکن است توسط فناوری‌های حریم خصوصی مخدوش شوند.
محدودیت‌هایی را که بیرون از صفحه قیمت‌گذاری آمده‌اند بررسی کنید
صفحات قیمت‌گذاری به‌ندرت کل قرارداد عملیاتی را در بر دارند. مستندات فعلی را برای تعداد گیرندگان، اندازه پیام، اندازه پیوست، نرخ اتصال، نشست‌های هم‌زمان، نرخ API، دامنه‌های DNS، قالب‌ها، تلاش‌های وب‌هوک، نگهداری رویدادها، ظرفیت فهرست توقف ارسال و محدودیت‌های گیرنده در دوره آزمایشی بازبینی کنید. مشخص کنید آیا پشتیبانی، لاگ‌های ممیزی، IPهای اختصاصی، پردازش منطقه‌ای، مسیرهای ایمیل ورودی یا قابلیت‌های انطباق به پلن پولی نیاز دارند. حساب واقعی را آزمایش کنید، زیرا حساب‌های جدید یا آزمایشی ممکن است محدودیت‌های پایین‌تر یا بازبینی دستی داشته باشند. هر محدودیت را با نشانی منبع و تاریخ مشاهده ثبت کنید. دقیقاً روی حداکثر طراحی نکنید؛ برای تغییرات ارائهدهنده، تلاش‌های مجدد و بازیابی از رخداد حاشیه بگذارید. اگر اپلیکیشن ممکن است از طریق آرایه‌های گیرنده یا پیوست‌های ارائه‌شده توسط کاربر بی‌صدا از یک محدودیت عبور کند، ابتدا یک محدودیت سخت‌گیرانه‌تر در محصول اعمال کنید. محدودیت‌های مستندنشده یا مبهم را ریسک بدانید، نه ظرفیت نامحدود.
کنترل‌های حریم خصوصی، امنیت و مقابله با سوءاستفاده را ارزیابی کنید
محتوای پیام، داده‌های گیرنده، هدرها، payload رویدادها، نشانی‌های IP، لاگها، دسترسی پشتیبانی، پشتیبان‌ها و پیمانکاران فرعی را در regionهای مختلف نقشه‌برداری کنید. فراداده سفارشی را به حداقل برسانید و از قرار دادن اسرار یا داده‌های شخصی غیرضروری در برچسب‌ها و هدرها پرهیز کنید. رفتار نگهداری و حذف داده را برای حساب‌های رایگان، از جمله پس از لغو، تأیید کنید. جداسازی tenantها، دسترسی مبتنی بر نقش، MFA، تاریخچه ممیزی، چرخش اعتبارنامه، امضای وب‌هوک، مجوزدهی فهرست توقف ارسال و اطلاع‌رسانی رخداد را بررسی کنید. تزریق هدر، انتخاب دلخواه فرستنده، گیرندگان بیش از حد، سوءاستفاده از پیوست، جست‌وجوی رویداد میان tenantها و تکرار (replay) را آزمایش کنید. سطح‌های رایگان هدف رایج سوءاستفاده‌اند، بنابراین ارائه‌دهندگان ممکن است بازبینی خودکار یا تعلیق سریع اعمال کنند؛ محصول به یک صف پایدار و مسیر توقف امن نیاز دارد. هرگز با چرخاندن حسابها، دامنهها، اعتبارنامه‌ها یا IPها از کنترل‌های سوءاستفاده فرار نکنید. وضعیت رضایت و توقف ارسال را بیرون از ارائهدهنده نگه دارید تا تعلیق یا مهاجرت نتواند محافظت‌های گیرندگان را از بین ببرد.
پیش از ارسال، هزینه خروج را محاسبه کنید
فیلدهای مخصوص ارائهدهنده را پشت یک adapter واحد قرار دهید و مدل رویداد اپلیکیشن را مستقل نگه دارید. هاست و احراز هویت SMTP، payloadهای API، قالب‌ها، دامنه‌های فرستنده، return pathها، selectorهای DKIM، وب‌هوک‌ها، نام رویدادها، شناسه‌های پیام، برچسب‌ها، فهرست توقف ارسال، مسیرهای ایمیل ورودی و لاگها را فهرست کنید. خروجی فهرست توقف ارسال و تاریخچه عملیاتی را در قالب‌هایی که محصول بتواند اعتبارسنجی کند الزامی کنید. مهاجرت باید کلیدهای رویداد کسب‌وکار، تاریخچه تلاش‌ها، رضایت، ایمنی گیرندگان و مالکیت فرستنده را حفظ کند. یک انتقال دوم را با هویتهای کنترلشده آزمایش کنید، اما آن را به‌عنوان مسیر دور زدن خودکار برای خطاهای دائمی گیرنده یا سیاست پیکربندی نکنید. پنجره‌های تغییر DNS، چرخش اعتبارنامه، تبدیل قالب‌ها، پردازش دوگانه وب‌هوک، جلوگیری از تکرار و نگهداری رویدادهای قدیمی را برآورد کنید. ارزان‌ترین سطح رایگان ممکن است انتخاب اشتباهی باشد، وقتی خروج از آن مستلزم از دست دادن شواهد، تغییر هویت فرستنده یا بازسازی کنترل‌های ایمنی زیر فشار یک رخداد باشد.
پیش از محیط عملیاتی یک آزمون اثبات امتیازدهی‌شده اجرا کنید
یک ماتریس آزمون نماینده بسازید: مذاکره TLS و خطای گواهی، احراز هویت و چرخش، فرستندگان تأییدشده و غیرمجاز، محتوای ساده و multipart، Unicode، پیوستها، گیرندگان جزئی، پاسخ‌های گذرا و دائمی، timeout پس از DATA، برگشت‌ها، گزارش‌های اسپم، لغو اشتراک‌ها، تکرار وب‌هوک، رویدادهای خارج از ترتیب، اتمام سهمیه، انقضای پلن، خروجی گرفتن و بستن حساب. از گیرندگان کنترلشده اختصاصی استفاده کنید و هرگز از فهرست‌های واقعی مشتریان استفاده نکنید. امنیت، درستی، شواهد، ظرفیت، حریم خصوصی، پشتیبانی، قابلیت انتقال و هزینه کل را جداگانه امتیاز دهید. در صورت نبود تأیید TLS، اسرار مشترک بدون چرخش، افشای cross-tenant، نبود مدیریت شکست دائمی، در دسترس نبودن خروجی فهرست توقف ارسال، مصرف مازاد بی‌صدا یا نگهداری مبهم داده، راه‌اندازی را متوقف کنید. هرگاه پلن قیمت‌گذاری، مسیر ارسال، دامنه یا قرارداد ارائهدهنده تغییر کرد، آزمون اثبات را دوباره اجرا کنید. پلن رایگان فقط زمانی میتواند برای یک بار کاری محدود و کم‌ریسک مناسب باشد که کنترل‌ها و برنامه خروج آن به همان معیاری برسند که از یک وابستگی پولی انتظار می‌رود.
پلن‌های کنونی SendHQ را ارزیابی کنید
SendHQ پلن رایگان ندارد. فضاهای کاری جدید یک دوره آزمایشی یکپارچهسازی کنترلشده شامل 100 تحویل به ایمیل حساب یا یک نشانی AWS SES simulator دریافت میکنند. برای قیمت‌ها، سهمیه‌ها و قابلیت‌های پلن‌های پولی کنونی، صفحه قیمت‌گذاری SendHQ را ببینید.
پرسش‌های متداول
آیا سرویس SMTP رایگان برای محیط عملیاتی امن است؟
برای یک بار کاری محدود، فقط زمانی میتواند امن باشد که الزامات TLS، اعتبارنامههای با دسترسی محدود، احراز هویت فرستنده، ایمنی گیرنده، شواهد، حریم خصوصی، ظرفیت، پشتیبانی و مهاجرت همگی برآورده شوند.
تفاوت سطح رایگان و دوره آزمایشی چیست؟
سطح رایگان سهمیهای دائمی تحت شرایط فعلی است؛ دوره آزمایشی منقضی میشود یا اعتبار موقت مصرف میکند. قرارداد زنده و رفتار در سقف را بررسی کنید.
یک تیم کدام واحدها را باید مقایسه کند؟
پیامها، گیرندگان، بایتها، پیوستها، درخواستها، رویدادها، ایمیل ورودی، لاگها، نگهداری داده، دامنهها، کاربران، محیطها، پشتیبانی و رفتار مصرف مازاد را مقایسه کنید. هر واحد را در حجم میانگین، اوج، رشد، تلاش مجدد و رخداد محاسبه کنید.
آیا پذیرش در SMTP رایگان تحویل را ثابت میکند؟
خیر. پذیرش فقط یک مرحله از ارائهدهنده یا انتقال است. پذیرش توسط سرور گیرنده، برگشت بعدی، فیلترینگ صندوق ایمیل، رسیدن به صندوق ورودی و تعامل انسانی نتایج جداگانهای هستند.
آیا باید تنها فهرست توقف ارسال نزد ارائهدهنده باشد؟
خیر. وضعیت رضایت و ایمنی گیرنده را در اختیار محصول و همراه با شواهد و تاریخچه ممیزی نگه دارید تا مهاجرت یا تعلیق نتواند محافظت‌ها را از بین ببرد. این وضعیت را درست پیش از هر تلاش ارسال بعدی اعمال کنید.
اتمام سهمیه را چگونه باید مدیریت کرد؟
درخواستهای جدید را متوقف کنید یا آنها را بسته به زمان انقضا بهطور پایدار در صف بگذارید، پیش از رسیدن به سقف هشدار دهید و هرگز با چرخاندن حسابها یا هویتهای غیرمجاز از محدودیتها فرار نکنید.
آیا سرویسهای رایگان به SPF، DKIM و DMARC نیاز دارند؟
هویت ارسال همچنان به احراز هویت و همراستایی درست نیاز دارد. پلن رایگان استانداردهای گیرنده، مالکیت دامنه یا ایمنی DNS را تغییر نمیدهد.
آیا SendHQ پلن رایگان دارد؟
خیر. فضاهای کاری جدید یک دوره آزمایشی یکپارچهسازی کنترلشده شامل 100 تحویل به ایمیل حساب یا یک نشانی AWS SES simulator دریافت میکنند.
منابع
- قیمت‌گذاری Amazon Simple Email Service — Amazon Web Services
- قیمت‌گذاری Resend — Resend
- قیمت‌گذاری Mailgun — Mailgun
- RFC 8314: متن بدون رمزنگاری منسوخ تلقی میشود: استفاده از Transport Layer Security (TLS) برای ارسال و دسترسی به ایمیل — RFC Editor
- RFC 4954: افزونه سرویس SMTP برای احراز هویت — RFC Editor
- RFC 5321: پروتکل ساده انتقال ایمیل (SMTP) — RFC Editor
- RFC 7489: احراز هویت، گزارش‌دهی و انطباق پیام مبتنی بر دامنه (DMARC) — RFC Editor