اصطلاح · Amazon SES

Amazon SES چیست و چه تأثیری بر ایمیل اپلیکیشن دارد؟

Amazon Simple Email Service یا Amazon SES، زیرساخت AWS برای ارسال ایمیل از طریق API یا رابط SMTP و دریافت ایمیل است. برای یک تیم اپلیکیشن، انتخاب SES یعنی مالکیت چیزی بیش از فراخوانی ارسال: هویت‌های تأییدشده، پیکربندی منطقه‌ای، مجوزهای IAM، مدیریت سهمیه، ساخت پیام، دریافت رویداد، واکنش به برگشت و گزارش اسپم، توقف ارسال و پایش عملیاتی. پذیرش SES یعنی AWS تلاش می‌کند ایمیل را تحویل دهد؛ این امر رسیدن به صندوق ورودی را اثبات نمی‌کند. با SES به‌عنوان یک لایه انتقال و بازخورد درون یک سامانه بزرگ‌تر ایمیل اپلیکیشن رفتار کنید.

مرزهای این سرویس را بشناسید

SES ایمیل اپلیکیشن را از طریق APIهای AWS یا یک endpoint SMTP می‌پذیرد و می‌تواند یک پیام MIME را از فیلدهای ساخت‌یافته بسازد یا پیامی را بپذیرد که فرستنده ساخته است. این آن را به زیرساخت تبدیل می‌کند، نه یک گردش‌کار کامل محصول. اپلیکیشن شما همچنان تعیین می‌کند چه کسی می‌تواند ارسال کند، کدام tenant مالک یک دامنه است، قالب‌ها و داده‌های گیرندگان چگونه مدیریت می‌شوند، چه زمانی تلاش مجدد ایمن است و کاربران پس از موفق‌شدن درخواست چه می‌بینند. یک معماری مفید سه وضعیت را جدا می‌کند: اپلیکیشن یک job را پذیرفت، SES یک پیام را پذیرفت و یک سرور ایمیل دریافت‌کننده پیام را پذیرفت یا رد کرد. این وضعیت‌ها در زمان‌های متفاوت رخ می‌دهند و به شناسه‌های متفاوت نیاز دارند. شناسه تغییرناپذیر job خود را کنار شناسه پیام SES ذخیره کنید تا تلاش‌های مجدد وب‌هوک و بررسی‌های پشتیبانی بدون حدس‌زدن بر پایه موضوع یا داده گیرنده قابل تطبیق باشند.

پیش از ارسال، هویت‌ها را تأیید کنید

AWS هویت تأییدشده را دامنه یا نشانی ایمیلی تعریف می‌کند که با SES استفاده می‌شود. پیش از ارسال، هویت From، Source، Sender یا Return-Path باید قوانین تأیید SES را برآورده کند. تأیید دامنه معمولاً انتخاب ماندگارتری برای اپلیکیشن است، چون می‌تواند نشانی‌های زیر آن دامنه را مجاز کند و از احراز هویت در سطح دامنه پشتیبانی می‌کند. تأیید، تیکی یک‌باره نیست که بتوان آن را در همه استقرارها کپی کرد. وضعیت هویت و راه‌اندازی Easy DKIM منطقه‌ای هستند، بنابراین دامنه‌ای که در یک AWS Region تأیید شده، به‌طور خودکار در Region دیگر آماده نیست. فرایند شروع کار را به‌صورت یک ماشین حالت بسازید: هویت را درخواست کنید، رکوردهای دقیق DNS را نمایش دهید، وضعیت مرجع ارائه‌دهنده را poll کنید و فقط پس از اعلام موفقیت در Region انتخاب‌شده، ارسال در محیط عملیاتی را مجاز کنید. وقتی DNS با فرستنده دیگری مشترک است، سیاست SPF و DMARC موجود را دست‌نخورده نگه دارید و هرگز برای راحتی یک رکورد SPF دوم نسازید.

Region را بخشی از پیکربندی ایمیل کنید

منابع و محدودیت‌های عملیاتی SES منطقه‌ای هستند. هویت‌های تأییدشده، وضعیت sandbox، سهمیه روزانه، حداکثر نرخ ارسال، راه‌اندازی Easy DKIM، پیکربندی فهرست توقف ارسال و مقصدهای بازخورد ممکن است بین Regionها متفاوت باشند. اعتبارنامه‌ای که در AWS معتبر است، هویت را به endpoint دیگری از SES قابل انتقال نمی‌کند. Region را در پیکربندی کنار حساب ارائه‌دهنده و هویت قرار دهید، نه اینکه آن را در یک مقدار پیش‌فرض عمومی محیط پنهان کنید. برای failover، Region ثانویه را پیش از وقوع رخداد آماده کنید: هویت را تأیید کنید، رکوردهای DKIM آن را منتشر کنید، دسترسی محیط عملیاتی و سهمیه مناسب بگیرید، مقصدهای رویداد را پیکربندی کنید، شناسه‌های پیام و پردازش وب‌هوک را آزمایش کنید و مطمئن شوید رفتار فهرست توقف ارسال را می‌شناسید. در غیر این صورت، تغییر صرف endpoint در زمان قطعی ممکن است یک رخداد را با خطاهای تأیید، throttling یا بازخوردهای گم‌شده جایگزین کند.

بین API و SMTP آگاهانه انتخاب کنید

AWS از ارسال در محیط عملیاتی از طریق SES API و رابط SMTP پشتیبانی می‌کند. API برای اپلیکیشن‌هایی مناسب است که از قبل از احراز هویت و SDKهای AWS استفاده می‌کنند و عملیات ساختاریافته و پیام خام (raw) را در اختیار می‌گذارد. SMTP برای نرم‌افزاری مناسب است که از قبل با SMTP کار می‌کند، اما اعتبارنامه‌های SMTP در SES با کلیدهای دسترسی معمولی AWS متفاوت‌اند و همچنان منطقه‌ای هستند. این انتخاب نیاز به صف، idempotency، مدیریت timeout یا قوانین تلاش مجدد بی‌خطر را از بین نمی‌برد. اگر اتصال پیش از دریافت پاسخ توسط اپلیکیشن قطع شود، ممکن است ارائه‌دهنده پیام را پذیرفته باشد. از تلاش مجدد کورکورانه برای درخواستی که کاربر می‌بیند با یک شناسه جدید اپلیکیشن پرهیز کنید. یک بار در صف قرار دهید، پاسخ ارائه‌دهنده را در صورت وجود نگه دارید و workerها را طوری بسازید که یک job پایدار را دوباره امتحان کنند. فقط زمانی از عملیات پیام خام استفاده کنید که به کنترل دقیق MIME نیاز دارید و پیش از تحویل پیام به SES، هدرها و طول خطوط را اعتبارسنجی کنید.

sandbox و سهمیه‌ها را محدودیت‌های زمان اجرا بدانید

ترکیب‌های حساب-Region جدید SES می‌توانند در sandbox باشند. AWS در حال حاضر محدودیت sandbox را 200 تحویل به گیرنده در هر 24 ساعت و یک ایمیل در ثانیه مستند می‌کند؛ ارسال نیز جز برای mailbox simulator به گیرندگان تأییدشده محدود است. سهمیه‌های محیط عملیاتی بر حسب حساب، Region و مورد استفاده تأییدشده متفاوت‌اند. سهمیه‌ها گیرندگان را می‌شمارند نه درخواست‌های API؛ بنابراین یک درخواست برای ده گیرنده، ده واحد مصرف می‌کند. سهمیه واقعی هر Region فعال را بخوانید و backpressure را هم بر پایه سهمیه روزانه گردشی و هم نرخ ارسال طراحی کنید. throttle ارائه‌دهنده باید یک job صف‌شده را به تأخیر بیندازد، نه اینکه ارسال‌های تکراری ایجاد کند یا به‌شکل موفقیت توضیح‌نداده‌شده ظاهر شود. پیش از راه‌اندازی، دسترسی محیط عملیاتی و محدودیت‌های واقع‌گرایانه را درخواست کنید، سپس با گیرندگان کنترل‌شده load-test اجرا کنید. sandbox را free tier توصیف نکنید و فرض نکنید تأیید در یک Region برای region دیگر نیز اعمال می‌شود.

وضعیت تحویل را از رویدادها بسازید

یک عملیات ارسال موفق در SES یعنی درخواست پذیرفته شده و SES برای تحویل تلاش خواهد کرد. این به معنای باز شدن پیام توسط گیرنده، دیده شدن آن در صندوق ورودی یا حتی پذیرش آن توسط سرور گیرنده نیست. انتشار رویداد در SES می‌تواند ارسال‌ها، تحویل‌ها، برگشت‌ها، گزارش‌های اسپم، رد شدن‌ها، خطاهای رندر، تأخیرها، اشتراک‌ها، باز شدن‌ها و کلیک‌ها را از طریق مقصدهای پیکربندی‌شده AWS گزارش کند. تمایز مهم عملیاتی این است که رویداد delivery نشان‌دهنده پذیرش توسط سرور ایمیل گیرنده است، در حالی که رویدادهای bounce و complaint به واکنش مبتنی بر سیاست نیاز دارند. رویدادها را به‌صورت idempotent دریافت کنید، چون سیستم‌های تحویل ممکن است اعلان‌ها را دوباره ارسال کنند. شناسه پیام ارائه‌دهنده و زمان رویداد را نگه دارید، payloadهای نادرست وب‌هوک را رد کنید و تا حد امکان تغییر وضعیت‌ها را یک‌طرفه (monotonic) نگه دارید. مشاهده باز شدن و کلیک، سیگنال‌های اختیاری تعامل با محدودیت‌های حریم خصوصی و کلاینت هستند؛ نباید تعریف رخ دادن تحویل در لایه انتقال را تغییر دهند.

برگشت ایمیل، گزارش اسپم و فهرست توقف ارسال را مدیریت کنید

قرار دادن گیرندگان نامعتبر یا ناراضی شناخته‌شده در فهرست توقف ارسال، هم از کاربران و هم از حساب ارسال محافظت می‌کند. AWS رفتار توقف ارسال را در سطح سراسری، حساب، configuration set و به‌تازگی در سطح tenant ارائه می‌دهد، اما دامنه دقیق آن به پیکربندی و Region بستگی دارد. اپلیکیشن شما همچنان به یک سیاست روشن برای گیرندگان نیاز دارد. نشانی‌هایی که برگشت دائمی خورده‌اند نباید دیگر تلاش‌های مجدد روزمره دریافت کنند، گزارش اسپم باید بلافاصله به توقف ارسال منجر شود و حذف از فهرست باید نیازمند شواهدی باشد که نشانی معتبر است و گیرنده انتظار آن ایمیل را دارد. در یک محصول چند-tenant، پیش از پذیرش مشتریان تصمیم بگیرید که فهرست توقف ارسال در سطح کل حساب باشد یا جداگانه، چون فهرست مشترک ممکن است باعث شود نتیجه یک tenant بر ارسال tenant دیگر اثر بگذارد. نشانی‌های خام را از analytics و لاگ‌های عمومی دور نگه دارید. سیستم‌های عملیاتی ممکن است برای اعمال توقف ارسال به نشانی نیاز داشته باشند، اما داشبوردها و آزمایش‌ها باید از معیارهای تجمیعی یا مستعار استفاده کنند.

حداقل دسترسی را اعمال کنید و tenantها را جدا کنید

سیاست‌های IAM می‌توانند محدود کنند که یک principal کدام عملیات SES را فراخوانی کند و برای عملیات ارسال، نشانی‌های From، گیرنده یا Return-Path را محدود کنند. سیاست‌های sending authorization مسئله دیگری را حل می‌کنند: به مالک یک هویت اجازه می‌دهند استفاده از هویت تأییدشده را به دیگری واگذار کند و به‌طور مستقل قابل لغو هستند. برای یک اپلیکیشن واحد، principalی را ترجیح دهید که فقط عملیات ارسال و پایشی را دارد که بار کاری واقعاً نیاز دارد. هرگز اعتبارنامه‌های AWS را به مرورگر وب ندهید. یک محصول ایمیل چند-tenant به مجوزدهی در لایه اپلیکیشن هم نیاز دارد، چون یک حساب مشترک SES به‌طور خودکار مدل فضای کاری شما را نمی‌شناسد. پیش از ارسال به SES بررسی کنید که tenant احرازهویت‌شده مالک یک دامنه From تأییدشده است، کلیدهای API و سوابق پیام را به همان tenant محدود کنید و کاری کنید که شناسه‌های متعلق به tenant دیگر هیچ داده‌ای برنگردانند. IAM ارائه‌دهنده و مجوزدهی اپلیکیشن کنترل‌هایی مکمل هستند، نه جایگزین یکدیگر.

از یک چک‌لیست آمادگی محیط عملیاتی استفاده کنید

پیش از راه‌اندازی، حساب AWS، Region، ARN هویت، وضعیت تأیید، وضعیت DKIM، وضعیت sandbox، سهمیه روزانه، حداکثر نرخ ارسال، مقصد رویداد، دامنه فهرست توقف ارسال و مالک اعتبارنامه را ثبت کنید. یک تحویل عادی، یک برگشت از طریق mailbox simulator، یک آزمون گزارش اسپم در صورت پشتیبانی، یک پاسخ throttle، یک تلاش مجدد رویداد و یک timeout ارائه‌دهنده پس از ارسال را امتحان کنید. تأیید کنید که workerهای صف یک job پایدار را تکرار نمی‌کنند، رویداد delivery پیام درست را به‌روز می‌کند و یک برگشت دائمی از ارسال روزمره بعدی جلوگیری می‌کند. برای درخواست‌های ردشده، throttling، خطاهای دریافت رویداد، تغییرات برگشت ایمیل و گزارش اسپم و فضای باقی‌مانده سهمیه هشدار تنظیم کنید. هر زمان Region، دامنه، نوع tenant یا کلاس پیام جدیدی اضافه شد، پیکربندی را بازبینی کنید. این چک‌لیست SES را از یک وابستگی پنهان به یک زیرسیستم صریح با مالک مشخص و حالت‌های خطای قابل‌مشاهده تبدیل می‌کند.

جایگاه SendHQ را مشخص کنید

تیم‌ها وقتی کنترل بومی AWS را می‌خواهند و آماده ساخت لایه اپلیکیشن پیرامونی هستند، می‌توانند مستقیماً با SES یکپارچه شوند. SendHQ یک قرارداد ایمیل محدودتر در سطح فضای کاری ارائه می‌دهد که شامل دامنه‌های ارسال تأییدشده، کلیدهای API با دسترسی محدود، ارسال تکی و دسته‌ای، صندوق‌های ورودی برای ایمیل ورودی، دسترسی به رویدادهای تحویل و گردش‌کارهای فهرست توقف ارسال است. API عمومی آن الزام می‌کند که دامنه From متعلق به فضای کاری و تأییدشده باشد و پیام‌های پذیرفته‌شده را برای بررسی بعدی ثبت می‌کند. این لایه محصول جایگزین قوانین هویت، سهمیه، اعتبار یا فیلترینگ سمت گیرنده در SES نمی‌شود. دو لایه را جداگانه ارزیابی کنید: ارائه‌دهنده ایمیل را منتقل می‌کند و درباره آن گزارش می‌دهد، در حالی که لایه اپلیکیشن مالکیت tenant را اعمال می‌کند، منابع پایدار ارائه می‌دهد و وضعیت عملیاتی را نمایش می‌دهد. نه SES مستقیم و نه SendHQ رسیدن به صندوق ورودی را تضمین نمی‌کنند؛ پس هر دو را بر اساس کنترل‌ها، مشاهده‌پذیری، مالکیت و تناسب با گردش‌کار اپلیکیشن خود بسنجید.

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

Amazon SES یک API ایمیل است یا یک سرور SMTP؟

هم یک API مبتنی بر HTTPS و هم یک رابط SMTP ارائه می‌دهد. انتخاب را بر اساس نیازهای اپلیکیشن در احراز هویت و ساخت پیام انجام دهید و صف‌ها، شناسه‌های پایدار job، پردازش رویدادها و فهرست توقف ارسال را بیرون از فراخوانی انتقال نگه دارید.

آیا برای استفاده از Amazon SES باید دامنه را تأیید کنم؟

باید هر هویتی را که به‌عنوان نشانی From، Source، Sender یا Return-Path استفاده می‌شود تأیید کنید. هویت نشانی ایمیل برای موارد محدود کارساز است، اما تأیید دامنه برای نشانی‌هایی که اپلیکیشن کنترل می‌کند و برای DKIM عموماً عملی‌تر است.

آیا پاسخ موفق SES یعنی ایمیل تحویل داده شده است؟

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

آیا سهمیه‌های Amazon SES بین Regionها مشترک است؟

خیر. AWS سهمیه‌های ارسال، وضعیت sandbox، هویت‌های تأییدشده، راه‌اندازی DKIM و پیکربندی فهرست توقف ارسال را منطقه‌ای اعلام می‌کند. هر Region را که ممکن است ترافیک محیط عملیاتی دریافت کند از پیش آماده و آزمایش کنید، نه اینکه در میانه رخداد endpoint را عوض کنید.

اپلیکیشن پس از ارسال از طریق SES چه چیزی را باید ذخیره کند؟

یک شناسه پایدار job در اپلیکیشن، شناسه پیام SES در صورت پذیرش، ارائه‌دهنده و Region، وضعیت فعلی، زمان‌ها و رویدادهای تحویل نرمال‌شده را ذخیره کنید. محتوای پیام و داده‌های گیرنده را از لاگ‌ها و analytics گسترده دور نگه دارید.

تیم چه زمانی باید به‌جای SES مستقیم از SendHQ استفاده کند؟

وقتی تیم می‌خواهد یکپارچه‌سازی با AWS و همه کنترل‌های پیرامونی را خودش در اختیار داشته باشد، از SES مستقیم استفاده کنید. وقتی کلیدهای API در سطح فضای کاری، بررسی مالکیت دامنه، صندوق‌های ورودی، منابع پیام، رویدادهای تحویل و گردش‌کارهای فهرست توقف ارسال برای اپلیکیشن شما اجزای پایه مفیدی هستند، SendHQ را در نظر بگیرید.

منابع

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

هزینه Amazon SES: مدل قیمت‌گذاری برای تیم‌های محصولهزینه Amazon SES را بر اساس گیرندگان، حجم داده، پلن‌های قیمت‌گذاری، IP اختصاصی، زیرساخت رویدادها، سهمیه‌ها و لایه مهندسی پیرامون تحویل مدل‌سازی کنید.