Комментарии 13
Давно работаю с Mandrill, удобный сервис и API, буквально утром настраивал один проект. До этого поправлял несколько других. Хотелось бы отметить то, о чём забывают многие при передаче файлов: при кодировании в base64 размер файла увеличивается примерно на треть, после чего возникают ошибки отправки… У них вроде как помечено, но не уверен.
Не так давно создавали аналогичный сервис, правда, для внутреннего использования компании. Как ориентир, использовали готовые почтовые сервисы, аналогичные рассматриваемому. У нас был список из 14 сервисов. Наиболее удобным и совершенным выглядит в этом списке Mailgun. Mandrill занимает только вторую строчку — тоже весьма удобен и совершенен, но до лидера не дотягивает.
Недостатки всех без исключения — достаточно слабая поддержка в работе с атачментами, отсутствие или слабая поддержка почтовых конверторов (хотя не исключаю, что они просто надежно спрятаны в коммерческих версиях), полное игнорирование алгоритмов шифрования писем типа PGP/GPG (это очень востребованный инструментарий, но его почему-то неактивно внедряют), негибкая авторизация — сомнительная возможность имплементировать свой алгоритм авторизации.
Недостатки всех без исключения — достаточно слабая поддержка в работе с атачментами, отсутствие или слабая поддержка почтовых конверторов (хотя не исключаю, что они просто надежно спрятаны в коммерческих версиях), полное игнорирование алгоритмов шифрования писем типа PGP/GPG (это очень востребованный инструментарий, но его почему-то неактивно внедряют), негибкая авторизация — сомнительная возможность имплементировать свой алгоритм авторизации.
Хорошее примечание. Когда есть из чего выбрать это здорово.
Спасибо за наводку на Mailgun.
В области защиты/подписи электронных писем S/MIME несколько более распространён, нежели PGP.
А какие «свои» алгоритмы авторизации хочется внедрять? Ведь лучше использовать стандартные проверенные, а не свои самопальные.
В области защиты/подписи электронных писем S/MIME несколько более распространён, нежели PGP.
А какие «свои» алгоритмы авторизации хочется внедрять? Ведь лучше использовать стандартные проверенные, а не свои самопальные.
Ну да, насчет «самопальный» — это несколько огульно. Речь, скорее, об альтернативах существующей токенной авторизации, когда онлайн или через АПИ получаешь рабочий токен и можешь с ним работать. Если процесс авторизации не прямой (к примеру, у нас централизованный сервис авторизации для всех продуктов компании), то это не очень удобно (я сейчас не буду вдаваться в подробности, но сделать быстро и удобно не получилось). Второе ограничение — используя один аккаунт на сервисе, используем токен(ы) для всего акка, а хотелось бы разграничения ролей при доступе к одному акку, что в обозреваемых сервисах не было доступно. Весьма заманчивой также выглядела бы реализация OAuth2 в сервисах (уверен, на сегодняшний день она есть у кого-то, но на момент обзора год назад этого не было ни у кого из рассматриваемых).
Все круто, сервис действительно удобный. Не понятно только зачем документацию переводить. Хоть тег поставьте, что ли.
Наиболее подходящие теги вроде бы добавил. Еще есть еще предложения у вас?
Зачем переводить документацию? Отвечу. На удивление статей в «рунете» по mandrill не было (а может просто не нашел). У меня изначально были вопросы по использованию шаблонов (разница между динамическим контентом и заменяемыми метками). Некоторые называют работу с шаблонами — эта работа с динамическими блоками, а некоторые на оборот. Поэтому возникла идея написать статью для внесения ясности. Возможно кому ни будь поможет сэкономить время.
Зачем переводить документацию? Отвечу. На удивление статей в «рунете» по mandrill не было (а может просто не нашел). У меня изначально были вопросы по использованию шаблонов (разница между динамическим контентом и заменяемыми метками). Некоторые называют работу с шаблонами — эта работа с динамическими блоками, а некоторые на оборот. Поэтому возникла идея написать статью для внесения ясности. Возможно кому ни будь поможет сэкономить время.
Сервис действительно замечательный, однако есть одно важное «но», которое перечеркивает все его достоинства для нашего проекта — письма доходят медленно.
Отправляем через smtp. В логах API письмо появляется сразу, а в логах Outbound оно может появиться только через несколько минут, а реально идти может вплоть до получаса.
На stackoverflow есть подобный вопрос, но ответа на него до сих пор нету.
Отправляем через smtp. В логах API письмо появляется сразу, а в логах Outbound оно может появиться только через несколько минут, а реально идти может вплоть до получаса.
На stackoverflow есть подобный вопрос, но ответа на него до сих пор нету.
Так в этом же вся суть асинхронной отправки
Т.е. для отправки срочных писем он не годится?
Тогда подскажите пожалуйста сервис для надежной отправки почты, который бы доставлял письма быстро и при этом хорошо работал со статусами писем, а также — спамом и т.д.
Тогда подскажите пожалуйста сервис для надежной отправки почты, который бы доставлял письма быстро и при этом хорошо работал со статусами писем, а также — спамом и т.д.
Уверен, у него есть нотификаторы, стандартный перечень которых извещает о получении новой почты, изменении папок и т.д. Другое дело, что это часть АПИ, с которым обычно работает собственное приложение или адаптированный софт. Внешние готовые решения типа Outbound могут иметь таковую… а могут не иметь.
На то это и не почтовый сервер, а почтовый сервис, который ориентирован на использование своего АПИ.
К примеру, в своем продукте у нас был нотификатор, который немедленно извещал клиент о получении нового письма (если он подписан на получение извещений). Соответственно, клиент либо показывал сообщение, что письмо пришло — пользователь должен обновить окно, либо клиент автоматически посылает запрос на получение новых писем (обычное поведение онлайн-клиентов). В любом случае, этот процесс не происходит автоматом.
В твоем случае пауза перед получением новой порции писем вызвана тем, что обычно клиенты имею функцтонал опроса родительского сервиса на предмет поддержки сессии/токена, получения новой почты и прочего сопутствующего функционала. Вот и получается, что если опрос стоит на полчаса, то реально пауза может быть от 0 до 30 минут, смотря в какой момент задержки таймера прийдет письмо. Аналогия — старые версии MS Outlook, у которых по дефолту стояло 2 минуты для поллинга — новые письма были доступны либо после рефреша, либо по таймеру.
На то это и не почтовый сервер, а почтовый сервис, который ориентирован на использование своего АПИ.
К примеру, в своем продукте у нас был нотификатор, который немедленно извещал клиент о получении нового письма (если он подписан на получение извещений). Соответственно, клиент либо показывал сообщение, что письмо пришло — пользователь должен обновить окно, либо клиент автоматически посылает запрос на получение новых писем (обычное поведение онлайн-клиентов). В любом случае, этот процесс не происходит автоматом.
В твоем случае пауза перед получением новой порции писем вызвана тем, что обычно клиенты имею функцтонал опроса родительского сервиса на предмет поддержки сессии/токена, получения новой почты и прочего сопутствующего функционала. Вот и получается, что если опрос стоит на полчаса, то реально пауза может быть от 0 до 30 минут, смотря в какой момент задержки таймера прийдет письмо. Аналогия — старые версии MS Outlook, у которых по дефолту стояло 2 минуты для поллинга — новые письма были доступны либо после рефреша, либо по таймеру.
Всё, акки MailChimp и Mandrill сливаются в один и с 16-03-2016 все услуги MailChimp team становятся платными. Минимальный платёж – 20 бакинкских.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Работа с API почтового сервиса Mandrill