Мне кажется что сервис по отправке email-ов это уж совсем бредово, если есть сервер на котором крутятся сайты то почему бы с него не отправлять email-ы
Вся их инфраструктура которую некоторые могут считать «лишней», реально выстреливает при больших масштабах проектов, когда вам надо не просто отправлять почту. а гарантированно ее отправлять, и массово, и без дубликатов… В общем если разрабатывали подобные системы, сами понимаете что вопросы гарантированной отправки\доставки всерьез встают на крупных объемах. И вот чтобы не городить «свои велосипеды», можно пользоваться сервисом через API.
Вас наверное удивляет и Azure Queue Service — типа что там делать то, очередь сообщений. Вот когда будет остро стоять (особенно — в денежном эквиваленте) вопрос «недоставки» хотя бы одного сообщения — вот тогда будете готовы платить за гарантированность в таких вроде как простых и «ненужных» решениях.
> Ну ну. Я это называю воинствующая безграмотность.
Полностью аналогично. Я всё понял — типа ура-ура, всё круто, но суть от меня ускользнула. MQ это MQ, а электропочта — это электропочта. Мы тут начали какое-то сравнения слона и дождя.
> Удачи вам в ваших хостингах…
Да спасибо, у нас всё вполне удачно :))
> Если вы такой умный и быстрый — почему еще не Билл Гейтс?
Не такой наглый и вороватый? Я вот тоже себя всё спрашиваю. Надо сходить к психотерапевту.
Явасумоляю, что значит гарантированно? почти любой неглючный сервер доставляет почту гарантированно за прошедшие годы эволюции почтовых программ.
А вот за короткое время, с большим числом IP, с «пробоем» greylist, с поддержкой специалистов берущих на себя взаимодействие со списками антиспама и вообще решающих все непредвиденные проблемы — это да, это востребовано.
Это значит, что при поломке любого звена в любой момент времени система не потеряет ни одного «сообщения», а после починки звена — обработает все необработанные данные или откатит соответствующие бизнес-транзакции, которые невозможно обработать…
И дело тут не в неглючных эволюционировавших почтовых сервисах, а в механизмах межсистемного взаимодействия (или неочевидно что речь не про postfix и sendmail а про свои системы которые должны заниматься коммуникацией с другими компонентами и делать это надежно).
Это кастомные очереди сообщений\уведомлений (это не почта, это сообщение от одного сервиса другому о произошедших изменениях), которые после постановки в некую очередь будут гарантированно доставлены до listener'а или обладают достаточной информацией для отката действия их вызвавшего.
Просто вместо утреннего выпиливания лобзиком своего велосипеда предлагается бизнес-решение с определенным SLA. И многие готовы платить за это (как и за поддержку\развитие и уведичение количества 9 в гарантированном аптайме сервиса.).
А где вы увидели «ткатит соответствующие бизнес-транзакции, которые невозможно обработать» у амазона, по мойму у них по сути смтпшник дан и все.
А какая по вашему система стоит у амазона?
Вот про вашу очередь я не понял, вы вообще про амазон с его SES или про что то у себя в голове? Как можно говорить о гарантированной доставке когда у клиента например кончилось место на емейле? Я вот пока не смог этого побороть.
Основная проблема почты не в SLA, а в борьбе со спамом. Некоторые уроды такие методы борьбы со спамом используют, что их вешать надо.
Это я пояснял что я вкладываю в слово «гарантированно». И сообщения это не только почта. Если вы внимательно перечитаете оба поста, то большинство заданных вопросов отпадет.
Я не про что-то у себя в голове, я про решения которые становятся ключевыми при построении распределенных систем, и которые проще отдать на такой вот своеобразный service-аутсорсинг.
И еще раз — тут речь уже не о почте, а об общем взгляде на вопрос — «кому и зачем нужны такие, на первый взгляд примитивные, сервисы»
Обычно получается наоборот — стоимость разработки надежной системы с определенными гарантиями, стоимость железа и поддержки — несравнима с услугой типа 10 000 писем за 1$ (цена амазона да и конкуренции пока еще нету).
Посчитайте сколько вы можете сэкономить на зп разработчикам ( они могут решать другие полезные задачи). Даже на московскую месячную ЗП в 3k$ можно отправлять 3 миллиарда писем. Поверьте это такие копейки по сравнению с трудозатратами по созданию и поддержке подобных решений.
Тем более (если вы не спаммер) если у вас так много клиентов, для которых надо рассылать по миллиарду писем в месяц — у вас есть на это деньги.
Даже у фэйсбука нету миллиарда зарегистрированных пользователей, а в мире миллиардов всего 6-7… И кому вы собрались слать триллион писем?
Там будут проблемы если они просто залогинятся все. ВЫ же понимаете что активных там на порядок меньше.
И таки вам жалко 2000$ чтобы 500 млн пользователей отправили по 4 письма каждый? да вы поймите у вас сервера это обрабатывающие сожрут электричества на сравнимую сумму…
amazon ses позволяет только отправлять, но может делать это в очень больших количествах и быстро. в каком-то смысле данный сервис можно сравнить с публичным smtp сервером. а гугл не позволяет отправлять более 500 писем с одного аккаунта в день.
Удивляет столь поздний выход на рынок подобных услуг, что в общем-то объясняет невысокую цену.
centur +1 (не могу плюсануть, кармы нет)
Тут много «умных молодых ребят», которые знают все тонкости email маркетинга, начиная от серверной инфраструктуры и заканчивая
особенностями отображения входящих писем различными ISP, так что всех не переспоришь…
Не совсем по теме, но один из моих клиентов разместив сайты на Amazon EC был вынужден пользоваться услугами стороннего мэйл-сервиса, потому что Амазоновские IP постоянно оказывались в блэк-листах. Поэтому такой сервис вполне логичен.
Я тут получил уведомление сегодня: You have limit on the volume of email you were able to send out of SMTP port. Странно, у меня там даже почтовика нет (только штатный сендмейл, наверное, на ubuntu server).
VPN не пользуетесь? мне они такое же присылали и даже сендейла нет — отписал, что это почтовые программы через VPN на мои сервера обращаются — включили анлим.
Вот что ответили на форуме — «If you are not running an externally accessible email server on your instance, you may safely ignore this email. It is possible that this email notification was triggered by external activity such as a spurious port scan.
Security groups block all incoming traffic by default, except that which is explicitly allowed by rules in the group. I would suggest reviewing your security group settings and ensuring that you are not allowing any access on any port unnecessarily. You should also be aware that security groups only restrict inbound internet traffic, outbound traffic is unrestricted.
Amazon анонсирует сервис для отправки электронной почты (Amazon SES)